Spec Kit, Kiro, OpenSpec, Tessl: O Mapa De Ferramentas De SDD Em Setembro De 2026

Recebi essa semana uma mensagem de um tech lead que acompanha o blog com uma pergunta direta: "qual dessas ferramentas de SDD eu escolho pro meu time?" Ele tinha acabado de ler o post sobre a spec como contrato executável que escrevi em julho e queria resposta prática, não explicação de conceito. Já sabia o que era SDD. Não sabia por onde começar a escolher a ferramenta.

A pergunta ficou mais difícil de responder do que era há dois meses. Quando escrevi aquele post, o campo já tinha um punhado de nomes disputando espaço. Voltando a olhar a documentação de cada ferramenta agora, em setembro, dá para ver que a disputa não arrefeceu, só ficou mais específica: quem era model-agnostic ficou mais model-agnostic, quem apostava em IDE fechada aprofundou o acoplamento, quem prometia compliance publicou mais template regulatório. Escolher errado custa mais caro agora, porque migrar uma base inteira de specs de um formato para outro não é tarefa de uma tarde.

Não testei essas ferramentas lado a lado, nem rodei benchmark cronometrando execução entre elas — isso exigiria semanas de setup repetido. O que fiz foi ler a documentação oficial de cada uma, relatos de quem já roda isso em produção, e o material acadêmico e jornalístico acumulado sobre o tema em 2026. É leitura organizada, não experimento de bancada.

Este post é o mapa que eu escreveria hoje para aquele tech lead: o que mudou na categoria desde julho, o workflow comum por baixo de nomes diferentes, uma comparação lado a lado das sete opções que mais importam, um exemplo real de quanto tempo isso economiza, e os critérios para decidir qual ferramenta cabe em qual tipo de time.

De Conceito Emergente A Categoria Disputada

SDD deixou de ser ideia de um punhado de early adopters. Por volta de meados de 2026, a categoria já tinha um artigo de referência de Birgitta Bockeler no site de Martin Fowler propondo um espectro de rigor em três níveis, um curso dedicado da DeepLearning.AI chamado "Spec-Driven Development with Coding Agents", e um paper no arXiv, de Deepak Babu Piskala, detalhando workflow e taxonomia da prática — sinal de que a prática cruzou a linha entre modismo e disciplina que fica.

O espectro de rigor que Bockeler descreve, repetido quase palavra por palavra no paper de Piskala, é a lente mais útil para entender por que tantas ferramentas competem pelo mesmo rótulo. No nível mais leve, spec-first, a especificação dá clareza inicial e depois é descartada ou deixada para driftar assim que o código começa a ser gerado — comportamento padrão de Spec Kit e Kiro na configuração default. No meio, spec-anchored, a spec é mantida junto do código pela vida inteira do sistema e testes automatizados garantem que os dois não se separem — o ponto ideal para a maioria dos sistemas de produção, segundo Bockeler. No extremo, spec-as-source, humanos só editam a spec e todo código é gerado e nunca tocado à mão — é onde a Tessl mira, ainda de forma aspiracional.

Essa distinção importa porque "qual ferramenta é melhor" é a pergunta errada. A certa é "em qual desses três níveis eu preciso operar", porque cada ferramenta se compromete com um nível diferente, e forçar uma spec-first a se comportar como spec-anchored é a receita mais comum de frustração relatada.

O segundo eixo é mais prático: quem é dono da spec, e o que acontece com ela depois que o código é escrito. De um lado, ferramentas open source e agnósticas de modelo, pensadas para não prender o time a um fornecedor único. Do outro, IDEs proprietárias que entregam integração em troca de acoplamento. No meio, plugins que vivem dentro de uma IDE que o time já usa. Esse eixo — open source e agnóstico, IDE proprietária, plugin de IDE existente — é o fio condutor do resto do post, o critério que mais rápido elimina opções erradas.

O Workflow Que Quase Toda Ferramenta Copia

Antes de comparar as sete ferramentas, vale registrar o quanto convergem num único pipeline, ainda que os nomes dos comandos mudem: uma constituição de regras de projeto, depois specify, clarify, plan, tasks, implement, e por fim uma validação cruzando spec, plano e tarefas.

A constituição — assim no Spec Kit, ou como AGENTS.md na convenção que Cursor e outros adotaram — é o conjunto de regras que o time não quer repetir a cada spec nova: linguagem, framework, política de dependência, padrão de teste. É escrita como afirmações sempre verdadeiras, no estilo "o sistema deve usar TypeScript em modo estrito", e funciona como pano de fundo imutável para tudo que vem depois.

Specify captura o "o quê" e o "por quê": histórias de usuário e critério de aceite, sem decisão técnica ainda. Entra aqui a notação EARS — Easy Approach to Requirements Syntax, criada por Alistair Mavin na Rolls-Royce em 2009 para requisitos de motor de aeronave, adotada por quase toda ferramenta de SDD porque produz frases que humano e modelo de linguagem leem da mesma forma. Seus cinco padrões colapsam qualquer requisito numa afirmação testável, do tipo "QUANDO o usuário submete um formulário com dado inválido, O SISTEMA DEVE exibir erro junto ao campo" — não vira teste executável sozinho, mas remove a ambiguidade que faz um agente preencher lacuna com suposição própria.

Clarify é onde o agente devolve pergunta em vez de assumir, e o time responde antes de qualquer linha de código existir. Plan traduz a spec aprovada em arquitetura, modelo de dado e escolha de biblioteca. Tasks quebra o plano em itens atômicos, cada um citando a cláusula da spec que satisfaz. Implement executa tarefa por tarefa contra o critério de aceite original. E a análise final — que a maioria trata como opcional, e é exatamente aqui que a categoria mais falha na prática — deveria cruzar spec, plano e tarefas para garantir que nada ficou órfão.

Depois de ler várias fontes lado a lado, fica claro que a validação é o gargalo real da categoria. Spec Kit e a configuração padrão do Kiro geram uma spec disciplinada para lançar a sessão, e deixam o código voltar a ser a fonte de verdade assim que a geração começa — a spec foi real, só parou de governar qualquer coisa depois do primeiro commit. Já o OpenSpec mantém uma spec viva, mas a sincronização com o código continua manual. Nenhuma falha é fatal, mas conhecer qual delas a ferramenta escolhida comete evita surpresa seis meses depois de adotada.

Sete Ferramentas, Sete Apostas Diferentes

Cada ferramenta decide onde investir peso extra dentro desse mesmo esqueleto de workflow.

O GitHub Spec Kit é a referência que todo mundo cita primeiro: deu nome moderno à categoria, aberto como open source em setembro de 2025 sobre a pesquisa de John Lam para tornar desenvolvimento guiado por LLM mais determinístico. É um CLI chamado specify, mais prompts e slash commands (de /constitution a /implement) que funcionam com Claude Code, GitHub Copilot, Cursor, Codex CLI, Gemini CLI, opencode e Qwen Code. É MIT, portável, e não amarra o time a nenhum modelo. A crítica mais honesta que já li, da Scott Logic, descreve a experiência de "revisar o código em vez dos documentos" numa "maré de markdown" — o risco de toda ferramenta spec-first quando a revisão não acompanha o volume gerado.

O AWS Kiro é o oposto em filosofia: IDE agêntica de ponta a ponta, fork de VS Code, onde spec, plano, tarefas e código vivem no mesmo workspace, com integração profunda à AWS. Adota EARS em requirements.md, design.md e tasks.md, e o recurso mais elogiado é o Agent Hooks — automação que roda teste, lint ou verificação de segurança após cada ação do agente. É sucessor declarado do Amazon Q Developer, descontinuado pela AWS, e roda sobre Bedrock. O custo é o acoplamento e um modelo de créditos metrificados já alvo de reclamação pública.

O Cursor Plan Mode ataca o planejamento antes de qualquer edição, sem sair do editor: um modo somente-leitura que explora a base de código e produz um plano, mais a convenção AGENTS.md. Spec Kit e OpenSpec funcionam dentro dele via MCP, então o time pode somar os dois. É a opção certa para squads que já vivem no editor e resistem a artefato separado de código.

O Claude Code, no que o mercado chama informalmente de cc-sdd, oferece slash commands nativos de SDD no terminal, e os prompts do Spec Kit funcionam quase nativamente ali — menor fricção para quem já padronizou nele.

O OpenSpec, da Fission AI, é a opção mais leve e sem lock-in: MIT, sem chave de API, mais de vinte agentes suportados, Markdown com YAML, e rastreamento de delta entre versões da spec — útil para evoluir base legada. A ressalva é que verify não bloqueia nada e os cenários Given/When/Then são opcionais; a reclamação mais comum é drift manual que ninguém percebe até virar contradição.

O BMAD-METHOD orquestra uma equipe ágil simulada — analista, PM, arquiteto, dev, QA — num ciclo em duas fases, fragmentando PRD e arquitetura em histórias hiperdetalhadas. É gratuito, MIT, o mais estrelado no GitHub adjacente à categoria, mas também o mais pesado: semanas para aprender, mais token por tarefa, pouco retorno em mudança pequena. Faz sentido para times com papéis já separados e alto risco com trilha de auditoria exigida.

A Tessl é a aposta mais radical: spec-as-source de verdade, código como artefato regenerável que ninguém edita à mão, apoiada por Guy Podjarny, fundador da Snyk. O motor segue em beta fechado há cerca de nove meses, só para JavaScript, e já foi observado gerando output não determinístico a partir da mesma spec. O que existe hoje é mais um registro de skills focado em compliance do que o compilador de spec prometido — vale acompanhar, não apostar produção nela ainda.

A tabela resume os pontos que mais pesam na decisão:

Ferramenta	Modelo	Onde vive	Melhor encaixe	Ponto fraco
GitHub Spec Kit	Open source, agnóstico	CLI + prompts	Times heterogêneos	"Maré de markdown"
AWS Kiro	Proprietário, IDE completa	Fork de VS Code, Bedrock	Ecossistema AWS	Acoplamento, créditos metrificados
Cursor Plan Mode	Proprietário, modo no editor	Cursor + AGENTS.md	Squads já no editor	Plano descartado após uso
Claude Code (cc-sdd)	Proprietário, skills nativas	Terminal	Já padronizados em Claude Code	Ecossistema mais fechado
OpenSpec	Open source	Repositório, sem API key	Brownfield, sem lock-in	`verify` não bloqueia, drift manual
BMAD-METHOD	Open source	Papéis multiagente	Papéis definidos, alto risco	Curva de aprendizado, custo de token
Tessl	Proprietário, beta fechado	Plataforma + skills	Fintech, healthtech	Não determinístico, só JavaScript

Um Exemplo Real De Quanto Isso Rende

Falar em economia de tempo sem número concreto vira promessa vazia. Em fevereiro de 2026, um time da própria AWS publicou como construiu, em três semanas e com apenas três arquitetos de solução, um agente de identificação de alvo para descoberta de fármacos usando Kiro: dias 1 a 3 de requisito e alinhamento com stakeholder, dias 4 a 6 de design técnico, dias 7 a 14 de specs e implementação do webapp completo, dias 14 a 21 de teste e ajuste. O Kiro gerou mais de 95% do código de lógica de negócio, economizando mais de 80 horas de desenvolvimento, e o README gerado automaticamente economizou outras 8 horas.

Vale registrar que esse número vem de material publicado pela própria AWS, com o viés natural de quem quer mostrar o produto funcionando — não é auditoria independente. Ainda assim, o detalhamento por dia e a divisão explícita de responsabilidade entre os três arquitetos, trabalhando em paralelo sobre o mesmo conjunto de specs, dá concretude que falta na maioria dos cases de material de venda.

Esse tipo de resultado não é exclusividade de Kiro. O CTO da NYSE descreveu à American Banker ter "reconectado o processo de engenharia" usando Claude Code, com agentes internos que levam ticket do Jira até código commitado por fluxo próprio de spec para implementação, processando mais de um trilhão de mensagens em dia de pico de negociação. A Box relatou 85% dos seus desenvolvedores usando Cursor diariamente, com .cursor/rules/ reforçando convenção de time, e cita aumento de 30 a 50% no throughput de roadmap. Nenhuma dessas empresas chama isso de SDD — mas o padrão de fundo, spec estruturada antes de o agente escrever código, é o mesmo em todos os relatos.

Já escrevi com mais profundidade sobre a arquitetura interna do Kiro em o post dedicado à IDE da AWS — o que importa reter aqui é a ordem de grandeza: quando a spec é levada a sério como artefato central, o ganho relatado aparece consistentemente na faixa de dobrar ou triplicar a velocidade de entrega em relação à estimativa original.

Que Time Se Encaixa Em Qual Ferramenta

A primeira pergunta é sobre heterogeneidade: o time já convergiu para um único agente de código, ou ainda mistura Claude Code, Copilot e Cursor? Se for heterogêneo, Spec Kit ou OpenSpec ganham na largada — trocar de agente sem reescrever a base de specs é alívio real quando o mercado mudar de novo.

A segunda é sobre onde o planejamento já acontece. Se o time vive dentro de um editor e resiste a documento fora dele, Cursor Plan Mode ou os slash commands do Claude Code colam melhor, porque só formalizam o que já é feito de cabeça. Se a cultura é de documentação separada, revisada por quem não escreve código, OpenSpec ou Tessl cabem melhor.

A terceira é sobre maturidade de processo. Times com papel bem definido — arquiteto, revisor, implementador —, mesmo que informalmente, tendem a se dar bem com BMAD-METHOD, que só formaliza uma divisão que já existe na cabeça das pessoas. Times fluidos e com pouca paciência para processo preferem algo menos prescritivo como Spec Kit puro.

A quarta, e mais decisiva, é sobre acoplamento de fornecedor e tipo de indústria. Kiro entrega profundidade de integração porque vive num ecossistema fechado — vale a pena quando o time já apostou nele, via Bedrock. Tessl é a única pensada explicitamente para compliance de ponta a ponta, candidata natural para fintech e healthtech, com a ressalva de que o motor central segue em beta fechado. Para o resto, o custo de reescrever a spec se a ferramenta mudar deveria pesar mais que uma integração nativa mais bonita.

Nenhuma dessas perguntas substitui a disciplina de tratar a spec como algo que alguém realmente lê e atualiza. Já discuti isso no post sobre como times inteiros estão se organizando ao redor de agentes: ferramenta nenhuma resolve isso sozinha, só facilita ou dificulta a disciplina que o time já tem ou não tem.

Os Limites Que Ninguém Deveria Ignorar

Toda categoria em ascensão atrai crítica séria. A mais recorrente é a comparação com waterfall: especificação pesada demais no início, entrega em big bang, os defeitos que a comunidade ágil passou duas décadas tentando corrigir. A Marmelab pediu ao Spec Kit para especificar uma funcionalidade de exibir a data atual e recebeu de volta 1.300 linhas de especificação para algo trivial. Bockeler, da ThoughtWorks, usou Kiro para corrigir um bug pequeno e recebeu quatro histórias de usuário com dezesseis critérios de aceite — "usar uma marreta para quebrar uma noz", nas palavras dela. E o estudo randomizado do METR, de julho de 2025, encontrou desaceleração de 19% quando devs experientes usaram ferramentas de IA em tarefas reais de projeto open source — resultado que não é sobre SDD especificamente, mas que vale considerar antes de assumir ganho automático.

A resposta mais honesta não é descartar a crítica, é calibrar o rigor ao tamanho da tarefa: arquivo markdown solto para mudança pequena, workflow completo para funcionalidade que múltiplas pessoas vão manter depois. A própria Marmelab, após a crítica, pivotou para uma ferramenta que gera spec a partir de log de agente — inverte a ordem do workflow, mas continua sendo SDD.

O segundo limite, mais estrutural, é que quase nenhuma ferramenta verifica o código gerado contra a spec de forma automática e bloqueante. EARS padroniza como o requisito é escrito, não faz dele um teste executável, e um validate que confere se uma seção de markdown existe não confere comportamento. A promessa central de SDD — a spec como fonte de verdade que o código não pode contradizer — ainda depende de disciplina humana de revisão, não de garantia mecânica embutida. Vale deixar isso explícito porque some do material de marketing, como venho notando desde o texto sobre SPDD e prompt estruturado.

Conclusão

Voltando à pergunta que abriu este post: não existe resposta única para "qual ferramenta de SDD eu escolho", e qualquer post que prometesse isso estaria vendendo simplicidade que a categoria não tem. O que existe é um conjunto pequeno de perguntas — heterogeneidade de agente, hábito real de planejamento, maturidade de processo, tolerância a acoplamento de fornecedor — que elimina a maior parte das opções erradas e deixa duas ou três candidatas plausíveis para testar de verdade.

O que mudou de julho para cá não foi a lista de nomes, foi a profundidade de cada aposta. GitHub Spec Kit ficou mais reconhecidamente o padrão de fato para quem não quer lock-in. Kiro acumulou casos publicados de uso real, incluindo dentro da própria AWS, que dão mais peso ao argumento de integração profunda. Tessl segue sendo a aposta mais ambiciosa e a menos pronta para produção. É sinal de categoria amadurecendo, não se resolvendo — e acho que vai continuar assim por um bom tempo, porque o problema de fundo, fazer a spec realmente governar o código em vez de só documentá-lo, segue sem solução mecânica confiável em nenhuma das sete ferramentas que olhei aqui.

Se o time daquele tech lead ainda trata spec como documento que se escreve uma vez e nunca mais se revisita, a resposta não muda dependendo da ferramenta escolhida. O primeiro passo continua sendo mudar o hábito antes de gastar energia decidindo qual produto comprar para operacionalizar uma disciplina que ainda não existe.

Fontes:

Spec Kit, Kiro, OpenSpec, Tessl: O Mapa De Ferramentas De SDD Em Setembro De 2026

Spec Kit, Kiro, OpenSpec, Tessl: O Mapa De Ferramentas De SDD Em Setembro De 2026

De Conceito Emergente A Categoria Disputada

O Workflow Que Quase Toda Ferramenta Copia

Sete Ferramentas, Sete Apostas Diferentes

Um Exemplo Real De Quanto Isso Rende

Que Time Se Encaixa Em Qual Ferramenta

Os Limites Que Ninguém Deveria Ignorar

Conclusão

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

eltonjose