Інженерія агентів у п’яти шарах: від специфікацій та паралельних агентів до правил та нагляду

Підхід Vibe coding мав успішний період існування. Андрей Карпати, людина, яка ввела цей термін, згодом оголосив про завершення тієї епохи, і він не лише описав проблему. Він накреслив те, що її замінює: агентне інжиніринг, у рамках якого штучні інтелектуальні агенти планують, пишуть, тестують та випускають код, тоді як людина забезпечує структурований нагляд. Людина визначає мету, агенти її реалізують, а людина перевіряє результат. Це професійний метод створення програм з використанням ШІ, а не просто їх використання поруч із ним, і це далеко від випадкових запитів з наступною надією.

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

Чому важлива назва

Ця назва — це більше, ніж просто брендинг. Вона позначає межу між двома дуже різними способами роботи, і Карпаті провів цю межу за допомогою пари запитань. Підхід Vibe coding ставить питання про те, чи можна щось зробити так, щоб воно працювало. Підхід Agentic engineering ставить питання про те, чи можна зробити щось так, щоб воно працювало надійно, у масштабах, без виникнення вразливостей.

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

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

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

Рівень 1: специфікація

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

Різні практики в інженерії ШІ називають це стратегічним плануванням, визначенням мети або просто специфікацією. Назва може варіюватися, але сама практика залишається незмінною: потрібно знати, чого очікують, перш ніж просити агента це створити.

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

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

# Feature Spec: [Feature Name]
## Last updated: [Date] — this document is the source of truth

Далі йдуть чек-листи поведінки — розділ з обов’язковими формами поведінки та розділ з суворими обмеженнями, наприклад, заборона на обробку повернення коштів у сумі понад 500 доларів без схвалення людини:

## What this must always do
- [ ] [Behaviour 1 — specific, testable]
- [ ] [Behaviour 2 — specific, testable]## What this must never do
- [ ] [Boundary 1 — e.g. "Never process refund >$500 without human approval"]
- [ ] [Boundary 2 — e.g. "Never fabricate a citation"]## Success criteria (measurable)
- Context recall: >0.85
- Faithfulness: >0.90
- Cost per query: <$0.15
- Latency p95: <2s## Failure signals (alert if breached)
- Any metric drops >5% from 7-day baseline
- Cost per task exceeds 3x expected range
- User complaint rate exceeds 2% of sessions## Decomposition (for parallel agents)
- [ ] Task A: [scope] — can be delegated independently
- [ ] Task B: [scope] — depends on Task A output
- [ ] Task C: [scope] — can run parallel with Task A

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

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

Рівень 2: оркестрація

Розгляньмо функцію, яка впливає на схему бази даних, API, фронтенд та набір тестів. Традиційно один інженер працює над кожною частиною по черзі, або команда координує свої зусилля протягом спринту. У підході з агентами чотири агенти одночасно беруться за всі чотири складові. Один пише код міграції, інший — ендпоїнти, третій — компоненти фронтенду, а четвертий пише тести та перевіряє решту на наявність проблем з безпекою. Кожен має свій власний контекст та обмеження, а їхні результати об’єднуються в одну цілісну зміну.

Це не є гіпотетичним. Stripe використовує таку схему у реальних умовах, маючи внутрішню систему агентів, яка щотижня створює понад 1 000 об’єднаних запитів на зміни; кожен з них пише агент, переглядає людина, проходить перевірку CI та випускається. Користь є значною, а не вдвічі більшою.

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

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

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

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

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

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

Оркестратор-скелет може описати цей цикл у своєму документаційному тексті:

class AgenticOrchestrator:
    """Plan → Execute (parallel) → Verify"""

та впровадити крок планування, який розділяє функцію на завдання, що можна делегувати:

    def plan(self, feature_spec: dict) -> dict:
        """Decompose feature into independently delegatable tasks."""
        tasks = []
        for component in feature_spec["decomposition"]:
            tasks.append({
                "id": component["id"],
                "spec": component["scope"],
                "constraints": feature_spec["must_never"] + component.get("local_rules", []),
                "depends_on": component.get("depends_on", []),
                "verification": component.get("success_criteria", []),
            })
        independent = [t for t in tasks if not t["depends_on"]]
        sequential  = [t for t in tasks if t["depends_on"]]
        return {"parallel": independent, "sequential": sequential}    async def execute(self, plan: dict):
        """Run independent tasks in parallel, sequential tasks in order."""
        parallel_results = await asyncio.gather(*[
            self.delegate_to_agent(task) for task in plan["parallel"]
        ])
        for task in plan["sequential"]:
            result = await self.delegate_to_agent(task, prior=parallel_results)
            parallel_results.append(result)
        return parallel_results    def verify(self, results: list, spec: dict) -> dict:
        """Check all outputs against the spec — structural, not line-by-line."""
        issues = []
        for result in results:
            if not self.satisfies_spec(result, spec):
                issues.append(f"{result['id']}: does not satisfy spec")
            if self.conflicts_with(result, results):
                issues.append(f"{result['id']}: conflicts with another module")
        return {"passed": len(issues) == 0, "issues": issues}

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

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

Рівень 3: кодифіковані правила

Більшість інструментів вже мають щось подібне. Claude Code завантажує файл CLAUDE.md на початку кожної сесії, Cursor читає файл .cursorrules, а Codex — AGENTS.md. Концепція є спільною: файл у корені проекту, який вказує агенту, як поводитися.

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

• Розробка, керована специфікацією – коли саме специфікація керує процесом роботи (Рівень 1).
• Кодовані правила та архітектурні обмеження: конвенції, політики безпеки, шаблони обробки помилок, стандарти найменувань та процедури розгортання – усе це знаходиться у файлах, які агенти завантажують перед початком роботи.
• Атомарний розклад з паралельними агентами – функції розділяються на найменші частини, які можна передавати окремо (Рівень 2).

Спостережуваний розвиток: відстеження та оцінка кожної дії, яку виконує агент (рівень 5, нижче).

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

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

your-company/
├── .ai-rules/
│   └── org-rules.md          ← Company-wide: security, compliance, style
│
├── team-payments/
│   ├── .ai-rules/
│   │   └── team-rules.md     ← Team-level: error handling, testing, deploys
│   │
│   ├── service-checkout/
│   │   ├── CLAUDE.md          ← Repo-level: architecture, tech stack, builds
│   │   ├── src/
│   │   │   ├── auth/
│   │   │   │   └── .ai-rules.md  ← Module: auth-specific constraints
│   │   │   └── payments/
│   │   │       └── .ai-rules.md  ← Module: PCI compliance rules

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

# org-rules.md (loaded for every agent, every repo)
- Never commit secrets or credentials
- All public APIs require authentication
- Error responses must never expose stack traces
- Log every state-changing operation with user context

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

# team-rules.md (inherits org, adds team specifics)
- Use Result<T, E> pattern — never throw exceptions
- All database queries go through the repository layer
- Tests must cover the happy path + 2 failure modes minimum# CLAUDE.md (inherits team, adds repo specifics)
- This repo uses Express.js + Prisma + PostgreSQL
- Run `npm test` before suggesting any PR is ready
- Migrations are append-only — never modify applied migrations# module .ai-rules.md (inherits repo, adds module specifics)
- auth/: All token operations must use constant-time comparison
- payments/: PCI DSS requires field-level encryption on card data

Агент завантажує правила організації, правила команди, файл CLAUDE.md репозиторію та правила модуля, з яким він працює. Це дозволяє зберігати контекст у вузьких межах та без зайвого обсягу інформації. Агент у модулі оплати отримує правила відповідності стандартам PCI, тоді як агент у фронтенді їх не отримує, оскільки ці правила марнуватимуть ресурси контексту без жодної користі.

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

Рівень 4: людський нагляд

Три слова описують модель функціонування, яка сформувалася: делегувати, перевіряти, нести відповідальність.

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

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

Відповідальність. Людина несе відповідальність за кінцеву якість. Агент виконав роботу, людина схвалила її, і будь-які проблеми в продакшені є її обов’язком. Саме ця відповідальність відрізняє інженерію з використанням агентів від кодування без чіткої відповідальності, де ніхто не несе відповідальності за результат.

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

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

Чек-лист для перевірки допомагає перед тим, як щось, створене агентом, потрапить у продакшн. Його заголовок:

## Agent Output Review Checklist

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

### Spec alignment (does it do what was asked?)
- [ ] All "must always do" behaviours are implemented
- [ ] No "must never do" boundaries are violated
- [ ] Success criteria from the spec are met or tested### Architectural coherence (does it fit the system?)
- [ ] No new dependencies introduced without justification
- [ ] Consistent with naming, patterns, and structure of existing code
- [ ] No duplication of logic that exists elsewhere### Safety and edge cases
- [ ] Error handling covers the failure modes the spec anticipated
- [ ] No hardcoded credentials, keys, or environment-specific values
- [ ] Input validation present on all external-facing boundaries### What the agent cannot check for itself
- [ ] Does this make business sense? (not just technical correctness)

Варто його роздрукувати та прикріпити біля монітора. Інструменти для перевірки коду та процеси CI можуть частково автоматизувати перші три розділи. Останній — бізнес-логіка — є причиною, чому людина залишається у процесі.

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

Рівень 5: спостережуване розроблення

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

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

На практиці все зводиться до трьох звичок:

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

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

Кожна сесія впливає на правила. Вивчені закономірності, зустрінуті проблеми та знайдені рішення стають оновленнями правил рівня 3. Те, що спостерігає рівень 5, кодується рівнем 3, а від цього отримує користь рівень 2, тож дисципліна поступово зміцнюється з тижня в тиждень.

Мінімальна налаштування починається з імпортів для створення невеликого запису трасування:

from dataclasses import dataclass, field
from datetime import datetime

та клас даних trace, застосований до кожного делегованого завдання:

@dataclass
class AgentTrace:
    """Minimum trace for every agent-delegated task."""
    task_id: str
    agent_id: str
    spec_given: str                    # What was the agent told to do?
    tools_used: list[str]              # Which tools did it invoke?
    files_modified: list[str]          # What did it change?
    model_version: str                 # Which model, which version?
    tokens_consumed: int               # What did it cost?
    started_at: datetime = field(default_factory=datetime.utcnow)
    completed_at: datetime | None = None
    verification_result: str = ""      # pass / fail / needs_review
    human_reviewer: str = ""           # Who signed off?
    issues_found: list[str] = field(default_factory=list)

Додайте щотижневий огляд тривалістю п’ятнадцять хвилин. Його заголовок:

## Weekly Observable Development Review (15 minutes)

та пов’язані з ним запитання: скільки завдань було делеговано, скільки з них пройшли перевірку з першої спроби (ціль — понад 80%), в якій категорії було найбільше проблем, та якими були трійка найпоширеніших проблем:

1. How many agent tasks were delegated this week?        ___
2. How many passed verification on first attempt?        ___  (target: >80%)
3. Which task category had the most issues?              ___
4. Top 3 issues found during review:
   - ___
   - ___
   - ___
5. Which issues should become codified rules (Layer 3)?  ___→ Update CLAUDE.md with any new rules from this week's observations.

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

Докази ефективності

Два показники особливо привертають увагу. У Stripe щотижня об’єднується понад 1 000 запитів типу pull request, які створюються агентами, перевіряються людьми, проходять тестування CI та використовуються у реальних умовах — це не просто експеримент у сандбоксі. Такий рівень продуктивності був неможливий рік тому. Інша аудиторія бачить інші цифри: дослідження McKinsey вказує на зниження операційних витрат на 20–40 відсотків, що дозволяє перетворити ШІ з інноваційної ініціативи на частину операційної інфраструктури — саме цього вимагає фінансовий директор, а не лише технологічний.

Що це означає для кар’єри інженера

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

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

У розмовах з керівниками інженерних відділів постійно згадуються три ключові компетенції:

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

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

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

П’ятиденний план для початківців

П’ять вправ протягом тижня, кожна з яких ґрунтується на попередній:

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

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

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

У п’ятницю завершіть процес. Додайте до CLAUDE.md три найважливіші уроки тижня: правило, яке агент постійно порушував, шаблон розбирання завдань, який спрацював, та перевірку, яку потрібно включати до кожного майбутнього огляду. Це і є процедурна пам’ять, і агент наступного тижня буде трохи кращим, ніж цього. Якщо так продовжувати протягом восьми тижнів, різниця стане значною.

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

Чому підхід, заснований лише на специфікаціях, є недостатнім

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

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

Що буде далі

Видно два напрямки: один майже безумовний, а інший — спекулятивний.

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

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

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