Тёмная фабрика и с чего начинать

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

Цифры

СО СЦЕНЫ: Kikimora, внутренняя фабрика Tessl

• Кто и где: Роб Уиллоуби, AI engineering lead, Tessl — «Inside the Dark Factory: AI That Ships Code Solo», AI Native DevCon 2026.
• Что показали: внутренняя фабрика под кодовым именем Kikimora забирает тикеты из Linear, гоняет агента в песочнице, ведёт PR через ботов-ревьюеров и CI и мёрджит результат. «Тёмная» — потому что в логи в момент работы никто не смотрит, только post-hoc.
• Цифры: 65–70% всех PR компании идут через фабрику; ~40% PR в продакшен; 516 PR за неделю, когда вся компания была на выездной встрече; ~600–700 PR в неделю в целом при ~24 инженерах. Отдельно по коду самой фабрики: человек когда-либо смотрел в PR около 5% — то есть 95% кода фабрики никто не видел. Рекорд по автомёрджу: 150 PR за выходные на двоих.
• Что это меняет: это производственная система, у которой есть пропускная способность, очередь и режим отказа. Инженерить её нужно по правилам системной инженерии.

Уиллоуби объясняет название дословно: «It's called a Dark Factory because we're not looking at the logs as it's operating».

Начали они с двух правил, которые Дру Нокс перечисляет в докладе «Harness Engineering: The New Discipline of Agentic Dev»: (1) больше никакого написанного человеком кода, (2) больше никаких интерактивных сессий с кодинг-агентом. Второе вызвало в зале реакцию, которую он описывает как «Two people collapsed out of shock». Но на практике, по его словам, это оказалось малым шагом: люди и так запускали агента, уходили в другую вкладку и потом ревьюили результат — ревью при этом шло в чате вместо PR.

Правило автомёрджа

Самое ценное в докладе Уиллоуби — правило, которым они объясняют политику мёрджа:

Если мы не можем это автомёрджить, значит, у нас нет верификации, дающей уверенность.

Фраза звучит как бравада, а работает как диагностический инструмент. Разберём, что за ней стоит.

Первое: автомёрдж служит измерением зрелости верификации. Обычная логика — «мы доверяем агенту настолько, что готовы мёрджить». У Tessl логика обратная: невозможность автомёрджа означает, что вы не знаете, работает ли код, — и человеческое ревью в этой ситуации лишь маскирует проблему. Человек в PR не проверяет, что интеграционные тесты покрывают маршрутизацию. Он смотрит на дифф. Если уверенность держится на том, что «Вася посмотрел», верификацией она не является.

Второе: правило применяется по зонам. У Tessl автоматически мёрджится код самой фабрики, research-часть и то, что строит GTM-команда. Продакшен-код — то, что видит пользователь, — требует человеческого ревью. То есть правило формулируется так: в каждой зоне мы честно отвечаем, есть ли у нас верификация, и не притворяемся.

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

Побочный эффект оказался культурным: люди начали сами дробить свои PR, потому что маленький и изолированный PR уедет без человека. Нокс отвечает этим же на вопрос из зала о начальнике, который выкатил PR на 100 тысяч строк без обсуждения: культуру меняет кодификация. Целевой размер PR у них — 200–300 строк. Если маленький сфокусированный PR классифицируется как low risk и уезжает автомёрджем, люди сами начнут дробить свои двадцатитысячные диффы. Его же оговорка: «это частичные ответы, культурную часть мы всё ещё выясняем».

Четвёртое: accountability не переезжает. Уиллоуби фиксирует это отдельно — ответственность остаётся на том, кто завёл тикет. Формула «Dark Factory сделала» не снимает accountability ни с кого.

Пятое: реакция на прорыв — fix forward. Когда в автомёрдж проезжает что-то нежелательное, вопрос звучит «что мы не проверили, раз это прошло», и следом заводится verifier или тест. И к этому прилагается намеренно избыточная коммуникация: команда фабрики шлёт в свой Slack-канал в 10–15 раз больше сообщений, чем другие команды, будучи меньше по размеру. Причина простая: кодовая база меняется способами, которых никто не отслеживает вручную. Итоговая формула Уиллоуби: «Autonomy is earned, not enabled».

Автономия и автоматизация — разные оси

Нокс отдельно разводит понятия, которые в разговорах постоянно слипаются.

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

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

Третья ось — качество, и по нему у Нокса порядок такой: сначала не просаживать, потом поднимать.

Спор: где стоит человек

Здесь материал расходится, и расхождение содержательное. Три позиции.

Tessl: автомёрдж как тест на зрелость верификации. Позиция описана выше. Человек стоит там, где верификация ещё не построена, — и это временное состояние, которое надо сокращать.

GitHub Next: PR — жёсткие человеческие ворота, и это не обсуждается. Дон Сайм в «The Agentic Repository Automation Revolution» говорит, что в GitHub Agentic Workflows агенты никогда не мёрджат pull request. PR — точка, где человеческий надзор гарантирован конструкцией. При этом он же считает нормальным сознательно тормозить фабрику под человеческие и организационные нужды: «It's always okay to slow down the factory» — домашнюю фабрику тоже не гоняют ночью.

Патрик Дебуа: тусклая фабрика. В разговоре «The DevOps Godfather on AI's Dark Factory Problem» он снимает саму бинарность. Реалистичный вариант он называет dim factory: спектр от микроменеджмента до автономного одобрения, и уровень риска выбирается отдельно для каждой новой функции. Автономными станут не все фичи, поэтому он предлагает инвестировать в аудит, provenance (кто менял код), verifiers и situational awareness при отказах, не гоняясь за автономией как самоцелью. Про сопротивление у него есть точное наблюдение: «"It will not work here" — what they're actually signaling is: we're not ready yet».

Разница между позициями — в том, что считается источником уверенности, и к смелости она отношения почти не имеет. У Tessl это верификация, и человек — временная заглушка на её месте. У Сайма человеческие ворота — конструктивная константа, не зависящая от качества верификации, потому что автоматизация масштабируется на чужие репозитории, где вы не контролируете, насколько хороша чья-то проверка. У Дебуа выбор источника уверенности привязан к риск-аппетиту конкретной фичи и не является свойством компании.

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

Провал: переписать систему по одной верификации

Самый полезный кусок в докладе Уиллоуби — эксперимент, который не сработал.

Гипотеза была такая: если слой верификации достаточно силён и описывает поведение системы независимо от реализации, систему можно переписать с нуля на другом языке, дав агенту только верификацию. Проверяли на переписывании самой фабрики на Elixir. Агенту дали интеграционные и end-to-end тесты, формальную модель и свойства.

Получилось «что-то» — и это «что-то» вскрыло слепые зоны:

• маршрутизация по меткам Linear проверялась только юнит-тестами — верификация была привязана к реализации, хотя должна описывать поведение;
• стекинг PR не покрывался end-to-end вообще;
• батчинг CI-сигналов не покрывался тоже.

Новую реализацию включали дважды, и оба раза она ломала чужие PR. Вывод Уиллоуби: «Even after all the investments on verification we thought we had made, we had some pretty big blind spots».

Ценность этого эксперимента в том, что он даёт дешёвый способ измерить качество своей верификации — независимо от того, что само переписывание провалилось. Обычно вы узнаёте о дыре в покрытии, когда через неё проехал баг. Здесь дыра проявляется сразу и списком: всё, что новая реализация сломала, — это то, что ваша верификация не описывала. Если правило «нет автомёрджа — значит, нет верификации» звучит для вас слишком абстрактно, то этот эксперимент — его исполняемая версия.

Контрпример из того же доклада показывает, как выглядит обратный исход. У них была гонка очереди: комментарии PR попадали в очередь дважды, два агента в разных песочницах отвечали на один и тот же элемент, возникали гонки и конфликтующие коммиты. Чинили и регрессировали снова и снова — около 60 PR за 2–3 дня ушло в попытки. Решение — формальная модель поведения очереди на Quint, проверяемая на каждом PR. Модель вместе с фабрикой сделали примерно за день, после чего рецидивов не было. Комментарий Уиллоуби: «I wouldn't have known how to do that in a pre-agent world. Just flat out».

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

Границы автономии: что отдают, а что нет

Что отдают полностью	Что оставляют человеку
Код самой фабрики, research, GTM-инструменты (Tessl)	Продакшен-код, который видит пользователь (Tessl)
Триаж, метки, обновления, предложения улучшений (Сайм, repo assist)	Мёрдж pull request — всегда (GitHub Agentic Workflows)
Ночные maintenance-агенты в низкорисковых зонах (Нокс)	PR в продакшен-путях — идут человеку (Нокс)
Классификация риска PR по человекочитаемой политике	Согласование самой политики риска
Декомпозиция и последовательность подзадач внутри функциональности	Постановка задачи и accountability за тикет
Работа с данными за периметром через фиксированный словарь (Шошан)	Свободный текст наружу — только approved-группе

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

И меняется круг тех, кто может отгрузить код: у Tessl первый продакшен-PR провёл человек из people ops, а глава юридического отдела ходила с ноутбуком и отгружала код. Оговорка Нокса: запускать это надо в облаке, и ноутбук для такой работы не место.

Возражение про слоп

Главное возражение против фабрики — «скорость ценой качества». Нокс отвечает аргументом про бэклог: большинство багов известны и лежат P2, потому что чинить дорого. С фабрикой ёмкость такова, что бэклог как понятие исчезает, включая нишевые кейсы, до которых никогда не доходили руки. Показательно: те же пять «линз» ревью на человеческих PR вызывали жалобы «слишком много замечаний», на агентских те же линзы просто исправляются. Его формула: «If an agent can identify a problem, it can be fixed». Цифры у него косвенные — по его словам, у Intercom снизилось число багов, проходящих ревью, за счёт масштабирования усилий на ревью.

Дон Сайм закрывает смежное возражение — «агенты съедят всю работу»: автомобиль породил поездки, которых не было, фабрика — товары, которых не было. Его пример: continuous accessibility. Нанять отдельного инженера по доступности нельзя, а прогнать агента по работающему приложению — можно.

Как туда попадают

Нокс настаивает, что правильный вопрос звучит «на сколько процентов вы фабрика». Схема, которую он предлагает: выбрать рабочий процесс, положить его в коробку, понятную агенту, погонять интерактивно и набрать уверенность, затем автоматизировать. Монолитная трёхмесячная перестройка обречена — индустрия за это время изменится. «It's much easier if one piece doesn't work to just roll it back, rip it out and try something else». Реалистичная траектория, о которой он говорит: через полгода вдруг оказывается, что 40–50% PR никто из людей не смотрит.

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

Коротко

• 65–70% PR через фабрику, ~40% PR в продакшен, 95% кода самой фабрики человек никогда не видел в PR, 150 PR за выходные на двоих — перед нами работающая производственная система (Уиллоуби, Tessl).
• Правило «не можем автомёрджить — значит, нет верификации» работает как диагностика: человеческое ревью на месте отсутствующей проверки маскирует проблему.
• Автономия и автоматизация — разные оси. «Ревью стало бутылочным горлышком» — это разблокированная автономия при незакрытой автоматизации.
• Спор реальный: Tessl мёрджит автоматически там, где верификация доказана; GitHub Agentic Workflows не мёрджат PR агентами никогда; Дебуа предлагает спектр с риск-аппетитом на фичу. Общего ответа нет, есть проверяемый признак — можете ли вы назвать проверку, которая поймала бы конкретный класс ошибки.
• Эксперимент с переписыванием на Elixir по одной верификации провалился дважды и вскрыл слепые зоны (маршрутизация только в юнит-тестах, стекинг PR и батчинг CI без end-to-end) — это дешёвый способ измерить своё покрытие.
• Ответственность не переезжает на фабрику: она остаётся на том, кто завёл тикет.

С чего начинать оснастку

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

Порядок сборки

Шаг 0. Legibility — сделать работу видимой

• Перевести взаимодействие на цепочку «тикет, агент, PR, комментарии».
• Запретить локальную конфигурацию агентов: всё в репозиторий.
• Зачем: пока сигналы в логах на чьём-то ноутбуке, чинить нечего.
• Цена: неделя, ноль бюджета. Дешевле всего остального.
• Источники: Dru Knox (Tessl); OpenAI white paper о пятикратном росте за 2–3 месяца.

Шаг 1. Изоляция — дать каждому агенту свой воркспейс

• Отдельный контейнер, каталог или десктоп. Никаких пяти агентов в одной папке.
• Зачем: без этого параллелизм уничтожает работу вместо того чтобы её ускорять.
• Источник: Luke Marsden (HelixML) — 5 агентов, 2 инцидента за 2 дня.

Шаг 2. Детерминированная верификация — inner loop

• Компилятор, типы, линтеры, юнит- и интеграционные тесты.
• Всё, что можно сделать детерминированным, делать детерминированным.
• Педантичность теперь дешёвая: исполнять правила будет не человек.
• Источник: Dru Knox (Tessl).

Шаг 3. Verifiers — то, что в regex не выражается

• Один verifier на одно утверждение. Триггер — glob по файлам.
• Оценка — LLM-as-judge, один вызов на утверждение.
• Правило: увидел ошибку агента — не правь руками, заведи проверку.
• Источники: Dru Knox, Rob Willoughby (Tessl). Больше 100 verifiers на PR, порядка $0,30 в день.

Шаг 4. Песочница с полным стеком

• Всё, что может локальный инженер, за вычетом учётных данных.
• Прогретые окружения: старт занимает секунды вместо сорока минут.
• Агент кладёт скриншоты и видео в PR — проверка идёт глазами, без захода по SSH.
• Источники: Rob Willoughby (Tessl), Luke Marsden (HelixML).

Шаг 5. Outer loop — дорогие ворота на границе PR

• Агентное ревью, агентный QA, mutation testing.
• Норма — зелёный с первого раза. Красный outer loop означает, что проверка стоит не там.
• Источник: Dru Knox (Tessl). Порядка $25 на PR.

Шаг 6. Meta loop — петля, которая чинит петли

• Ночной разбор логов, PR-комментариев и упавших CI.
• Промоушен повторяющихся замечаний в verifiers (shift left).
• Правило: объяснил агенту дважды — это долг в оснастке.
• Источники: Dru Knox, Rob Willoughby (Tessl).

Шаг 7. Risk classification — кто решает, нужен ли человек

• Агент прогоняет PR против человекочитаемой политики.
• Политика — обсуждаемый скилл, открытый для ретро и донастройки.
• Калибровка: сначала ревьюить всё и сверять с решением классификатора.
• Источники: Rob Willoughby, Dru Knox (Tessl).

Шаг 8. Автомёрдж — только в зонах с доказанной верификацией

• Начинать с внутреннего тулинга, продакшен-путь оставить на потом.
• Реакция на прорыв — fix forward: что мы не проверили, раз это прошло.
• Источник: Rob Willoughby (Tessl). «Autonomy is earned, not enabled».

Обрати внимание на два свойства этого списка. Первое: шаги 0–1 не требуют бюджета и не требуют разрешения. Второе: шаг 8 не является целью. Дон Сайм (GitHub Next) вообще его не делает — в GitHub Agentic Workflows агенты не мёрджат PR никогда, и это осознанное проектное решение. Патрик Дебуа предлагает выбирать уровень автономии на каждую функциональность отдельно. Список описывает порядок, в котором элементы становятся возможными. Обязательную дистанцию он не задаёт.

Что проверить сегодня

Пять вопросов, которые дают честную картину за полчаса.

1. Где хранится история того, как агент ошибся вчера? Если ответ «в терминале Васи» — вы на шаге 0, и всё остальное преждевременно.
2. Какое замечание вы написали в PR третий раз за месяц? Оно должно было стать verifier'ом после второго. Это самый дешёвый первый verifier, который у вас есть.
3. Назовите проверку, которая поймала бы последний баг, доехавший до продакшена. Если не называется — у вас нет верификации в этой зоне, и человеческое ревью её не заменяет. Оно её маскирует.
4. Что сломается, если два агента запустятся в одном каталоге? Если ответ неизвестен — первым делом нужна изоляция, и только потом проверки.
5. Сколько мест в вашей системе требуют человека, залогиненного руками? Доступ к базе, к логам, к административной панели, к фиче-флагам. Каждое такое место — целый класс задач, недоступный агенту. Нокс предупреждает: их больше, чем кажется.

Чего не делать

Не начинать с автомёрджа: он стоит в конце списка. Правило Tessl при этом читается так: они мёрджат то, что умеют проверять, и честно признают, где не умеют. Смелость тут ни при чём.

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

Не резать бюджет на токены как первый шаг оптимизации. Дебуа: это ломает обучение организации. Оптимизировать надо вынесенные в отдельные рабочие процессы повторяющиеся задачи, где можно прогнать eval и принять осознанный размен — «на 5% хуже, но на 80% дешевле».

Не давать агенту широкий доступ вместо узкого набора инструментов. Ори Шошан (Cyera): whitelist из 50–60 узких tools с известной поверхностью атаки, bash не дают. И обязательный escape hatch — иначе агент начинает использовать инструменты не по назначению. Это худший режим отказа: снаружи его не видно.

Не запускать агентов в CI без архитектуры безопасности. Дон Сайм формулирует это как прямой запрет. Read-only шаг, без прямого доступа к секретам, узкий safe output, второй не-агентный этап на применение.

Не считать, что «фабрика сделала» снимает ответственность. Уиллоуби: accountability остаётся на том, кто завёл тикет.

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

Что мерить

Token spend в качестве главной метрики не годится. Из материала берутся две связки метрик.

От Дебуа: сколько человеческих касаний ещё нужно, чтобы агент сделал правильно, — эта цифра должна падать. И множитель от перехода от личного контекста к общему: одна правка общего контекста улучшает работу всех команд. Его вывод: герои — те, кто контрибьютит в общие компоненты, «not the token billionaires».

От Нокса: вниз — manual takeovers, человеческие комментарии в PR, случаи ручной декомпозиции тикета; вверх — доля PR, инициированных агентами без участия человека. По качеству: сначала не просаживать, потом поднимать.

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

Последнее

Во всей серии есть фраза, ради которой стоило этот материал разбирать. Роб Уиллоуби сказал её про свою фабрику, где 95% кода никто не смотрел: «Autonomy is earned, not enabled».

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

Поэтому вопрос «готовы ли мы отдать это агенту» всегда переводится в другой: какая проверка поймает нас, если он ошибётся. Если на него есть ответ — автономия уже заработана. Если нет — её нельзя выдать, сколько бы смелости у команды ни было.