Lições de uma biblioteca no-code: desenvolvimento guiado por especificação não é uma equação, é um triângulo

Na era dos agentes de coding com IA, o argumento é que enxergar o desenvolvimento guiado por especificação (Spec-Driven Development) simplesmente como uma equação linear de “especificação → código” é uma perspectiva equivocada.

Argumento central

O desenvolvimento guiado por especificação não é uma equação estática, e sim um triângulo dinâmico.
Um loop de feedback em que três eixos influenciam continuamente uns aos outros:

• Especificação (Spec)
• Código (Code)
• Testes (Tests)

Esses três elementos só funcionam direito quando permanecem sincronizados.

Principais casos e experimentos

• A biblioteca sem código whenwords, criada por Drew Breunig
  → sem código, publicou apenas a especificação (Markdown) + 750 testes (YAML), e deixou um agente de IA gerar o código
  → chamou a atenção de Andrej Karpathy + ultrapassou 1k estrelas no GitHub + recebeu contribuições ativas

Mas os problemas que se repetem nesses experimentos são:

• a implementação é rápida, mas quando a complexidade sobe um pouco, corrigir uma parte quebra outra
• no fim, a maioria dos projetos acaba abandonada e inacabada
• por melhor que a especificação seja, as discussões sobre a forma de implementação continuam

Por que um triângulo?

Ao criar o código → descobre-se ambiguidade/erros na especificação → a especificação é corrigida → novos testes se tornam necessários → o código é corrigido de novo → …
→ isso acontece porque é um loop que se repete sem parar.

Direção proposta para resolver: ferramenta Plumb

A ferramenta CLI Plumb, criada por Drew

• a cada commit no Git, analisa o log de conversas com o agente + as mudanças no código
• extrai as decisões que o agente tomou implicitamente → o desenvolvedor aprova
• decisões aprovadas → atualização automática da especificação
• fornece relatórios de lacunas na cobertura de especificação/testes
  → com o “modo de falha no commit”, decisões importantes passam obrigatoriamente por revisão humana

Contexto histórico

Neste momento, estamos passando novamente pela “crise do software” dos anos 1960.
Na época, o código ficou grande demais para caber na cabeça das pessoas → surgiram waterfall, agile e CI/CD
Agora, até ler o código está se tornando impossível → é preciso um novo processo
→ o argumento é que ferramentas como o Plumb apontam essa direção.

Conclusão em uma frase

Estamos numa era em que a IA produz código em velocidade enorme,
mas o realmente difícil é manter sincronizado o triângulo especificação-código-testes.

https://aisparkup.com/posts/9837