18 июня Stack Overflow Blog выпустил заметку о том, что у команд с AI-инструментами появилось новое узкое место разработки: код пишется быстрее, а продукт не едет заметно быстрее. Для русскоязычных команд это неприятно знакомый сюжет: можно закупить Copilot-подобные инструменты, поднять личную продуктивность инженеров и все равно упереться в те же согласования, ревью и расплывчатые требования.
Проблема, как пишет Stack Overflow Blog, не в том, что AI переоценили. Наоборот: многие инженерные команды действительно получили прирост на уровне отдельного разработчика. Быстрее собираются прототипы, быстрее выходят демо, быстрее закрываются отдельные задачи. Но если посмотреть не на локальный успех, а на скорость системы целиком, картина часто не меняется: sprint velocity стоит примерно там же, фичи застревают в тех же точках, а на ретро обсуждают все те же жалобы. Иными словами, компании обновили двигатель, но не пересобрали дорогу, по которой он едет.
Логика тут довольно приземленная и оттого неприятная. Stack Overflow опирается на теорию ограничений: у любой системы есть главное ограничение, и если его ослабить, узкое место просто сдвигается дальше по цепочке. В индустрии ПО долгие годы таким ограничением было само производство кода. Под это и собирали знакомую всем организационную обвязку: спринты, сторипойнты, ритуалы планирования, жесткие handoff-процессы между продуктом, дизайном и разработкой. Но если генерация кода резко дешевеет, старая конструкция начинает работать странно. Директор по инженерии Intuit Эрик Андерсон в подкасте Leaders of Code сформулировал это жестко: теперь дополнительная строка кода — едва ли не самая дешевая часть разработки. На квартальном планировании его команда, по его словам, поймала себя на мысли, что продолжает мыслить слишком мелко и все еще планирует работу так, будто код остается главным дефицитом.
Новое узкое место разработки выглядит не как один драматичный провал, а как набор привычных задержек, которые раньше считались фоновым шумом. Первая зона риска — требования и discovery. Когда код становится дешевым, цена туманного ТЗ, наоборот, растет. Хорошо настроенный AI-агент соберет именно то, что ему описали. Если описание было дырявым, команда быстро получит не экономию, а ускоренное производство переделок. Вторая зона — дизайн-хенд-оффы. Классическая схема, в которой инженерия ждет полностью завершенный дизайн, родилась в мире дорогих итераций. Если интерфейс можно перебрать почти в реальном времени, то ожидание «дизайн готов на 100%» начинает добавлять не качество, а задержку.
Третье ограничение — ревью и инженерное суждение. Чем больше AI генерирует полезного кода, тем больше поверхность для проверки. Если раньше объем работы одного senior-инженера примерно соответствовал размеру команды, то теперь этот же senior может внезапно стать единственным фильтром для потока, который вырос кратно. И здесь компании сталкиваются с простым фактом: output удвоился, а способность к code review, архитектурной оценке, QA и техническому sign-off — нет. Четвертая проблема еще менее заметна в стандартных метриках инженерии: межфункциональная координация. Продукт, дизайн, безопасность, legal и комплаенс часто не умеют двигаться с той же скоростью, что и команда, разогнанная AI. В результате готовая работа лежит на полке и ждет одобрения от процессов, которые изначально не были рассчитаны на такой темп.
Почему компании это не чинят, даже когда симптом уже очевиден? Потому что внедрить новый инструмент проще, чем договориться о новых правилах игры. Руководитель разработки может довольно быстро продавить adoption AI-кодинга внутри своей функции. Но он не может одним письмом переписать discovery у продуктовой команды или заставить дизайнеров отказаться от привычной модели handoff. Это уже не локальная оптимизация, а организационный конфликт интересов. Плюс старые процессы дают ощущение безопасности. Agile когда-то пришел как лекарство от waterfall, но во многих компаниях сам превратился в бюрократический ритуал. Спринты и церемонии продолжают успокаивать менеджмент даже там, где давно перестали добавлять скорости. Stack Overflow честно фиксирует еще одну причину: у рынка пока нет готового playbook для мира, где код почти бесплатен. Андерсон прямо говорит, что его команда экспериментирует и учится по ходу, а не следует устоявшейся методичке.
Для разработчиков и IT-менеджеров из России это важный сигнал без скидки на географию. Когда рынок обсуждает AI в разработке, разговор часто крутится вокруг моделей, IDE-плагинов и того, кто сколько процентов экономит на написании кода. Но главный вопрос смещается: не чем генерировать, а как перестроить поток работы вокруг этого ускорения. Если команда продолжает измерять себя старыми ритмами и защищать старые контрольные точки, AI не отменяет хаос, а делает его дороже. Ошибка в требованиях масштабируется быстрее, бессмысленное ревью забивает календарь сильнее, а затянутые согласования становятся заметнее, потому что инженерная часть уже закончилась. Практический вывод из текста Stack Overflow простой: проверять нужно не только стек инструментов, но и каждую стадию процесса на предмет того, какую старую боль она вообще лечит.
Следующий раунд конкуренции между командами, похоже, будет идти не за право первым подключить очередного AI-ассистента, а за способность убрать лишние задержки между идеей и проверкой гипотезы. У тех, кто пересоберет требования, дизайн-хенд-оффы и модель ревью под новую скорость, узкое место разработки снова сдвинется. У остальных AI останется дорогой витриной личной продуктивности, которая почти не меняет скорость бизнеса.