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