Практичний досвід: покроково навчіть вас використовувати 7 агентів для підвищення Vibe Coding до рівня експертного процесу розробки

Автор @sairahul1 розбив революцію робочого процесу від «Vibe Coding» до «Softwarе Factory»: розділив один AI-діалог на 7 спеціалізованих агентів: дослідник, сценарист, розробник специфікацій, бекенд-розробник, фронтенд-розробник, тестувальник, валідатор — кожен з них має лише одну відповідальність, чистий контекст і суворі межі.
(Передісторія: поєднання MCP, що з’єднує все, з Web3 — чи зможе це стати наступною хвилею AI-оповідей у сотні разів більших масштабах?)
(Додатковий фон: найкращі інвестиційні майстри допомагають тобі працювати! Збірка з Бейфітом, Монгом, Cathie Wood… 19 AI-агентів для аналізу ринку)

Зміст статті

Перемикач

• Той питання, про яке ніхто не говорить
• Перехід: від Vibe Coding до Softwarе Factory
• Сім агентів
  • Агент 1: Дослідник кодової бази (Codebase Researcher)
  • Агент 2: Сценарист (Story Writer)
  • Агент 3: Спеціаліст з технічних специфікацій (Spec Writer)
  • Агент 4: Бекенд-розробник (Backend Builder)
  • Агент 5: Фронтенд-розробник (Frontend Builder)
  • Агент 6: Тестувальник (Test Verifier)
  • Агент 7: Валідатор реалізації (Implementation Validator)
• Як працює вся ланцюг
• Основи: перед тим, як агент може працювати, потрібне це
  • CLAUDE.md — збереження пам’яті кожного діалогу
  • Зміщення контексту — той безмовний вбивця
• Результат: що справді змінюється
  • До фабрики:
  • Після фабрики:
  • Справжня зміна:
• Зроби свою версію вже цього вікенду
  • 8 кроків налаштування:
• Сім агентів — швидкий огляд

Я думав, що використовую AI для програмування. Насправді, я просто швидше друкую.

Ця стаття про різницю — і про «7 систем агентів», що кардинально змінює все.

Збережи цю статтю. Вона заощадить тобі кілька місяців.

Той питання, про яке ніхто не говорить

Цикл, що здається продуктивним, але насправді ні:

→ Попросити Claude зробити функцію → вона генерує код → щось зламалося → вставити помилкове повідомлення назад → вона виправляє → знову щось зламалося → знову питати

Перший день: Це здається магією.

Через 30 днів: ти витрачаєш більше часу на контроль AI, ніж раніше — сам писав би швидше.

Та сама логіка проявляється у трьох різних місцях. Claude забув твої домовленості двотижневої давності. Нові функції руйнують старі. Тестування або відсутнє, або дуже поверхове.

Ти прокидаєшся і усвідомлюєш: не AI провалюється, а твій робочий процес.

Суть проблеми — структурна.

Коли ти вводиш команду «зроби цю функцію» у Claude Code, ти фактично просиш AI-діалог одночасно виконувати ролі:

→ Аналізатор продукту → Архітектор → Бекенд-інженер → Фронтенд-інженер → Тестувальник → Рецензент коду

усе одразу. У одному хаотичному діалозі.

Помилки в плані стають неправильними моделями баз даних. Неправильна модель — неправильним API. Неправильний API — неправильним UI.

Коли ти це помічаєш, помилки вже розповсюдилися скрізь.

Це так званий vibe coding (програмування на основі відчуття).

В нього є дуже жорстка межа.

Перехід: від Vibe Coding до Softwarе Factory

Ключ, що справді змінює все:

справжня команда інженерів не працює у великому діалозі.

Різні люди мають різні ролі:

→ хтось уточнює проблему користувача → хтось думає про архітектуру → хтось пише API → хтось створює UI → хтось аналізує крайні випадки → хтось робить рев’ю

Коли все це зводиться до одного AI-діалогу, помилки тихо накопичуються.

Шлях до виправлення — розділити роботу між спеціалізованими агентами.

Кожен агент отримує:

→ сфокусоване завдання → чистий контекст → лише ті інструменти, що йому потрібні → суворі правила щодо «недоторканих» областей

Результат: Це — Softwarе Factory.

Один розробник + сім сфокусованих агентів = однако скоординована команда.

Ось сім агентів, що роблять цю систему можливою.

Сім агентів

Агент 1: Дослідник кодової бази (Codebase Researcher)

Що найчастіше роблять помилки при використанні AI для розробки?

Вважати «потрібен код» першим кроком.

AI отримує підказку, робить здогади, заповнює прогалини, починає генерувати. Поганий дизайн — це саме тоді, коли він «проникає» всередину.

Дослідник виправляє цю ситуацію.

Його єдине завдання: перевірити кодову базу і пояснити поточний стан — ще до написання рядка коду.

Що він робить:

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

Що він не робить:

• Редагує файли (тільки читання)
• Виконує дії, що змінюють стан системи
• Робить припущення — краще ставити запитання

Інструменти: Read, Grep, Glob — і більше нічого.

Правило: перед початком роботи завжди досліджуй.

Дослідник завжди перший.

Агент 2: Сценарист (Story Writer)

Більшість невдач функцій — не через неправильний код.

Але через те, що проблема ніколи не була чітко визначена.

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

Вхід:

• Ваші приблизні описи функцій
• Результати досліджень дослідника

Вихід:

• Користувацька історія: «Як [роль], я хочу [дію], щоб [результат].»
• Критерії прийняття: тестовані, чіткі описи — Happy path, сценарії відмови, бізнес-правила.
• Краї крайні випадки: крайні ситуації, повтори, мультиоренда
• Що не входить у сферу: що явно «не робитиметься»
• Нез’ясовані питання: що він справді не знає — не здогадується

Що він не робить:

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

Інструменти: Read — і більше нічого.

Правило: потрібно прочитати і затвердити історію, щоб перейти до наступного кроку.

Це — ключовий людський контрольний пункт 1.

Агент 3: Спеціаліст з технічних специфікацій (Spec Writer)

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

Цей документ — карта для всіх агентів, що будуть будувати.

Вхід:

• Затверджена історія користувача
• Результати досліджень дослідника
• Правила CLAUDE.md для проекту

Вихід:

• Зміни у моделі даних (поля, типи, міграції)
• Бізнес-процеси / логіка обробки
• Зміни API (ендпоїнти, формати запитів/відповідей)
• Зміни у фронтенді (компоненти, сторінки, hooks)
• Необхідні тести (успіх, провал, крайні випадки)
• Ризики і нез’ясовані питання
• Файли, що підлягають зміні

Що він не робить:

• Редагує файли напряму
• Винаходить нову інфраструктуру — лише вказує
• Ігнорує мультиоренду, часи
• Залишає нез’ясовані питання

Інструменти: Read, Grep, Glob — і більше нічого.

Правило: ця документація — людський контрольний пункт 2.

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

Якщо побачите «зберігати ID у пам’яті» — це червоний прапор.

Зараз — виявляйте. Не чекайте, поки змінять 10 файлів.

Агент 4: Бекенд-розробник (Backend Builder)

Тільки починаєте будувати.

Бекенд-розробник реалізує «бекенд-частину» функції — і тільки її.

Вхід:

• Затверджена технічна документація
• Результати досліджень дослідника
• Ваш проект CLAUDE.md

Він створює:

• API маршрути
• Сервіси і бізнес-логіку
• Доступ до бази даних і міграції
• Фонові задачі
• Юніт-тести для написаного коду

Що він не робить:

• Працює з React-компонентами, сторінками або клієнтськими hooks (це — робота агентів 5)
• Винаходить нові залежності без вказівки
• Модифікує файли поза межами бекенду
• Запускає без typecheck, lint, тестів

Після завершення — повертає короткий звіт: список змінених файлів, повторно використані шаблони або допоміжні модулі, зауваження щодо CLAUDE.md.

Інструменти: Read, Edit, Write, Bash — тільки для бекенд-папки.

Головне — розділяти відповідальність.

Бекенд-розробник ніколи не зможе випадково зламати фронтенд.

Агент 5: Фронтенд-розробник (Frontend Builder)

Фронтенд-розробник реалізує UI — і тільки UI.

Він читає з резюме бекенд-агента.

Це важливо.

Він використовує API, створений бекендом. Не винаходить нові ендпоїнти.

Якщо форма API неправильна для UI,** він повідомить про це — і не сам виправить.**

Вхід:

• Затверджена технічна документація
• Результати досліджень дослідника
• Резюме API від бекенд-агента (контракт API)

Він створює:

• React-компоненти і сторінки
• Hooks і стан клієнта
• Стани завантаження і помилок
• Юніт-тести для компонентів і логіки

Що він не робить:

• Працює з сервісами, API маршрутиками, воркерами або міграціями (це — робота агента 4)
• Винаходить нові ендпоїнти або формати відповідей
• Додає залежності без вказівки
• Запускає typecheck, lint, тести

Після завершення — отримує короткий звіт: файли, що змінені, і їхній зміст.

Інструменти: Read, Edit, Write, Bash — тільки для фронтенд-папки.

Два агенти. Два чистих контексти. Ймовірність, що один з них зламає іншого, — нульова.

Агент 6: Тестувальник (Test Verifier)

Обидва агенти пишуть юніт-тести.

Але цього недостатньо.

Тестувальник робить лише одне: переконатися, що функція справді виконує історію користувача.

Він пише «Acceptance Tests» — тестування, що імітує реального користувача.

Вхід:

• Затверджена історія користувача (з усіма критеріями)
• Затверджена технічна документація
• Резюме обох агентів

Вихід:

• Тести, що покривають усі критерії
• Звіт: що пройшло, що ні, що не покрите

Що він не робить:

• Модифікує код — ні бекенд, ні фронтенд
• Винаходить обходи для невідповідних стандартів
• Позначає невідповідні стандарти як пройдені

Якщо тест не пройшов — функція не відповідає історії.

Він повідомляє, яка саме умова не виконана.** Він не виправляє код.**

Виправлення — назад до агентів-розробників.

Інструменти: Read, Edit, Write (тільки тестові файли), Bash.

Правило: поки всі acceptance tests не пройдуть — функція не вважається реалізованою.

Агент 7: Валідатор реалізації (Implementation Validator)

Це агент, що знаходить пропущені речі.

Він порівнює поточну реалізацію з історією і презентацією,** повідомляє про розбіжності.**

Він ніколи не виправляє код. Він просто каже правду.

Що він перевіряє:

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

Висновки — за ступенем серйозності:

• Critical — обов’язково перед злиттям
• Important — потрібно виправити перед злиттям
• Minor — на розсуд рев’юера

Кожне виявлення містить шлях до файлу і номер рядка.

Якщо все гаразд — каже «все гаразд».** Не вигадує проблем, щоб здаватися більш серйозним.**

Інструменти: Read, Grep, Glob — і більше нічого.

Цей агент — причина, чому фабрика заслуговує довіри.

Самооцінка без цінності. Агент, що дивиться лише на «що на диску», але не на «як написано», — чесний.

Як працює вся ланцюг

Повний процес — один запит запускає все:

Відкриваєш Claude Code і вводиш:

«Зроби функцію «нагадування про неоплачені рахунки понад 7 днів».»

Далі нічого не потрібно писати — і так станеться:

Крок 1: — дослідник переглядає твої рахунки, платежі і код email. Повертає файли, моделі і ризики.

Крок 2: — сценарист створює історію користувача і критерії прийняття.

⏸ — пауза: ти читаєш і затверджуєш історію.

Крок 3: — спеціаліст з технічних специфікацій перетворює історію у технічний документ.

⏸ — пауза: ти читаєш і затверджуєш документ. (саме тут виявляєш «зберігати ID у пам’яті» — червоний прапор).

Крок 4: — бекенд-розробник реалізує сервіс, API, черги BullMQ і юніт-тести. Повертає: зміни у файлах, шаблони, що повторно використовуються, і всі тести зелені.

Крок 5: — фронтенд-розробник читає API-резюме і створює UI-інтерфейс і кнопки нагадування, пише тестування компонентів. Всі зелені.

Крок 6: — тестувальник пише acceptance tests для шести критеріїв. Звіт: 7 пройшли, 1 — провал. — вручну перевіряє, чи враховано право користувача.

Крок 7: — валідатор знаходить проблему. Відповідно до рівня Critical, повідомляє з файлом і рядком.

→ повертається до бекенд-розробника. Виправляє. Всі 8 тестів — зелені. Валідатор запускає знову. Чисто.

⏸ — пауза: ти переглядаєш і робиш PR.

Три людські контрольні точки. Інше — автоматично.

Основи: перед тим, як агент може працювати, потрібно це

CLAUDE.md — збереження пам’яті кожного діалогу

Кожного разу, коли ти відкриваєш Claude Code, він починає з «нульової пам’яті».

CLAUDE.md вирішує цю проблему.

Це — файл Markdown у кореневій папці репозиторію, що автоматично завантажується на початку кожного діалогу.

Він — «домівка» для «постійних фактів проекту»:

• Технічний стек (Next.js App Router, Node.js, Prisma, BullMQ, Resend)
• Команди (npm run dev, npm test, npx prisma migrate dev)
• Архітектурні правила («бізнес-логіка — у сервісах, API — тонкі»)
• Що не робити («не додавати cron — використовуйте BullMQ. Не записуйте оригінальні payload платежів у лог»)
• Посилання на документацію (docs/billing.md, docs/architecture.md)

Залишайтеся в межах 100–300 рядків.

Коли AI робить помилку, що вас дивує, запитайте себе: «Якщо б у CLAUDE.md була ця правила, чи можна було б її уникнути?»

Додайте цю правило.

Через кілька тижнів ваш CLAUDE.md стане записом «усіх припущень, у яких AI помилився» — і ваші діалоги стануть значно кращими.

Зміщення контексту — той безмовний вбивця

Більшість діалогів у Claude Code не провалюються драматично.

Вони «зміщуються».

Неправильне припущення потрапляє у контекст. Модель продовжує на нього накладати.

Ти просиш Claude зробити «управління підписками». Вона проектує: User → Subscription.

Потім ти згадуєш: підписки — це «компанія», а не «користувач».

Якщо ти просто скажеш «Неправильно, підписки — це компанія», — Claude зробить «патч».

І тепер у тебе є одночасно user.subscriptionId і company.subscriptionId, що «злітають» у різних місцях.

Правило:

• Мелкі помилки? Виправляй прямо в діалозі.
• Архітектурні помилки? Знищуй весь діалог і починай з чистого листа, закладаючи правильні припущення у перший запит.

Чистий діалог із правильною моделлю — завжди кращий за діалог із «патчами».

Результат: що справді змінюється

До фабрики:

• Вічний цикл vibe coding: prompt → генерування → помилка → патч → повтор
• Контекст переповнений шумом
• Неправильні припущення накопичуються у погані функції
• Один інженер може робити лише одну задачу за раз
• Кожна функція чекає, поки «той, хто потрібен», звільниться

Після фабрики:

• Структурована ланцюг: дослідження → сценарій → презентація → будівництво → валідація → підтвердження
• Кожен агент має чистий контекст, ісе лише те, що потрібно
• Неправильні припущення виявляються вже на рівні «затвердження презентації» — не через 10 файлів
• Інженер може створити цілісну вертикальну частину: бекенд, фронтенд, тестування, валідація
• Найкращі знання команди зосереджені в агентів — і не застрягають у «конкретній людині»

Справжня зміна:

експерт з платежів створює агента payments-integration. З того моменту кожен інженер може випустити функцію з обробкою платежів. Без очікування, без передачі.

Моделі компонентів для фронтенду, що веде фронтенд-лідер, зберігаються у агенті frontend-builder. DevOps-інженер — у CI/CD, у hook. QA-лід — у правилах test-verifier.

Експертні знання — у формі агентів. Не залежать від «хто має час».

Цей вікенд — зроби свою версію

8 кроків налаштування:

2. Встанови Claude Code → code.claude.com

3. Створи структуру папок:

   • .claude/agents/
   • .claude/skills/feature-factory/
   • .claude/skills/build-with-tests/
   • .claude/hooks/

4. Напиши свій CLAUDE.md (100–300 рядків: стек технологій, команди, архітектурні правила, список заборон)

5. За допомогою команди /agents у Claude Code створи 7 агентів. Опиши ролі кожного. Claude створить файли. Ти переглядаєш і робиш commit.

6. Створи навички orchestrator для feature-factory. Попроси Claude допомогти написати — вона зчитає твої 7 файлів агентів і з’єднає всю ланцюг.

7. Створи навичку build-with-tests. Опиши, як твоя команда будує: узгоджує з моделлю, пише тести паралельно з кодом, запускає typecheck.

8. Додай pre-commit hook, що блокує коміти файлів .env, .key, .pem або secrets.json. За 5 хвилин — і запобіжник великим катастрофам.

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

Загальний час: 2–3 години.

Запусти кілька функцій. Після 3–4 — фабрика «запам’ятає» твій кодовий репозиторій.

Ти витрачатимеш менше часу на контроль, більше — на рішення «що робити далі».

Сім агентів — швидкий огляд

• Дослідник (Researcher) — перед створенням будь-чого переглядає код (тільки читання)
• Сценарист (Story Writer) — перетворює ідеї у історії і критерії (тільки читання)
• Спеціаліст з технічних специфікацій (Spec Writer) — перетворює історії у технічний документ (тільки читання)
• Бекенд-розробник (Backend Builder) — створює API, сервіси, задачі, юніт-тести (тільки у бекенд-папці)
• Фронтенд-розробник (Frontend Builder) — створює компоненти, сторінки, hooks, UI-тести (тільки у фронтенд-папці)
• Тестувальник (Test Verifier) — пише acceptance tests для історій (тільки тестові файли)
• Валідаційник (Validator) — порівнює реалізацію з історією і презентацією, повідомляє про розбіжності (тільки читання)

3 людські контрольні точки:

→ затвердження історії → затвердження презентації → затвердження PR

Інше — автоматично.

Більшість розробників у Claude Code ще працює у vibe coding. Prompt → генерування → патчі → молитва.

Це не погано.** Але має межу.**

Фабрика не виводить тебе з процесу.** Вона виводить тебе з «не потрібно твоє рішення».**

Ти залишаєшся у тих «важливих для тебе» частинах:

Це правильне питання? Це правильний дизайн? Чи безпечно запускати?

Все інше — агент відповідає.

Ось різниця між «застосовувати AI як швидкий клавіатурний інструмент» і «застосовувати AI як команду».

Автор: @sairahul1