TL;DR
Spec-Driven Development — подход, при котором ты сначала пишешь точную спецификацию для ИИ, а потом итерируешь на ней, а не на результате. Исследование демонстрирует это через "самовоспроизведение" кодового агента: агент, реализованный по спецификации, сам воспроизводит себя по той же спецификации. Главный вывод — стабильный артефакт не код и не текст, который выдал ИИ, а задание, по которому он его выдал.
Большинство пользователей ИИ работают так: дали запрос → получили результат → начали его редактировать. Получилось плохо — переспросили или поправили вручную. В итоге хранят "правленый текст", но не понимают, почему он именно так устроен. При следующем похожем запросе снова лотерея. Проблема в том, что они итерируют на выходе — самом нестабильном месте в цепочке.
Исправить это просто: итерировать на задании. Если результат не устраивает — значит, в спецификации была дырка. Закрой дырку, регенерируй. Задание — это то, что ты хранишь, улучшаешь, передаёшь коллегам. Результат ИИ — расходный материал, который можно воспроизвести в любой момент.
Схема метода
(Все шаги в одном рабочем процессе, но в разных запросах)
ШАГ 1: Написать спецификацию
→ документ до 1500 слов
→ описывает ЧТО нужно, не КАК делать
ШАГ 2: Отдать ИИ → первый результат
ШАГ 3: Результат не устраивает?
→ найди дырку в спецификации
→ добавь/уточни требование
→ НЕ правь результат вручную
ШАГ 4: Регенерировать по обновлённой спецификации
ШАГ 5: Повторять до тех пор, пока спецификация не покрывает
все ситуации → хранить спецификацию, не результат
Пример применения
Задача: Ты — руководитель отдела продаж в B2B-компании. Менеджеры каждый раз пишут коммерческие предложения по-разному: кто в каком стиле, кто что включает. Ты хочешь, чтобы ChatGPT/Claude всегда выдавал предложения одного формата — и обучить этому можно было любого новичка за пять минут.
Промпт (написание спецификации):
Напиши спецификацию для ИИ-ассистента, который
составляет коммерческие предложения.
Спецификация должна быть короткой — до 1000 слов.
Описывай только ЧТО делает ассистент, не КАК технически.
Покрой следующее:
— Интерфейс: что получает на входе (данные о клиенте,
задача, бюджет, дедлайн), что выдаёт на выходе
— Обязательные разделы КП: что должно быть всегда
— Тон и стиль: деловой, без канцелярита
— Ограничения: что НЕЛЬЗЯ включать (лишние обещания,
сроки без согласования)
— Условия успеха: по каким критериям КП считается
правильным
После того как выдашь спецификацию, задай мне 3 вопроса
о том, что в ней могло быть неточным.
Результат:
Модель выдаст компактную спецификацию: что должен делать ИИ-ассистент для КП, что получает на входе, что выдаёт, какие разделы обязательны, какие запрещены. После — три уточняющих вопроса, где спецификация могла быть неоднозначной. Ты отвечаешь, правишь спецификацию, тестируешь на реальном запросе, снова находишь дырки — и так до тех пор, пока не будет закрыт каждый крайний случай. Финальная спецификация — это то, что ты даёшь новому менеджеру вместо "вот смотри как я делаю".
Почему это работает
У ИИ нет памяти о твоих намерениях. Когда ты даёшь вагое задание, модель заполняет пробелы случайным образом — из обучающих паттернов, из контекста диалога, из интерпретации. Каждый раз чуть по-другому. Ты правишь выход вручную, но правила остаются у тебя в голове — не в тексте, который ИИ читает.
Спецификация переносит правила из головы в текст. Модель хорошо следует явным, конкретным инструкциям. Чем точнее описано ЧТО делать и ЧТО не делать — тем меньше пространства для случайных вариаций. Это не магия, это просто сужение поля допустимых ответов.
Итерация на задании — это накопление знаний. Каждая правка спецификации — это зафиксированное понимание крайнего случая. Через 10 итераций у тебя не "отредактированный текст", а документ, который закрывает все ситуации, с которыми ты сталкивался. Его можно дать коллеге, другому ИИ, использовать в другом проекте.
Рычаги управления: - Длина спецификации → короче 1500 слов — обязательно, иначе самому не прочитать за один раз - Уровень абстракции → если в спецификации упоминаешь конкретный сервис или инструмент — скорее всего, слишком детально; описывай входы, выходы, условия - Тест на воспроизводимость → дай спецификацию второму ИИ (другой чат, другая модель) и проверь: результат сошёлся? Если нет — в спецификации была неоднозначность
Шаблон промпта
Напиши спецификацию для ИИ-ассистента,
который выполняет задачу: {задача}.
Требования к спецификации:
— До {лимит_слов} слов
— Описывай только ЧТО, не КАК
— Покрой: входные данные, выходные данные,
обязательные элементы, запрещённые элементы,
критерии правильного результата
Не называй библиотеки, инструменты,
технические решения — только поведение.
После напиши 3 вопроса: что в спецификации
могло быть неоднозначным или неполным?
Что подставлять:
- {задача} — что делает ассистент: "пишет посты для Telegram", "составляет брифы для дизайнеров", "отвечает на вопросы клиентов по тарифам"
- {лимит_слов} — 500–1500 слов, зависит от сложности задачи
🚀 Быстрый старт — вставь в чат:
Вот шаблон для написания спецификации ИИ-ассистента.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про конкретную задачу, ограничения, критерии результата — потому что без этого не может написать поведенчески полную спецификацию. Она возьмёт паттерн из шаблона и адаптирует под твой контекст.
Ограничения
⚠️ Сложность задачи: Подход хорошо работает для структурированных, повторяющихся задач. Для творческих или субъективных ("напиши что-то интересное") — спецификацию написать сложнее, потому что критерии успеха размытые.
⚠️ Сила модели: Подход требует, чтобы модель умела точно следовать длинным инструкциям. Старые или слабые модели выполняют спецификации хуже — результаты сходятся не всегда.
⚠️ Масштаб: Исследование протестировано на 926-словной спецификации. Работает ли при 10 000 и 100 000 словах — открытый вопрос. Практическое правило авторов: не больше 1 500 слов, или 15 минут чтения.
⚠️ Верификация: Ты получаешь воспроизводимый результат — но только если спецификация правильная. Ошибка в спецификации размножается в каждую следующую генерацию. Аудитировать надо задание, не результат.
Ресурсы
- Статья: Monperrus, M. "Bootstrapping Coding Agents: The Specification Is the Program." Preprint, 2026.
- Репозиторий: github.com/ASSERT-KTH/meta-circular
- Связанный проект: StrongDM Attractor — github.com/strongdm/attractor
- Связанная практика: Spec-Driven Development (Richard Piskala, arXiv, 2026)
- Автор: Martin Monperrus, профессор KTH Royal Institute of Technology, Стокгольм