# Spec antes do código Gerar código ficou barato, mas entender o que gerar continua caro. Esse sempre foi o gargalo, e agora ele aparece mais rápido porque o agente preenche qualquer lacuna deixada em aberto. Sem intenção explícita, ele inventa comportamentos, assume *edge cases* e escolhe *trade-offs* que ninguém pediu. O *PR* passa no teste genérico, mas semanas depois alguém descobre que o requisito de negócio era outro. A resposta que ganhou tração em 2026 não é nova em essência. "Especifique antes de construir" é uma máxima antiga na engenharia de software. O que mudou foi quem executa a *spec*: não é mais o programador lendo um documento na segunda-feira, mas o agente, em tempo real, tratando aquele texto como fonte de verdade operacional. O nome disso é **Spec-Driven Development (SDD)**, e o projeto que deu ao termo sua forma mais conhecida é o **GitHub Spec Kit**, liberado em código aberto em agosto de 2025. A formulação usada pelo próprio kit resume o giro conceitual: **especificações não servem ao código — o código serve às especificações**. --- ### Hierarquia invertida O Spec Kit começou com o objetivo de tornar o desenvolvimento guiado por LLM mais determinístico. O insight de John Lam foi que a falta de estrutura nos *prompts* levava a resultados inconsistentes, resolvida através de artefatos duráveis (*constitution*, *spec*, *plan*, *tasks*) que servem como contexto estruturado em vez de conversas *ad-hoc*. A estrutura padrão engloba etapas iterativas interconectadas: * **Constitution:** Princípios e *guardrails*. * **Specify:** Requisitos e critérios de aceite. * **Clarify:** Resolução de ambiguidades. * **Plan:** Arquitetura e fluxos. * **Tasks:** Unidades de implementação. * **Implement:** Geração de código. * **Validate:** Verificação contra a *spec*. Quando um requisito muda, atualiza-se a *spec.md*, o *plan.md* e o *tasks.md* sistematicamente antes de mexer no código. --- ### Onde a coisa fica menos limpa A Thoughtworks classificou a abordagem como *emerging*, apontando que o termo abrange desde *agent workflows* (onde a *spec* guia o agente no repositório, como o Spec Kit, Kiro e BMAD) até *spec compilers* (onde a *spec* é compilada deterministicamente sem LLM na geração, como o Archiet). Testes práticos em ambientes *brownfield* revelaram pontos de atrito: * **O que funcionou:** Um documento de constituição robusto capturando escopo, contexto de domínio, versões de tecnologia e padrões de codificação. * **O que quebrou:** O crescimento excessivo de instruções ao longo do tempo degradava o contexto, problema mitigado extraindo orientações para arquivos de *skills* reutilizáveis. * **Sobrecarga:** Verificações defensivas desnecessárias e saídas em Markdown excessivamente verbosas exigiram personalização de templates. Engenheiros experientes com sólidos fundamentos de *clean code* e arquitetura extraem o máximo de valor do SDD, pois ele amplifica quem já sabe o que está fazendo. --- ### O que o SDD não resolve Existem limitações concretas reconhecidas pelo ecossistema: * **Fadiga de manutenção:** Se o projeto muda e a *spec* não acompanha, cria-se documentação desatualizada na qual o agente confia cegamente. * **Escala mínima:** O *overhead* de escrever e versionar uma *spec* compensa apenas quando a funcionalidade justifica, devendo ser evitado em tarefas muito pequenas ou espalhadas por múltiplos serviços. * **Risco de *over-specification*:** Métricas como o *SpecFactor* (razão entre linhas de *spec* e linhas de código) ilustram a tensão; enquanto o OpenSpec produz um fator próximo de 0,75, o GitHub Spec Kit gera cerca de 2,5 vezes mais *spec* que código. *Specs* excessivamente longas tornam-se indigestas tanto para humanos quanto para agentes. --- ### Aprofunde-se no Tema Autor da série de livros **"Engenharia de Software Assistida por IA"** (disponível na Amazon). Aprofunde-se no tema de forma estruturada — do contexto à governança de agentes: > **Cupom de 30% OFF nos eBooks:** `LEIA30` > *Disponível também no Kindle Unlimited* %[https://livro-engenharia-de-software-assistida-por-ia.aspepper.workers.dev] --- ### Fontes da Pesquisa 1. GitHub Spec Kit – *Documentação Oficial* (setembro/2026). 2. Thoughtworks Technology Radar – *GitHub Spec Kit* (abril/2026). 3. Microsoft Developer Blog – *Spec-Driven Development: A Spec-First Approach to AI-Native Engineering* (junho/2026). 4. Kiro Docs – *Requirements-First Workflow* (junho/2026). 5. Spec Kit History – *GitHub Repository & Transition Logs* (2025/2026). 6. Spec-Driven Development in 2026 – *From Agent Prompts to Compiled Applications*. 7. Thoughtworks Technology Radar – *Spec-driven development* (novembro/2025). 8. Microsoft Learn – *Examen de flujos de trabajo del kit de especificaciones* (janeiro/2026). 9. Tencent Cloud – *从Prompt到Spec* (abril/2026). 10. Kiro Docs – *Specs* (agosto/2026). 11. Security Boulevard – *7 Spec-Driven Development Tools* (junho/2026). 12. Arvato Systems – *Spec-Driven Development: From Coder to Architect* (junho/2026). 13. Microsoft Learn – *Desenvolver aplicação Greenfield com GitHub Spec Kit*. 14. Microsoft Learn – *Implémenter une fonctionnalité avec GitHub Spec Kit*. 15. GitHub – *Spec Kit Install Guide* (yPin9/Learning-with-Claude). 16. heise online – *Specs first: OpenSpec sorts out the AI chaos* (julho/2026). 17. Thoughtworks Blog – *Desenvolvimento orientado por especificações* (dezembro/2025). --- Tags: #EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #SpecDrivenDevelopment #EngenhariaDeRequisitos #AgentesDeCodigo #EngenhariaDeSoftwareAssistidaPorIA