Внедрение Factory AI для автономной разработки ПО: опыт и результаты

Почему автономная разработка на Factory AI ломается на масштабе

На одиночной задаче автономная разработка на Factory AI выглядит убедительно: агент получает постановку, сам находит нужные файлы, вносит правки и прогоняет проверки. Пока задачи идут по одной, узкое место смещается в постановку — чем точнее сформулирован результат, тем меньше итераций до принятого изменения.

На потоке картина другая. Несколько агентов параллельно трогают общие модули: схемы данных, общие утилиты, конфигурацию сборки. Каждый видит репозиторий в своей версии, и конфликты изменений всплывают не в момент правки, а на слиянии — когда переписывать приходится уже проверенное и принятое решение. Именно на этом шаге автономная разработка на Factory AI перестаёт масштабироваться линейно.

Дальше подключается второй эффект — ложные срабатывания проверок. Набор тестов рассчитан на последовательную интеграцию, и при параллельных ветках падения приходят из чужих правок. Агент читает красный прогон как собственную ошибку и правит то, что к задаче не относится: объём изменения растёт, а разбор правок теряет предсказуемость.

Очередь задач при этом не рассасывается, а растёт: к каждой задаче добавляются перебазирования, повторные прогоны и разбор чужих падений. Время прохождения одной задачи увеличивается нелинейно, и выигрыш от автоматизации съедается координацией. Разбираем, как это закрывается — правилами очереди, изоляцией ветвей и границами, в которых агент не выходит за свою задачу.

Измеримые эффекты: что меняется после внедрения агентов

Пропускная способность команды измеряется не активностью агентов, а числом изменений, дошедших до основной ветки за цикл. После внедрения агентов этот счётчик растёт за счёт того, что рутинные правки перестают конкурировать с задачами, где нужен опыт инженера: обновления зависимостей и типовые изменения уходят в фон и не занимают ревью целиком.

Доля автономных задач — вторая метрика: сколько изменений агент доводит от правки до прогонки проверок без промежуточного вмешательства человека. Factory AI закрывает повторяющиеся сценарии — обновление зависимостей, миграции по шаблону, однотипные правки конфигурации, — а инженер подключается на этапе ревью и оценки риска, а не на каждом шаге.

Время восстановления сокращается за счёт готового контекста: агенту доступны история правок, логи сборки и результаты проверок, поэтому черновик исправления появляется раньше, чем инженер вручную восстановит картину сбоя. Откат при этом остаётся управляемым — изменения приходят небольшими порциями, которые можно снять по отдельности, не разворачивая весь релиз.

Отдельное следствие — уходит класс отказов, связанных с человеческим пропуском: забытая миграция, рассинхрон конфигурации между стендами, незакрытая ветка. Такие сбои дороги не сложностью, а частотой, и агент снимает их проверкой по чек-листу до того, как изменение уходит дальше по среде.

Режимы работы агентов: сравнение подходов и ограничений

Режим работы агента — это в первую очередь режим записи в репозиторий, и он задаёт класс рисков, а не «уровень автономности». В Factory AI переключение делается на уровне задачи: одна и та же модель в режиме подсказок и в автоматическом режиме даёт разный результат по контролю над изменениями. Ниже — три альтернативы, между которыми реально выбирают.

Общее ограничение автоматизации одно: агент видит код и тесты, но не видит договорённостей, причин прошлых решений и требований к данным. Поэтому в любом режиме остаётся точка, где нужна проверка человеком — приёмка изменений на стыке модулей, права доступа, работа с персональными данными. Режим подбирают под задачу, а не под сервис: для рутинных правок достаточно изолированной копии, для ядра продукта — обязательного ревью.

Этапы внедрения: от аудита задач до передачи регламентов

Автономная разработка даёт эффект не сама по себе, а как часть процесса с понятными границами: где агент работает сам, где нужен человек, кто отвечает за откат. Поэтому внедрение Factory AI идёт этапами — от аудита задач до передачи регламентов, и на каждом есть проверяемый результат.

1. Аудит задач и правил. Разбираем, какие работы повторяются — типовые правки, тесты, обновление зависимостей — и какие правила команда уже соблюдает: стиль, ревью, требования к покрытию. На выходе — список задач для контура и перечень того, что он не трогает.
2. Схема контура. Определяем, где запускаются агенты, как получают доступ к репозиторию и как результат попадает в основную ветку. Изолированная среда на каждую задачу — базовое требование.
3. Настройка ролей и доступов. Разграничиваем права: чтение, запись, где нужен подтверждающий человек. Ключи живут в хранилище секретов и выдаются на минимальный срок.
4. Пилот на узком участке. Один сервис или один класс задач, где результат легко измерить. Смотрим долю принятых правок без доработки и время от постановки задачи до проверенного изменения.
5. Проверка качества. Сверяем с ожиданиями команды: проходят ли изменения обязательные проверки, не растёт ли доля откатов, устраивает ли ревьюеров читаемость. При просадке правим правила и подсказки, а не расширяем охват.
6. Передача регламентов. После стабильного пилота подключаем остальные команды и отдаём документацию: схему контура, матрицу доступов, правила ревью, порядок отката, разбор типовых сбоев. Инженеры ведут контур сами.

Комплект поставки: конфигурации, политики доступа, документация

Внедрение не заканчивается запуском: у команды заказчика остаётся рабочий комплект, по которому систему можно развивать и передавать другим инженерам без нас. Мы фиксируем в нём то, что обычно живёт в переписке — какие файлы настройки за что отвечают, где проходят границы прав и в какой момент в процесс обязан включиться человек.

• Конфигурации — файлы настройки среды, правил запуска агентов и подключения к репозиториям, с пояснением, что меняется и к чему это приводит.
• Схема интеграции — как Factory AI связан с репозиториями, ветками и очередью задач: где ставится задача, где появляется результат, где нужно подтверждение.
• Политики доступа — матрица прав по ролям: что агент читает, куда пишет, какие операции выполняет только после подтверждения инженера.
• Роли агентов — назначение каждой роли (разработка, проверка, разбор сбоев) и её границы в спорной ситуации.
• Правила проверки — условия приёмки изменения: обязательные проверки, пороги, причины автоматического отклонения.
• Регламенты дежурства — действия дежурного при остановке очереди задач, порядок отката неудачного изменения и точка эскалации.
• Документация — инструкции по запуску, типовые сбои и порядок их разбора, журнал изменений настроек.

Комплект остаётся в вашем репозитории и обновляется вместе с системой — именно это делает передачу знаний воспроизводимой, а не зависящей от конкретного инженера.

Кейс внедрения Factory AI: метрики до и после

Внедряли Factory AI на живом направлении, где очередь задач держалась на нескольких десятках: правки в API, миграции схемы данных, обновления интерфейсов. Считали три метрики — время прохождения задачи от постановки до слияния, долю правок, закрытых автономно, и долю возвратов на доработку. Замеры шли две недели до внедрения и столько же после — чтобы сравнение не смазали разовые всплески.

Как было до

Задача шла по цепочке вручную: разработчик читает постановку, ищет связанный код, пишет правку, гоняет тесты, отвечает на замечания при проверке. На типовом изменении это 2-3 дня, и само написание занимало меньшую часть — остальное уходило на разбор контекста и переключения между задачами. Примерно каждая пятая задача возвращалась на доработку: не покрыт смежный случай, разошлись контракты, затронут лишний модуль.

Что изменили и что стало

Подготовительную часть отдали агентам: сбор контекста по репозиторию, черновик правки, прогон тестов до проверки человеком. Инженер утверждал план и принимал результат, правило слияния не меняли — без зелёных проверок в основную ветку ничего не уходит. Время прохождения задачи сократилось до 6-9 часов, доля правок, закрытых автономно, выросла до четырёх из десяти, возвраты на доработку упали с 21% до 7%.

Эффект держится на типовых изменениях: задачи, меняющие архитектуру, остаются целиком за инженером — там агент ускоряет разведку по коду, но не решение.

Чем автономный агент отличается от автодополнения кода

Автодополнение кода работает на уровне строки: модель видит открытый файл и соседние фрагменты, предлагая следующее выражение в момент набора. Оно не знает, какую задачу вы решаете, и не проверяет, соберётся ли проект после подсказки. Принять её или отклонить — решение инженера на каждом шаге.

Автономный агент получает задачу формулировкой — описание дефекта, требования к поведению — и разворачивает её в план правок. Он определяет, какие модули затронуть, в каком порядке вносить изменения, где нужны новые тесты и что потянет правка за собой. Планирование правок идёт до первого изменения файла, поэтому на выходе связный набор изменений, а не россыпь подсказок.

Ключевое отличие — правила проверки. Агент не может считать работу законченной, пока не пройдут тесты, статический анализ и проверка типов, заданные обязательными. Упавшая проверка возвращает вывод в цикл: агент читает ошибку, правит код и запускает прогон снова. Число итераций ограничено, и при исчерпании попыток задача возвращается человеку с отчётом, а не с молчаливым «вроде работает».

В нашей практике Factory AI подключали именно на этом уровне: агент работал в отдельной ветке, с запретом трогать конфигурации сборки и миграции данных, а слияние оставалось за ревьюером.

Отсюда разница в назначении: автодополнение экономит время на наборе, автономный агент сокращает путь от задачи до проверенного изменения — при условии, что правила проверки и границы его работы описаны заранее.

Технические сомнения: ограничения, риски, контроль

Автономная разработка не снимает инженерных ограничений — она переносит их в зону настройки и контроля. Ниже пять вопросов, которые задают до старта внедрения Factory AI: доступ к секретам, изоляция среды, измерение качества, судьба незакрытых задач и совместимость с правилами, уже развёрнутыми в вашем репозитории.

Правки уходят прямо в рабочую ветку?

Работа идёт на изолированной копии — отдельный контур, собственные тестовые данные, никаких обращений к боевым базам. Изменения попадают в основную ветку только через проверку кода и обязательные автоматические проверки, которые уже настроены в проекте.

Как вы измеряете качество результата?

Три метрики: доля путей, покрытых автоматическими проверками; доля изменений, принятых без правок человеком; время от обнаружения дефекта до отката. Они снимаются на каждом этапе, поэтому деградация видна до релиза, а не после.

Что происходит с задачами, которые агент не закрыл?

Работа не исчезает: остаётся ветка с историей, черновик изменений и журнал попыток. Задача помечается и передаётся инженеру вместе с контекстом — он продолжает с той же точки, а не восстанавливает ход рассуждений заново.

Это совместимо с нашими правилами и линтерами?

Да. Настройки линтеров, шаблоны коммитов, схемы ветвления и уже развёрнутые правила читаются из репозитория как есть. Агент подстраивается под существующий порядок работы, а не требует переписать конфигурацию под себя.

Обсудим задачу: разберём ваш контур и вернёмся с планом

Чтобы оценка сроков опиралась на факты, а не на средние по рынку, начинаем с вводных данных о вашем контуре разработки. Полный аудит не нужен — достаточно описать текущее состояние, и мы вернёмся с планом внедрения Factory AI, разбитым по этапам.

• Как устроены репозитории: языки, системы сборки, доля устаревшего кода.
• Процессы ревью и релизов: кто согласует изменения и какие проверки обязательны перед выкладкой.
• Система трекинга задач и формат требований — от них зависит, насколько автономно сможет работать агент.
• Тестовый контур: насколько он близок к промышленному и какие проверки запускаются автоматически.
• Ограничения по данным: что запрещено выносить за периметр, нужна ли изоляция внутри вашей инфраструктуры.
• Критерии приёмки и метрики: доля задач без правок, время до релиза, покрытие проверками.

В ответ вы получаете план внедрения: этапы, порядок подключения к вашему контуру, требования к доступам, состав пилотной группы задач и сроки каждого этапа с точками сверки результата.

Чтобы обсудить задачу, достаточно короткого описания контура и ваших ожиданий. Опишите её — вернёмся с оценкой сроков и планом внедрения.