Американський підприємець і розробник Остін Маркезе, відомий своїми практичними гайдами з побудови AI‑стеків на базі Claude, у новому великому розборі восьми «лупів» зосереджується не лише на даних та аналітиці, а й на самому процесі розробки. Окрема частина його системи — code-build loop, який він пропонує використовувати для так званого «vibe coding» продуктів, навіть тим, хто не має технічного бекграунду.
Йдеться не про ще один генератор коду, а про структурований, поетапний конвеєр, де AI і людина працюють разом, а в критичних точках рішення залишається за людиною.
Що таке vibe coding і навіщо тут взагалі loop
Code-build loop у цій системі позиціонується як спеціальний інструмент для тих, хто хоче «vibe coding» — по суті, розробляти продукт, спираючись на бачення й цілі, а не на детальну технічну специфікацію, яку потрібно виписати вручну. Маркезе наполягає, що так має працювати буквально кожен, «чи є у вас технічний бекграунд чи ні».
Центральна ідея така: замість того, щоб одразу «тиснути на газ» і змушувати AI щось програмувати, спочатку потрібно дати системі правильно зчитати ваш задум, перетворити його на план, потім підтвердити його людиною — і лише після цього запускати розробку.
Як він формулює головний принцип: у будь-якому vibe coding «не можна просто взяти й усе одразу “grip and rip”». Потрібен план перед тим, як щось робити. Без цього навіть потужний code‑assistant перетворюється на інструмент для генерування хаосу, який доведеться дорого виправляти.
Як працює code-build loop: від цілей до коду
Code-build loop у цій архітектурі — це не просто один промпт, а послідовність кроків, які зшиті через skill chaining. На екрані в його розборі видно промпт, який розбиває завдання на шість частин; саме цей поділ і створює «луп», що проходить через увесь цикл розробки.
Логіка виглядає так.
Спочатку система витягує або підтягує ціль. Це може бути інтерв’ю з користувачем усередині Claude або вже готовий документ з описом продукту чи функціональності. Важливо, що луп починає роботу не з коду, а з уточнення того, «чого ми насправді хочемо досягти».
Далі Claude планує доставку, використовуючи вбудований plan mode. На цьому етапі AI перетворює розмиті цілі на структурований план реалізації: які підзадачі потрібні, які модулі треба створити, у якій послідовності це робити. Це ключова відмінність vibe coding у такому форматі від звичайного «згенеруй мені функцію X».
Третій крок — підписати план. Це момент, коли у гру заходить людина. Луп спеціально зупиняється, щоб користувач переглянув і затвердив план. На цьому етапі ще нічого не написано, але вже зрозуміло, в який бік рухається система.
Лише після цього, на четвертому кроці, луп переходить до власне «build it» — генерації коду відповідно до затвердженого плану. П’ятий крок — рев’ю коду, де використовується спеціальний skill /code-review-fix. Claude тут не просто пише код, а одразу ж проходить через внутрішню перевірку, шукає помилки й пропонує виправлення.
Шостий крок — верифікація поведінки проти початкової цілі. Тут у хід іде /verify: система порівнює, чи поводиться зібраний модуль або продукт так, як це було задумано на першому та другому кроках. Лише якщо відповідність підтверджена, луп можна вважати завершеним.
Таким чином, code-build loop перетворює спонтанне «давай щось напишемо» на керований процес: ціль → план → людське підтвердження → розробка → рев’ю → перевірка відповідності цілі.
Approval gates: чому людський підпис критичний
Окрема тема, на якій Маркезе робить акцент у контексті code-build loop, — це approval gates, тобто вбудовані точки, де без людського підтвердження система не рухається далі.
Третій крок — «sign off on the plan» — якраз і є таким approval gate. Він називає його «critical call checkpoint» і пояснює логіку дуже прямо: якщо на цьому етапі ви рухаєтесь не в той бік, «кроки чотири, п’ять і шість будуть повністю неправильними, і ви просто витрачатимете час і гроші».
Звідси його загальне правило: для будь-якого лупа, який ви створюєте, якщо десь з’являється критичний момент прийняття рішення, туди обов’язково потрібно додавати human approval gate. Десь це може бути один такий чек‑пойнт, у іншому лупі — чотири чи п’ять, а в якомусь — жодного. Все залежить від того, що саме будується і які ризики несуть помилки.
У випадку code-build loop критичним виявляється саме момент планування. Від того, наскільки точно луп зчитав ваші цілі та перетворив їх на кроки, залежить усе подальше: і якість коду, і релевантність перевірок, і навіть корисність фінальної верифікації. Якщо план схибив, подальша автоматизація лише прискорить рух у неправильному напрямку.
Таким чином approval gates тут виконують одразу дві ролі: з одного боку, вони захищають від марнування ресурсів; з іншого — залишають за людиною роль «творчого диригента» навіть тоді, коли вся технічна реалізація делегована AI.
Dynamic workflows: як Claude ділить роботу між агентами
Другий концепт, який Маркезе пов’язує з code-build loop, — це dynamic workflows. Саме через них Anthropic реалізує поділ складних цілей між різними AI‑агентами всередині Claude.
Ідея в тому, що коли ви формулюєте ціль у рамках лупа, система не обов’язково вирішує її одним «монолітним» проходом. Dynamic workflows дозволяють розподілити завдання на ролі й етапи, які можуть виконуватись різними агентами, а потім зібрати результат назад у єдину відповідь.
За словами Маркезе, Anthropic задокументував шість патернів для таких dynamic workflows. На його скріншоті їх можна роздивитися, але, як він сам зауважує, щоб отримати 80 % користі, про більшість деталей можна не думати: система сама обирає відповідний патерн для даного завдання.
Для користувача code-build loop це означає, що за єдиним промптом і зручним «лупом» насправді ховається гнучка архітектура з кількох агентів, які ділять між собою роботу: хтось «інтерв’ює» вас і витягує цілі, хтось планує, хтось пише код, хтось його рев’ює, хтось перевіряє поведінку. І все це відбувається без необхідності вручну налаштовувати кожну роль.
Водночас тим, хто хоче глибше «погратися» з такими схемами, Маркезе пропонує використовувати офіційну документацію як стартову точку: зрозуміти базові шість патернів і вже від них будувати власні комбінації в рамках своїх лупів.
Vibe coding як дисципліна, а не хаос
Коли говорять про «vibe coding» з AI, легко уявити собі якийсь хаотичний процес: користувач описує ідею у вільній формі, модель щось генерує, усе швидко змінюється й переписується. У запропонованій Маркезе архітектурі все навпаки: vibe coding стає дисциплінованим, контрольованим і поетапним.
Code-build loop робить дві речі одночасно. З одного боку, він захищає людину від технічних деталей: не потрібно самому продумувати структуру коду, послідовність задач чи шаблони рев’ю. З іншого — змушує не перескакувати через фундаментальні етапи: спочатку чітка ціль, потім план, потім людський підпис, і лише після цього — автоматизація.
У поєднанні з approval gates і dynamic workflows це перетворює AI‑кодогенерацію з «чорної скриньки», якій просто підкидають побажання, на прозорий виробничий процес, де кожен крок можна побачити, скоригувати або зупинити.
Для тих, хто хоче будувати продукти швидше, але не готовий віддавати контроль над напрямком, такий підхід пропонує компроміс: AI бере на себе важку технічну роботу, а людина визначає, що саме треба будувати й коли сказати «стоп».