AI-ассистенты пишут код быстро. Очень быстро. Но «быстро написать» ≠ «быстро сделать продукт». Если ИИ мгновенно генерирует код по непонятному ТЗ — вы получаете мгновенно неправильный код. Потом мгновенно переделываете. И снова.
Бесплатная диагностика — результат за 5 минут
Что такое spec-driven development
Подход, при котором:
- Спецификация — source of truth. Прежде чем писать код, фиксируем: что делаем, для кого, какие критерии приёмки, какие границы
- Код следует за спекой. ИИ (или человек) реализует то, что описано в спеке
- Изменения — через спеку. Нужно изменить поведение? Сначала меняем спеку, потом код
Thoughtworks включил spec-driven development в Technology Radar как emerging technique.
Анатомия хорошей спеки
- Контекст: Зачем это нужно? Какую проблему решаем?
- Критерии приёмки: Как понять, что сделано правильно?
- Границы: Что НЕ входит в scope?
- Примеры: Input → Output для типичных и граничных случаев
- Зависимости: От чего зависит? Что блокирует?
C4 для архитектуры
C4 model (Simon Brown) — способ описать архитектуру текстом и простыми диаграммами:
- Context — система в окружении (пользователи, внешние системы)
- Containers — основные «коробки» (веб-приложение, база, API)
- Components — внутренняя структура контейнера
- Code — классы и функции (только если нужна такая детализация)
Это не UML — это читаемые диаграммы, которые понимают и бизнес, и разработчики.
CLAUDE.md и аналоги: контракт с AI-кодером
Современные AI-кодеры (Claude Code, Cursor, GitHub Copilot) поддерживают файлы контекста — CLAUDE.md, .cursorrules, copilot-instructions.md. Это спецификация для ИИ-ассистента:
- Архитектурные решения — какие паттерны использовать, какие запрещены
- Конвенции кода — именование, структура файлов, стиль
- Бизнес-правила — что нельзя менять, какие инварианты соблюдать
- Процесс — маленькие коммиты, тесты перед мержем, ветки для фич
По сути, это перенос spec-driven подхода на уровень инструмента. Чем точнее «контракт» — тем предсказуемее результат.
Метрика: налог на переделки
Введите метрику для команды:
Rework Tax = (Время на переделки + Время на исправление багов от переделок) ÷ Общее время разработки
Команды без спецификаций обычно показывают Rework Tax 40-60%. С хорошими спеками — 10-20%. Разница — это прямая экономия бюджета разработки.
Считайте еженедельно, отслеживайте тренд. Если после внедрения spec-driven подхода налог не снижается — проблема в качестве спецификаций, не в инструментах.