Не спеками едиными
Сейчас в разработке (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 проектах). Но это уже вкусовщина для отдельной беседы.
Ваш,
@llm_under_hood 🤗