Цена разработки с помощью ИИ инструментов, когда дешевле?

18.09.2026, 18:50 expert.com.ua

Взгляд фаундера на то, когда ИИ действительно ускоряет инженерную работу, замедляет ее, и что это меняет в подходе к найму.

В командах с высоким уровнем внедрения ИИ время ревью pull request выросло почти на 91 процент, по данным Faros AI, на основе данных более 10 000 разработчиков из 1255 команд. Написание кода стало быстрее. Скорее не стал результат, за который вы фактически платите: рабочий продукт, выполняющий именно то, что вы просили.

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

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

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

Шон Гроув, инженер OpenAI, утверждает, что именно написание кода составляет всего 10-20 процентов ценности, которую создает инженер. Остальные 80-90 процентов, по его определению, это то, что он называет структурированной коммуникацией: точная формулировка того, что именно нужно построить настолько четко, чтобы это можно было корректно реализовать. Не обязательно соглашаться с точными цифрами, чтобы увидеть направление.

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

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

На простых, новых проектах, например, создание MVP , доказательства однозначны и положительны В контролируемом исследовании, где разработчики создавали простой HTTP-сервер с нуля, те, кто использовал AI-ассистента, завершали задачу заметно быстрее. Исследования показывают, что в таких проектах количество возмущенных pull request возросло примерно на 26 процентов. Итак, если вы создаете что-то новое и несложное, ИИ, скорее всего, действительно ускорит поставки.

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

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

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

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

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

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

У этого есть прямое бюджетное значение. Если ваша команда генерирует гораздо больше кода, чем раньше, ревью и проверка – это обязательный расход. План, учитывающий, что ИИ напишет первый черновик, но не учитывает, что кто-то его тщательно проверит, это не более быстрый план. Это план со скрытым, незапланированным шагом, и обычно он проявляется в самый худший возможный момент: у продакшни, на глазах у клиента. Так что, клиенты, учитывайте это.

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

Когда-то предполагалось, что компиляторы должны были позволить бизнес-аналитикам писать собственный софт без инженеров. Языки четвертого поколения и CASE-инструменты обещали приложения, сгенерированные по спецификациям, без разработчиков. DevOps должен был заставить роль администратора баз данных исчезнуть. Ничего из этого не произошло так, как прогнозировали. Каждая такая заявка снижала порог входа в разработку софта, что увеличивало объем строящегося софта, а это, в свою очередь, увеличивало спрос на более квалифицированных инженеров, способных это строить и отвечать за это. Компиляторы не устранили разработчиков, они устранили написание кода вручную на ассемблере и подняли уровень, на котором все работают. Администратор баз данных не исчез вместе с DevOps, эта роль просто трансформировалась в новые требования.

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

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

Читать полностью…