Gerar código ficou barato, mas entender o que gerar continua caro. Foi sempre esse o gargalo — só que agora ele aparece mais rápido, porque o agente preenche qualquer lacuna deixada em aberto. Sem intenção explícita, ele inventa comportamento, assume edge case e escolhe trade-off 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 velha na engenharia de software. O que mudou é quem executa a spec. Não é mais o programador lendo um documento Word na segunda-feira; é o agente, em tempo real, tratando aquele texto como fonte de verdade operacional.
O nome disso é Spec-Driven Development, e o projeto que deu ao termo sua forma mais conhecida é o GitHub Spec Kit, liberado em código aberto em setembro de 2025 e construído sobre a pesquisa de John Lam para tornar o desenvolvimento guiado por LLM mais determinístico. 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. Não é retórica vazia, mas uma inversão de hierarquia onde o código deixa de ser a verdade e vira derivação, como binário compilado a partir de fonte.
O Kiro, da Amazon, chegou a uma arquitetura parecida por caminho próprio com três estágios (requisitos, design e criação de tarefas), funcionando cada um como checkpoint antes do próximo. Diferentes empresas e definições parecidas geram uma difusão semântica que, somada ao ritmo da mudança tecnológica, torna difícil nomear práticas adjacentes à IA. Isso, no entanto, não desqualifica a prática, mas sim o hype em torno dela.
Os custos e limites do modelo
A abordagem possui custos que raramente aparecem em posts de redes sociais:
- Manutenção: Specs precisam ser mantidas; 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, revisar e versionar uma spec só compensa quando a funcionalidade justifica, sendo recomendado pular a abordagem em funcionalidades pequenas ou em trabalhos espalhados por múltiplos serviços.
- Risco de longo prazo: Encher a IA de regras detalhadas escritas à mão pode ser mais uma repetição de padrões que a engenharia de software já tentou no passado sem grande sucesso de escala.
A orientação prática é tratar a spec como interface de contrato entre você e o agente, escrevendo o mínimo que elimina a ambiguidade (intenção, critério de aceite e escopo externo) sem exagerar no tamanho. O ganho real está em mover o ponto onde o erro custa uma frase de correção, em vez de um merge inteiro para desfazer.
Artigo Completo no Blog
Leia o artigo mais aprofundado, com exemplos e a análise de arquitetura completa no meu blog:
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 — consultando a série:
Cupom de 30% OFF:
LEIA30
Disponível também no Kindle Unlimited
Fontes
- Codemyspec – Spec-Driven Development in 2026: The Complete Guide and Tool Comparison
- Thoughtworks Radar (zh-cn) – Spec-driven development (nov/2025)
- Thoughtworks Technology Podcast (AWS) – What is spec-driven development?, com Laura Tacho
- Augment – 6 Best Spec-Driven Development Tools for AI Coding in 2026
#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #SpecDrivenDevelopment #EngenhariaDeRequisitos #AgentesDeCodigo #EngenhariaDeSoftwareAssistidaPorIA
Top comments (0)