Фраза «сделай бронирование оборудования» выглядит конкретной, пока два человека не выбирают один проектор на одно время. Затем появляются зависшие резервы, отменённые заявки в календаре и разные статусы в интерфейсе и API.
Источник идеи: учебный пример spec-driven разработки на Хабре. Автор не описывает производственное внедрение и не обещает измеримое ускорение. Ниже — протокол подготовки задачи и результат локальной проверки на синтетической фикстуре ИИ-цеха.
Начните с правил, которые можно нарушить
Для учебной брони достаточно пяти правил:
- Один объект нельзя занять двум людям на один интервал.
- Временная бронь истекает через заданное время.
- Отмена освобождает интервал.
- Повтор запроса не создаёт дубль.
- Интерфейс и API используют одинаковые статусы.
Каждое правило должно иметь пример нарушения. Иначе агент увидит пожелание, но не получит проверяемую границу.
Опишите состояния до экранов
Запишите конечные состояния draft, held, confirmed, cancelled, expired и разрешённые переходы между ними. Отдельно перечислите запретные переходы: например, cancelled → confirmed без новой брони.
Такой список отделяет бизнес-правило от кнопки. Экран можно переделать, а состояние и причина перехода остаются проверяемыми.
Свяжите API с той же моделью
В OpenAPI нужны операции создания, подтверждения, отмены и чтения брони. Для каждой операции запишите вход, успешный ответ и конфликт.
Если интерфейс называет состояние reserved, а API возвращает held, это отдельное решение, а не мелочь реализации. Несогласованность лучше обнаружить до генерации кода.
Передавайте агенту небольшие задачи
Одна задача меняет один слой и заканчивается наблюдаемым результатом. Например:
- добавить переход
held → expired; - запретить пересечение интервалов;
- сделать повтор создания идемпотентным;
- добавить ответ конфликта в OpenAPI;
- провести один acceptance case.
После каждого шага проверяются правила, переходы, контракт и тест. Следующая задача не начинается только потому, что агент написал «готово».
Сравните два прохода
Для проверки метода нужны одинаковая модель, лимит времени и набор приёмочных случаев. В первом проходе агент получает только описание функции. Во втором — те же вводные плюс правила, state machine, C4-контекст, OpenAPI и acceptance cases.
Сравнивать нужно число пройденных случаев и конкретные расхождения. Один красивый ответ или объём созданного кода ничего не доказывают.
На локальной qwen3-vl:8b мы провели по две попытки с seed 42 и 43. Без пяти артефактов модель закрыла 5 из 10 заранее записанных ограничений в обеих попытках. С правилами, state machine, C4-контекстом, OpenAPI и acceptance cases она закрыла 10 из 10 в обеих попытках.
В первом условии модель потеряла точный набор состояний, часть переходов, правило пересечения для held и confirmed, привязку идемпотентности к request_id и полный API-контракт с HTTP 409. Сырые ответы и машинный отчёт сохранены в локальном эксперименте CNT-2026-10-29-019.
Критерий готовности
- двойное бронирование заблокировано;
- истёкшая и отменённая бронь освобождают интервал;
- повторный запрос не создаёт вторую запись;
- ответы соответствуют OpenAPI;
- фактические переходы входят в state machine;
- найденная ошибка остаётся в регрессионном наборе.
Этот прогон проверял только покрытие контракта. Он не измерял скорость разработки, число переделок и качество исполняемого кода. Для таких выводов нужен отдельный тест с реализацией и одинаковым внешним набором проверок.
Что проверить следом
Даже подробная спецификация не спасёт, если старый instruction-файл требует другой архитектуры. Для такого случая используйте отдельный порядок: как проверить конфликт AGENTS.md и текущего кода.
Как зашло?
Ответ засчитывает гайд и помогает нам его улучшить
