Програмна фабрика — це масштабовані зациклені процеси. Ви можете запускати цикл із залученням людей (світла фабрика), обмінюючи судження та концентрацію на швидкість і ризик поломок. Або ви можете ігнорувати людей (темна фабрика) і дозволити агентам самостійно визначати обсяг, створювати та випускати код, без того, щоб хтось уважно вчитувався в деталі. Але якщо люди перестануть читати, вони перестануть розуміти ваше програмне забезпечення. Ваше найскладніше завдання тепер — знати, які перевірки вбудовувати і скільки автономії делегувати.
Це поняття програмної фабрики сягає корінням доповіді Боба Бемера «Економіка виробництва програм» 1968 року. Протягом півстоліття багато хто мріяв про світ, де створення програмного забезпечення є повторюваним і контрольованим виробничим процесом (аналогічно штампуванню деталей на заводі), а не ізольованим ремеслом окремих людей. Історично ця мрія, як правило (хоча й не завжди), зазнавала невдачі, частково через складність «штампування» ідей.
Але за останні два роки все змінилося настільки кардинально, що тепер має сенс по-новому поглянути на стару мрію. І оскільки деякі нюанси легко випустити з уваги, варто бути досить точними щодо того, що насправді є новим і відмінним, а що може бути повторюваними пастками, замаскованими під нові можливості.
@dexhorthy, співзасновник HumanLayer, нещодавно виступив із чудовою доповіддю на AI Engineer World's Fair під назвою «Harness Engineering is not Enough: Why Software Factories Fail.», яку варто подивитися на цю тему.
Цикл — це атом. Фабрика — це масштабований цикл.
Структура — це все, і все починається з малих одиниць. Уся система — це насправді три концепції, накладені одна на одну: цикл, обв'язка (harness) і фабрика.
Цикл — це один агент, який виконує одне завдання повторювано: збирати контекст, виконувати дію, перевіряти результат і повторювати, доки не буде виконано певну умову. Це найменша одиниця агентної роботи, і все, що над нею, — це просто цикли, складені один на одного.
Суть циклоінженерії (loop engineering) полягає в тому, що ви перестаєте давати агенту підказки крок за кроком, а натомість проєктуєте невелику систему, яка робить це за вас.
Обв'язка — це стіни навколо циклу: пісочниця, в якій він працює, інструменти, до яких він має доступ, пам'ять, що зберігається між запусками, і ворота, які визначають, що означає «готово». Цикл — це поведінка; обв'язка — це середовище, в якому ця поведінка виконується.
Дайте сирій моделі без обв'язки, і вона буде радісно крутитися вічно. Обв'язка — це все навколо неї, що робить її корисною та безпечною для запуску.
Програмна фабрика — це безліч зациклених процесів з обв'язкою, що працюють одночасно, живляться з черги завдань і проходять через ворота рецензування у виробництво, при цьому люди контролюють усе це зверху. Це не більший агент; це організаційна схема, складена з циклів.
Останній парадигмальний зсув — це перехід від написання коду до створення та запуску фабрики, яка його пише. Одиниця роботи піднімається на рівень вище, до циклу, обв'язки та потоку між ними, а не до окремої зміни коду (code diff).
Цикл → обв'язка → фабрика. Фабрика — це не розумніший агент; це безліч зациклених процесів з обв'язкою, що живлять одні ворота рецензування, причому людина контролює зовнішній цикл. Зображено фабрику.
Центральний слайд, на якому Декс зупинився найдовше, був блискучим, тому що це прояснювальна принципова схема, яка візуалізує те, що інакше виглядало б як очевидний цикл. Ось моє бачення:
Фабрика — це замкнений цикл: намір і виробничі сигнали живлять чергу, обв'язка будує, автоматичні перевірки та ворота рецензування пропускають, розгортання відправляє, моніторинг перетворює продукцію назад на сигнали. Намір надходить від бачення інженерного керівництва та безпосередньо від інженерів у чергу справ. Сигнали, спричинені інцидентами та запитами користувачів, рухають ту саму чергу.
Обв'язка — це просто те, що вибирає елемент із черги та створює для нього зміну. За обв'язкою ми бачимо всі автоматичні перевірки, необхідні, щоб зробити зміни достатньо безпечними для випуску у виробництво. Ці автоматичні перевірки виконуються одночасно, без зусиль, без свідомої участі інженерів, завдяки CI, тестам, статичному аналізу та скануванню всіх видів. Єдиною точкою прийняття рішень тут є ворота рецензування. Після схвалення зміни розгортаються та відстежуються у виробництві, а дані моніторингу надходять назад у сигнали, які спочатку запустили цикл.
Загалом, кожна коробка на цій діаграмі коштує майже нуль: генерація, тести, сканування. Всі вони працюють у масштабі з незначною вартістю. Є лише одна дорога коробка, яка вперто не піддається масштабуванню, і це ворота рецензування. Ця блискуча бурштинова коробка — це «судження», і саме в ній криється суть суперечки про те, чи можемо ми зробити розробку швидшою та частішою.
Чому ми називаємо це «темним»
Темна фабрика працює при фізично вимкненому світлі, тому що єдине, що знаходиться на підлозі цеху — це машини, а машинам не потрібне світло, щоб бачити. Темна програмна фабрика — це те саме: код випускається без прочитання людиною, перевірений лише іншими машинами.
Цей образ запозичений із виробництва. Його витоки фізичні, а не цифрові, і сягають корінням у приміщення, де світло вимикається, а роботу виконують роботи. FANUC у Японії працює на таких безлюдних фабриках з 2001 року; Xiaomi у 2024 році відкрила власну високоавтоматизовану темну фабрику. Їх об'єднує те, що продукт збирається та відвантажується без того, щоб жодна людина прочитала що-небудь із нього. «Темрява» настає тоді, коли цей акт читання вилучається з процесу.
Я запозичую це поняття не заради його атмосфери чи як образу. Незважаючи на всю його моторошну популярність, «темний» тут — це просте фізичне твердження: оригінальний заводський цех, але без світла. У програмному забезпеченні цехом є diff (зміна коду). Хто б не написав цей diff, хто б його не рецензував, хто б не випустив, цих людей більше немає, і залишається лише diff, перевірений лише машинами, які його створили.
Це напрочуд легко зробити, принаймні спочатку. Це легко, тому що відсутній крок рецензування заважає всьому. Його відсутність змушує ваше сприйняття вертикальної пропускної здатності команди здаватися раптово та радикально вищою. Відчувається, ніби ви подолали звуковий бар'єр. Незважаючи на всю свою позірну легкість, вижити в цих темних робочих процесах з усіма їхніми прихованими витратами важче, ніж здається.
Однієї інженерії обв'язки (Harness Engineering) недостатньо
Обв'язка оркестрації, прототипування в пісочниці та виклику інструментів, оскільки моделі взаємодіють зі світом та одна з одною, ставатимуть дедалі потужнішими та ефективнішими. Однак існує внутрішня неспроможність моделі підтримувати якість кодової бази в довгостроковій перспективі та під час поступових змін, і я вважаю, що є вагомі підстави вважати, що зрештою моделі самі по собі програють битву з боргом розуміння (comprehension debt).
Борг розуміння — це зростаючий розрив між тим, скільки коду існує, і тим, скільки з нього ще розуміє будь-яка людина. Темна фабрика не погашає цей борг; вона набирає його якомога швидше, і тести при цьому залишаються зеленими.
Це важливе розмежування, оскільки моделі добре справляються з деякими завданнями. Але для всього, що не є негайною зміною невеликої частини кодової бази, особливо в складній brownfield-системі, автоматичне кодування лише на основі моделі стикається з непереборною перешкодою. Greenfield-застосунки, вихідні іграшки та побічні проєкти схожі тим, що кількох місяців циклів розробки зазвичай достатньо, щоб привести все в робочий стан або хоча б приблизно.
Але корпоративна система, яка розроблялася десятиліття або більше, — це зовсім інша справа; її потрібно підтримувати в професійному середовищі з професійною швидкістю. Через три-шість місяців після початку проєкту ви вже потопаєте в непрочитаному коді. Таке середовище, і особливо обмеження, що накладаються виробничим кодом, змусили б навіть потужного агента працювати погано, і все це контрастує з «vibe-coding», яким насолоджуються розробники, працюючи над вихідними іграшками.
Декс повідомляє з досвіду, що це серйозна невдача, настільки серйозна, що для її виявлення знадобилося ретельне ручне налагодження. Це стало результатом роботи повністю автоматизованої фабрики коду протягом приблизно чотирьох місяців, протягом яких жодна людина не дивилася на написаний код. В основі цього досвіду лежить компроміс між двома конфліктуючими метриками. Одна — максимізація використання токенів, число, яке ми зараз сприймаємо як прогрес. Інша, яку вона тихо мінімізує, — це обсяг системи, який будь-який учасник-людина все ще розуміє в будь-який момент.
Темна фабрика справді сяє у своїй здатності «спалювати» бездоганний код, поки тести залишаються зеленими. Остаточна розплата, коли вона настане, не буде драматичним моментом «все пішло шкереберть». Це буде тихо і пізно.
Темний і освітлений режими — це один і той самий конвеєр, але зі світлом у різних місцях. Освітлена версія не просто додає рецензування в кінці — вона переносить людське судження вгору за течією, на етапи дизайну та архітектури. Вузьким місцем ніколи не була генерація.
Фундаментальне обмеження програмної фабрики полягає не в тому, скільки коду ми можемо видавати, а в тому, як швидко ми можемо його перевірити.
Зворотний тиск — це правило, згідно з яким циклу можна надати лише стільки автономії, скільки ви можете дешево та надійно перевірити, і ні на йоту більше. Перевірка, а не генерація, є реальним обмеженням фабрики.
Оскільки необмежена здатність до генерації перебуває в постійній напрузі з обмеженим ресурсом людської уваги, який не масштабується, основною проблемою є розрив між дешевою генерацією та обмеженим рецензуванням. Подивіться на лійку: доки шийка, яка представляє перевірку, не розширюється, буде накопичення. Як зазначає Декс, сам по собі обсяг не є проблемою: насправді ми страждаємо від надлишку поганих PR (pull request). Коли у вас великий обсяг без надійних воріт, неминучі виробничі дефекти. Це знову ж таки зворотний тиск: автономія не може розширюватися за межі того, що можна дешево та надійно перевірити.
Проблема другого порядку полягає в тому, чому покращення моделі не повинно автоматично закривати розрив між тим, що вона може створювати, і тим, що можна перевірити. Навчання на добре спроєктованих системах є, безперечно, складнішим завданням, ніж проходження простих тестів: пам'ятайте, що функції витрат, які вимірюють архітектурну досконалість, вимірюються не в секундах або навіть хвилинах, а в місяцях і роках. Акуратні градієнти функціонально неможливо обчислити, тому систему, яка очікує чіткої, миттєвої оцінки складних проєктних рішень, не буде навчено на хороших прикладах.
Генерація — це широкий отвір; перевірка — це вузька шийка. Прискорення отвору лише поглиблює купу біля шийки.
Вмикаємо світло
Світла фабрика — це той самий конвеєр, але з увімкненим світлом там, де живе судження. Агенти все ще виконують більшість роботи зі створення, але людина читає результат, перш ніж він потрапляє у виробництво, і світло залишається увімкненим скрізь, де помилкове рішення є дорогим.
Освітлена версія не просто додає рецензування в кінці, а переносить точку людського судження вгору за течією — до продукту, дизайну та архітектури, перш ніж агент почне цикл.
Одна чудова річ у цій попередній годині полягає в тому, що вона веде до меншої кількості годин на впровадження. Вона перетворює довге, неприємне рецензування коду на швидке читання двохсотрядкового плану. Ви перевіряєте рішення до того, як воно буде реалізовано, тому пізніше вам не доведеться переглядати дві тисячі рядків згенерованого коду, щоб з'ясувати, яким взагалі було рішення. Деякі рішення є настільки дорогими та довгостроковими, що варто залучити людину на ранньому етапі, перш ніж витрати зростуть. Звичайно, все одно бувають випадки, коли ви дивитеся на diffs, навіть якщо ви витратили час на початку.
Можливо, ви думаєте, що все це звучить не дуже захопливо. Ви маєте рацію. Страхувальна сітка складається з цілком звичайних архітектурних практик, які ми завжди знали, але здебільшого ігнорували: хороші типи та сигнатури методів, щоб помилки виявлялися компілятором, а не у виробництві; тестові шви (test seams), де ми можемо зафіксувати поведінку та зробити зміну спостережуваною; розташування коду так, щоб наступний читач, людина чи модель, знав, де знайти те, що його цікавить; підтримка коротких і зрозумілих стеків викликів; чітке визначення меж компонентів, щоб зміна не мала великого радіусу ураження; та впровадження залежностей (dependency injection), щоб ми могли замінити одну частину іншою. Нічого з цього не є новим. Ми завжди говорили, що нам важлива хороша архітектура. Але тепер, коли ми використовуємо автоматизовані агенти кодування, ця архітектура нарешті виконує другу роботу як дешева та важкопідроблювана страхувальна сітка проти помилок, яких припуститься агент.
Ця страхувальна сітка повинна існувати за межами моделі, тому що модель її не надасть. Агенти кодування, які здаються найбільш здатними, зокрема Claude Code та Codex, навчені з підкріпленням проти власної обв'язки та інструментів: вільно володіють усіма інструментами та ідіомами професії, але не такими речами, як довгострокова підтримуваність. Продумана архітектура, про яку ми завжди говорили, є інструментом, який виловлює цей борг, і інвестиції, які ми в неї робимо, — це наш спосіб викупити нашу автономію.
Поєднайте це з безпечною інфраструктурою, і ви отримаєте деякі тісні, майже безризикові цикли, які можна запускати без нагляду. Хорті описав один у нещодавньому дописі: нічний cron у GitHub Actions, який виправляє рівно один антипатерн, порушення правил лінтера або непотрібно опціональний проп, робить коміт і відкриває один маленький pull request, все самостійно, так що команда прокидається до трохи кращої кодової бази та diff, досить короткого, щоб його прочитати. Але для циклів з високими ставками ви не ризикуєте прокинутися до зламаної системи автентифікації, платіжного двигуна чи публічного API-контракту. Залишайте світло увімкненим там і довіряйте, що людина з судженням і реальним робочим знанням системи помітить помилку.
Що дозволяє циклу стати темним
Це правило застосовується незалежно від того, чи називаєте ви це зворотним тиском, перевіркою або вимикачем світла.
Цикл може заслужити повністю автоматизований статус, лише якщо перевірка є дешевою, виконується з високою частотою та покладається на щось, що важко підробити. Оракули «зелений-червоний», типові ворота (type gates), перевірки властивостей (property tests) і агент рецензування, поєднаний із реальним рубрикатором, — усе це підходить. Вам також потрібно, щоб оракул відповідав негайно і не змінювався з часом. Коли «готовність» може бути доведена не лише вами, а й машиною, ви досягли автоматизації.
Короткі цикли легше перевіряти, ніж довгі. Емпіричне правило Декса: агент витримує від трьох до десяти кроків, а після двадцяти починає втрачати нитку. Причина — накопичення контексту: чим більше агент тягне за собою, тим більша ймовірність, що він відхилиться. Коли цикл короткий, його перевірка є дешевою. Розлогі цикли ховають помилки по кутках, що є іншим способом сказати, що вони ніколи не заслужили статусу «без світла».
Залишати світло увімкненим — це протилежний випадок. Цикл потребує рецензування, якщо неправильна відповідь є дорогою, і лише людина може її виявити. Тонкі виробничі помилки, які неможливо виявити тестами, великий радіус ураження та рішення, яке впливатиме на роботу протягом року або більше, — усе це підпадає під цю категорію. У таких випадках ваша увага є фактичним продуктом, дорогим і необхідним.
Небезпека полягає в тому, щоб забути перемкнути кожен вимикач і просто встановити всі в один режим. Усі в темний — і через чотири місяці ви застрягнете, розбираючи все дощенту. Усі в світлий — і ніхто не встигає зробити рецензування вчасно, і ви застрягнете у величезному вузькому місці. Складна, кваліфікована робота полягає в тому, щоб вирішити, куди поставити кожен вимикач.
Цикли, графи чи скінченні автомати?
Вам варто прочитати «State machines in 2 minutes» від @DavidKPiano
Коли ви даєте агенту завдання, ви, швидше за все, побудуєте навколо нього граф, незалежно від того, чи називаєте ви цей граф скінченним автоматом чи набором умовно пов'язаних викликів сервісів. Це формулювання, в якому програмне забезпечення слідує не просто абстрактним правилам, а структурованому робочому процесу: кожен вузол — це явний крок, а кожне ребро між вузлами — це явна умова.
Це звучить як багато структури, але більша її частина вже присутня в будь-якому програмному забезпеченні, оскільки будь-який код можна виразити у вигляді графа потоку керування. Отже, єдиною справжньою новизною є те, що агент, який наполягає на автономії, насправді просто ходить по певному графу, і його свобода обмежена внутрішньою частиною вузла. І ось частина, яку люди забувають, яку Декс записав рік тому: програмне забезпечення завжди мало мати цю структуру. Є причина, чому ми колись малювали програми у вигляді блок-схем.
Справді новим кроком була спроба викинути діаграму, покладаючись на цикл, де модель вибирає шлях виклик за викликом інструменту, доки не оголосить себе завершеною. Це здавалося звільненням, аж доки воно не зустріло десятирічну кодову базу, і дисципліна, яку зараз всі заново відкривають, — володіння власним потоком керування, — це насправді просто повернення графа навколо циклу. Отже, питання про те, чи варто нам переходити від циклів назад до графів, майже є визнанням того, що блок-схема була потрібна нам весь час.
Ось як це виглядає на практиці. Візьмемо виправлення помилки. Як чистий цикл, ви сідаєте і думаєте: з'ясувати, що не так, змінити код, запустити тести, подивитися, що вийде, і якщо цей раунд не вирішив проблему, повернутися на початок і почати спочатку. Весь шлях вирішується в процесі: яку проблему ви переслідуєте, який саме код змінюєте, які тести запускаєте і в якому порядку, чи запускаєте тести взагалі, чи намагаєтеся знову або оголошуєте перемогу.
Як граф, перше, що ви робите, — це описуєте, що має статися. Відтворити помилку або попросити додаткову інформацію, знайти причину, спробувати виправлення, запустити тести, і дозволити невдалому запуску повернутися до виправлення, тоді як успішний переходить до рецензування, де лише схвалення досягає завершення. Агент все ще розумний всередині кожної коробки; він просто не може відхилятися від шляхів, які ви санкціонували. Санті представив це з діаграмою, яка робить різницю очевидною.
Справжня привабливість цього графа, звісно, полягає в тому, що це зворотний тиск, намальований як діаграма. Ви відмовляєтеся від частини свободи агента і натомість отримуєте обов'язкові перевірки та зрозумілі точки відмови, тому коли запуск «вмирає», ви можете вказати на вузол, який його вбив. Це той самий інстинкт, що стоїть за різкою лінією Декса про те, що більшість так званих агентів зовсім не є дуже агентними, «переважно детермінований код, з LLM-кроками, вкрапленими в потрібних місцях». І це не просто артефакт того, як люди зараз будують речі: ви можете побачити цю закономірність у LangGraph і LlamaIndex Workflows, у гібридному робочому процесі-граф-над-агентами Джеррі Лю (Jerry Liu) із зовнішнім циклом, який зростає частинами графа під час виконання, і в нагадуванні Девіда Хуршида (David Khourshid) про те, що це насправді просто скінченні автомати та модель акторів, які з'явилися в новому одязі.
Одне уточнення, оскільки термін дуже перевантажений: коли я називаю це графом, я не маю на увазі граф знань. Я маю на увазі попередньо визначений спрямований граф того, як має протікати робота, з умовними ребрами та всім іншим, що надає циклу форму, якій можна довіряти.
Куди насправді дівається людина
Зверніть увагу, що людина ніколи не покидала фабрику. Вона перемістилася.
Я вважаю, що інженери повинні все більше контролювати зовнішній цикл (outer loop). Агенти можуть досліджувати помилку, написати діагноз, реалізувати виправлення, запустити тести та написати звіт. Це виконання внутрішнього циклу, і вони можуть робити це так само ефективно, як і будь-хто. Але це ніколи не було роботою. Частини, якими ви володієте, — це те, що я називаю зовнішнім циклом: вирішити, чи це правильний спосіб вирішення проблеми, перевірити, чи є діагноз і реалізація обґрунтованими, схвалити зміну та нести наслідки помилки. Межа між двома циклами — це докази: diffs, тести, логи та коротке пояснення, яке їх пов'язує. Типи, шви (seams) та рубрикатори роблять можливим контролювати все це, не виконуючи багато роботи для кожної зміни.
Корисно сформулювати це так: ви більше не стоїте біля конвеєра, пишучи зміни; ви стоїте в кінці виробничої лінії, проєктуючи її та охороняючи ворота. Ви можете багато зробити, щоб покращити модель і зробити обв'язку більш здатною, але я помітив, що виявлення проблем, які є дорогими в довгостроковій перспективі, зазвичай не є тим, що можна автоматизувати. Основна річ, яка все ще залишається роботою, — це застосовувати людське судження краще, ніж будь-який потік паперу та обчислювальної потужності.
Роботи чудово працюють у темряві, але людям потрібно бачити, що вони роблять. Якщо все на заводському цеху темно, і ви нічого не бачите, і навіть не можете знайти вимикач, ось де криється небезпека.
Pangram оцінив цю статтю як написану людиною на 100%.
