У спільноті AI‑інженерів ім’я Люка Алвоейру дедалі частіше звучить у контексті не просто «розумних» моделей, а систем, які реально доводять проєкти до продакшену. Розробник із бекграундом у dev‑tools, колишній інженер Block і автор одного з провідних open source‑кодингових агентів Goose, сьогодні очолює core agent harness у компанії Factory. Її амбіція — привнести автономію в увесь життєвий цикл розробки програмного забезпечення.
Досвід створення Goose, його еволюція та подальший перехід до Factory формують послідовну лінію: від «агента, який пише код», до багатоденних місій, де команди агентів планують, реалізують і перевіряють складні фічі майже без участі людини. Історія цього шляху добре показує, як змінюється саме поняття «інструментів для розробників» у добу агентного AI.
Витоки: dev‑tools, Block і народження Goose
Люк Алвоейру прийшов у агентний AI не з академічних лабораторій, а з практичного світу інструментів для розробників. Його бекграунд — dev‑tools, тобто все, що допомагає інженерам писати, тестувати й підтримувати код ефективніше. Приблизно два з половиною роки до нинішнього виступу він працював у Block (колишній Square) і саме там запустив проєкт, який згодом перетворився на Goose.
Початковий задум був типовим для епохи перших кодових LLM‑агентів: використати моделі, щоб автоматизувати частину рутинної розробки. Але з часом цей внутрішній експеримент еволюціонував у повноцінного кодингового агента, який вийшов далеко за межі однієї компанії.
Goose став одним із провідних агентів у своєму класі: open source‑рішенням, яке активно використовують і розвивають у спільноті. Важливий момент — його не залишили закритим корпоративним інструментом. Goose було передано до Agentic AI Foundation, що перетворило його з внутрішнього проєкту Block на спільний актив екосистеми.
Цей крок показовий із кількох причин. По‑перше, він закріпив Goose як відкриту платформу, на якій інші можуть будувати власні рішення. По‑друге, він продемонстрував, що для Люка агентний AI — це не лише продукт, а й інфраструктура, яка має жити й розвиватися поза межами однієї компанії. По‑третє, досвід масштабування Goose до рівня «одного з провідних кодингових агентів» дав практичне розуміння того, де саме впираються можливості одиночних агентів.
Це розуміння і стало фундаментом для наступного етапу — роботи у Factory.
Від одиночного агента до команд: чому Goose виявилося замало
Goose як кодинговий агент добре ілюструє перше покоління «розумних помічників» для розробників. Модель може писати код, генерувати тести, допомагати з рефакторингом, аналізувати помилки. Але навіть найкращий агент такого типу залишається, по суті, розширеним інструментом у руках людини.
Ключова проблема, яку Люк формулює вже з позиції Factory, полягає не в браку інтелекту моделей, а в обмеженості людської уваги. Сучасні LLM достатньо розумні, щоб «зрозуміти» десятки фіч у беклозі, але інженер фізично не може паралельно супервізувати реалізацію всіх цих завдань. Кожен коміт потребує рев’ю, кожна зміна — перевірки, кожна фіча — контексту.
Це створює новий тип «вузького місця»: не когнітивного, а операційного. Goose допомагає писати код швидше, але не знімає з людини тягар постійного контролю, планування, валідації й координації. У певний момент стає очевидно, що одиночний агент, навіть дуже потужний, не здатен автономно тягнути проєкти, які тривають не години, а дні й тижні.
Саме тут починається перехід від «агента» до «системи агентів». І саме тут досвід Goose виявляється критично важливим: він показує, як далеко можна зайти з одним агентом — і де доводиться змінювати саму архітектуру підходу.
Factory: автономія як місія, а не фіча
Сьогодні Люк працює у Factory й очолює там core agent harness — базовий «каркас» для агентів, на якому будується вся система. Місія компанії сформульована максимально прямо: принести автономію в увесь життєвий цикл розробки програмного забезпечення.
Це означає не просто «допомогти написати код», а охопити весь цикл: від формулювання цілей і планування фіч до реалізації, тестування, рев’ю, інтеграції й довготривалої підтримки. Якщо Goose — це інструмент, який сидить поруч із розробником у редакторі коду, то Factory намагається побудувати інфраструктуру, де людина визначає, що потрібно зробити, а система з агентів сама розбирається, як це реалізувати.
У цьому підході є важливий зсув: людина перестає бути «операційним менеджером» для кожного кроку й стає радше постановником задач і арбітром результату. Саме тому Люк формулює свою мету в розмові дуже конкретно: через 20 хвилин слухач має розуміти, як зібрати команди агентів, здатні виконувати завдання на порядки складніші, ніж ті, що сьогодні під силу одному агенту.
Це не про ще один фреймворк для LLM‑ботів. Це про спробу переформатувати саму організацію розробки: від моделі «інженер + інструменти» до моделі «інженер + автономна багатоденна місія».
Goose як передісторія Missions: чому досвід кодування важливий для автономії
На перший погляд може здатися, що Goose і Factory — це два різні світи: один про кодинг‑агента, інший — про складні багатоденні місії. Насправді між ними пряма спадковість.
По‑перше, Goose дав практичний досвід того, як агенти поводяться в реальних кодових базах. Це не абстрактні «іграшкові» завдання, а живі репозиторії з технічним боргом, історією комітів, неоднорідними стилями коду. Саме в таких умовах стає очевидно, що агент, який сам собі пише тести після реалізації фічі, часто лише підтверджує власні рішення, а не ловить помилки. Тести «підганяються» під реалізацію, а не під реальні вимоги.
По‑друге, досвід Goose показав, наскільки важливо розділяти ролі й контексти. Людина‑рев’юер, яка вперше бачить код, знаходить помилки, які автор не помічає через когнітивне упередження. Те саме стосується агентів: свіжий контекст і відсутність «інвестиції» в конкретну реалізацію роблять перевірку якіснішою.
По‑третє, робота над Goose виявила, що одиночний агент неминуче накопичує «втому контексту»: довгі сесії, змішані завдання, розмиті цілі. Це природне обмеження, яке важко подолати, не розбиваючи процес на окремі ролі з чіткими межами відповідальності.
Усе це безпосередньо відбилося в архітектурі Missions — багатоденної системи Factory, яка поєднує кілька агентів у єдину цілісну «місію».
Missions: як Factory збирає команди агентів, що працюють днями
Missions — це відповідь Factory на питання, як змусити агентні системи працювати не хвилини, а дні й навіть тижні. Замість одного «універсального» агента тут діє екосистема з чітко визначеними ролями, які взаємодіють через структуровані хендофи й спільний стан.
Користувач описує ціль, разом із системою уточнює вимоги, затверджує план — і далі місія може працювати годинами чи днями, поки людина займається іншими справами. Найдовша місія, за даними Factory, тривала 16 днів, і в компанії вважають, що архітектура дозволяє дотягнути до 30‑денних прогонів.
У центрі цієї системи — три ролі: оркестратор, воркери й валідатори.
Оркестратор відповідає за планування. Він спілкується з користувачем, ставить стратегічні запитання, виявляє неясні вимоги й у підсумку формує план із фічами, майлстоунами та ключовим артефактом — валідаційним контрактом. Саме цей контракт визначає, що означає «готово» ще до того, як буде написано перший рядок коду.
Воркери займаються реалізацією. Кожен воркер отримує чистий контекст: без «втоми», без накопиченого історичного шуму. Він читає специфікацію своєї фічі, імплементує її й комітить зміни в Git. Наступний воркер успадковує вже оновлену, робочу кодову базу й знову стартує з чистим контекстом.
Валідатори відповідають за перевірку. На відміну від багатьох систем, де валідація обмежується лінтерами, тайпчеками й тестами, Missions додає ще один критичний рівень — поведінкову перевірку. Питання ставиться не лише так: «Чи виглядає код правильним?», а й так: «Чи працює все це end‑to‑end так, як задумано?».
Ця трирольова архітектура — прямий розвиток уроків, отриманих із Goose: розділення відповідальності, чисті контексти, незалежна перевірка.
Валідаційний контракт: як формалізувати «готово» до написання коду
Одним із найцікавіших елементів Missions є валідаційний контракт. Це документ, який створюється на етапі планування оркестратором і визначає коректність незалежно від конкретної реалізації.
У типовому сценарії з кодинговими агентами тести часто пишуться після того, як реалізовано фічу. У результаті вони відображають уже прийняті рішення, а не початкові вимоги. Такий підхід погано ловить логічні помилки: тест підтверджує те, що код уже робить, а не те, що він мав би робити.
Валідаційний контракт у Missions працює навпаки. Він фіксує вимоги до поведінки системи до того, як з’являється код. Для складних проєктів це можуть бути сотні тверджень, кожне з яких описує окремий аспект коректності. Кожній фічі в плані призначаються одна або кілька таких assertions, які вона має задовольнити. У сумі всі фічі повинні покрити весь контракт.
Це зміщує центр ваги з реалізації на специфікацію. Код більше не є «джерелом істини» щодо того, як має працювати система. Джерелом істини стає контракт, сформований до реалізації, і саме він керує як розробкою, так і перевіркою.
Для Factory це не просто технічна деталь, а ключ до довготривалих місій. Якщо валідація прив’язана до реалізації, система неминуче «дрейфує» з часом. Якщо ж вона прив’язана до незалежного контракту, у неї з’являється стабільний орієнтир, який не змінюється разом із кожною ітерацією коду.
Дві лінії захисту: scrutiny‑ та user‑testing‑валідатори
Щоб валідаційний контракт не залишався теорією, Missions використовує два типи валідаторів, які запускаються після кожного майлстоуна.
Перший — scrutiny‑валідатор. Це більш традиційний рівень перевірки: він запускає тестовий набір, тайпчекінг, лінтери й, що важливо, породжує окремих агентів‑рев’юерів для кожної завершеної фічі в межах майлстоуна. Таким чином, кожна зміна проходить через свій «код‑рев’ю», але виконаний агентом із чистим контекстом, який не брав участі в реалізації.
Другий — user‑testing‑валідатор. Він поводиться як QA‑інженер: піднімає живий застосунок, взаємодіє з ним через інтерфейс комп’ютера, заповнює форми, клікає кнопки, перевіряє рендеринг сторінок і цілісність функціональних потоків. Це вже не перевірка коду, а перевірка поведінки системи в реальному середовищі.
Саме цей етап займає більшу частину «настінного» часу місії. Більшість годин витрачається не на генерацію токенів, а на реальне виконання застосунку й інтерактивні дії з ним. Це ще один наслідок переходу від одиночних агентів до автономних місій: вузьким місцем стає не швидкість моделі, а час, потрібний для реального прогону системи.
Критично важливо, що жоден із валідаторів не бачить код до моменту перевірки. Вони не «вкладені» в процес розробки й не «співпереживають» реалізації. Валідація задумана як принципово адверсаріальна: завдання валідатора — не підтвердити роботу воркера, а знайти, де вона не відповідає контракту.
Структуровані хендофи й самовідновлення місій
Ще одна проблема довготривалих агентних систем — втрата контексту. Якщо просто передавати «я все зробив» від одного агента до іншого, помилки неминуче накопичуються, а система втрачає уявлення про те, що саме відбувалося на кожному кроці.
У Missions це вирішується через структуровані хендофи. Коли воркер завершує роботу над фічею, він не просто сигналізує про завершення. Він заповнює детальний звіт: що саме було зроблено, що залишилося невиконаним, які команди запускалися, з якими кодами виходу, які проблеми були виявлені й чи дотримувався він процедур, визначених оркестратором.
Ці хендофи стають основою для самовідновлення місії. Помилки ловляться на межах майлстоунів, а коригувальні роботи оформлюються як нові фічі. Місія «повертає себе на курс» не за рахунок того, що агенти «пам’ятають», що сталося, а за рахунок того, що вони зобов’язані це задокументувати й потім явно відреагувати.
Саме така структурованість дозволяє місіям тривати 16 днів і більше. Без неї система неминуче загрузла б у хаосі часткових знань і неявних припущень.
Серійність замість хаотичного паралелізму
Інтуїтивно може здаватися, що для прискорення роботи агентної системи потрібно просто запустити більше агентів паралельно. Але досвід Factory показав, що в домені розробки ПЗ такий підхід швидко впирається в конфлікти: агенти наступають один одному на зміни, дублюють роботу, приймають несумісні архітектурні рішення. Координаційні витрати з’їдають виграш у швидкості, а витрати на токени лише ростуть.
Missions обирає іншу стратегію: серійне виконання фіч. У будь‑який момент часу активний лише один воркер або один валідатор. Паралелізм дозволяється, але тільки всередині фічі й лише для операцій «тільки читання»: пошук по кодовій базі, дослідження API, аналіз документації. У валідаторах аналогічно паралелізуються read‑only‑задачі, наприклад код‑рев’ю.
На папері це виглядає повільніше. Але різко падає рівень помилок, а на горизонті багатоденних місій саме коректність починає «композуватися» й давати виграш. Якщо система рідше помиляється, їй потрібно менше переробок, менше коригувальних фіч і менше людського втручання.
Це ще один приклад того, як Factory відходить від інтуїтивних, але поверхневих оптимізацій на користь структурних рішень, які працюють на довгій дистанції.
«Droid whispering»: нова компетенція інженера в епоху агентів
Уся описана архітектура Missions передбачає ще одну важливу передумову: у кожній ролі має бути «правильна» модель. Планування виграє від повільного, обережного міркування; реалізація — від швидкої кодової «плавності» й креативності; валідація — від максимально точного слідування інструкціям. Жодна окрема модель чи провайдер не є найкращими в усіх трьох режимах одночасно.
У Factory це називають «droid whispering» — умінням ментально моделювати, як різні LLM поводяться, де вони помиляються й як ці помилки накопичуються в багатоденних місіях. Інженер, який працює з Missions, має свідомо обирати, яка модель «сидить» у якій ролі, а не покладатися на єдиного «універсального» постачальника.
Більше того, валідація може й повинна використовувати інший модельний стек, ніж реалізація, щоб зменшити ризик спільних упереджень, пов’язаних із тренувальними даними. Це ще один структурний плюс модель‑агностичної архітектури: система не прив’язана до одного вендора й може комбінувати сильні сторони різних моделей.
У підсумку виявляється, що в епоху агентних систем інженерна компетенція зміщується. Важливо не лише вміти писати код чи налаштовувати пайплайни, а й розуміти, як «оркеструвати» різні моделі в різних ролях, щоб вони разом давали стійкий результат на довгій дистанції.
Висновок: від інструментів до автономних місій
Шлях Люка Алвоейру — від dev‑tools через Goose до Factory — добре ілюструє еволюцію інструментів для розробників у добу AI. Спочатку з’являється потужний кодинговий агент, який допомагає писати й рефакторити код. Потім стає зрозуміло, що справжнє вузьке місце — не в інтелекті моделей, а в обмеженій людській увазі. Далі народжується ідея системи, де людина визначає цілі, а команда агентів сама планує, реалізує й перевіряє роботу протягом днів.
Goose як один із провідних open source‑кодингових агентів і його передача до Agentic AI Foundation створили фундамент для спільноти й дали практичний досвід роботи з агентами в реальних кодових базах. Factory, де Люк тепер очолює core agent harness, піднімає планку: місія компанії — принести автономію в увесь життєвий цикл розробки ПЗ, а не лише в написання коду.
Missions — конкретне втілення цієї амбіції: трирольова архітектура з оркестратором, воркерами й валідаторами, валідаційний контракт, структуровані хендофи, серійне виконання з вибірковим паралелізмом і модель‑агностичний підхід до вибору LLM. Усе це разом дозволяє місіям працювати 16 днів і більше, ловити помилки на межах майлстоунів і самостійно повертатися на курс.
У цьому контексті питання вже звучить не так: «Чи може AI писати код за нас?», а радше так: «Як організувати команди агентів так, щоб вони виконували завдання на порядки складніші, ніж ті, що сьогодні під силу одному агенту?». Відповідь, яку пропонує Factory, спирається на роки роботи з Goose і показує, що наступний етап еволюції dev‑tools — це не ще один помічник у редакторі, а повноцінні автономні місії, які працюють дні й тижні.
Джерело
YouTube: Missions: Multi-Agent Systems That Ship for Days — Luke Alvoeiro, Factory