ИИ-ассистенты для написания кода давно перестали быть новинкой, но большинство команд используют их так же, как поисковик: задал вопрос, получил ответ, закрыл вкладку. Thoughtworks зафиксировала системную проблему такого подхода и предложила альтернативу.
Вэй Чжан и Джесси Цзе Ся из внутренней ИТ-службы Thoughtworks (Global IT Services) описали метод Structured Prompt-Driven Development (SPDD) в статье на сайте Мартина Фаулера — одного из наиболее авторитетных источников по инженерным практикам в индустрии. Рабочий пример с кодом опубликован на GitHub.
| Раздел Canvas | Расшифровка | Что фиксирует |
|---|---|---|
| R — Requirements | Требования | Проблема и критерии готовности (DoD) |
| E — Entities | Сущности | Объекты предметной области и связи между ними |
| A — Approach | Подход | Стратегия выполнения требований |
| S — Structure | Структура | Место изменений в архитектуре, компоненты и зависимости |
| O — Operations | Операции | Конкретные проверяемые шаги реализации |
| N — Norms | Нормы | Сквозные инженерные стандарты (именование, наблюдаемость и др.) |
| S — Safeguards | Меры безопасности | Жёсткие ограничения: инварианты, пределы производительности, правила безопасности |
Проблема, которую решает SPDD, хорошо знакома командам, уже внедрившим LLM-ассистентов. Отдельный разработчик пишет код быстрее — но узкое место перемещается: неоднозначные требования мгновенно превращаются в неоднозначный код, объём изменений на ревью растёт, несогласованность между модулями накапливается. Авторы сравнивают ситуацию с Ferrari на грунтовой дороге: мощность двигателя есть, но время прибытия определяется состоянием трассы.
Ключевой инструмент метода — REASONS Canvas: семичастная структура, охватывающая требования, сущности, подход, архитектуру, операции, нормы и меры безопасности.
SPDD строится на двух компонентах. Первый — REASONS Canvas, структура из семи разделов, которая заполняется до того, как LLM генерирует хоть строчку кода. Аббревиатура расшифровывается так: Requirements (требования и критерии готовности), Entities (сущности предметной области и связи между ними), Approach (стратегия выполнения), Structure (место изменений в архитектуре), Operations (конкретные проверяемые шаги реализации), Norms (сквозные инженерные стандарты — именование, наблюдаемость, защитное кодирование) и Safeguards (жёсткие ограничения — инварианты, пределы производительности, правила безопасности). Canvas охватывает весь путь от намерения до исполнения и явно фиксирует границы, в которых должна работать модель.
Второй компонент — рабочий процесс, который обращается с промптами так же, как с кодом: история коммитов, ревью, контроль качества. Центральное правило звучит просто: если реальность изменилась, сначала правится промпт, потом код. Это смещает ревью от «обнаружения ошибки» к «проверке намерений» — рецензент видит единый структурированный артефакт, а не разрозненные логи чата и частичные диффы.
Авторы разграничивают SPDD и более ранний подход Spec-Driven Development (SDD), с которым у метода есть общая отправная точка — сначала спецификация, потом код. Разница в том, что в SPDD промпт не генерируется один раз и не выбрасывается: он остаётся живым артефактом, который синхронизируется с кодом на протяжении всего жизненного цикла. Биргитта Бёкелер классифицирует такой подход как «привязку к спецификации».
Практическое следствие для команд: успешные промпты накапливаются в библиотеку переиспользуемых шаблонов, снижая вариативность между разработчиками и уменьшая потери при смене состава команды. Авторы называют три ключевых навыка, необходимых для работы по SPDD: согласованность, подход «сначала абстракция» и итеративный анализ.
Метод пока описан на примере внутренней практики одной компании, и независимых оценок его эффективности в открытом доступе нет. Тем не менее сама постановка задачи — сделать результаты LLM управляемыми на уровне команды, а не только на уровне отдельного разработчика — отражает реальный запрос индустрии, который пока не имеет устоявшегося ответа.
