Не SDD единым

Сейчас в разработке (SDLC) популярна тема SDD - Spec-Driven Development.

Идея простая. Берем пару скиллов, прогоняем через них наше видение того, что нужно сделать в виде кода, отвечаем на вопросы и получаем спеки (которые понятны агентам)! А потом эти спеки скармливаем агентам, и они пишут код. Ну и допускаем, что если спеки были написаны хорошо и реализовывал их агент мощный, то код будет делать то, что от него ожидают.

Правда потом эти спеки будут лежать в кодовой базе мертвым грузом и источником галлюцинаций, ибо нельзя никак проверить то, что код все еще соответствует спекам. Разве только потратив кучу токенов и без каких либо гарантий. Например, регулярно делать аудит кода агентами (что плохо масштабируется)

То есть у нас не спеки получаются, а просто одноразовые вайб-планы.

А можно ли лучше? Да легко. Смотрим в OpenAI Harness engineering - доки должны быть актуальны, а harness должен верифицировать.

Потом смотрим в древние способы разработки, задолго до SDD, когда были только буквы в начале алфавита: Behaviour-Driven Development. BDD родился задолго до LLM-ok (этак лет двадцать назад), когда перед человеческими командами стояла та же проблема - как синхронизировать работу разработчиков, продактов и тестировщиков так, чтобы требования не устаревали.

И тогда придумали формат Given-When-Then - формат читаемых сценариев, который могли понимать и технари и люди от бизнеса (пару примеров скину в комментарии). Эти сценарии описывали поведение системы с точки зрения черного ящика (как она выглядит снаружи).

Эти сценарии обсуждались и писались лапками - вручную, но используя определенную структуру. А потом технари делали эти сценарии исполняемыми. То есть тестовая обвязка парсила сценарии, превращая в спеки, и просто запускала как end-to-end тесты системы.

Получалась такая иерархия:
(1) Описание требований
(2) Набор читаемых сценариев под требования (обычно их группировали в папочки по именам требований)
(3) Код, который на лету парсит сценарии и прогоняет тест системы.

И если код начинал нарушать сценарий какого-то требования, то это сразу приводило к ошибке билда. А если добавляли новые требования, то у нас получался обычный Test-Driven Development.

Чаще всего использовали формат сценариев Gherkin, а в качестве парсеров - Cucumber, JBehave, RSpec, Behave (и еще куча других).

Оно работало хорошо и в эпоху до ChatGPT, когда все делалось лапками. А сейчас агенты замечательно нарезают высокоуровневые требования в BDD сценарии, и потом реализуют код. И при этом сценарии остаются синхронизированными с требованиями, но превращаются в нормальный AI-Native Harness, который агент может запускать хоть по сто раз за сессию.

Правда у меня формат Gherkin всегда вызывал аллергию (ибо парсеры у команд становились источником отдельных проблем по мере роста продукта). Я предпочитаю более специфичный формат исполняемых Given-When-Then спеков - event-driven specs. Он требует больше инвестиций на уровне архитектуры, но зато лучше масштабируется на проектах от 10k спеков и выше (это в эру до ChatGPT, работа в AI Native - это отдельная песня). Но это уже вкусовщина для отдельной беседы.

А как вы тестируете в 2026 году?

Ваш, @llm_under_hood 🤗