Количество багов на разработчика выросло на 54%, а соотношение инцидентов к PR — сразу на 242,7%, хотя команды с ИИ-инструментами действительно стали писать и вливать код быстрее. Для тех, кто строит фабрику софта, это неприятный, но полезный сигнал: ускорение разработки само по себе еще не означает рост продуктивности, а для русскоязычных IT-команд это прямой вопрос к качеству процессов, а не только к выбору очередного код-ассистента.
Об этом пишет VentureBeat, разбирая, почему модная идея «фабрики софта» слишком часто сводится к банальному ускорению поставки дефектов. Логика понятна: большие языковые модели резко снизили порог входа в написание кода, подняли личную производительность инженеров и подтолкнули компании смотреть на разработку как на производственную систему. Но если раньше узким местом был сам акт написания кода, то теперь вопрос меняется на более неприятный: нужно ли вообще писать этот код, выдержит ли он эксплуатацию и не превратится ли через полгода в дорогую свалку технического долга.
Термин «фабрика софта» заметно оформился за последний год. VentureBeat ссылается на тезис Луки Росси о том, что ИИ меняет не просто скорость программирования, а весь контур производства ПО. Под этим термином разные компании понимают разное: кто-то имеет в виду набор агентных инструментов и skills-файлов в репозитории, кто-то — более быстрый CI/CD, кто-то — автоматизацию ревью и релизов. Но в материале проводится жесткая граница: фабрика софта — это не россыпь промптов, плагинов и агентов по углам, а платформа, которая задает, как работа проходит через систему, как код генерируется, тестируется, ревьюится, трассируется, выкатывается и чинится после сбоев. Иначе это не фабрика, а просто одинокий станок посреди пустого цеха.
Почему тема взлетела именно сейчас, тоже довольно прозрачно. Бизнесу всегда нужно было больше внутреннего софта, чем могли произвести команды разработки; отчасти поэтому в компаниях десятилетиями процветали Excel-таблицы и другие суррогаты недостающих систем. ИИ убрал часть барьера: рабочий код теперь получить проще, пусть не всегда дешевле и не всегда лучше. Один инженер способен производить заметно больше, чем еще несколько лет назад. Для менеджмента это выглядит как подарок, но у подарка неприятная гарантия: вместе с объемом выпуска растет и объем потенциальных ошибок. Небольшая команда сегодня может разогнать кодовую базу до масштабов, которые десять лет назад ассоциировались с куда более крупными технологическими компаниями. Проблема в том, что процессы сопровождения, контроля и стандартизации у таких команд часто остались на до-ИИ уровне.
Цифры из статьи как раз про это. По данным Faros AI, пропускная способность по задачам на одного разработчика выросла на 33,7%, а частота слияния PR — на 16,2%. Звучит как хороший квартальный отчет, если не смотреть на вторую половину таблицы. Соотношение инцидентов к PR подскочило на 242,7%, а число багов на разработчика — на 54%. Отдельно VentureBeat приводит выводы Google DORA: более активное внедрение ИИ оказалось связано с ухудшением стабильности поставки. Для CTO и тимлидов это плохая новость не потому, что ИИ «не работает», а потому, что он сдвигает бутылочное горлышко. Узкое место больше не в генерации кода, а в способности организации понимать, проверять, воспроизводить и безопасно менять то, что этот код делает.
Автор материала добавляет и практическое наблюдение из собственных проектов: за последний год ему пришлось разбирать как минимум два кейса, где ИИ-сгенерированная дата-инфраструктура постепенно становилась неуправляемой. Несколько инженеров двигались быстро, общих стандартов не было, и кодовая база за месяцы расползалась на пять-шесть стилистических направлений. Раньше такой зоопарк зрел годами, теперь его можно получить за один активный сезон. Дальше включается предсказуемый режим: новые LLM подхватывают уже существующий хаос, начинают воспроизводить его в следующих итерациях, и команда слой за слоем теряет понимание, что именно происходит в системе. Для российских продуктовых команд и интеграторов это особенно узнаваемый сценарий: сначала все радуются, что прототипы и внутренние сервисы делаются быстрее, а потом внезапно выясняется, что никто не хочет отвечать за их долгосрочную поддержку.
Вывод VentureBeat довольно приземленный и потому полезный. Рабочая фабрика софта строится не вокруг скорости, а вокруг нескольких дисциплин. Первая — платформа вместо набора разрозненных инструментов: данные, процессы, стандарты и сами этапы работы должны быть связаны в единую систему. Вторая — воспроизводимость и трассируемость: нужно уметь поднять любой прогон, понять, где он сломался, и повторить его, а не гадать по логам и чужим комментариям. Третья — защитные механизмы и контроль качества как можно раньше в цепочке: тестирование, статический анализ, шаблоны для генерации кода, проверки на уровне спецификации. Четвертая — стандартизация, потому что без нее кодовый ассистент не помогает команде, а лишь масштабирует ее привычки, включая плохие. Наконец, пятая — встраивание качества в сам процесс, а не в последний этап ревью. В статье это сравнивают с производственной логикой Toyota: лучше остановить линию раньше, чем героически отбраковывать результат на выходе.
Главный вопрос теперь не в том, какая команда научится генерировать больше кода за день. Намного интереснее, какая сможет превратить этот поток токенов в устойчивый продукт, который не рассыпается на проде и не требует переписывания через квартал. Если рынок и дальше будет мерить успех ИИ по скорости коммитов и числу закрытых задач, фабрика софта легко станет фабрикой техдолга.