Microsoft говорила о software factories еще в 2008 году, но всерьез к этой идее рынок вернулся только сейчас. Причина проста: генерация кода подешевела и ускорилась настолько, что фабрики ПО снова выглядят не как красивая метафора, а как рабочая модель для выпуска приложений, обновлений и внутренних сервисов. Для русскоязычной IT-аудитории здесь важен не сам термин, а сдвиг роли команды: узким местом становится уже не написание кода, а проверка, контроль и выпуск.
Об этом сообщает ZDNet в материале о том, как крупные игроки AI-рынка заново собирают концепцию «программного конвейера». Логика почти промышленная: есть прототип, условно собранный в vibe-coding-режиме, а дальше он попадает в систему, которая валидирует, тестирует, прогоняет через пайплайны и доводит до состояния, пригодного для массовой поставки. Не «один инженер ночью накатил фичу в прод», а повторяемый процесс, где каждый шаг фиксируется и воспроизводится.
Именно это, по версии ZDNet, и становится новой нормой в эпоху агентной разработки. Глава CloudBees Мориц Плассниг прямо говорит, что еще недавно бутылочным горлышком для многих компаний был кодинг как таковой: чтобы выпускать больше, приходилось нанимать больше инженеров, а это было долго и дорого. Теперь фундаментальные модели и кодовые агенты снимают часть этого ограничения. Но вместе с этим меняется и профиль работы разработчика. Его ценность смещается от набора строк кода к инженерному суждению: что вообще имеет смысл строить, как это проверить, где риски, что можно выпускать, а что нельзя.
Что такое фабрика ПО в версии 2026 года
ZDNet приводит наблюдение Джеймина Уэста, инженера и технологического евангелиста: за последние 18 месяцев компании, которые автоматизируют жизненный цикл разработки с помощью агентов, фактически пришли к одной и той же архитектуре. Среди них он перечисляет Anthropic, Cognition, Cursor, Factory, Google, GitHub, OpenAI и Ramp. Это важный момент: рынок еще спорит о моделях, интерфейсах и ценообразовании, но инфраструктурный шаблон уже проступает довольно отчетливо. Если несколько независимых компаний приходят к одной форме организации работы, это обычно не мода на неделю, а ранний признак стандарта.
Уэст описывает такую фабрику ПО через шесть компонентов. Первый — очередь задач: работа приходит в виде issue, а не в виде разового промпта в чат. Второй — control plane, то есть постоянная управляющая поверхность, а не локальный ноутбук отдельного разработчика. Третий — sandbox: изолированная среда под каждую задачу, которую потом можно уничтожить без сожалений. Четвертый — pull request как единица результата, которую человек получает на проверку. Пятый — event stream, где можно видеть действия агента и при необходимости остановить процесс, не разрушая весь запуск. Шестой — durable memory: если результат не записан в файл или систему хранения, он не переживет новый прогон. Звучит сухо, но по сути это попытка превратить работу AI-агента из магии в управляемый производственный цикл.
На практике сценарий выглядит так. Сотрудник поддержки, аналитик или продакт замечает повторяющуюся боль клиентов и собирает прототип инструмента. Неважно, написан ли он вручную или частично сгенерирован агентом. Дальше этот прототип не должен жить как «самоделка на коленке». Его отправляют на фабрику: система создает первую реализацию, после чего продуктовые, инженерные и IT-команды проверяют идею, а затем снова возвращают ее в конвейер для доработки, тестирования и упаковки. Это очень похоже на разделение между опытным образцом и серийным производством в обычной промышленности. Для стартапов и крупных компаний разница критична: прототипов можно делать сколько угодно, но бизнес-ценность появляется только там, где есть повторяемый выпуск.
Почему проблема теперь не в коде, а в верификации
На этом месте легко впасть в восторг: если агенты могут писать код быстрее людей, значит, релизы станут почти бесплатными. Но именно тут начинается менее гламурная часть истории. Плассниг обращает внимание на то, что при кратном росте числа изменений человек уже не способен вручную отслеживать, что работает, а что ломается. Если обновления идут ежедневно или вообще каждые несколько минут, прежняя модель с набором алертов и ручной проверкой начинает сыпаться. Нужно понимать не только наличие багов, но и поведение системы под нагрузкой, всплески ошибок, изменение потребления памяти агентами, деградацию качества и скрытые регрессии. Иначе «ускорение разработки» очень быстро превращается в ускорение поломок.
Это, пожалуй, самый трезвый вывод из всей истории про фабрики ПО. Генерировать код теперь действительно проще и дешевле, чем раньше. Но верификация не подешевела автоматически. Более того, она становится главной инженерной задачей. Отсюда и возврат к фабричной логике: когда изменений слишком много, нужна не героика отдельных команд, а дисциплина процесса. Очереди задач, изолированные среды, обязательные pull request, наблюдаемость, журнал событий и жесткая фиксация артефактов нужны не для красоты архитектурной схемы, а для элементарной управляемости.
Для разработчиков это означает довольно неприятную, но полезную правду: писать код как единственный источник ценности уже недостаточно. Будут расти требования к качеству ревью, проектированию тестов, описанию требований, работе с CI/CD и метриками эксплуатации. Для продактов и фаундеров вывод тоже не самый очевидный: дешевый прототип еще не равен готовому продукту. Скорее наоборот, чем проще стало собрать демо-версию, тем важнее становится инфраструктура, которая отделяет рабочую идею от красиво упакованного хаоса. Для IT-директоров и HR в IT эта история про другое распределение спроса: меньше дефицита на «просто кодеров», больше спроса на инженеров, которые умеют строить надежные пайплайны и контролировать качество в среде, где код появляется быстрее, чем его успевают читать люди.
Следующий вопрос уже не в том, вернутся ли фабрики ПО окончательно, а в том, кто первым научится делать их не только быстрыми, но и скучно надежными. Рынок, похоже, договорился об общей форме такого конвейера. Теперь придется доказать, что за этой формой стоит реальная инженерия, а не очередная версия старой мечты о том, что софт можно штамповать безболезненно и в промышленных объемах. Подробнее об исходном материале можно прочитать в .