Parte 1 estabeleceu: IA democratiza construção de software e muda onde PMs, Designers e Devs gastam tempo. Menos no downstream executando, mais no upstream especificando. Agora: como estruturar esse sistema na prática.
SDD tem arquitetura de documentação com níveis de maturidade diferentes. Você pode começar descartável e evoluir para fonte viva. Pode usar para projeto greenfield, feature em sistema legado, ou modernização completa. A estrutura se adapta.
Três níveis de maturidade SDD
Spec-first: o mínimo viável
Você escreve spec bem pensada antes de começar feature. A spec guia desenvolvimento daquela tarefa específica. Quando termina, pode descartar ou arquivar — ela cumpriu seu papel.
Approach mais leve. Funciona bem para features isoladas, POCs, ou quando você está experimentando SDD pela primeira vez. Kiro opera principalmente nesse nível — você cria requirements, design, tasks para história específica, executa, e segue em frente.
A spec morre quando código é entregue. Simples assim.
Spec-anchored: documentação viva
A spec evolui junto com código. Quando você precisa modificar funcionalidade daqui a 6 meses, volta na spec, atualiza com novos requisitos, usa como base para mudanças no código.
Spec-anchored resolve problema que documentação tradicional sempre teve: virar obsoleta. Aqui, spec é fonte da verdade que evolui. SpecKit do GitHub e Agent-os operam nesse nível, mantendo specs que servem de referência para futuras iterações.
Vantagem: contexto documentado permanente. Dev novo no time consegue entender decisões passadas lendo specs. Precisa refatorar? Tem requisitos originais documentados para garantir que nenhum comportamento esperado será quebrado.
Spec-as-source: inversão completa
Esse é nível mais radical. Spec vira artefato principal e código é apenas output gerado. Humanos só editam spec. Código pode até ser marcado como "gerado automaticamente, não editar".
Isso precisa ser combinado com o time. Isso me lembra quando controles de versão estavam sendo adotados. Era uma zona. Galera fazia commit e já pushava para produção. Aí começou a combinar o processo... code review, wait to deploy, etc... parou de ficar subindo direto pra produção.
Aqui mesma coisa: ninguém mexe mais no código. Tudo é feito pela IA. Não vou falar que é vibe coding total, porque é mancada. Mas aqui o spec-as-source deve ser seguido e 99% do código da aplicação.
Tessl Framework explora esse território. Criam specs em nível de componente (um spec por arquivo de código) e marcam arquivos gerados com "// GENERATED FROM SPEC - DO NOT EDIT". Quando precisa mudar algo, edita spec e roda build de novo.
Se funcionar em escala, você pode trocar tech stack regenerando código a partir das mesmas specs. Python pra Go? Mesma spec, constitution diferente. React pra Vue? Mesma lógica de negócio, implementação diferente.
Desafios existem. Geração de código por IA ainda tem não-determinismo — rodar mesma spec duas vezes pode gerar código ligeiramente diferente. E quando encontra bug, você precisa entender qual parte da spec levou àquele comportamento e como alterar spec pra corrigir, em vez de simplesmente consertar o código direto.
Aqui, o melhor é o dev trabalhar por partes, controlando todas as fases com boas definições, gerando arquivos de sessões bem e controlando bem o contexto para a IA não endoidar.