A spec is a structured, behavior-oriented artifact - or a set of related artifacts - written in natural language that expresses software functionality and serves as guidance to AI coding agents.
Eu não gosto de escrever as SPECs pensando apenas em AI coding. Eu gosto bastante de Reduzir o nível de abstração entre o que se pretende e o que se executa poderia ser benéfico para o entendimento humano?, porque reforça a idéia de conhecimento
There is a useful difference to be made I think between specs and the more general context documents for a codebase. That general context are things like rules files, or high level descriptions of the product and the codebase. Some tools call this context a memory bank, so that’s what I will use here. These files are relevant across all AI coding sessions in the codebase, whereas specs only relevant to the tasks that actually create or change that particular functionality.
Isso é interessante, uma forma de definir o que vai e aonde vai. Mas e o problema do overdoc? (Existe esse termo?)
At first glance, GitHub seems to be aspiring to a spec-anchored approach (“That’s why we’re rethinking specifications — not as static documents, but as living, executable artifacts that evolve with the project. Specs become the shared source of truth.
Essa ideia me agrada, porque ai sim parece valoroso (porque no final, somos humanos e sabemos ler)
A Tessl spec can serve as the main artifact that is being maintained and edited, with the code even marked with a comment at the top saying
// GENERATED FROM SPEC - DO NOT EDIT
Gostei disso
Even at this low abstraction level I have seen the non-determinism in action though, when I generated code multiple times from the same spec.
O fator não determinístico é interessante de abordar…
O não determinismo na programação é realmente um problema introduzido pelo spec-driven development? Manifesto para uma utilização não singular de Inteligências Artificiais