Разработка по спецификациям:
- https://opengsd.net/
- https://openspec.dev/
- https://docs.bmad-method.org/
- https://github.github.com/spec-kit/
- другие
Концептуально
- считаем, что в моменте мы точно знаем в голове, чего хотим
- полная спецификация – это код
- значит, все спецификации неполные
- неполнота 2х типов: положительная неполнота, отрицательная неполнота
- положительная неполнота: не указано, но сделано как у нас в голове
- отрицательная неполнота: не указано, но сделано не так как у нас в голове
- с отрицательной неполнотой фреймворки как-то борятся
- с положительной можно бороться только удалением спеки (после реализации)
Практические выводы
- код первичен
- при этом важно документировать почему было принято то или иное решение (ADR, например)
- спеки лучше удалять после реализации, т.к. иначе будет рассинхрон с кодом в итоге
При этом спеки как инструмент хороши (решают различные проблемы, просто не нужно их возводить в абсолют):
- обзор человеку перед реализацией как будет реализовано – экономия времени и токенов
- возможность паралельно работать
- возможность работать разными агентами над разными частями