Не спеками едиными — 17 июня 2026 г. в 11:56:05.388
Не спеками едиными Сейчас в разработке (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 спеков и выше (особенно в AI Native проектах). Но это уже вкусовщина для отдельной беседы. Ваш, 🤗