Я бачу два способи, як команди помиляються в роботі з AI, і вони є дзеркальним відображенням один одного.
Перша команда опирається. Кожен рядок, написаний асистентом, переписується вручну, бо довіра до нього здається нерозсудливістю. Генерація сприймається як загроза, яку треба стримувати, а не як можливість, яку слід спрямовувати. Такі команди витрачають час на церемонії, не отримують швидкості та переконують себе, що це ціна якості.
Друга команда капітулює. Вимоги живуть у чатах, асистент створює pull request, який ніхто не може нормально перевірити, бо немає зафіксованого задуму для порівняння. Визначення "готово" звучить як «один раз запустилося на моїй машині». Це швидко рівно до того моменту, поки не стає катастрофічно повільно — зазвичай на третій фічі, коли context window заповнюється і model починає непомітно суперечити рішенням, прийнятим годину тому.
Обидві команди ставлять хибне питання. Вони запитують, скільки AI використовувати, ніби відповідь — це повзунок від нуля до одиниці. Корисне питання звучить інакше: яка робота належить машині, у який момент життєвого циклу змін, і хто контролює перехід між етапами?
На це питання є чітка відповідь, навколо якої можна побудувати робочий процес. Я хочу розібрати життєвий цикл розробки, де правильний agent підключається у правильний час, підпорядковується стандартам архітектури та працює в межах легкої runtime-системи.
Життєвий цикл, до якого ми прагнемо
Основну роботу виконують два методи, на які я буду спиратися.
Shape Up задає зовнішній трек. Роботу оформлюють у чітко обмежений пітч (pitch), перш ніж брати на себе зобов'язання. Потім за неї "голосують" за столом ставок (betting table) і передають команді, яка має фіксований "апетит" (appetite) на всю розробку. Слово appetite тут ключове. Ми не оцінюємо, скільки часу займе зміна, щоб потім не вкластися в дедлайн. Ми вирішуємо, скільки ця зміна коштує, фіксуємо бюджет і коригуємо scope, щоб у нього вписатися. Якщо робота не встигає, ми ріжемо обсяг, а не якість, і ніколи не додаємо час нишком.
OpenSpec — це двигун всередині треку. Сформований пітч однією командою розгортається у конкретні артефакти: proposal (чому і що ми робимо), набір specs (сценарії приймання), design (опис підходу) та список завдань. Робота виконується згідно зі specs, публікується, проходить review і зберігається як "джерело істини". Specs лежать у repository поруч із кодом, тому наступна зміна починається з актуальної картини, а не з нечітких спогадів.
У цьому описі є прогалина, якій і присвячена ця стаття. Specs кажуть, що робить зміна. Але вони нічого не говорять про те, як ваша команда вирішила будувати систему. Якщо залишити model саму на себе, вона обере найпопулярнішу архітектуру зі своїх тренувальних даних. Це майже ніколи не буде та архітектура, про яку домовилася ваша команда. У результаті ви отримаєте патерни, які заборонили два роки тому, або черги там, де ви домовилися обробляти все у запиті. Це просочуватиметься в codebase з кожним новим pull request.
Три джерела істини
Рішення полягає в тому, щоб визнати: здоровий життєвий цикл має не два джерела істини, а три.
Пітч (Pitch) відповідає за "чому". Він тимчасовий і зникає, щойно роботу прийняли або відхилили.
Спеки (Specs) відповідають за "що". Вони описують поведінку конкретної зміни та архівуються в живу документацію системи.
Architectural Decision Records (ADR) відповідають за "як". Вони довговічні, стосуються кожної зміни та фіксують сталі рішення команди щодо розробки. ADR — це короткий, навмисно нудний документ: статус, контекст, саме рішення та наслідки. Прийнятий ADR не редагують — його замінюють новим, щоб зберегти логіку прийняття рішень.
Ось як ADR стають корисними в AI-процесі: прийняті рішення перетворюються на обмеження, в яких працює кожен agent. Зміна, що потребує нового архітектурного рішення, не може бути реалізована просто за вказівкою AI. Стандарти вливаються в specs і діалоги, а нові стандарти з'являються лише під контролем людини.
Державна машина зі змішаним володінням
Якщо виписати стадії зміни — shaped, bet on, proposed, built, published, reviewed, archived — і запитати, хто саме виконує роботу на кожному етапі, ви отримаєте три різні відповіді.
Деякі етапи — це виключно людське судження. Agent не має до них відношення. Визначення appetite — це оцінка цінності. Ставка (bet) — це рішення про те, чим ми готові пожертвувати. Прийняття ADR — це зобов'язання, з яким команда житиме роками. Жодна model не має тут права голосу.
Деякі етапи — це чернетка машини та правки людини. Розгортання грубого пітчу в детальний spec — це саме та структурована робота, в якій сильна reasoning model. Людині простіше прочитати й виправити, ніж писати з чистого аркуша. Те саме стосується опису pull request на основі spec.
Деякі етапи є фактично автоматичними. Перенесення замердженої зміни назад у джерело істини — це механічна робота. Вона має просто відбуватися.
Більшість інструментів для agent ігнорують цей розподіл, вважаючи, що кожна стадія потребує однакового підходу. Питання не в тому, наскільки розумна model, а в тому, де зосереджена влада. Архітектура — це сфера людської влади. Agent може застосовувати прийняте рішення або пропонувати чернетку нового, і це межа його повноважень.
Runtime — це те, що тримає ворота
Якщо дивитися на життєвий цикл так, то внутрішня система (runtime) стає простою. Це workflow engine, який знає послідовність етапів, розуміє, де потрібна людина, а де — agent, і рухає зміну крок за кроком. Нічого екзотичного.
Цінність такої системи не в розумності, а в правилах, які вона відмовляється порушувати. Вона не пропустить етап, де потрібна людина. Вона не запустить agent там, де йому не місце. Вона не дозволить зміні вийти за межі appetite. І вона не просуне зміну на основі архітектурного рішення, яке не схвалила людина. Це чотири правила, які зазвичай тримаються на силі волі, але тепер передані системі, яка не втомлюється і не має дедлайнів.
Правило, що живе лише у wiki — це просто порада. А поради завжди програють дедлайнам. Правило, яке забезпечує runtime — це реальність, на яку команда може покластися навіть о шостій вечора, коли всі готові апрувнути будь-що.
Правильний agent на правильному етапі
Коли ми проходимо по етапах, принцип "правильний інструмент у потрібний час" перестає бути гаслом.
На етапі shaping швидкий і дешевий "критик" сперечається з чернеткою пітчу. Він не формує роботу — це робить людина. Він тисне: чи чесний цей appetite, чи не є велика задача "вовком в овечій шкурі", де приховані ризики і чи не потребує ця робота архітектурного рішення, якого ще немає. Виявлення останнього до початку розробки означає, що ставка робиться свідомо.
На етапі betting асистента немає взагалі. Це найважливіший вибір у дизайні системи. Ставка — це рішення про те, чим ми жертвуємо в цьому циклі, і я не хочу бачити тут model. Відсутність автоматизації в цьому місці захищає процес від надмірного втручання AI.
На етапі proposing reasoning model розгортає пітч у повний spec. Тут вступають у дію стандарти. Прийняті ADR передаються моделі як обмеження, тому дизайн відповідає домовленостям команди, а не статистичній популярності в інтернеті. Якщо дизайн вписується в ADR, він посилається на них. Якщо ні — model не імпровізує. Вона створює чернетку нового ADR, описує контекст і зупиняється. Дизайн, що суперечить чинному рішенню, обробляється так само — як пропозиція замінити ADR, що є серйозним кроком і виключно людським рішенням.
На етапі building coding agent виконує завдання зі списку і звітує про прогрес. На "спуску", коли робота зрозуміла, agent працює швидко і надійно. Якщо він застряє на "підйомі" (невизначеності) занадто довго — це ваше раннє попередження, набагато ефективніше за пропущений дедлайн.
На етапі publishing підготовка механічна, а дія — ні. Agent пише опис pull request на основі spec та ADR, і зупиняється. Людина відкриває його. Все, що змінює світ за межами repository, залишається під контролем людини.
Ворота — це сенс процесу
Завжди є спокуса прибрати обмеження (gates) заради швидкості. Але вони критично важливі.
Існує три типи воріт: ворота судження (shaping, betting, review), де робота чекає на схвалення людини. Ворота архітектури, де зміна стоїть на паузі до рішення щодо ADR. І ворота побічних ефектів (publishing, merging), дії яких не повинні виконуватися лише на основі впевненості моделі.
Помилка інструментів для agent — це рідко поганий рядок коду. Review це виправить. Справжня проблема — це незворотна дія або неперевірений архітектурний вибір, зроблений у невідповідний момент. Ви ставите ворота саме для того, щоб вони тримали удар, коли людина втомлена і готова натиснути "так" на все підряд.
Запобіжник і стандарти подвійної дії
Appetite — це не рекомендація. Якщо зміна виходить за межі бюджету, робота не переноситься і дедлайн не обговорюється. Вона повертається на етап shaping, щоб бути переосмисленою. Зупинка незавершеної роботи замість її нескінченного затягування — це найздоровіша звичка, яку дає Shape Up.
Стандарти працюють так само: їх дотримуються, а не просто сподіваються на них. Кожен spec і кожен діалог з agent обмежені рішеннями, які прийняла людина. Архітектура не може деградувати через один "зручний" pull request. Кожне нове рішення виноситься на обговорення окремо, а не ховається всередині diff.
Варто уточнити різницю між ADR та звичайним файлом конвенцій. Конвенції — це дистильовані правила, яким agent слідує щодня. ADR — це логіка прийняття цих правил. Коли хтось запропонує змінити правило, він буде сперечатися з оригінальним контекстом, а не вгадувати його. Тримайте обидва формати і, якщо можливо, генеруйте конвенції з прийнятих ADR.
Чому це важливо, а не просто набір команд
Можна запитати: навіщо життєвому циклу цілий runtime, якщо можна просто запускати команди, а ADR — це лише файли в папці?
Тому що процес — це перше, чим нехтують під тиском. Людина у стресі — найгірший охоронець правил. Цінність runtime у тому, що він тримає ворота там, де людина б здалася. Він не дасть просунути зміну без схвалення пізно ввечері. Він спрацює як запобіжник для задачі, в яку всі емоційно вклалися, але не встигли. Дисципліна перестає залежати від пам'яті кожного і стає властивістю системи.
Серце цієї системи — послідовність етапів, ворота, апетит, лог рішень — не залежить від жодного framework чи мови програмування. Це workflow engine із розподіленою владою. Я б будував його незалежним, дозволяючи AI-інструментам підключатися по краях. Що, як ви помітили, саме по собі є архітектурним рішенням, яке варто зафіксувати в ADR. Runtime зрештою будується так, як каже його власний лог рішень — і в цьому полягає ідея, що працює сама на себе.
Наступного разу я хочу детальніше розібрати двох agents: критика, який сперечається з вашим пітчем, та рев'юера, який перевіряє AI-код на коректність та відповідність стандартам. Бо саме тут найменша помилка в ролі моделі може отруїти весь подальший процес.