Как минимум на двух уровнях ИИ уже меняет разработку: отдельный инженер пишет код быстрее, но инженерная продуктивность команды в целом не растет тем же темпом. В этом и состоит неприятный разрыв, о котором пишет The New Stack: ускорение на личном уровне не превращается автоматически в ускорение поставки, найма, ревью и выпуска продукта. Для русскоязычного IT это знакомый сюжет: купить ассистент для кода проще, чем перестроить весь конвейер вокруг него.
Поводом для обсуждения стала статья с прямым вопросом: если AI coding реально ускорился, почему быстрее не стала сама инженерия? Короткий ответ звучит почти обидно своей приземленностью: потому что код — это только часть работы. Даже если разработчик пишет фичу вдвое бодрее, дальше ее ждут те же ревью, согласования, тестовые контуры, требования безопасности, приоритизация, архитектурные споры и релизные окна. Иными словами, ИИ срезает минуты и часы на одном участке, но не отменяет очередь на соседних.
Это особенно заметно в зрелых командах, где скорость определяется не тем, как быстро человек набирает код, а тем, как быстро система в целом превращает идею в стабильный прод. Чем больше компания, тем сильнее эффект. В стартапе можно получить почти мгновенный выигрыш: попросил ассистента набросать API, поправил руками, выкатил. В крупной организации та же заготовка сначала попадает в корпоративные стандарты, потом в обязательные проверки, затем в CI/CD, а после этого в бесконечную цепочку уточнений, кто и за что отвечает, если все это сломается в пятницу вечером.
В этом смысле ИИ не столько опроверг старую истину про узкие места, сколько сделал ее виднее. Если раньше слабые звенья инженерного процесса можно было списать на нехватку рук, то теперь отговорка работает хуже. Когда код появляется быстрее, сразу видно, что тормозом были не только люди, но и сама организация разработки: перегруженные ревьюеры, плохо описанные требования, раздутые циклы согласования, хрупкая инфраструктура тестов, ручные проверки и непредсказуемый релизный процесс. ИИ здесь действует как контрастный краситель: он не чинит систему, а подсвечивает, где она давно буксует.
Отсюда и главный практический вывод. Измерять эффект от AI coding по количеству сгенерированных строк или по субъективному ощущению разработчика уже недостаточно. Инженерная продуктивность не равна скорости набора кода. Для команды важнее другие показатели: насколько быстрее доезжает задача до продакшена, уменьшается ли время ревью, падает ли число возвратов, проще ли сопровождать сгенерированный код через месяц и сокращается ли стоимость изменений после первого коммита. Если этого нет, значит ИИ встраивается как локальный бустер, а не как реальное улучшение инженерной системы.
Где именно ломается обещанное ускорение
Самая распространенная ошибка компаний сейчас — считать, что внедрение AI coding само по себе должно дать эффект масштаба. Логика понятна: если каждый разработчик стал быстрее, то и команда должна стать быстрее. На практике между этими двумя тезисами лежит масса «если». Если команда доверяет качеству сгенерированного кода. Если правила ревью адаптированы под новый поток изменений. Если тесты достаточно надежны, чтобы отлавливать побочные эффекты. Если архитектура не превращает каждую правку в каскад зависимостей. Если безопасность и compliance не устроены так, что любой нестандартный кусок кода автоматически едет на дополнительную проверку.
Отдельная проблема — рост объема изменений. ИИ способен ускорить производство кода быстрее, чем организация способна переварить этот поток. Разработчик присылает больше pull request, но ревьюеров больше не стало. Команда создает больше прототипов, но не успевает принимать решения, какие из них вообще нужны бизнесу. В итоге узкое место просто переезжает с этапа написания на этап проверки и принятия решений. Для тимлидов и директоров по разработке это неприятный, но полезный сигнал: покупать инструменты генерации проще, чем повышать пропускную способность инженерной машины.
Есть и менее очевидный эффект. Когда барьер на создание кода падает, резко растет цена хорошего контекста. Ассистент может быстро собрать функцию, тест или интеграционный слой, но не знает приоритетов продукта, исторических компромиссов системы и не чувствует, где команда сознательно выбрала «неидеальное, но поддерживаемое» решение. Поэтому выигрыш получают не все одинаково, а прежде всего те команды, у которых уже есть внятные спецификации, чистые интерфейсы, нормальная документация и дисциплина в разработке. Там ИИ ускоряет движение. Там, где процессы хаотичны, он скорее увеличивает шум и объем будущей уборки.
Что это значит для рынка и команд
Для разработчиков вывод довольно прозаичный: ценность смещается от механического написания кода к умению задавать ограничения, проверять результат и встраивать его в рабочую систему. Быстрее всех выигрывают не те, кто бездумно жмет на генерацию, а те, кто умеет быстро отбрасывать плохие варианты, формулировать четкие требования и держать в голове последствия изменений на уровне продукта и эксплуатации. Для бизнеса вывод еще жестче: если компания хочет повысить инженерную продуктивность, ей придется инвестировать не только в AI-инструменты, но и в ревью-практики, тестовую инфраструктуру, стандарты архитектуры и управляемость поставки.
Это, пожалуй, и есть самый трезвый взгляд на нынешнюю волну AI coding. Рынок уже получил доказательство, что отдельного человека можно ускорить. Следующий, куда более сложный этап — доказать, что ускорение переживет встречу с реальными процессами команды. Если этого не произойдет, компании получат не более быструю инженерию, а просто более быстрый способ производить очередь из задач, pull request и спорных решений.