AI возвращает нам право владеть своим софтом

SaaS стал одной из самых успешных моделей в истории программного обеспечения по очень простой причине: он сделал сложные вещи удобными.

Не нужно устанавливать сервер. Не нужно обновлять приложение. Не нужно разбираться с резервными копиями, SSL, совместимостью библиотек и deployment. Открываешь браузер, регистрируешься и работаешь.

Пользователи совершенно рационально обменяли часть контроля на огромное снижение сложности.

Но у этой сделки всегда была вторая сторона.

Вместе с обязанностью обслуживать систему мы часто отдавали поставщику саму систему.

Нельзя получить исходный код. Нельзя запустить продукт у себя. Экспорт данных ограничен. Возможности интеграции определяет API. Если нужной функции нет в продукте и vendor не собирается её делать, пользователь практически ничего не может изменить.

Долгое время это казалось неизбежной ценой удобства.

Coding agents начинают менять саму формулу обмена.

Старый выбор: свобода или удобство

Условно существовали два мира.

В первом у компании был собственный проект:

source code
server
runtime
database
configuration
deployment

Можно было изменить почти всё. Можно было перенести систему на другой сервер. Можно было нанять другого разработчика. Можно было сделать fork.

Но за свободу приходилось платить экспертизой и постоянным обслуживанием.

Во втором мире был SaaS:

login
browser
subscription

Всё остальное решал поставщик.

Для большинства небольших компаний второй вариант был намного выгоднее. Свобода исходного кода имеет мало практической ценности, если для любого изменения сначала нужно найти дорогого специалиста, который несколько дней будет разбираться в проекте.

Именно поэтому аргумент «зато open source» далеко не всегда побеждал удобный облачный продукт.

AI меняет цену свободы

Coding agent не делает инфраструктуру несуществующей. Сервер всё ещё нужно где-то запускать. Базу нужно хранить. Резервные копии нужны. Ошибки происходят.

Но резко уменьшается стоимость взаимодействия со всей этой технической реальностью.

Показательный сценарий последних месяцев: работа с MODX, Laravel и Ruby всё чаще сводится к двум первым действиям:

1. запустить проект в Docker;
2. объяснить AI, что требуется сделать.

Дальше агент исследует репозиторий, находит нужный код, читает конфигурацию, выполняет команды, меняет несколько слоёв приложения и проверяет результат.

То, ради чего раньше выбирали закрытую платформу — «я не хочу разбираться в коде», — больше не обязательно требует отсутствия доступа к коду.

Пользователь по-прежнему может в нём не разбираться.

Просто теперь между пользователем и кодом стоит AI.

Свобода становится практически используемой

Это важный сдвиг.

Open source всегда давал теоретическую возможность изменить программу. Но возможность полезна только тогда, когда кто-то способен ей воспользоваться.

Если изменение требует неделю работы редкого специалиста, право на изменение существует юридически и технически, но экономически почти недоступно.

Coding agents уменьшают эту дистанцию.

Можно сформулировать так:

AI повышает ценность доступа к исходному коду, потому что резко увеличивает число изменений, которые реально можно сделать с этим доступом.

То же относится к данным, runtime и инфраструктуре.

Полный SQL dump раньше мог быть страховкой «на случай переезда». Теперь это ещё и материал, который агент способен исследовать, мигрировать и преобразовать. Dockerfile — не просто DevOps-артефакт, а способ дать агенту воспроизводимую среду. Старый репозиторий — не архив, а исполняемая модель системы.

bizneshelper.ru: несколько дней вместо реставрации legacy

Недавняя миграция bizneshelper.ru хорошо показывает, как это выглядит практически.

5 сентября 2026 года была создана задача перенести старый Ruby-сайт на новую систему. Legacy-приложение запустили локально и начали использовать как источник данных и reference.

Внутри обнаружилось много накопленной сложности: специализированные таблицы для похожих видов контента, разные представления, отдельный CSS, исторический HTML, Rails Asset Pipeline, неработающие OAuth-сценарии, старый Sunspot/Solr и другие следы многолетнего развития.

Классический путь мог бы заключаться в аккуратной реставрации существующей системы или в длительном проекте миграции с воспроизведением всех её возможностей.

Вместо этого полезные данные отделили от архитектуры, содержательные сущности свели к более простой универсальной модели, а старый сайт оставили средством сверки.

К 10 сентября новая версия была фактически собрана. В журнале проекта основная техническая переделка оценена примерно в 3–4 дня, причём значительная часть времени ушла именно на обход особенностей legacy, а не на создание новой функциональности.

Эта цифра интересна не как обещание скорости. Другой проект может занять месяц.

Интересен сам характер работы: наличие старого кода не привязало проект навсегда к старой архитектуре. Полный доступ к системе позволил агенту и специалисту разобрать её на полезные данные, необходимые функции и исторический мусор, а затем собрать более подходящую реализацию.

С закрытым SaaS такая операция может быть невозможна в принципе.

Новый парадокс SaaS

SaaS-платформы сегодня активно добавляют AI. Это естественный путь: пользователь формулирует желание, система выполняет больше работы сама.

Но здесь возникает парадокс.

Чем способнее становится AI, тем заметнее искусственные ограничения закрытой платформы.

Допустим, агент технически способен написать нужную функцию. Но исходного кода нет. Тогда он может действовать только через API и extension points, которые предусмотрел vendor.

человек → AI → API платформы → разрешённое изменение

В собственном проекте цепочка другая:

человек → AI → software

Если нужно изменить базу — меняется база. Нужен новый service — добавляется service. Понадобился Varnish — появляется Varnish. Нужна нестандартная бизнес-логика — она пишется непосредственно в проекте.

AI не делает эти решения автоматически правильными. Но закрытая платформа может вообще не дать их принять.

Владение не означает самостоятельное обслуживание

Здесь часто возникает ложная дихотомия.

Если проект принадлежит клиенту, значит клиент должен сам быть DevOps, программистом и администратором?

Нет.

Мы давно не считаем, что владение автомобилем означает необходимость самостоятельно ремонтировать двигатель. Можно владеть активом и платить специалистам за обслуживание.

С программным обеспечением исторически сложилось иначе, потому что стоимость индивидуального сопровождения была высокой. SaaS объединил тысячи клиентов на одной платформе и благодаря этому сделал обслуживание дешёвым.

AI открывает возможность другой модели:

индивидуальный проект остаётся индивидуальным, но значительная часть его обслуживания автоматизируется.

Тогда клиент может владеть кодом, данными и инфраструктурой, но взаимодействовать с системой примерно так же просто, как с SaaS:

«Добавьте на сайт бронирование».

Ему не обязательно знать, какие миграции базы, компоненты интерфейса и API для этого понадобятся.

Роль сильного специалиста становится даже важнее

У этого оптимистичного сценария есть существенное условие.

AI хорошо снижает стоимость механической инженерной работы и исследования незнакомого стека. Но кто-то должен отличать реальную пользу от маркетинга и технически возможное решение от разумного.

Нужно понимать, когда отдельный сервис действительно нужен, а когда он только увеличит сложность. Нужно увидеть, что старую OAuth-интеграцию не следует переносить. Нужно решить, стоит ли чинить существующую архитектуру или проще заменить её часть. Нужно оценивать риски миграции данных, безопасность и последствия инфраструктурных решений.

Поэтому AI особенно сильно увеличивает производительность не абстрактного «пользователя без технических знаний», а опытного универсального инженера.

Раньше значительная часть его времени уходила на чтение документации, boilerplate, CRUD, миграции, поиск по незнакомому коду и ручную интеграцию компонентов. Теперь эту работу можно делегировать агенту, оставляя человеку постановку задачи, архитектурное суждение и контроль результата.

Один сильный специалист потенциально способен сопровождать гораздо больше разнородных проектов.

И именно это может сделать владение собственным software экономически конкурентоспособным SaaS.

Vendor lock-in перестаёт быть необходимой платой

Полностью избежать зависимостей невозможно. Любой проект зависит от языка, библиотек, базы данных, cloud provider или внешних API.

Но есть принципиальная разница между зависимостью и невозможностью уйти.

Хороший критерий свободы проекта можно сформулировать практически:

• можно получить весь исходный код;
• можно получить данные;
• можно получить файлы и assets;
• можно воспроизвести runtime;
• можно перенести deploy;
• можно заменить обслуживающую команду;
• можно продолжить разработку без разрешения прежнего поставщика.

Если всё это возможно, пользователь действительно владеет своим проектом.

Он может оставаться у текущего сервиса десять лет — но остаётся потому, что сервис полезен, а не потому, что выход слишком дорог или технически невозможен.

Возвращение к software, но не к старой сложности

Возможно, следующий этап после тотального SaaS — не отказ от облаков и не возвращение к ручному администрированию серверов.

Скорее это возвращение самого понятия собственного программного проекта, но уже с другим интерфейсом управления.

Не:

пользователь → IDE → код → сервер

и не обязательно:

пользователь → закрытый SaaS

а:

пользователь → AI / обслуживающая команда → собственный software

Hosting при этом может оставаться managed. Database может быть managed. CDN может быть внешним сервисом. Ничего плохого в SaaS-компонентах нет.

Критично другое: они должны быть заменяемыми компонентами проекта, а не местом, внутри которого заперт сам проект.

Мы можем снова получить и свободу, и удобство

SaaS выиграл предыдущий этап развития веба потому, что сделал сложность невидимой для пользователя.

Это было огромным достижением, а не ошибкой.

Но исторически невидимость сложности часто достигалась передачей контроля поставщику.

AI предлагает другой механизм: сложность может оставаться внутри собственного проекта, но взаимодействовать с ней будет машина и обслуживающий специалист.

Поэтому старый компромисс начинает слабеть:

раньше:
больше свободы → больше сложности для пользователя

теперь:
больше свободы → больше работы для AI

Пока это не универсальная реальность. Нужны хорошие инструменты, воспроизводимые окружения, качественные агенты и опытные специалисты.

Но направление уже видно на практических проектах.

И, возможно, одно из самых интересных последствий AI-разработки состоит не в том, что теперь каждый сможет стать программистом.

А в том, что для владения собственным программным обеспечением больше не обязательно становиться программистом вообще.