cucumber.io

Не 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) Код, который на лету парсит с