Как перестать крутить промпты и начать нормально разрабатывать с ИИ: практическое введение в spec-driven подход — VogueTech

Что нового

Microsoft предлагает разработчикам сменить привычный цикл работы с ИИ «промпт → генерация → правки → ещё промпт» на более структурированный подход — spec-driven development.

Ключевое отличие:

вместо расплывчатого запроса к ИИ — чёткая спецификация задачи;
вместо угадывания нужного промпта — проверка кода по заранее описанному контракту.

Никаких новых платных продуктов или тарифов тут нет. Это именно подход к работе с тем, что у вас уже есть: GitHub Copilot, Azure AI Studio, GPT‑4, Claude 3, любые другие LLM.

Новые элементы процесса:

Перед обращением к ИИ вы формулируете короткую, но структурированную спецификацию.
Спецификация включает: входы, выходы, ограничения, крайние случаи.
ИИ получает на вход не «сделай красиво», а формальный контракт, к которому нужно подогнать реализацию.
Итерации остаются, но вы крутите не промпт, а саму спецификацию, пока она не станет достаточно точной.

Результат по опыту автора подхода:

более стабильная структура ответов ИИ;
меньше сюрпризов на краях (пустые ответы, большие данные, ошибки валидации);
меньше бессмысленных перефразирований промптов.

Как это работает

Идея простая: ИИ лучше работает, когда вы даёте ему структуру, а не эссе.

Вместо:

«Сделай API, который возвращает заказы пользователя»

вы даёте ИИ спецификацию:

Input: userId, page, pageSize;
Output:
- userId
- orders[]
  - orderId
  - totalAmount
  - orderDate
- pagination
  - page
  - pageSize
  - totalRecords
Constraints:
- pageSize по умолчанию = 10;
- если заказов нет — вернуть пустой список;
- уметь работать с большими наборами данных.

ИИ получает это как вход и уже подгоняет код и формат ответа под заданный контракт.

Пример без спецификации

Промпт:

«Напиши API, который возвращает детали заказов пользователя»

Типичный ответ ИИ:

{
  "userId": 123,
  "orders": [
    { "id": 1, "amount": 250 }
  ]
}

Проблемы:

названия полей плавают (id vs orderId, amount vs totalAmount);
нет пагинации;
не описано, что делать, если заказов нет;
при следующем запуске промпта структура может поменяться.

Пример со спецификацией

Спецификация та же, что выше. Ответ ИИ уже ближе к тому, что реально нужно в проде:

{
  "userId": 123,
  "orders": [
    {
      "orderId": 1,
      "totalAmount": 250,
      "orderDate": "2024-01-10"
    }
  ],
  "pagination": {
    "page": 1,
    "pageSize": 10,
    "totalRecords": 50
  }
}

Что поменялось под капотом:

ИИ не выдумывает структуру ответа, а заполняет заранее заданный каркас;
вероятность пропустить крайние случаи ниже — вы явно их перечислили;
поле pagination не «магическим образом появилось», а было требованием контракта.

Тот же принцип работает при рефакторинге. Вместо:

«Почини баг в Auth controller»

вы описываете, как должен вести себя логин:

какие поля валидировать;
как должен выглядеть успешный ответ;
как должны выглядеть ошибки;
после скольких неудачных попыток логин блокировать;
какие внутренние ошибки нельзя показывать наружу.

Тогда ИИ не «угадывает», что вы имели в виду, а сверяет текущий код с этой спецификацией и приводит его к нужному поведению.

Что это значит для вас

Когда spec-driven подход реально помогает

API и бэкенд-контракты
- REST и GraphQL API;
- микросервисы с чёткими DTO;
- интеграции между командами и внешними партнёрами.
Здесь выигрыши максимальные: меньше расхождений в полях, меньше сюрпризов в проде, проще документация.
Схема‑ориентированные системы
- базы данных с жёсткой схемой;
- генерация кода по схемам;
- миграции и рефакторинг, где важно не сломать контракт.
Рефакторинг и багфиксы

Вместо того чтобы просить ИИ «починить баг», вы:
- описываете, что именно считается корректным поведением;
- перечисляете сценарии и крайние случаи;
- просите переписать код так, чтобы он им соответствовал.
Пример для аутентификации:
- валидация логина и пароля на входе;
- единый формат ошибок;
- блокировка после 5 неудачных попыток;
- отсутствие утечек внутренних ошибок наружу.
Командная разработка

Спецификация — это не только «корм для ИИ», но и:
- единое понимание задачи внутри команды;
- точка входа для ревью и тестов;
- основа для автотестов и контрактного тестирования.

Когда можно остаться на обычных промптах

Spec-driven подход не нужен, если вы:

пишете маленький скрипт на Python или Bash;
меняете пару строк в UI;
делаете быстрый эксперимент, прототип, черновой PoC;
просите ИИ сгенерировать текст, а не строгую структуру.

В этих сценариях проще и быстрее написать один‑два внятных промпта и сразу посмотреть на результат.

Практический чек‑лист: как начать

Сформулируйте задачу словами
Кратко опишите, что хотите получить. Можно прямо в чате с ИИ.
Напишите черновую спецификацию
Минимальный набор:
- Inputs — какие параметры приходят на вход;
- Outputs — какие поля и в каком формате должны вернуться;
- Constraints — ограничения (пагинация, лимиты, дефолтные значения);
- Edge cases — что делать в пограничных ситуациях.
Уберите двусмысленность
- замените «иногда», «как обычно», «логично» на конкретные правила;
- явно опишите, что делать при ошибках и пустых результатах.
Отдайте спецификацию ИИ
- попросите сгенерировать код строго по этому контракту;
- не бойтесь добавлять в промпт: «следуй только этой спецификации».
Проверьте реализацию по спецификации
- не по ощущению «нравится/не нравится», а по чек-листу из Inputs/Outputs/Constraints/Edge cases;
- если что‑то не совпало — правьте спецификацию и запускайте снова.

Важный побочный эффект

Spec-driven подход не убирает сложность задачи. Он вытаскивает её на поверхность раньше.

Часто оказывается, что:

написать код несложно;
сложно сформулировать, как система должна вести себя в сложных сценариях;
ещё сложнее — договориться об этом внутри команды.

Спецификация становится живым документом:

вы обновляете её по мере понимания предметной области;
используете как основу для автотестов и документации;
подсовываете ИИ при каждом следующем изменении функциональности.

Место на рынке

Spec-driven development — это не продукт, а надстройка над существующими инструментами. Он хорошо стыкуется с:

GitHub Copilot — чем структурированнее запрос, тем стабильнее код, который Copilot предлагает в IDE.
Azure AI Studio — удобно хранить и версионировать спецификации рядом с промптами и пайплайнами.
GPT‑4, Claude 3, любые другие LLM — модели лучше держат структуру, когда вы задаёте её явно.

Подход не привязан ни к Microsoft, ни к конкретной модели. Его можно применять:

в VS Code, JetBrains, Visual Studio;
в CI/CD пайплайнах для генерации и проверки кода;
в внутренних тулзах, где ИИ выступает кодогенератором или помощником по рефакторингу.

Если вы уже используете Copilot или GPT‑4 для разработки, spec-driven — это смена привычки работы, а не миграция на новый стек. Придётся чуть больше думать на старте, но меньше бороться с «капризами» ИИ и разъезжающимися контрактами.

Как запустить: пример рабочей схемы

Ниже — простой шаблон, который можно буквально копировать в промпт и заполнять под задачу.

Контекст: я хочу реализовать/изменить функциональность.

Задача (человеческим языком):
- ...

Спецификация:
1) Inputs:
   - ...
2) Outputs:
   - ...
3) Constraints:
   - ...
4) Edge cases:
   - ...

Сгенерируй код, который строго следует этой спецификации. Не добавляй произвольные поля и поведение, не описанные в контракте.

Можно дополнительно просить ИИ:

сгенерировать тесты по этой же спецификации;
показать, где текущий код расходится с контрактом;
предложить, как упростить или уточнить спецификацию.

Кому это особенно зайдёт

Бэкенд‑разработчикам, которые устали от бесконечных правок API‑ответов и несостыковок между фронтом и бэком.
Тимлидам и техлидам, которым нужен единый источник правды по поведению сервиса.
Разработчикам, активно использующим Copilot/GPT‑4, но недовольным тем, что результат каждый раз немного «другой».
Командам, которые часто рефакторят монолиты и старые сервисы и боятся ломать существующие контракты.

Если вы относитесь к этим группам, spec-driven development — хороший кандидат на то, чтобы попробовать его в одном‑двух сервисах и посмотреть, насколько уменьшится количество «магических» багов и бессмысленных итераций с ИИ.