Spec-First Engineering (RFC-Driven AI Dev)(Розробка від специфікації (Spec-First Вайбкодинг))

1. Огляд концепції та системна проблема

Головна пастка початківців у вайбкодингу — це поспіх. Розробник відкриває агентське IDE і одразу пише в чат: "Зроби мені сторінку кошика покупок із промокодами". Агент генерує 1000 рядків коду за 15 секунд, але:

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

Spec-First Engineering — це золотий закон продуктивного кодингу з ШІ: ніколи не торкатися коду без затвердженого плану. Інженер виступає у ролі головного архітектора, який формує вичерпний контракт (implementation_plan.md), узгоджує крайові випадки і лише потім дає команду агенту на генерацію.

2. Архітектурна таксономія та ментальна модель

┌─────────────────────────────────────────────────────────────┐
│                 SPEC-FIRST ENGINEERING CYCLE                │
├─────────────────────────────────────────────────────────────┤
│ 1. Intent Exploration (Дослідження наміру)                  │
│    • Brainstorming, Edge-Case Interview ("Grill-Me")        │
│    • Визначення Anti-Goals (чого НЕ повинно бути)           │
├─────────────────────────────────────────────────────────────┤
│ 2. Formal Spec Artifact Creation                            │
│    • Types & Data Contracts (TypeScript interfaces / Zod)   │
│    • File Mutation Map ([NEW], [MODIFY], [DELETE])          │
│    • Verification Criteria (Automated test commands)        │
├─────────────────────────────────────────────────────────────┤
│ 3. Human Gate & Peer Approval                               │
│    • Інженер рецензує план, вносить корективи               │
├─────────────────────────────────────────────────────────────┤
│ 4. Deterministic Autonomous Execution                       │
│    • Агент виконує план покроково без відхилень             │
└─────────────────────────────────────────────────────────────┘

3. Практичні інженерні сценарії в продакшені

01. Інтерв'ювання моделі перед фічею (Grill-Me патерн)

Перед написанням плану розробник дає інструкцію: "Я хочу додати платіжну систему Stripe. Постав мені 5 прискіпливих питань щодо обробки вебхуків, повторних оплат та безпеки, перш ніж писати план". Це виявляє приховані проблеми на етапі ідеї, а не в продакшені.

02. Захист від архітектурної ерозії

Якщо проект веде команда з трьох інженерів з агентами, усі зміни спочатку проходять через PR у папку docs/specs/. Команда бачить намір ще до того, як модель створить 50 нових компонентів.

4. Підводні камені, типові помилки та безпека

• Analysis Paralysis (Надмірна бюрократія): Написання 20-сторінкового плану для зміни кольору кнопки — це марнування часу. Для тривіальних правок діє правило прямого редагування. Специфікація потрібна для задач, що зачіпають більше 2 файлів або бізнес-логіку.
• Дрейф плану під час виконання (Spec Drift): Якщо під час кодування агент виявляє нову деталь і самовільно змінює архітектуру без оновлення специфікації, система втрачає керованість. Вимагайте від агента оновлювати план при будь-яких непередбачених труднощах.

5. Стратегічний висновок для інженера 2026 року

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