A Spec Virou Contrato Executável: o Mapa de Ferramentas de SDD

Eu já escrevi spec de projeto que ninguém abriu depois da reunião de aprovação. Documento bem organizado, diagrama caprichado, e no fim o código andou para um lado, a spec ficou parada no outro, e seis meses depois ninguém sabia qual dos dois representava a verdade. Isso era normal até pouco tempo atrás. Não é mais.

Em 2026, a especificação virou um contrato operacional executável. Ela não descreve mais o sistema depois do fato, ela governa o comportamento do agente enquanto ele trabalha. É a memória persistente e o contexto compartilhado que humanos e agentes de código usam para não perder o alinhamento no meio de uma tarefa longa. Isso muda a pergunta que todo tech lead deveria estar fazendo: não é "qual metodologia eu escolho", é "qual ferramenta traduz minha spec em restrição que o agente respeita de fato".

Esse post é o mapa prático para essa pergunta. Eu vou comparar as ferramentas que lideram esse ecossistema agora, GitHub Spec Kit, AWS Kiro, Claude Code Skills, Cursor Plan Mode, OpenSpec, BMAD-METHOD e Tessl, e te ajudar a decidir qual adotar dependendo do contexto do seu time. Se você ainda está com a cabeça no vocabulário confuso que rotula tudo de "SDD", recomendo ler antes o post sobre semantic diffusion no vocabulário agêntico; este aqui é a continuação prática daquela discussão.

De PDF Morto a Contrato Vivo

A ideia central da spec-driven development é simples de enunciar e difícil de praticar: a especificação é o artefato principal, o código é o output de build. Funciona parecido com um arquivo-fonte que compila para um binário. Você edita a spec, não o binário. Quando a spec muda, você reroda o processo e o código sai atualizado, em vez de você caçar manualmente todo lugar que precisa mudar.

Isso virou relevante porque agentes de código são poderosos, mas cegos de contexto. Um agente não sabe, por padrão, quais restrições de negócio importam, quais decisões arquiteturais já foram tomadas, ou onde estão os limites do que ele pode inventar. Numa execução curta isso pouco importa. Numa execução longa, sem uma spec precisa amarrando o que pode e o que não pode, o agente sofre drift: ele preenche as lacunas com suposição própria, e a suposição raramente bate com o que o time queria.

É exatamente aqui que a spec deixa de ser documentação e passa a ser contrato. Um contrato executável não é lido uma vez e arquivado, ele é consultado a cada etapa da tarefa, funcionando como a fonte de verdade que tanto o agente quanto o humano revisam quando alguma coisa parece estranha. Se o comportamento do sistema não bate com a spec, o bug está na spec ou está no código, e agora existe um jeito objetivo de descobrir qual dos dois.

O efeito colateral bom disso é que a spec vira também o canal de comunicação entre pessoas. Um dev sênior não precisa mais ler três mil linhas de diff para entender o que mudou; ele lê a spec atualizada e entende a intenção. Isso reduz retrabalho de revisão e evita a situação clássica de aprovar um PR sem entender de fato o que ele faz.

SDD e Context Engineering Convergindo

O tema mais importante de 2026 nesse espaço é que spec-driven development e context engineering estão convergindo, e a linha entre os dois está ficando borrada de propósito. SDD resolve o "o quê": dar ao agente specs estruturadas e claras sobre o que o sistema deve fazer. Context engineering resolve o "como": gerenciar o que o modelo efetivamente vê e tem disponível em cada momento da execução. Já falei sobre isso com mais profundidade no post sobre context engineering como a skill mais importante para quem trabalha com agentes, e a conclusão daquele post ficou ainda mais evidente agora.

As linguagens de especificação mais recentes já incluem diretivas de contexto embutidas. Em vez de a spec só descrever comportamento esperado, ela declara explicitamente qual informação o agente precisa ter carregada em cada etapa: qual arquivo consultar antes de tocar num módulo, qual decisão arquitetural prévia é inegociável, qual dado de domínio é obrigatório antes de gerar uma função. Isso é spec e é context engineering ao mesmo tempo, só que ninguém mais separa os dois rótulos.

Na prática isso significa que uma spec boa em 2026 não é só "o sistema deve fazer X". É "o sistema deve fazer X, e para isso o agente precisa ter em contexto o schema Y, a regra de negócio Z, e não deve tocar no módulo W sem confirmação". Essa granularidade é o que separa uma spec decorativa de uma spec que realmente evita drift em execuções longas.

Para um tech lead, essa convergência importa porque muda o critério de avaliação de ferramenta. Não basta perguntar "essa ferramenta gera specs bonitas". A pergunta certa é "essa ferramenta consegue traduzir a spec em contexto real que o agente carrega durante a execução, e não só em texto que o agente lê uma vez no começo".

Comparando as Ferramentas na Prática

Vou destacar seis ferramentas que, no meu radar, cobrem os cenários mais comuns de adoção. Nenhuma delas é superior de forma absoluta, cada uma resolve um recorte diferente do problema.

O GitHub Spec Kit é a opção que eu recomendo quando o time trabalha com múltiplos agentes de código ou não quer ficar amarrado a um fornecedor único. Ele é open source e model-agnostic, funciona com qualquer agente que você já usa hoje, seja Claude Code, seja outro assistente. Se o seu time tem gente usando ferramentas diferentes e você quer uma camada de spec comum entre todo mundo, o Spec Kit é o ponto de partida mais seguro, porque a spec não fica presa a um produto que pode mudar de rumo.

O AWS Kiro é o oposto em filosofia: é uma IDE agêntica com fluxo spec-to-code nativo, pensada para quem quer a experiência inteira dentro de um único ambiente, da spec até o código gerado, sem trocar de ferramenta no meio do caminho. Faz sentido para times que já vivem no ecossistema AWS e querem previsibilidade de ponta a ponta. O custo é o acoplamento: você ganha fluidez, perde portabilidade.

Claude Code Skills resolve um problema mais específico: reutilização de conhecimento operacional dentro do ecossistema Anthropic. São skills carregadas por índice, ou seja, o agente só busca a skill quando ela é relevante, em vez de carregar tudo de uma vez. Isso é context engineering aplicado de forma direta, e funciona bem quando seu time já padronizou em Claude Code e quer capturar padrões internos, convenções de código e checklists de revisão como skills reaproveitáveis. É a escolha certa quando você já decidiu o assistente e quer profundidade, não abrangência.

Cursor Plan Mode ataca a etapa que mais gera retrabalho: o planejamento antes de qualquer edição. Dentro do próprio editor, o modo de planejamento força uma pausa consciente onde agente e dev alinham o que vai ser feito antes de o código começar a mudar. Isso é ótimo para squads pequenos que trabalham direto no editor e não querem manter um artefato de spec separado do código, o plano vive ali mesmo, próximo do trabalho.

OpenSpec e Tessl seguem uma linha parecida com o Spec Kit, propondo especificação como formato portável e auditável, com foco em manter a spec como fonte de verdade rastreável ao longo do tempo, algo que ajuda bastante em times regulados ou em produtos com muitos stakeholders não técnicos que precisam revisar intenção sem ler código.

Já o BMAD-METHOD tem uma proposta diferente das outras: é mais orientada a processo, com agentes de papel definido, como se você tivesse um "agente arquiteto", um "agente revisor" e um "agente implementador" seguindo uma coreografia. Faz sentido para times que já pensam em papéis bem separados no fluxo de trabalho humano e querem espelhar essa divisão nos agentes, em vez de um agente generalista fazendo tudo.

Como Decidir o Que Adotar no Seu Time

A primeira pergunta que eu faço antes de recomendar qualquer ferramenta dessas é: o time já convergiu para um assistente de código único, ou ainda está heterogêneo? Se for heterogêneo, comece pelo Spec Kit ou por OpenSpec, porque o valor de ser model-agnostic supera qualquer ganho de integração nativa. Trocar de agente sem reescrever toda a base de specs é um alívio real seis meses depois.

A segunda pergunta é sobre onde o trabalho de planejamento realmente acontece hoje. Se o seu time já vive dentro de um editor e resiste a manter documento fora dele, Cursor Plan Mode tende a colar melhor, porque não exige mudança de hábito, só formaliza o que já é feito de cabeça. Se o time tem cultura de documentação separada do código, Tessl ou OpenSpec cabem melhor, porque tratam a spec como artefato próprio, versionado, revisável por gente que não escreve código.

A terceira pergunta é sobre maturidade de processo. Times que já têm papéis bem definidos, arquiteto, revisor, implementador, mesmo que informalmente, tendem a se dar bem com BMAD-METHOD, porque a ferramenta só formaliza uma divisão que já existe na cabeça das pessoas. Times mais fluidos sofrem com esse modelo e ficam mais confortáveis com uma ferramenta menos prescritiva.

E a última pergunta, que eu considero a mais decisiva na prática, é sobre acoplamento de fornecedor. AWS Kiro e Claude Code Skills entregam profundidade de integração porque vivem dentro de um ecossistema fechado. Isso é uma vantagem enorme quando você já apostou nesse ecossistema e quer explorar o máximo dele. É uma desvantagem quando você ainda está testando qual assistente vai ganhar espaço no seu time nos próximos anos, e não quer reescrever a camada de spec se a decisão mudar.

Nenhuma dessas ferramentas resolve sozinha o problema de drift. O que resolve é a disciplina de tratar a spec como contrato vivo, seja qual for a ferramenta escolhida para operacionalizar isso.

Conclusão

O que mudou de fato em 2026 não foi a ideia de escrever specs, isso já existia. O que mudou foi a spec ganhar poder de execução real sobre o comportamento do agente, funcionando como memória compartilhada entre quem escreve a intenção e quem gera o código a partir dela. Isso torna a escolha de ferramenta uma decisão de arquitetura, não uma preferência de estilo.

Se você está decidindo por onde começar, não escolha pela ferramenta mais comentada da semana. Escolha pela pergunta que eu fiz na seção anterior: heterogeneidade de agentes, hábito de planejamento, maturidade de processo e tolerância a acoplamento de fornecedor. Essas quatro respostas já eliminam a maior parte das opções erradas para o seu contexto específico.

E se o seu time ainda trata spec como PDF que se escreve uma vez e nunca mais se olha, o primeiro passo não é escolher ferramenta nenhuma. É mudar o hábito antes de mudar a stack.

Fontes:

A Spec Virou Contrato Executável: o Mapa de Ferramentas de SDD

A Spec Virou Contrato Executável: o Mapa de Ferramentas de SDD

De PDF Morto a Contrato Vivo

SDD e Context Engineering Convergindo

Comparando as Ferramentas na Prática

Como Decidir o Que Adotar no Seu Time

Conclusão

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

eltonjose