Правило первое: код не должен писаться людьми. Правило второе: код не должен проверяться людьми. Оба пункта стоят в уставе ИИ-команды StrongDM, который Саймон Уиллисон разобрал в феврале 2026 года. Первый к тому моменту уже никого не удивлял. Второй удивляет до сих пор, и Диогу Соареш, инженер с пятнадцатью годами опыта в разработке, честно пишет, что каждый его инстинкт против: непроверенный код это то, с чего начинаются инциденты.

Тем не менее идея не исчезает. Кодинг-агенты работают часами, открывают пулл-реквесты параллельно и сами чинят упавшие тесты. Где-то между автодополнением и «код больше никто не читает» проходит граница, и большинство команд пересекает её, не решив, где она.

У этой границы появилось название. Тёмная фабрика (dark factory) это пайплайн, в котором агенты пишут, тестируют и выкатывают код, не прочитанный ни одним человеком. Светлая фабрика (light или lit factory) делает то же самое, но оставляет людей в точках, где нужно суждение. Вся разница сводится к одним воротам: кто решает, что изменение достаточно хорошее для продакшена.

Откуда взялись термины

Метафора пришла с производства. Lights-out factory работает без людей на полу, поэтому свет там просто не нужен: FANUC годами гоняет роботов, которые собирают роботов, а Адди Османи в своём эссе ссылается на фабрику Xiaomi 2024 года как на свежий пример.

В разработке терминология сложилась за первую половину 2026 года. В январе Дэн Шапиро опубликовал пять уровней ИИ-программирования по образцу уровней автопилота, и верхняя ступень у него называлась тёмной фабрикой софта. В феврале StrongDM показала реальную команду, которая работала по правилам «никто не пишет, никто не проверяет» и проверяла результат скрытыми сценариями. В июле Османи выпустил эссе «Software Factories, Light and Dark», где развёл понятия цикла, обвязки и фабрики и заявил, что выключатель нужен каждому циклу отдельно, а не всей компании.

Его словарь оказался самым рабочим. Цикл (loop) это один агент, который повторяет одну работу: собрать контекст, сделать, проверить, повторить до выполнения условия. Обвязка (harness) это всё вокруг цикла: песочница, инструменты, память и ворота, определяющие, что значит «готово». Фабрика это множество циклов в обвязке, которые кормятся из очереди задач и сливаются через ревью в продакшен. Вопрос «тёмная или светлая» касается только последних ворот.

Генерация подешевела, понимание нет

Агенты сделали написание кода почти бесплатным. Понимание кода они не удешевили никак. Этот разрыв Османи называет долгом понимания (comprehension debt): расстояние между объёмом кода, который существует, и объёмом, который кто-то ещё держит в голове.

Тёмная фабрика набирает такой долг ровно с той скоростью, с какой производит код, и всё это время тесты остаются зелёными. Ничего не выглядит сломанным до момента, когда что-то ломается, а разобраться в этом куске системы некому.

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

Люди недооценивают последний пункт светлой стороны. Фабрика, где человек нажимает «одобрить», не читая, это та же тёмная фабрика, только с дополнительной задержкой. Вы получаете риск тёмной версии и стоимость светлой одновременно.

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

Автономия упирается в проверку

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

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

Ответ StrongDM стоит изучить именно потому, что бьёт в эту точку. Сквозные сценарии лежат вне репозитория, кодинг-агент их не видит: тот же принцип, что holdout-набор при обучении модели. Тестирование идёт против «цифрового двойника вселенной», набора поведенческих клонов сторонних сервисов. И вместо бинарного pass/fail команда измеряет satisfaction, долю прогонов, которые вероятно удовлетворили пользователя.

Бюджет StrongDM повторять не обязательно, принцип переносится на минимальную конфигурацию. Сценарии живут в отдельном репозитории, workflow на пулл-реквесте их подтягивает по токену только на чтение, дальше запускается Playwright по конфигу из этого репозитория. Важна не технология, а граница: агент, который пишет код, не может прочитать или отредактировать проверки, которые его судят. Без этой границы «тёмный» означает просто «непроверенный».

Свет бывает двух видов

Самая практичная мысль Османи в том, что полностью тёмный и полностью светлый режимы ломаются по-разному, поэтому решение принимается для каждого цикла, а не для организации.

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

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

Четыре вопроса перед выдачей автономии

Прежде чем гасить цикл, его стоит оценить по четырём вопросам. Чем он проверяется: типами, property-тестами, сквозными сценариями, линтерами, или единственным критерием «выглядит правильно» и тестами, написанными тем же агентом. Каков радиус поражения: один файл и лёгкий откат или авторизация, платежи, миграции, публичные API. Сколько живёт решение: дни, как у правки линтера или обновления зависимости, или год и больше, как у схемы и архитектурных контрактов. Насколько операция обратима: git revert и передеплой или потерянные данные, утёкшие секреты, отправленные клиентам письма.

Логика выбора короткая. Необратимое и критичное всегда получает человека до мержа. Долгоживущее решение требует человека на плане, а не на каждой строке. Если проверки не относятся к тем, что трудно подделать, цикл остаётся светлым на мерже. Всё остальное можно гасить.

Как это выглядит на практике

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

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

Закономерность простая: в темноте живут циклы маленькие, скучные и хорошо защищённые. Это не ограничение, а условие. Османи приводит эмпирическое правило Декса Хорти: агент держится примерно три-десять шагов, а после двадцати теряет нить. Короткие циклы с крепкими воротами и делают темноту доступной по цене.

Границы прописать текстом

Агент не догадается, где находятся выключатели, поэтому правила autonomy boundaries держат в CLAUDE.md или аналогичном файле, чтобы каждая сессия начиналась с них. Там перечисляют, какие пулл-реквесты можно открывать без спроса (правки линтера, патч-версии зависимостей, тесты, документация) и с каким пределом по размеру. Там же стоит требование: перед любой другой работой выдать план и остановиться на одобрение. Отдельным пунктом идёт список запретов на изменение, куда попадают auth, сессии, платежи, миграции, CI и каталог со сценариями.

Последняя строка в таком файле самая важная: никогда не ослаблять существующий тест или утверждение, чтобы пройти проверку. Это самый частый способ, которым unattended-цикл «успешно» завершает работу, ничего не сделав.

Следите за откатами

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

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

Когда тёмная фабрика не нужна

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

Не гасите цикл, если не можете написать проверки независимо от агента. Если единственные тесты это те, что написал сам агент, вы просите его поставить оценку самому себе. Не гасите его в регулируемой или связанной с безопасностью области: «это никто не проверял» плохой ответ аудитору. Не гасите в легаси с дырявыми тестами: агенты усиливают то, что уже есть, включая путаницу. И не гасите, если в команде нет человека, способного отладить этот код в три часа ночи. Если такого человека нет, вы занимаете понимание в долг.

Часто задаваемые вопросы

Тёмная фабрика и вайб-кодинг это одно и то же?

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

Светлая фабрика значит читать каждую строку агента?

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

Можно ли переходить из светлого режима в тёмный постепенно?

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

Важна ли архитектура, если код пишут агенты?

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

Итог

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

Какой цикл в вашей команде сегодня работает без присмотра, и какая проверка поймает его, если он ошибается? Напишите в комментариях.