Агент пише код швидше за команду, але все, що ви не описали, він добудує на власний розсуд. Питання доповіді: який комплект документів покласти перед агентом, щоб на виході була робоча система, а не гарний прототип із неправильною логікою.
Людина-розробник, отримавши неповне ТЗ, найчастіше прийде з питаннями. Агент теж уміє уточнювати й зупинятися, але за відсутності явної інструкції може заповнити прогалину найімовірнішим припущенням і продовжити роботу.
«Користувач може скасувати замовлення» — за скільки годин? Хто платить комісію? Що зі складом? Агент вигадає три відповіді з трьох.
Без критеріїв приймання неможливо сказати, чи задача завершена. Приймання перетворюється на нескінченне «ще трохи не так».
Агент додасть бібліотеку, зламає стиль коду, змінить схему БД — бо ніхто не написав, що так не можна.
Наслідок: вузьким місцем стає не швидкість написання коду, а точність опису задачі й швидкість перевірки результату.
| Етап | Класичний процес | Процес з агентом |
|---|---|---|
| Вимоги | Текст «для людини», багато неявного контексту | Явний, структурований, однозначний документ |
| Оцінка | Людино-дні | Кількість ітерацій і обсяг контексту |
| Код | Основні витрати часу | Генерація значно швидша й дешевша; витрати зміщуються в постановку та перевірку |
| Перевірка | Code review колеги | Автотести + критерії приймання + review |
| Ризик | Не встигли зробити | Зробили швидко, але не те |
Головна теза: агент однаково швидко масштабує і правильну вимогу, і помилкову — зросла швидкість поширення помилки в коді.
Product Brief → Functional Requirements → Non-Functional Requirements → Acceptance Criteria → API & Data Contracts
Кожен шар відповідає на своє питання. Пропущений шар агент добудує сам — і зазвичай не так, як ви очікували.
Шар 1
Brief / Vision
Навіщо і для кого
Шар 2
Функціональні вимоги
Що система робить
Шар 3
Нефункціональні
Наскільки добре робить
Шар 4
Критерії приймання
Як довести, що працює
Шар 5
Контракти й тех. контекст
У яких межах будувати
Документ достатній, якщо новий розробник без доступу до вашого чату зробить за ним ту саму фічу. Це ж і є вимога до агента.
Markdown у репозиторії поруч із кодом, а не PDF у пошті. Вимоги версіонуються разом із кодом і змінюються в тому ж pull request.
Product Brief · Vision & Scope · PRD — Product Requirements Document
Найкоротший документ і найбільший вплив: він дозволяє агенту приймати десятки дрібних рішень у правильний бік.
Розділ «Поза межами» економить найбільше часу: без нього агент регулярно робить більше, ніж треба.
Functional Requirements (FR) — розділ SRS, Software Requirements Specification (ISO/IEC/IEEE 29148:2018) · User Stories & Use Cases
Перевірка якості пункту: чи можна з нього написати тест, не ставлячи жодного питання? Якщо ні — пункт недописаний.
Non-Functional Requirements (NFR) · Quality Attributes · SLO — Service Level Objective · SLA — Service Level Agreement
Це те, що агент ніколи не вгадає правильно. Формулювання має містити число й спосіб вимірювання.
| Категорія | Погано | Придатно для агента |
|---|---|---|
| Продуктивність | Швидко працює | 95-й перцентиль (p95) відповіді API ≤ 300 мс при 200 запитах/с (rps) |
| Масштаб | Багато користувачів | 50 тис. записів/міс, пік ×5 у понеділок зранку |
| Доступність | Надійна система | 99,5% на місяць; деградація без втрати даних |
| Безпека | Захищені дані | Автентифікація через OpenID Connect (OIDC); персональні дані шифруються; журнал доступу 12 міс |
| Доступність accessibility, a11y | Зручний інтерфейс | WCAG 2.2 рівень AA (Web Content Accessibility Guidelines); повна робота з клавіатури |
| Сумісність | Працює скрізь | Chrome / Safari / Firefox −2 версії; мобільний від 360 px |
| Супровід | Чистий код | Покриття тестами ≥ 70%; структуровані логи; трасування запиту |
Кожну НФВ треба вміти перевірити командою або скриптом. Невимірювана вимога — це побажання, і агент може зробити не те, що очікували.
Acceptance Criteria (AC) · Gherkin: Given / When / Then · BDD — Behaviour-Driven Development
Найцінніший документ у роботі з агентом: він одночасно є завданням, тестом і актом приймання.
Дайте агенту критерії до написання коду й попросіть спершу перетворити їх на тести, що падають. Далі — реалізація до зеленого стану. Значна частина технічного приймання зводиться до запуску відтворюваних тестів; ризикові зміни все одно дивиться людина.
API — Application Programming Interface Contract · OpenAPI Specification · Data Model & State Machine · ADR — Architecture Decision Record
Схема — одна з найточніших форм вимоги: вона різко зменшує двозначність у структурі даних та інтерфейсах і дозволяє генерувати код, тести й документацію. Семантику — права доступу, побічні ефекти, гроші — все одно описують окремо.
Код агент перепише за хвилини. Базу з реальними записами — ні: зміна схеми означає міграцію, сумісність зі старими даними, простій і ризик втрати. Вимоги бізнесу змінюються постійно, тому модель даних проєктують під зміну: додавати поле й статус має бути дешево, а перейменовувати сутність і переносити зв'язки не має бути потрібно щоспринту.
Фреймворк, бібліотеки й спосіб розділення системи розробник обирає під очікувану зміну вимог, а не під сьогоднішній список фіч. Рішення й альтернативи фіксують в ADR, інакше агент через місяць приведе паралельне рішення тієї ж задачі.
Схема в репозиторії — єдине джерело правди. Якщо код і документ розійшлися, виправляють обидва в одному pull request.
AGENTS.md / CLAUDE.md · Contributing & Coding Guidelines · Constraints
Файли інструкцій агента (наприклад, AGENTS.md або CLAUDE.md) і пов'язані проєктні правила, які агент отримує в контексті роботи. Конкретний механізм завантаження залежить від інструмента.
Test Plan · Test Strategy · Verification & Validation
Тести, типізація, лінтер, збірка. Агент має змогу запускати їх сам і виправлятися без вас — це головний цикл зворотного зв'язку.
Проходимо критерії приймання (Acceptance Criteria, AC) із задачі по одному. Кожен має або тест, або відтворюваний ручний сценарій із конкретними даними.
Дивимось на межі та ризики: доступ до даних, гроші, необоротні дії, продуктивність запитів. Саме тут людське рішення найцінніше.
Правило: агент не може бути єдиним, хто підтверджує власну роботу. Перевірку робить незалежний механізм — тести й людина.
Task Specification · Work Item · Ticket & Scope Boundaries
Великий документ добре описує систему, але задача для одного запуску має бути вузькою: один зрозумілий результат, який можна перевірити швидко. Нижче — практичні орієнтири, а не галузевий стандарт.
Мета (одне речення) → Контекст (посилання на функціональну вимогу, критерії приймання і схему) → Межі (що не чіпати) → Критерії приймання → Як перевірити (команда запуску тестів).
Усе — текст у репозиторії: версіонується, рев'ювиться, читається і людиною, і агентом.
Рекомендоване правило команди: зміни, що стосуються персональних даних, платежів та необоротних операцій, завжди проходять людське рев'ю — незалежно від того, наскільки добре написана специфікація.
DoR — Definition of Ready · DoD — Definition of Done
| Документ | Питання, на яке відповідає | Ознака готовності | Хто власник |
|---|---|---|---|
| Brief | Навіщо і для кого | Є метрика успіху й розділ «поза межами» | Product Ownerза участі бізнес-аналітика |
| Функціональні | Що система робить | Кожен FR має id, сценарій помилки й пріоритет | Бізнес-аналітикпріоритети ставить Product Owner |
| Нефункціональні | Наскільки добре | Кожна вимога має число й спосіб виміру | Архітекторбізнес-обмеження — від аналітика |
| Критерії приймання | Як довести, що працює | Дано / Коли / Тоді, включно з межами й помилками | Бізнес-аналітик + QAпогоджує Product Owner |
| Контракти | Яка форма даних і API | Схема в репозиторії, формат помилок єдиний | Архітектор, розробникмодель домену — від аналітика |
| Тех. контекст | У яких межах будувати | Команди запуску, стиль, заборони, Definition of Done | Команда розробкиtech lead як редактор |
| Задача | Що робимо зараз | Один результат, 2–5 критеріїв приймання, точка входу в код | Розробникчерга й пріоритет — Product Owner |
Власник відповідає за актуальність документа, а не пише його сам-один. Суміщати ролі можна, пропускати документи — ні: кожен документ має мати того, хто відповідає за його актуальність.
Якщо на будь-який рядок відповідь «ще ні» — дешевше дописати документ, ніж переробляти код.
А · Класичний процес — без агентів ШІBusiness Owner → Project Management → Product & Analysis → Architecture → Design → Team / Tech Lead → Development → QA → Operations → Support → End User
Тім лід відповідає за людей і потік роботи, тех лід — за технічні рішення й якість коду, проджект-менеджер — за строки, бюджет і комунікацію із замовником. У великих командах це три різні люди, у малих — одна.
Б · Той самий ланцюг із агентом ШІті ж ролі; агент прискорює ділянку розробки
Ідея, гроші, пріоритети, рішення про запуск
Мета, метрики, межі релізу, черга задач
Brief, функціональні вимоги, критерії приймання
Нефункціональні вимоги, контракти, технічні межі
Сценарії, макети, стани помилок, доступність
Постановка задачі агенту, реалізація, code review
Тест-план, автотести за критеріями, приймання
Реліз, середовища, моніторинг, інциденти
Робота з системою, звернення, зворотний зв'язок
Зворотний зв'язок замикає ланцюг: користувач → підтримка → продукт → нові вимоги.
Агент прискорює ділянку 06, але не замінює жодну з ролей: він не формулює мету, не домовляється про компроміси й не приймає роботу. Ролі тім ліда й тех ліда тут не зникають — вони переходять у постановку задач агенту та рев'ю згенерованого коду.
В · Гранична форма суміщенняусі проміжні ролі — на одній людині, що працює агентами
Ідея, гроші, пріоритети, рішення про запуск
Одна людина веде весь шлях від розмови із замовником до релізу, тримаючи агентів як виконавчу потужність: формулює мету й метрики (Product Owner) · пише brief, функціональні вимоги та критерії приймання (Business Analyst) · задає нефункціональні вимоги й контракти (Architect) · проєктує сценарії та інтерфейс (UX / UI) · ставить задачі агенту й рев'ювить код (Developer · Agent Operator) · складає тест-план і приймає роботу (QA) · випускає та супроводжує (DevOps · SRE).
Ціна такої компактності — зникає незалежна перевірка: той, хто написав вимогу, сам її й приймає. Робоче для MVP, внутрішніх інструментів і невеликих продуктів; для платежів, персональних даних і необоротних операцій рев'ю все одно виносять назовні.
Робота з системою, звернення, зворотний зв'язок
Однозначно, версійно, з тестами й межами. Агент дає швидкість; точність опису лишається за командою — і саме вона визначає, що ви отримаєте на виході.
Комплект із шести документів плюс постановка задачі. Почніть із критеріїв приймання — найбільший ефект за найменших витрат.
Візьміть одну наступну фічу й опишіть за шаблоном. Порівняйте результат агента з попереднім запуском без документів.
Мета, межі, компроміси, ризики та приймання. Це не автоматизується разом із кодом.
Жодна специфікація не буває остаточною — бізнес уточнює правила, ринок і закон змінюються. Тому і документи, і система мають бути адаптивними: вимоги живуть у репозиторії й версіонуються разом із кодом, модель даних і архітектура проєктуються під зміну, а критерії приймання дають змогу безпечно переробити реалізацію. Специфікація — не бетон, а креслення, яке перевидають.
Дякую за увагу. Питання?