Программная фабрика — это масштабированные зацикленные процессы. Вы можете запустить цикл с участием людей (светлая фабрика): жертвуя скоростью и риском поломок ради суждений и концентрации. Или вы можете игнорировать людей (темная фабрика) и позволить агентам самостоятельно определять объем работ, писать и поставлять код, без реального чтения деталей. Но если люди перестанут читать, они перестанут понимать ваше программное обеспечение. Ваша самая сложная задача теперь — знать, какие проверки внедрять и сколько автономии делегировать.
Сама идея программной фабрики восходит к статье Боба Бемера «Экономика производства программ», представленной в 1968 году. На протяжении полувека многие мечтали о мире, где разработка ПО — это повторяемый и измеримый производственный процесс (аналогичный штамповке автомобильных деталей на заводе), а не изолированное ремесло отдельных людей. Исторически эта мечта обычно (хотя и не всегда) терпела крах, отчасти из-за сложности «штамповки» идей.
Но за последние два года всё изменилось настолько драматично, что сейчас имеет смысл по-новому взглянуть на старую мечту. И поскольку некоторые нюансы легко упустить, стоит проявить определенную точность в отношении того, что действительно ново и отличается, а что может быть повторяющимися ловушками, замаскированными под новые возможности.
@dexhorthy, соучредитель HumanLayer, недавно выступил с отличным докладом на AI Engineer World's Fair под названием «Harness Engineering недостаточно: почему программные фабрики терпят неудачу», который стоит посмотреть на эту тему.
Цикл — это атом. Фабрика — это цикл в масштабе.
Структура — это всё, и всё начинается с малых единиц. Весь стек, по сути, состоит из трех концепций, наложенных друг на друга: цикл, обвязка (harness) и фабрика.
Цикл — это один агент, выполняющий одну задачу повторно: собрать контекст, совершить действие, проверить результат и повторить, пока не будет выполнено какое-либо условие. Это наименьшая единица агентной работы, и всё, что выше, — это просто циклы, наложенные на циклы.
Смысл цикловой инженерии в том, что вы перестаете давать агенту инструкции «пошагово» и вместо этого проектируете небольшую систему, которая делает это за вас.
Обвязка (harness) — это границы вокруг цикла: песочница, в которой он работает, инструменты, к которым он может получить доступ, память, сохраняющаяся между запусками, и шлюзы, определяющие, что означает «готово». Цикл — это поведение; обвязка — это среда, в которой это поведение выполняется.
Дайте сырой модели без обвязки, и она будет счастливо вращаться бесконечно. Обвязка — это всё вокруг нее, что делает ее полезной и безопасной для запуска.
Программная фабрика — это множество обвязанных циклов, работающих одновременно, питаемых из очереди задач и проходящих через шлюз рецензирования в продакшн, при этом люди контролируют всё сверху. Это не bigger агент; это организационная диаграмма, состоящая из циклов.
Конечный парадигмальный сдвиг — это переход от написания кода к созданию и запуску фабрики, которая его пишет. Единица работы смещается на уровень выше, к циклу, обвязке и потоку между ними, а не к отдельному diff'у кода.
Цикл → обвязка → фабрика. Фабрика — это не более умный агент; это множество обвязанных циклов, питающих один шлюз рецензирования, причем человек контролирует внешний цикл. Фабрика, нарисованная
Центральный слайд, на котором Декс остановился дольше всего, был блестящим, потому что это проясняющая принципиальная схема, которая визуализирует то, что иначе было бы очевидным циклом. Вот моя интерпретация:
Фабрика — это замкнутый цикл: намерения и сигналы продакшна питают очередь, обвязка собирает, автоматические проверки и шлюз рецензирования проверяют, деплой доставляет, мониторинг превращает продакшн обратно в сигналы. Намерения поступают от видения технического руководства и напрямую от инженеров в очередь задач. Сигналы, вызванные инцидентами и запросами пользователей, также направляются в ту же очередь.
Обвязка — это просто то, что выбирает элемент из очереди и создает для него изменение. За обвязкой мы видим все автоматические проверки, необходимые для того, чтобы изменения были достаточно безопасны для выпуска в продакшн. Эти автоматические проверки выполняются одновременно, без усилий, без сознательного участия инженеров, благодаря CI, тестам, статическому анализу и сканированию всех видов. Единственная точка принятия решения здесь — это шлюз рецензирования. После одобрения изменения развертываются и контролируются в продакшне, а данные мониторинга поступают обратно в сигналы, которые запустили цикл.
В целом, каждый блок на этой диаграмме стоит почти ноль: генерация, тесты, сканирование. Они все работают в масштабе с ничтожными затратами. Есть только один дорогой блок, который упорно сопротивляется масштабированию, и это шлюз рецензирования. Этот блестящий янтарный блок — это «суждение», и именно здесь находится суть аргумента о том, можем ли мы сделать разработку быстрее и чаще.
Почему мы называем это «темным»
Темная фабрика работает с физически выключенным светом, потому что единственное, что находится на полу, — это машины, а машинам не нужен свет, чтобы видеть. Темная программная фабрика — это то же самое: код поставляется без прочтения человеком, проверенный только другими машинами.
Этот образ заимствован из производства. Его происхождение — физическое, а не цифровое, коренящееся на предприятиях, где свет выключен, а работу выполняют роботы. FANUC в Японии работает на таких «безлюдных» фабриках с 2001 года; Xiaomi в 2024 году открыла свою собственную heavily automated темную фабрику. Что их объединяет, так это продукт, собранный и отправленный без единого человека, прочитавшего что-либо из этого. «Темнота» наступает, когда этот акт чтения удаляется из процесса.
Я заимствую эту концепцию не ради ее атмосферы или как оскорбление. Несмотря на весь жуткий хайп, «темнота» здесь — это простое физическое утверждение: оригинальный заводской цех, но без света. В программном обеспечении цех — это diff. Кто бы ни написал diff, кто бы ни рецензировал его, кто бы ни отправлял его, эти люди исчезли, и остался только diff, проверенный только машинами, которые его создали.
Это удивительно легко сделать, по крайней мере, на первый взгляд. Легко, потому что отсутствие этапа рецензирования мешает всему. Его отсутствие заставляет ваше восприятие вертикальной пропускной способности команды внезапно и радикально возрасти. Кажется, что вы преодолели звуковой барьер. Несмотря на кажущуюся легкость, выжить в этих темных рабочих процессах со всеми их скрытыми издержками сложнее, чем кажется.
Harness Engineering недостаточно
Обвязка оркестрации, изолированного прототипирования и вызова инструментов, поскольку модели взаимодействуют с миром и друг с другом, будет становиться все более мощной и эффективной. Однако существует внутренняя, присущая модели, ошибка в попытке поддерживать качество кодовой базы в долгосрочной перспективе и при аддитивных изменениях, и я думаю, есть веские причины полагать, что одни модели в конечном итоге проиграют эту битву долгу понимания.
Долг понимания — это растущий разрыв между тем, сколько кода существует, и тем, сколько из него еще понимает какой-либо человек. Темная фабрика не погашает этот долг; она накапливает его так быстро, как только может, при этом тесты остаются зелеными на всем пути.
Это важное различие, потому что модели хорошо справляются с некоторыми задачами. Но для всего, что не является немедленным изменением небольшой части кодовой базы, особенно в сложной brownfield-системе, автоматическое кодирование только на основе модели сталкивается с непреодолимым препятствием. Greenfield-приложения, выходные игрушки и побочные проекты схожи в том, что нескольких месяцев циклов разработки обычно достаточно, чтобы привести все в рабочее состояние или, по крайней мере, достаточно близко к нему.
Но корпоративная система, разрабатываемая десять лет или более, — это совсем другой зверь; ее нужно поддерживать в профессиональной среде в профессиональном темпе. Через три-шесть месяцев после начала проекта вы уже тонете в непрочитанном коде. Такая среда, и особенно ограничения, налагаемые продакшн-кодом, заставят даже мощного агента работать плохо, и все это в отличие от «vibe coding», которым наслаждаются разработчики, работающие над выходными игрушками.
Декс из опыта сообщает, что это является серьезной неудачей, настолько серьезной, что потребовалось кропотливое ручное исследование, чтобы точно определить ее причину. Это произошло в результате работы полностью автоматизированной фабрики кода в течение примерно четырех месяцев, в течение которых ни один человек не смотрел на написанный код. В основе этого опыта лежит компромисс между двумя противоречивыми метриками. Одна — максимизация использования токенов, число, которое мы в настоящее время считаем прогрессом. Другая, которую она тихо минимизирует, — это объем системы, который любой участвующий человек все еще понимает в любой момент времени.
Где темная фабрика действительно сияет, так это в своей способности быстро перерабатывать безупречный код, пока тесты остаются зелеными. Окончательная расплата, когда она наступит, не будет драматичным моментом «всё пошло наперекосяк». Это будет тихо и поздно.
Темная и освещенная — это один и тот же конвейер, но с размещенным в разных местах светом. Освещенная версия не просто добавляет рецензирование в конце — она перемещает человеческое суждение вверх по потоку, на этапы проектирования и архитектуры тоже. Узким местом никогда не была генерация
Фундаментальное ограничение программной фабрики — это не то, сколько кода мы можем выдать; это то, как быстро мы можем его проверить.
Обратное давление — это правило, согласно которому вы можете дать циклу ровно столько автономии, сколько можете дешево и надежно проверить, и ни на дюйм больше. Верификация, а не генерация, является реальным ограничением для фабрики.
Поскольку неограниченная мощность генерации находится в постоянном напряжении с конечным, не масштабируемым ресурсом человеческого внимания, основная проблема — это разрыв между дешевой генерацией и ограниченным рецензированием. Посмотрите на воронку: пока горлышко, представляющее верификацию, не расширяется, будет образовываться пробка. Как указывает Декс, объем сам по себе не является проблемой: на самом деле мы страдаем от избытка плохих PR. Когда у вас большой объем без надежных шлюзов, производственные дефекты неизбежны. Это снова обратное давление: автономия не может расширяться за пределы того, что можно дешево и надежно проверить.
Проблема второго порядка заключается в том, почему улучшение модели не должно автоматически закрывать разрыв между тем, что она может генерировать, и тем, что можно проверить. Обучение на хорошо спроектированных системах — это, возможно, более сложная задача, чем прохождение простых тестов: помните, функции затрат, измеряющие архитектурное совершенство, измеряются не в секундах или даже минутах, а в месяцах и годах. Аккуратные градиенты функционально невозможно вычислить, поэтому система, ожидающая четкой, мгновенной оценки сложных проектных решений, не будет обучена на хороших примерах.
Генерация — это широкое устье; верификация — это узкое горлышко. Ускорение устья только углубляет кучу у горлышка.
Включаем свет обратно
Освещенная фабрика — это тот же конвейер, но с включенным светом там, где живет суждение. Агенты все еще выполняют большую часть сборки, но человек читает результат перед отправкой, и свет остается включенным везде, где неверное решение дорого.
Освещенная версия не прикрепляет рецензирование в конце, а перемещает точку человеческого суждения вверх по потоку, к продукту, дизайну и архитектуре, прежде чем агент начнет цикл.
Одно из замечательных свойств этого предварительного часа в том, что он приводит к меньшему количеству часов на реализацию. Он превращает долгое, утомительное рецензирование кода в быстрое чтение двухсотстрочного плана. Вы проверяете решение до того, как оно будет реализовано, поэтому позже вам не придется продираться через две тысячи строк сгенерированного кода, чтобы понять, каким вообще было решение. Некоторые решения настолько дороги и долговечны, что вы хотели бы привлечь человека на раннем этапе, прежде чем затраты возрастут. Конечно, все еще бывают случаи, когда вы смотрите на diff'ы, даже если потратили время заранее.
Вы можете подумать, что всё это звучит неприглядно. Вы правы. Сеть безопасности состоит из совершенно обычных архитектурных практик, которые мы всегда знали и в основном игнорировали: хорошие типы и сигнатуры методов, чтобы ошибки отлавливались компилятором, а не в продакшне; тестовые стыки, где мы можем зафиксировать поведение и сделать изменения наблюдаемыми; компоновка кода так, чтобы следующий читатель, человек или модель, знал, где найти то, что ему нужно; поддержание коротких и читаемых стеков вызовов; поддержание четко определенных границ компонентов, чтобы изменение не имело огромного радиуса поражения; и внедрение зависимостей, чтобы мы могли заменить один компонент другим. Ничего из этого не ново. Мы всегда говорили, что нам важна хорошая архитектура. Но теперь, когда мы используем автоматизированные агенты кодирования, эта архитектура, наконец, выполняет вторую работу как дешевая и трудно подделываемая сеть безопасности против ошибок, которые сделает агент.
Эта сеть безопасности должна находиться вне модели, потому что модель ее не предоставит. Агенты кодирования, которые кажутся наиболее способными, среди них Claude Code и Codex, обучаются с подкреплением против своей собственной обвязки и инструментов: они свободно владеют всеми инструментами и идиомами ремесла, но не такими вещами, как долгосрочная поддерживаемость. Продуманная архитектура, о которой мы всегда говорили, — это инструмент, который ловит этот долг, и наши инвестиции в нее — это выкуп нашей автономии.
Объедините это с безопасной инфраструктурой, и вы получите некоторые жесткие, низкорисковые циклы, которые можно запускать без присмотра. Хорти описал один из них в недавнем посте: ночной cron GitHub Actions, который исправляет ровно один анти-паттерн, нарушение линтинга или ненужный опциональный проп, делает коммит и открывает один маленький pull request, полностью самостоятельно, так что команда просыпается и видит немного улучшенную кодовую базу и diff, достаточно короткий, чтобы его можно было прочитать. Но для циклов с достаточно высокими ставками вы не захотите рисковать, проснувшись и обнаружив сломанную систему аутентификации, платежный движок или публичный API-контракт. Оставьте свет там включенным и доверьтесь, что человек с суждением и реальным рабочим знанием системы поймает ошибку.
Что заслуживает циклу статуса «темного»
Это правило применяется независимо от того, называете ли вы это обратным давлением, верификацией или выключателем света.
Цикл может заслужить статус полностью автоматизированного только в том случае, если проверка дешева, выполняется с высокой частотой и опирается на то, что невозможно легко подделать. Оракулы типа «зеленый-красный», шлюзы типов, property-based тесты и агент рецензирования в сочетании с реальным рубрикатором — всё это подходит. Вам также нужно, чтобы оракул отвечал немедленно и не менялся со временем. Когда «готово» может быть доказано не только вами, но и машиной, вы достигли автоматизации.
Короткие циклы легче верифицировать, чем длинные. Эмпирическое правило Декса: агент держится от трех до десяти шагов, а затем начинает терять нить после двадцати. Причина — накопление контекста: чем больше агент тащит за собой, тем больше вероятность, что он отклонится. Когда цикл короткий, его верификация дешева. Разрастающиеся циклы прячут ошибки по углам, что является еще одним способом сказать, что они никогда не заслужили статуса «без света».
Оставление света включенным — это противоположный случай. Цикл нуждается в рецензировании, если неверный ответ дорог и только человек может его поймать. Тонкие ошибки продакшна, которые нельзя отловить тестами, большой радиус поражения и решение, которое сформирует работу на год или более, — всё это подходит. В таких случаях ваше внимание — это фактический продукт, дорогой, необходимый.
Опасность в том, чтобы забыть переключить каждый выключатель и просто установить их все в один режим. Всё темное — и вы застряли, снося всё четыре месяца спустя. Всё освещенное — и никто не может вовремя сделать рецензии, и вы застряли в гигантском узком месте. Трудная, требующая навыков работа — это решить, где разместить каждый выключатель.
Циклы, графы или конечные автоматы?
Вам стоит прочитать «Конечные автоматы за 2 минуты» от @DavidKPiano
Когда вы даете агенту задачу, вы, вероятно, построите вокруг нее граф, называете ли вы этот граф конечным автоматом или набором условно связанных сервисных вызовов. Это такая рамка, где программное обеспечение не просто следует каким-то абстрактным правилам, а представляет собой структурированный рабочий процесс: каждый узел — это явный шаг, и каждое ребро между узлами — это явное условие.
Это звучит как много структуры, но большая ее часть уже есть в любом программном обеспечении, поскольку любой код можно выразить в виде графа потока управления. Так что единственная реальная новизна в том, что агент, настаивающий на автономии, на самом деле просто ходит по определенному графу, и его свобода ограничена внутренностями узла. И вот часть, которую люди забывают, которую Декс записал год назад: программное обеспечение всегда должно было иметь эту структуру. Есть причина, по которой мы раньше рисовали программы в виде блок-схем.
Действительно новым шагом была попытка выбросить диаграмму, полагаясь на цикл, где модель выбирает путь, вызов инструмента за вызовом инструмента, пока не объявит себя завершенной. Это чувствовалось как освобождение, ровно до тех пор, пока не встретило десятилетнюю кодовую базу, и дисциплина, которую сейчас все заново открывают, — владение своим потоком управления, — это на самом деле просто возвращение графа вокруг цикла. Так что вопрос о том, должны ли мы перейти от циклов обратно к графам, — это почти признание того, что блок-схема была нужна нам всё это время.
Вот как это выглядит на практике. Возьмем исправление ошибки. Как чистый цикл, вы садитесь и думаете: выяснить, что не так, изменить код, запустить тесты, посмотреть, что получится, и если этот раунд не убил выполнение, вернуться в начало и начать заново. Весь путь решается по ходу дела: какую проблему вы преследуете, какой именно код меняете, какие тесты запускаете и в каком порядке, запускаете ли вы тесты вообще и пробуете ли снова или объявляете победу.
Как граф, первое, что вы делаете, — это намечаете, что должно произойти. Воспроизвести ошибку или запросить дополнительную информацию, найти причину, попробовать исправление, запустить тесты и позволить неудачному выполнению вернуться к исправлению, в то время как успешное переходит к рецензированию, где только одобрение достигает состояния «готово». Агент все еще умен внутри каждого блока; он просто не может отклоняться от путей, которые вы разрешили. Санти изложил это на диаграмме, которая делает разницу очевидной.
Реальная привлекательность этого графа, конечно, в том, что это обратное давление, нарисованное в виде диаграммы. Вы отказываетесь от некоторой свободы агента и взамен получаете обязательные проверки и читаемые точки отказа, так что когда выполнение умирает, вы можете указать на узел, который его убил. Это тот же инстинкт, что и за прямой линией Декса о том, что большинство так называемых агентов на самом деле совсем не агентны, «в основном детерминированный код, с шагами LLM, вкрапленными в нужных местах». И это не просто артефакт того, как люди сейчас строят вещи: вы можете увидеть этот паттерн в LangGraph и LlamaIndex Workflows, в гибридном рабочем процессе-графе-над-агентами Джерри Лю с внешним циклом, который выращивает части графа по мере выполнения, и в напоминании Дэвида Хуршида о том, что это на самом деле просто конечные автоматы и модель актора, появляющиеся в новой одежде.
Одно уточнение, поскольку термин сильно перегружен: когда я продолжаю называть это графом, я не имею в виду граф знаний. Я имею в виду предопределенный направленный граф того, как должна течь работа, со всеми условными ребрами, придающий циклу форму, которой вы можете действительно доверять.
Куда на самом деле девается человек
Заметьте, что человек никогда не покидал фабрику. Он переместился.
Я думаю, что инженерам все больше необходимо владеть внешним циклом. Агенты могут исследовать ошибку, написать диагноз, реализовать исправление, запустить тесты и написать отчет. Это выполнение внутреннего цикла, и они могут делать это так же эффективно, как кто-либо. Но это никогда не было работой. Части, которыми вы владеете, — это то, что я бы назвал внешним циклом: решить, правильный ли это способ решения проблемы, проверить, что диагноз и реализация верны, одобрить изменение и нести последствия ошибки. Граница между двумя циклами — это доказательства, diff'ы, тесты, логи и краткое объяснение, которое их связывает. Типы, стыки и рубрикаторы делают возможным контролировать всё это, не выполняя много работы для каждого изменения.
Полезно сформулировать это так: вы больше не стоите на линии, пиша изменения; вы находитесь в конце производственной линии, проектируя ее и охраняя шлюз. Вы можете многое сделать, чтобы улучшить модель и сделать обвязку более способной, но я заметил, что выявление проблем, которые дороги в долгосрочной перспективе, — это не то, что обычно можно автоматизировать. Основная вещь, которая все еще остается работой, — это применять человеческое суждение лучше, чем любой поток бумаги и вычислительной мощности.
Роботам нормально работать в темноте, но людям нужно видеть, что они делают. Если всё на заводском полу темно, и вы ничего не видите, и вы даже не можете найти выключатель, вот где кроется опасность.
Pangram оценил эту статью как написанную на 100% человеком.
