Что такое AI Factory

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

Слой 1. Замысел. Требование со стабильным идентификатором, результатом на языке заказчика и критериями приёмки. Архитектурный документ с контрактами, от которых зависят другие, и решениями, у каждого из которых есть абзац о цене. Рабочее задание, куда критерии перенесены дословно, вместе с идентификаторами. Запись прогона с планом, чек-листом, пакетом доказательств и журналом ревью. Как проверить: идентификатор находит ровно один файл, а файл находит все ссылки на себя одним поиском. Главная ошибка при чтении этого слоя: принять его за проверку. Все четыре артефакта пишет тот, кто делает работу, поэтому доказательством правильности они не являются.

Слой 2. Исполнение. Цикл внутри обвязки: песочница, набор инструментов, память между запусками. Как проверить: прогон читается без чата, который его породил, и повторяется другим человеком. Если понять, что происходило, можно только из переписки, значит записи прогона нет, а есть ощущение, что работа шла. Слой 3. Проверка. Ту проверку, которая решает, правильно ли выполнена задача, в методе называют оракулом: дёшево, часто, и её нельзя подделать, и все три свойства сразу, потому что любые два из трёх автономии не дают. Как проверить: выключили поведение в коде и запустили, упали ровно его тесты, остальные остались зелёными. Слой 4. Приземление. Девять гейтов, у каждого назван человек, который подхватывает работу. Как проверить: проверка прошла на точной версии кандидата и находится вне власти того, кого она проверяет. Слой 5. Обратная связь. Сигнал из прода меняет очередь и правила, а обходы процесса не запрещены, а сосчитаны и датированы. Как проверить: есть число обходов за период и список артефактов, которые по ним ещё не дописаны. Слой, у которого такой проверки нет, это намерение, а не слой.

Четыре механизма, три из которых мы фиксировали замером. Проверка живёт внутри того, что агент правит: её настройки и условия запуска обычно лежат в той же зоне изменения, так что автор кода оказывается автором доказательства. Проверка смотрит на то, чего потребитель не видит: строка инструкции длиной 10542 байта, клиент читает первые 2048, восемьдесят процентов невидимо, а тесты искали по всей строке. Проверка не исполняется: 63 из 93 падающих тестов не запускались вовсе, потому что не было плагина, который документация объявляла установленным. Проверка мерит ремонт вместо цели: сторожевой процесс доказал успех канарейкой, которую сам же и запустил, при нуле работающих приложений. Отсюда правило формулировки: критерий успеха обязан называть целевое состояние, а не отсутствие исходного симптома.

Событие, которое решает всё, это обновление основной ветки, а не одобрение ревью. Девять гейтов решают, уходит ли туда конкретный класс задач без человека, и у каждого назван тот, кто подхватывает работу при непрохождении. G1 Объём проходит, когда это одна рутинная ограниченная задача с проверяемым условием готовности, иначе её разбивают или отдают человеку. G2 Зрелость проходит, когда репозиторий достиг хотя бы третьего из пяти уровней зрелости, L3: процессы описаны, их соблюдение обеспечивает автоматика, а тесты, линтеры и проверки безопасности идут на каждом изменении; одного L3 мало, он необходим, но не достаточен, иначе агент только готовит кандидата, а в ветку кладёт человек. G3 Риск проходит, когда путь лежит вне авторизации, биллинга, схем, миграций и публичных контрактов, иначе задача уходит на ручной контроль. G4 Оракул проходит, когда проверка дёшева и часта, и её нельзя подделать, иначе диф читает человек либо строится оракул сильнее. G5 Обвязка проходит при урезанных инструментах, изоляции состояния и ресурсов и записанной базовой версии, иначе запускать без присмотра нельзя. G6 Улики проходят, когда диф, проверки, логи и объяснение привязаны к версии кандидата, иначе кандидат возвращается во внутренний цикл. G7 Независимая проверка перед веткой проходит в одном из двух режимов: либо ветка принимает изменение только после успешной защищённой проверки на точной версии кандидата, либо CI проверяет уже отправленную версию, следующая отправка не идёт до подтверждения, а сбой включает G9, иначе проверяющим становится человек. G8 Полномочие на выкатку проходит, когда тот, кто кладёт код в ветку, в одиночку не выкатывает прод, иначе это считается релизом. G9 Итог и восстановление проходит, когда влитая версия наблюдается, а откат возвращает зелёное состояние, иначе без присмотра в ветку ничего не попадает. Автономия выдаётся классу задач, никогда не репозиторию целиком. Основную нагрузку несут два гейта: первый спрашивает про свойства проверки, второй про то, кто управляет проверяющим. Хук на ноутбуке разработчика второго не даёт, его снимают одним флагом.

Рёбра между артефактами уже лежат там, где их никто не забудет обновить. Задание указывает на требование идентификатором внутри себя. Изменение указывает на требование служебной строкой в сообщении коммита. Изменение указывает на доказательства каталогом прогона, ключом которого служит версия кандидата. Сигнал из прода указывает на задание, которое на него отвечает, своим идентификатором внутри этого задания. Граф пересобирается из чистой копии за один прогон, а разорванная связь обрушивает проверку, а не пишет предупреждение. Разница между таким графом и базой принципиальная: хранилище нужно синхронизировать с репозиторием, то есть появляется вторая вещь, которая может устареть, причём устаревание в слое прослеживаемости невидимо до момента, когда трассировка понадобилась. Граф, собираемый из репозитория, устареть не может. Теперь о том, чем фабрика не является. Это не обещание автономии: правдивый результат оценки часто звучит как «этот класс задач может вливаться в ветку без человека, и больше никакой». Это не распространение изменений из требования в код: такого не умеет никто, включая продукты, которые эту фразу рекламируют, а поставляется на деле детектор расхождений плюс процесс с человеком внутри. Это не замена ревью на второго агента: проверяющий на той же модели с тем же контекстом повторяет те же ошибки, а не проверяет независимо. И это не передача ответственности: она переходит договором, а не конвейером, поэтому у вендора, который её обещает, стоит спросить пункт договора. И это не про количество написанного кода: долг понимания копится и при полностью зелёных тестах, а ни одно измерение модели зрелости его не ловит.

На классах задач, проходящих гейты, рутинная поставка идёт примерно в 3 раза дешевле и в 5 раз быстрее, чем через человеческую очередь на ревью. Дорогим в рутине никогда не был набор кода: дорогим было ожидание ревьюера, среды и человека, который помнит, почему модуль устроен именно так. Что показали замеры на реальных системах: 93 красных теста превратились в 13 за один день в одном репозитории; 63 из 93 падающих тестов не запускались вовсе; 80 процентов проверенного не доходило до потребителя; проверка памяти отрапортовала 8192 МБ на машине с 49152 МБ; p75 размера изменения составил 5, 6 и 12 файлов в трёх репозиториях одной команды; живой статус публиковала одна параллельная сессия из восьми. Второй эффект менее очевиден и в долгую важнее. Когда у каждого изменения есть требование, пакет доказательств и запись прогона, вопрос «зачем это было сделано» остаётся отвечаемым через год, без обращения к человеку, который к тому времени может уже не работать в компании.

Вопрос про платформу задают целиком, а отвечать на него нужно по строкам: для каждого модуля вендора называется локальный эквивалент, то, из чего он собирается, и способ проверить, что он работает, а не просто присутствует. Требования это markdown в репозитории на git с шаблоном и ревью. Архитектура это три уровня документов и соглашение об именах. Рабочие задания это задача в том трекере, который уже используется. Граф знаний это артефакт сборки, а не база, и собирает его скрипт в две-три сотни строк. Прослеживаемость это служебная строка в коммите плюс пакет доказательств, git и CI. Детектор дрейфа это красная проверка по расписанию, а не письмо. Тесты и приёмка это девять гейтов и свой потолок размера: его берут с p75 истории самого репозитория, а изменение крупнее разрешено, просто теряет право уйти в ветку без человека. Отдельно стоит проверка, которая решает, платформа перед вами или обёртка: один и тот же вход обрабатывается дважды на самой сильной модели и один раз на самой дешёвой. Если качество рушится на дешёвой, вы покупаете провайдера модели, а наценка идёт за обёртку. Остальные заявки проверяются так же, на вашем собственном материале: детектор дрейфа против набора, где половина примеров намеренно расходится с кодом; двадцать вопросов о вашем репозитории, ответы на которые вы уже знаете; извлечение правил из модуля, чьи правила вы уже выписали. И то, что не собирается своими силами ни при каком бюджете: подпись под ответственностью за дефект в проде, канал продаж к регулируемому покупателю, референсные клиенты и люди, готовые выйти на проект со следующей недели.

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

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