Spec-First Engineering (RFC-Driven AI Dev)

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 года

В мире, где генерация кода стоит ноль центов, самой ценной инженерной навыком становится не скорость набора текста, а глубина и точность формулировки технической спецификации. Кто владеет спецификацией — тот контролирует систему.