Why ad-hoc prompting breaks down

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

Проблемы начинаются, когда результат должен жить дольше одной сессии. Первая: намерение существует только у вас в голове и размазано по чату. Никто — включая вас через две недели — не сможет восстановить, почему код именно такой. Вторая: каждый ре-промпт мутирует код непредсказуемо. Агент, исправляя кнопку, «заодно» переписывает обработку ошибок, и вы этого не замечаете, потому что смотрели только на кнопку. Третья: такой код некому осмысленно ревьюить. Ревьюер видит diff на две тысячи строк без единого документа о том, что этот diff должен делать, — и либо читает всё построчно, либо ставит approve вслепую.

Ad-hoc промптинг — это не «плохо», это инструмент с потолком. Потолок наступает ровно там, где появляется команда, продакшен или второй агент. Дальше нужен артефакт, который фиксирует намерение отдельно от диалога.

Разберём, почему история диалога не может служить источником истины. Во-первых, она неструктурирована: важное ограничение «никогда не пиши в таблицу orders напрямую» сформулировано на сороковом сообщении между двумя правками CSS. При компакции контекста или в новой сессии оно молча исчезает — и агент нарушает его с полной уверенностью.

Во-вторых, диалог невоспроизводим. Тот же самый стартовый промпт завтра даст другой код: другая температура, другая версия модели, другой порядок исследования репозитория. Пока требования живут в чате, у вас нет способа сказать «сделай то же самое ещё раз» — ни другому агенту, ни коллеге.

В-третьих, знание не передаётся. Новый разработчик или свежезапущенный агент начинает с нуля: все решения, компромиссы и запреты, выясненные за двадцать сессий, приходится проговаривать заново. В командах это превращается в «спроси у того, кто это промптил» — худшую форму bus-фактора.

Симптом, по которому это легко диагностировать: вы копируете куски старых диалогов в новые сессии. Это и есть момент, когда неявная спека уже существует — просто она размазана по переписке. Spec-driven development предлагает честно вынести её в файл.

Spec-driven development (SDD) переворачивает привычное отношение: не «код — главное, документация — если успеем», а «спека — главный артефакт, код — её производная». Спека здесь — не отчёт, написанный после, и не двадцатистраничный ТЗ-документ, а компактный исполняемый вход для агента: намерение (зачем это нужно), ограничения (что нельзя) и критерии приёмки (как проверить, что готово).

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

Идея не нова: это прямой наследник specification by example и BDD, где требования записывались проверяемыми примерами, и инженерной культуры design docs, где решение сначала описывают, потом строят. Новое — экономика: раньше «сначала опиши, потом сделай» стоило дорого, потому что делал человек. Теперь реализация подешевела на порядок, и узким местом стала точность описания. GitHub Spec Kit оформил это в конвейер specify → plan → tasks → implement, который мы пройдём в третьем уроке.

SDD — не религия, и есть класс задач, где спека честно избыточна. Одноразовый скрипт для миграции данных, который умрёт после запуска. Исследовательский прототип, где вы сами не знаете, что хотите, пока не увидите три варианта. Правка опечатки. Во всех этих случаях цикл «промпт → результат» быстрее и достаточен: цена ошибки мала, а результат не переживёт сессию.

Рабочее правило: спека нужна, если выполняется хотя бы одно из трёх. Результат живёт дольше сессии — его будут менять, а значит, кому-то понадобится знать контракт. Результат трогает кто-то ещё — коллега, ревьюер или второй агент, которым нужен общий источник истины. Цена ошибки высока — платежи, миграции, публичные API, где «вроде работает» не аргумент.

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