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

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

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

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

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

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

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

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

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

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