Команда AI for Devs подготовила перевод статьи о том, как агентные инструменты разработки меняют экономику создания ПО. Автор утверждает: трудозатраты на выпуск продукта стремительно падают, скрытый спрос на софт растёт, а единственным настоящим конкурентным преимуществом становится глубокая экспертиза в предметной области.

Я почти 20 лет профессионально занимаюсь разработкой ПО. За это время я видел много перемен: «рождение» SaaS, массовый переход к мобильным приложениям, безумный хайп вокруг блокчейна и вечные обещания, что low-code сделает разработчиков ненужными.

С появлением агентной разработки экономика изменилась радикально, и это полностью перестроит индустрию создания софта (и экономику в целом). 2026 год застанет многих врасплох.

В предыдущем посте я писал о том, почему, на мой взгляд, evals упускают некоторые ключевые прорывы, но размышления после этого (и недавний опыт) укрепили меня в уверенности, что мы входим в раннюю фазу изменения масштаба целого поколения.

Стоимость релиза

Я начал заниматься разработкой примерно в тот момент, когда Open source действительно начал расти, и было очевидно, что это первый большой сдвиг в снижении стоимости создания кастомного ПО. Я отлично помню заоблачные цены на SQL Server и Oracle, поэтому начинал, разумеется, с MySQL, который позволял строить сетевые приложения, не платя пяти- или шестизначные суммы в год за лицензии на базы данных.

Потом пришло облако (хотя я бы поспорил, что это вообще экономия, но будем щедры и допустим, что оно снижало первоначальные капитальные затраты), а затем, как мне кажется, наступила эпоха сложности. Инженерия софта стала значительно — часто, на мой взгляд, неоправданно — сложнее: люди бросились в трудоемкие практики вроде TDD, микросервисов, чрезмерно усложненных React-фронтендов и Kubernetes. Уверен, в последние годы мы не увидели почти никакого снижения стоимости.

Однако ИИ-агенты, как я считаю, радикально сокращают трудозатраты на разработку софта.

Так откуда вообще берётся экономия в 90%?

В начале 2025 года я был крайне скептичен по поводу большинства инструментов ИИ для кодинга — и многие из них меня до сих пор не убеждают. Большинство платформ ощущались как разрекламированные low-code средства (Loveable, Bolt и т. п.) или форки VS Code с чуть-полезным (и часто раздражающим) автодополнением.

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

Раньше над этим работала бы небольшая команда: кто-то настраивал бы CI/CD, кто-то реализовывал бы шаблоны доступа к данным, кто-то писал бы базовые сервисы. Затем следовала бы куча CRUD-страниц, возможно, несколько дэшбордов и графиков. В конце вы бы (в идеале) добавили автоматические unit/integration/e2e тесты, чтобы всё было достаточно надежным, и отправили бы проект в прод примерно через месяц.

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

Почти всё это сейчас можно выполнить за несколько часов с помощью агентной CLI для разработки. Claude Code, например, написал мне полный набор unit и интеграционных тестов (300+ тестов) за несколько часов для достаточно сложного внутреннего инструмента. На это у меня или у многих уважаемых мной разработчиков ушли бы дни.

Агентные инструменты действительно научились превращать бизнес-логику в хорошо написанные API и сервисы.

Проект, который занимал месяц, теперь занимает неделю. Время на продумывание остается примерно тем же, но время реализации схлопнулось. И с меньшими командами включается обратная версия Закона Брукса: вместо того чтобы накладные расходы на коммуникацию росли с численностью команды, они исчезают. Небольшая группа людей внезапно может делать на порядок больше.

Скрытый спрос

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

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

Если перенести это на разработку софта, достаточно посмотреть на соотношение спроса и предложения. Скрытого спроса на программные решения невероятно много. Уверен, в любой организации найдутся сотни, если не тысячи Excel-таблиц, которые отслеживают важные бизнес-процессы и куда лучше подошли бы под формат SaaS-приложений. Допустим, компания запрашивает у агентства оценку стоимости превращения о��ной из таких таблиц в приложение и получает сумму в 50 тысяч долларов. В итоге в работу идут только самые критичные из них. Но если стоимость падает до 5 тысяч (при участии хорошего разработчика и инструментов ИИ), то спрос начинает расти на порядки.

Единственная реальная защита — экспертиза в предметной области

Что это всё значит для нас? Пока что человеческое участие всё ещё критически важно: кто-то должен «присматривать» за агентом, проверять результат, задавать правильный вектор и вовремя разворачивать его от ошибочных траекторий. Если пойти в чистое YOLO-кодерство, всё очень быстро превращается в хаос. Но с человеком в контуре можно получать софт действительно высокого качества и делать это очень быстро.

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

Добавьте к этому погружение в бизнес-домен — и ощущение такое, что мифический «10x инженер» наконец стал реальностью. Более того, связка предметного эксперта и мотивированного разработчика с такими инструментами становится невероятно сильной комбинацией. И, думаю, мы увидим это как новый стандарт: вместо «сквода» из бизнес-специалиста и нескольких разработчиков — тесная работа пары людей.

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

Не позволяйте застать себя врасплох

Агенты и модели продолжают стремительно улучшаться, и, как мне кажется, бенчмарки этого вообще не отражают. Opus 4.5, например, уверенно удерживает нить 10–20-минутных сессий, не уходя куда-то в сторону. Мы только начинаем видеть отдачу от сотен миллиардов долларов капекса, вложенных в GPU GB200, и уверен, следующие поколения моделей очень быстро сделают текущие устаревшими.

Тем не менее я поговорил уже со многими разработчиками, которые сопротивляются переменам. Одни и те же аргументы повторяются бесконечно: LLM слишком часто ошибается, он «не понимает» [framework], он на самом деле не экономит время.

Эти утверждения стремительно перестают быть правдой. Очень напоминает мне разработчиков desktop-ПО, которые отмахивались от iPhone в 2007 году. Итог известен: сети стали лучше, телефоны ускорились, мобильные ОС стали мощными.

Разработчикам, на мой взгляд, нужно не сопротивляться, а идти навстречу изменениям. Это не произойдет за один день. Крупные корпорации сильно отстают: их завязали бюрократия, процессы согласования вендоров ПО для разработчиков, иерархии — и всё это делает их уязвимыми для более мелких конкурентов.

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

Частый аргумент, который я слышу: LLM хороши только для greenfield-проектов. Я категорически не согласен. Я провёл кучу времени, пытаясь понять кодовые базы старше трёх лет, авторы которых давно ушли. Агенты радикально упрощают это: объясняют, что делает код, находят баги, предлагают исправления. Честно говоря, я бы с куда большим удовольствием унаследовал репозиторий, написанный агентом под присмотром хорошего инженера, чем тот, который три года назад написал сомнительного уровня подрядчик без тестов и с кучей классов и методов, связанной в одну огромную спагетти-структуру.

Русскоязычное сообщество про AI в разработке

Друзья! Эту статью подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-ассистентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!