За что бизнес будет платить ИТ-подрядчику, если написание кода дешевеет

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

В исследовании NBER на данных более чем 100 тысяч разработчиков GitHub автономные агенты увеличивали число коммитов на 180%, но количество релизов — только на 30%. И, чем дальше результат находился от непосредственного написания кода, тем слабее был эффект.

Если реализация дешевеет быстрее выпуска готового продукта, возникает закономерный вопрос: а за что бизнесу теперь платить ИТ-подрядчику? Ответ становится понятен, если взглянуть на весь путь от бизнес-задачи до работающего решения.

Код больше не главный дефицит

По данным Developer Ecosystem Survey 2026 от JetBrains, 90% профессиональных разработчиков используют ИИ-агентов в работе хотя бы раз в неделю, а 68% — ежедневно. Агентные инструменты уже часть обычного процесса разработки.

Это не означает, что специалисты больше не нужны или что решение можно собрать за вечер. Просто стоимость типовой реализации действительно снижается.

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

Сэкономленные часы разработчика не равны сэкономленному проекту

Упрощенная цепочка выглядит так: бизнес-задача → требования → архитектура → реализация → интеграции → проверка → безопасность → выпуск → эксплуатация.

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

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

Что на самом деле остается дорогим

Можно выделить четыре аспекта, где стоимость практически не меняется:

1. Понимание задачи и контекста. Требования нечасто удается объединить в один непротиворечивый, предельно понятный документ. Они распределены между владельцами продуктов, регламентами, корпоративными системами, историческими исключениями и правилами безопасности. Сам код можно сгенерировать быстро — а вот разобраться, какой именно код нужен бизнесу, уже тяжелее.
2. Архитектура и интеграции. Новому компоненту недостаточно «просто работать»: он должен вписываться в систему. Ошибка здесь часто проявляется через несколько месяцев, когда очередная функция начинает требовать изменений сразу в нескольких частях продукта.
3. Проверка результата. Получить готовую реализацию — это только начало. Теперь надо убедиться, что она решает исходную задачу, выдерживает нагрузку, не ломает соседние сценарии и отвечает требованиям безопасности.
4. Ответственность после запуска. Когда решение становится частью критичного процесса, заказчику мало исполнителя, который передал код. Ему нужна сторона, способная разобраться в деградации, изменить архитектуру, восстановить работу после сбоя и оценить последствия следующей доработки.

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

Вместо мощности команды подрядчик продает снижение риска

Отсюда меняется и предмет сделки. Раньше понятной единицей была команда: разработчики, аналитик, тестировщик. Теперь один и тот же состав с помощью нейросетей может производить значительно больший объем работы.

Заказчику стало не столь принципиально, какое количество человек занимается проектом. Гораздо важнее то, какой результат подрядчик способен довести до эксплуатации — и что произойдет после запуска.

Этот сдвиг уже заметен в коммерческих моделях. В исследовании BCG рынка технологических услуг около 60% поставщиков решений с агентным ИИ пока используют оплату времени и материалов или фиксированную цену. Однако более 70% корпоративных заказчиков предпочли бы модели, связанные с бизнес-эффектом или объемом результата, по крайней мере в клиентском сервисе и аутсорсинге бизнес-процессов. 

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

Человеко-часы не исчезнут

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

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

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

За что тогда есть смысл платить

Если сам код перестает быть главным доказательством ценности, на первый план выходят иные способности:

1. правильно сформулировать задачу и отыскать противоречия в требованиях, прежде чем переходить к выполнению;
2. спроектировать архитектуру, которая решает текущую задачу и не блокирует дальнейшее развитие;
3. встроить решение в реальные данные, процессы и корпоративные системы, а не просто собрать работающий прототип;
4. проверить качество, безопасность и устойчивость до промышленного запуска;
5. взять ответственность за результат после выпуска, вместо того чтобы закончить работу на передаче исходного кода;
6. сохранить низкую цену следующих изменений, чтобы ускорение сегодня не превратилось в технический долг завтра.

Именно здесь становится видна новая экономика разработки. Чем проще получить еще одну функцию, тем меньше сама способность ее написать отличает сильного подрядчика от слабого.

Подведем итоги

Дешевеющий код не обязательно означает дешевеющий ИТ-проект. Скорее из его стоимости постепенно исчезает большой объем ручного написания — и становятся более заметны другие составляющие.

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

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