Впровадження моделі програмної фабрики: повзати, ходити, бігати

Підхід «програмної фабрики» (замкнений агентний цикл, що працює в хмарі) набуває дедалі більшої популярності, але його впровадження може здатися складним завданням. У цій статті я розгляну етапи «повзати, ходити, бігати» для переходу від локальних інтерактивних агентів до автоматизованої хмарної розробки.

Повзати

Багато керівників інженерних команд та платформних інженерів, з якими я спілкуюся, вже почали етап «повзання» у побудові програмної фабрики, створюючи прості автоматизації за допомогою хмарних агентів.

Уявіть ці автоматизації як ланцюжок: Тригер → Діяльність агента.

Наприклад:

• Відтворення та тріаж задач: агент переглядає всі нові створені задачі (issues), відтворює їх та додає мітки.
• Код-рев’ю: Автоматичне перевірка pull request (PR) одразу після їх створення та залишення коментарів.
• Моніторинг: агент реагує на сповіщення Sentry, діагностикує та виправляє проблему.
• Самовідновлення CI: виправлення зламаних процесів CI шляхом визначення PR для відкату або конфліктів злиття для вирішення.
• Автооновлення документації: оновлення документації для користувачів та генерація списків змін (changelogs).
• Верифікація: агенти browser-use та computer-use візуально проводять QA та верифікують зміни.
• Прості виправлення багів: агенти ідентифікують та виправляють прості проблеми, про які повідомляють користувачі.

Спільною рисою всіх цих підходів є те, що вони автоматизують окремі частини життєвого циклу програмного забезпечення. Початок із простих автоматизацій — це підхід з низьким ризиком та невеликою вартістю, який допомагає виробити інтуїцію щодо ефективного використання агентів у більш складних багатоетапних задачах.

Приклад автоматизації для моніторингу сповіщень

Ці автоматизації можуть бути побудовані на власній інфраструктурі (наприклад, розміщення Claude Code SDK у Docker-контейнері та налаштування сервера для їх запуску) або використовувати універсальну платформу автоматизації хмарних агентів, призначену для запуску агентів за тригерами. Також можна використати цілу платформу, присвячену одному етапу циклу (наприклад, спеціалізований агентний код-рев’юер або AI SRE).

Починати з набору точкових автоматизацій цілком нормально, але з часом більшість команд стикається з обмеженнями такого підходу.

Зокрема:

• Залежно від налаштувань, ці автоматизації можуть не мати спільного контексту. Це означає, що покращення одного аспекту (наприклад, код-рев’ю) не переносяться на інші етапи, такі як тріаж та QA.
• Відсутнє глобальне бачення того, чи дійсно ці одноразові автоматизації підвищують загальну продуктивність, і немає системного способу тестувати та покращувати високорівневі метрики, важливі для вас, такі як вартість на PR, час циклу, відсоток автоматизації тощо. Для відстеження цього потрібна система, яка працює на всіх етапах розробки.
• Кожне точкове рішення створює власне навантаження на налаштування та обслуговування. Вони розширюють поверхню безпеки, яку потрібно керувати. У них немає єдиного інтерфейсу для спостережності. З часом команди хочуть централізованого налаштування, аудиту та управління.

Ходити

Усі ці проблеми вказують на потребу в більш комплексному підході. Організації, які пройшли етап «повзання», ставлять собі питання: «Яка система нам потрібна для справжнього масштабування агентної розробки?»

Більш конкретно, вони питають:

• Де має відбуватися розробка? Локально чи в хмарі? Через які інтерфейси?
• Як виглядає успішний процес автоматизованої розробки? Які ключові метрики?
• Який наш стан щодо суверенітету ШІ? Наскільки важливо володіти даними наших кодинг-агентів? Наскільки ми маємо залежати від постачальників моделей?
• Як ми плануємо покращувати наш процес розробки з часом? Як контролювати витрати, прискорюючи випуск продуктів? Як ми дізнаємося, що рухаємось у правильному напрямку?
• Як ми готуємось до майбутнього, коли моделі та агенти вдосконалюватимуться? Чи враховуємо ми регуляторні ризики, які можуть вплинути на доступ до моделей?
• Як саме інженери мають брати участь у процесі розробки? Те саме стосується дизайнерів, PM та інших творців?
• Як ми забезпечуємо безпеку розробки? Який наш план дій, якщо процес виробництва ПЗ буде скомпрометований?

Більшість керівників інженерних команд та платформних груп, які серйозно думають над цими питаннями, приходять до чогось подібного на підхід хмарної програмної фабрики. Вони хочуть:

• Розробку в хмарі за замовчуванням, оскільки надавати агентам пісочниці безпечніше, ніж дозволяти їм працювати локально.
• Централізоване управління кодинг-агентами та інструментами й системами, до яких вони мають доступ.
• Повні сліди дій агентів для аудиту та аналізу продуктивності.
• Гнучкість у виборі моделей та середовищ виконання (harnesses) для мінімізації ризиків та оптимізації продуктивності.
• Інтеграцію розробки в усі інструменти, які команда вже використовує (наприклад, Slack/Teams, Jira, GitHub тощо).
• Можливість для людей взяти контроль на себе, або через керування живими агентами, або перенесення роботи в внутрішній цикл розробки.
• Спільний шар контексту, який працює між агентами на всіх фазах розробки.
• Підхід, що дозволяє тестування, оцінки та бенчмаркінг, щоб ваша команда була впевнена, що система постійно покращується.

Коли компанія обирає фабричний підхід, постає питання: як перейти від наявних точкових автоматизацій до нього? Зазвичай це зводиться до вибору між (1) розширенням інфраструктури навколо цих автоматизацій або (2) переходом на таку платформу, як Warp Factories, яка надає інфраструктуру фабрики.

Зауважте, що я б не називав це традиційним вибором «розробити чи купити». Незалежно від обраного шляху, очікуйте, що вашій внутрішній команді доведеться щось будувати, адже для ефективної роботи фабричного підходу фабрика має бути глибоко інтегрована в контекст та робочі процеси вашої команди. Це скоріше питання того, чи будуєте ви інфраструктуру автоматизації повністю з нуля, чи співпрацюєте з тими, хто дає вам фору.

Наприклад, незалежно від шляху, очікуйте, що вам доведеться створювати організаційно-специфічні скіли та налаштовувати їх під вашу кодову базу. Очікуйте, що вам доведеться виставляти та налаштовувати специфічні для організації MCP та внутрішні джерела контексту. Але, можливо, ви не захочете будувати хмарну інфраструктуру для запуску та управління агентами, спрямування їхньої роботи, передачі результатів, вимірювання їхньої ефективності, використання комп’ютера тощо. Загальне правило: фокусуйтеся на створенні компонентів, специфічних для вашої організації, а не тих, що потрібні будь-якій компанії.

Який би підхід ви не обрали, я рекомендую, що найбільшою віхою на етапі ходіння є розгортання першої фабрики end-to-end на простому продуктовому рівні. Це може бути ваш маркетинговий сайт або внутрішній додаток.

Початок з одного простого проекту має перевагу: він запускає весь цикл з низькими ризиками та мінімальною складністю. Додавання більше репозиторіїв, рядків коду, залежностей сервісів, людських стейкхолдерів тощо збільшує складність і може створити відчуття, що ви ще не готові до автоматизації. Краще спочатку відлагодити простий цикл.

Мета — створити мультиагентну систему, яка проходить шлях від тріаж → специфікація → імплементація → рев’ю → верифікація → моніторинг. Детальніше:

1. Нова задача потрапляє в систему, або від людини, або від агента моніторингу.
2. Агент тріажу аналізує задачу, намагається її зрозуміти та відтворити. Якщо він визначає, що задачу можна автоматизувати → передає її агенту імплементації. Якщо потрібні специфікації через масштаб → агент специфікацій ітеративно працює з людиною для створення специфікації. Якщо задача неоднозначна → отримує ввід від людини та перезапускається, або просто вирішує відкласти задачу.
3. [За потреби] Працює агент специфікацій, людина переглядає специфікації, потім передає їх агенту імплементації.
4. Агент імплементації пише код.
5. Агент код-рев’ю перевіряє код.
6. Агент верифікації виконує використання комп’ютера або іншу верифікацію.
7. Людина переглядає код та результати верифікації. За потреби повертається до кроку 2, 3, 4 або 5.
8. CI / CD.
9. Випуск (Ship it).
10. Агент моніторингу працює та створює нові задачі за потреби, завершуючи цикл.

Всередині Warp наша фабрика на етапі ходіння автоматизує приблизно 75% змін на warp.dev, нашому маркетинговому сайті. На відміну від Warp Terminal (65k зірок на GitHub, майже мільйон активних розробників, 1 млн рядків нативного Rust), наш маркетинговий сайт — досить простий додаток. Зауважте, що під «автоматизацією» я маю на увазі перехід від вводу людини до випущеної функції повністю через фабрику, з мінімальними точками контакту людини, окрім опису бажаної зміни, або в Slack, або в нашому трекері задач.

Бігати

Лише коли базовий цикл налагоджено на простому проекті, варто масштабуватися на складніші проекти. Масштабування фабрик вимагає більш надійної інфраструктури.

Зокрема, при масштабуванні виникають певні вузькі місця:

• Налаштування віддалених середовищ розробки для великих проектів є складним. Більше репозиторіїв, рядків коду, залежностей сервісів ускладнюють автоматизацію.
• Коли у вас стає більше скілів, коду тощо, стає важче зрозуміти, чи зміни, які ви вносите у свої фабрики, позитивно впливають на розробку, чи просто створюють зайву метушню.
• Ви природно стикаєтеся з ризиками зростання витрат, коли агенти працюють зі складнішими кодовими базами, оскільки потрібні потужніші моделі, а агентам потрібно працювати довше. Маршрутизація моделей та вибір середовища виконання стають важливішими.
• Безпека та аудит стають критичними, чим більше ви впроваджуєте фабричний підхід у mission-critical користувацькі додатки.
• Більше стейкхолдерів додатку означає більше координації та погоджень між людьми. Вам знадобиться рішення для фабрик, яке дозволяє багатокористувацький ввід та зберігає сліди аудиту.
• Неминуче PR почнуть накопичуватися, тому вам знадобиться чітка стратегія щодо того, що проходить код-рев’ю, та як ви використовуєте агентну верифікацію та QA.
• Вам знадобляться більш надійні інструменти для замикання циклу, гарантуючи, що зміни, які потрапляють у продакшн, мають високу якість, не падають тощо.

Створення масштабованих робочих фабрик, на мою думку, стане одним із найцікавіших викликів у програмній інженерії в найближчі кілька років; програмна інженерія перетворюється на фабричну інженерію. Організації, які зможуть зробити свої фабрики надійними, стабільними та самовдосконалюваними, зможуть випускати більше продуктів за кращої собівартості та отримають конкурентну перевагу.

Щоб фабрики реально «гуділи», потрібні значні інвестиції. У Warp ми розглядаємо це як повне побудування стека вашої фабрики:

Детально про кожен із цих шарів я розповідаю в цьому пості:

https://x.com/zachlloydtweets/status/2097739116720910619

Кілька ключових моментів, які можуть бути неочевидними:

• Фабрики як код: один із ключових виборів, який ви можете зробити, — це визначення ваших фабрик як коду. Це дозволяє тестувати різні конфігурації фабрик, щоб побачити, які з них є найбільш ефективними, мають найвищу якість тощо.
• Мульти-модельність та мульти-середовищність: переконайтеся, що ваші фабрики можуть використовувати найновіші моделі, як передові (frontier), так і з відкритою вагою, а також різні середовища виконання кодинг-агентів, такі як Claude Code та Codex.
• Володіння даними: переконайтеся, що ви зберігаєте та володієте всіма даними, що генеруються вашою фабрикою — це сировина для покращення її роботи.

У повністю «гудучій» фабриці ключовою характеристикою є те, що це замкнений цикл, вимірювана та керована система. Це має бути метою. У такій системі всі працюють з одного контексту, публічно, у повністю аудитованому та відстежуваному режимі. Самі агенти спостерігають за скілами та конфігураціями, які керують системою, і пропонують покращення. Платформенні інженери можуть розширювати систему, інтегруючи її з усіма внутрішніми системами. Керівники інженерних команд можуть бачити метрики продуктивності та розуміти, які зміни вносяться для їх покращення. Все це працює емпірично, а не «на відчуття».

У Warp ми наближаємося до цього бачення. Щодня ми всі працюємо публічно, налаштовуємо нашу фабрику, знижуємо витрати та покращуємо пропускну здатність і якість.

Наша місія — надати найкращим інженерним командам світу інструменти для створення, вимірювання та оптимізації власних робочих процесів з використанням будь-якої базової моделі та середовища виконання на відкритій інфраструктурі. Ці можливості допоможуть командам швидше та ефективніше випускати краще програмне забезпечення.

Warp Factories зараз перебуває на стадії раннього доступу. Кваліфіковані компанії отримують $10k на використання фабрики.