ИИ в разработке уже не выглядит экспериментом: автор The New Stack прямо пишет, что пользуется такими инструментами каждый день и не хотел бы возвращаться назад. Но ключевой тезис заметки в другом: скорость разработки с ИИ не растет автоматически, и для инженеров это, пожалуй, важнее любого очередного восторженного демо.
Лауреано Гонсалес в колонке для The New Stack разбирает не абстрактную «трансформацию индустрии», а более приземленный вопрос: в каких задачах ИИ реально экономит часы, а в каких создает дополнительные круги проверки, правок и сомнений. Для русскоязычной IT-аудитории здесь узнаваемая боль: почти у каждой команды уже есть Copilot, ChatGPT, Cursor или внутренний ассистент, но KPI у всех один и тот же — выпускать код быстрее, не превращая ревью и отладку в археологию.
В этом смысле материал ценен своей трезвостью. Автор не спорит с тем, что ИИ полезен. Наоборот, он начинает с почти максимальной степени принятия: инструмент вошел в ежедневную практику. Но дальше следует неприятная для рынка мысль: выигрыш возникает не от самого факта использования модели, а от совпадения инструмента и типа задачи. Там, где работа рутинная, шаблонная или требует быстрого первого прохода, выигрыш очевиден. Там, где цена ошибки высока, а проверка занимает больше времени, чем ручное выполнение, обещанная скорость разработки с ИИ быстро растворяется.
Это важное уточнение на фоне последних двух лет, когда рынок продавал ИИ-помощников почти как универсальный ускоритель. Менеджменту нравилась формула «разработчик с ИИ работает в разы быстрее», стартапам — идея, что можно держать меньшую команду, а самим инженерам было приятно переложить на модель черновики, бойлерплейт, документацию, тестовые заготовки и поиск очевидных ошибок. Проблема в том, что большая часть реальной разработки состоит не из эффектных генераций, а из цепочки мелких решений с контекстом: почему система устроена именно так, где у нас исторические ограничения, какие зависимости хрупкие, что нельзя ломать ради красивого рефакторинга.
Именно здесь колонка The New Stack попадает в нерв индустрии. ИИ действительно хорош как ускоритель входа: быстро набросать структуру, предложить вариант запроса, подсказать синтаксис, собрать черновик функции, помочь с документацией или пояснить незнакомый фрагмент кода. Для опытного разработчика это сокращает количество переключений между IDE, документацией, поиском и внутренней памятью. Но как только задача выходит из режима «сгенерируй стартовую версию» в режим «докажи, что это корректно для моего проекта», экономия становится куда менее очевидной. Чем сложнее контекст, тем выше риск, что модель ответит уверенно, гладко и не совсем по делу.
Для команд это означает простую, но неприятную вещь: оценивать ИИ нужно не по тому, сколько строк он написал, а по полной стоимости результата. Если после генерации инженер еще двадцать минут проверяет API, сверяет поведение с бизнес-логикой, переписывает половину кода под архитектурные ограничения и ловит незаметные регрессии, то производительность выросла не обязательно. Более того, в некоторых сценариях она падает, потому что человек тратит когнитивный ресурс не на создание решения, а на аудит чужого текста, который выглядит правдоподобно. Это особенно знакомо тем, кто пробовал генерировать код для зрелых систем, где важно не «чтобы работало вообще», а «чтобы работало именно здесь и не ломало соседние модули».
Отсюда вытекает и более практичный вывод для руководителей разработки. ИИ имеет смысл внедрять не как магическую надстройку над всем SDLC, а как набор точечных усилителей. Он уместен там, где можно быстро проверить результат и дешево откатить ошибку: черновики текстов, вспомогательные скрипты, подготовка тестов, резюмирование обсуждений, первичная навигация по коду, генерация вариантов решения. Но когда речь идет о критичной бизнес-логике, интеграциях, безопасности, миграциях данных или сложном рефакторинге, реальная скорость зависит уже не от качества автодополнения, а от того, насколько команда умеет валидировать результат. Иными словами, ИИ меняет не только этап написания, но и этап проверки — а последний часто недооценивают.
Для разработчиков в этом есть даже небольшой профессиональный бонус. На фоне всеобщего увлечения генерацией снова дорожает то, что модели пока не умеют делать надежно: удерживать широкий контекст, помнить историю компромиссов в проекте, задавать неудобные вопросы к требованиям и чувствовать, где «почти правильно» на самом деле означает «потом будем чинить прод». Поэтому скорость разработки с ИИ у senior-инженера и у новичка может различаться не потому, что один лучше пишет промпты, а потому что один лучше знает, что именно нужно проверить и где модель, скорее всего, срежет угол.
Для бизнеса урок тоже довольно приземленный. Если смотреть только на демо, легко решить, что проблема найма и дорогой инженерной работы почти снята. Если смотреть на полный цикл, видно другое: ИИ пока сильнее снижает стоимость черновой фазы, чем стоимость ответственности за финальный результат. А значит, компании, которые рассчитывают на моментальную кратную экономию, могут столкнуться с тем, что выиграли в скорости набора текста, но не выиграли в качестве решений, сроках релиза и поддерживаемости кода.
Пожалуй, главный вопрос теперь не в том, нужен ли ИИ разработчику. Судя по тону колонки The New Stack, этот спор уже во многом закрыт. Вопрос в другом: смогут ли команды честно измерять, где ИИ действительно сокращает путь до результата, а где просто делает путь более шумным. На ближайшем этапе побеждать будут не те, кто громче всех обещает автоматизацию, а те, кто научится отличать полезное ускорение от дорогой иллюзии скорости.