Comments 4
Какое-то костыльное переизобретение тестов получилось. Вот только тесты детерминированы, а "исполняемую спецификацию" агент может частично проигнорировать, если она сложна.
К тому же тесты можно запустить вручную и\или встроить в пайплайн CI\CD. А "исполняемую спецификацию" - нет.
Получилось изобретение ради изобретения, работающее хуже, чем нативные тесты.
Вот только тесты детерминированы, а "исполняемую спецификацию" агент может частично проигнорировать, если она сложна
Каким образом? Спецификация определяется входные данные и ожидаемый результат в удобной для восприятия виде, она ни чем не отличается от теста по детерминированности.
К тому же тесты можно запустить вручную и\или встроить в пайплайн CI\CD. А "исполняемую спецификацию" - нет.
Почему вы так решили? У меня они запускаются командой npm test ее можно запустить где и как угодно.
Помимо спецификаций в таком подходе должны быть прописаны четкие правила написания кода (хотя бы конфиг линтера и форматтера) и подходов к реализации функционала. Описаны паттерны и антипаттерны. Общая архитектура. А также необходим артефакт, содержащий пополняемый список переиспользуемых модулей.
Иначе при вашем подходе у вас будет 127 черных ящиков, внутри которых можно будет часто встретить одинаковый, но не вынесенный функционал, разный код-стайл, разные подходы к чтению, валидации и обработке входных данных и тд.
Привести к единому стилю такие ящики будет довольно сложно. Либо можно этого не делать, но тогда, когда (а не если) что-то пойдет не так, отладить взаимодействие модулей будет достаточно трудоемкой задачей.
Исполняемые спецификации — эффективная работа с кодинг-агентами