Spec-driven development \u00e9 a metodologia de desenvolvimento de software que prioriza a especifica\u00e7\u00e3o documentada de requisitos, arquitetura e plano de implementa\u00e7\u00e3o antes da escrita de qualquer c\u00f3digo. O Kiro, IDE agentic da AWS, \u00e9 a primeira ferramenta a integrar essa metodologia diretamente na experi\u00eancia de desenvolvimento com IA, gerando especifica\u00e7\u00f5es em nota\u00e7\u00e3o EARS que podem ser convertidas em testes automatizados.<\/p>\n\n\n\n
Neste artigo, voc\u00ea vai entender como o spec-driven development funciona na pr\u00e1tica dentro do Kiro, por que ele resolve os problemas do vibe coding em escala e como adotar a metodologia de forma incremental no seu time.<\/p>\n\n\n\n
A populariza\u00e7\u00e3o do vibe coding trouxe ganhos reais de produtividade para desenvolvedores individuais. Descrever o que voc\u00ea quer em linguagem natural e deixar a IA gerar o c\u00f3digo funciona bem para prot\u00f3tipos. O problema aparece quando esse padr\u00e3o \u00e9 adotado por times inteiros, sem coordena\u00e7\u00e3o.<\/p>\n\n\n\n
C\u00f3digo gerado por IA sem estrutura tende a ser verboso, sem ader\u00eancia aos padr\u00f5es do time e dif\u00edcil de manter. Cada desenvolvedor usando IA de forma diferente cria um codebase fragmentado. Os requisitos ficam na cabe\u00e7a de quem escreveu o prompt, n\u00e3o no reposit\u00f3rio. Quando algu\u00e9m sai do time, o conhecimento vai junto.<\/p>\n\n\n\n
O spec-driven development existe para resolver exatamente esses problemas. Em vez de ir direto do prompt para o c\u00f3digo, a metodologia for\u00e7a um processo estruturado que documenta decis\u00f5es, padroniza o fluxo entre desenvolvedores e gera artefatos rastre\u00e1veis.<\/p>\n\n\n\n
Spec-driven development \u00e9 uma metodologia em que especifica\u00e7\u00f5es se tornam artefatos de primeira classe no reposit\u00f3rio, n\u00e3o documentos descart\u00e1veis. O desenvolvedor descreve o que quer construir, e a ferramenta conduz um processo de tr\u00eas fases antes de escrever c\u00f3digo: defini\u00e7\u00e3o de requisitos, proposta de design t\u00e9cnico e cria\u00e7\u00e3o de um plano de tarefas sequenciado.<\/p>\n\n\n\n
O Kiro da AWS \u00e9 o primeiro IDE a implementar spec-driven development de forma nativa. Quando voc\u00ea cria um novo spec no Kiro, o agente gera tr\u00eas arquivos Markdown versionados no Git, dentro da pasta requirements.md<\/strong> \u2014 hist\u00f3rias de usu\u00e1rio com crit\u00e9rios de aceita\u00e7\u00e3o em nota\u00e7\u00e3o EARS.<\/p>\n\n\n\n design.md<\/strong> \u2014 arquitetura t\u00e9cnica, diagramas de fluxo e decis\u00f5es de stack.<\/p>\n\n\n\n tasks.md<\/strong> \u2014 plano de implementa\u00e7\u00e3o com tarefas discretas, sequenciadas por depend\u00eancia.<\/p>\n\n\n\n Esses arquivos ficam no reposit\u00f3rio junto com o c\u00f3digo. N\u00e3o s\u00e3o rascunhos tempor\u00e1rios: s\u00e3o artefatos de projeto que documentam por que o c\u00f3digo existe da forma que existe.<\/p>\n\n\n\n “O tempo que voc\u00ea investe no planejamento com specs retorna multiplicado no c\u00f3digo que funciona de primeira.” – Desenvolvedor na comunidade DEV.to sobre spec-driven development<\/em><\/p>\n<\/blockquote>\n\n\n\n Quando voc\u00ea cria um novo spec e descreve uma funcionalidade em linguagem natural, o Kiro n\u00e3o gera c\u00f3digo: ele gera hist\u00f3rias de usu\u00e1rio estruturadas com crit\u00e9rios de aceita\u00e7\u00e3o em nota\u00e7\u00e3o EARS (Easy Approach to Requirements Syntax).<\/p>\n\n\n\n EARS \u00e9 um padr\u00e3o de escrita de requisitos criado originalmente pela Rolls-Royce para sistemas de software cr\u00edticos. O formato segue uma estrutura espec\u00edfica: WHEN<\/strong> [evento], THE SYSTEM SHALL<\/strong> [comportamento]. Esse padr\u00e3o torna os requisitos verific\u00e1veis: \u00e9 poss\u00edvel escrever testes automatizados diretamente a partir de cada crit\u00e9rio de aceita\u00e7\u00e3o. A AWS detalhou a vis\u00e3o por tr\u00e1s dessa escolha no artigo Kiro and the future of AI spec-driven software development<\/a>.<\/p>\n\n\n\n Exemplo de requisito em nota\u00e7\u00e3o EARS gerado pelo Kiro:<\/strong><\/p>\n\n\n\n Hist\u00f3ria:<\/strong> Como usu\u00e1rio, quero avaliar produtos para ajudar outros compradores.<\/p>\n\n\n\n Crit\u00e9rio 1:<\/strong> WHEN o usu\u00e1rio acessa a p\u00e1gina de um produto, THEN o sistema SHALL exibir a m\u00e9dia de avalia\u00e7\u00f5es e o total de reviews.<\/p>\n\n\n\n Crit\u00e9rio 2:<\/strong> WHEN o usu\u00e1rio envia uma avalia\u00e7\u00e3o sem texto, THEN o sistema SHALL exibir uma mensagem de erro solicitando ao menos 10 caracteres.<\/p>\n<\/blockquote>\n\n\n\n O resultado \u00e9 armazenado em Com os requisitos aprovados, o Kiro analisa o codebase existente e prop\u00f5e a arquitetura t\u00e9cnica necess\u00e1ria. Isso inclui decis\u00f5es de stack, novos componentes, mudan\u00e7as em componentes existentes, schemas de banco de dados e diagramas de sequ\u00eancia.<\/p>\n\n\n\n O design \u00e9 armazenado em A partir do design aprovado, o Kiro gera um plano de implementa\u00e7\u00e3o em Toda a pasta .kiro\/specs\/[nome-da-feature]\/<\/code> (veja a documenta\u00e7\u00e3o oficial de Specs<\/a>):<\/p>\n\n\n\n\n
As tr\u00eas fases do spec-driven development no Kiro<\/strong><\/h2>\n\n\n\n
Fase 1: Requirements \u2014 transformando ideias em requisitos verific\u00e1veis<\/strong><\/h3>\n\n\n\n
\n
requirements.md<\/code>. O Kiro tamb\u00e9m suporta dois workflows de spec: Requirements-First<\/strong> (define requisitos primeiro, depois gera design) e Design-First<\/strong> (come\u00e7a pela arquitetura e depois deriva os requisitos), conforme detalhado na documenta\u00e7\u00e3o de Feature Specs<\/a>. A escolha depende do cen\u00e1rio: funcionalidades novas geralmente se beneficiam de Requirements-First, enquanto refatora\u00e7\u00f5es complexas podem partir do design.<\/p>\n\n\n\nFase 2: Design \u2014 arquitetura antes do c\u00f3digo<\/strong><\/h3>\n\n\n\n
design.md<\/code> e deve ser revisado pelo time antes da implementa\u00e7\u00e3o. Esse \u00e9 o momento ideal para identificar conflitos de arquitetura, depend\u00eancias problem\u00e1ticas e decis\u00f5es que v\u00e3o afetar a manuten\u00e7\u00e3o futura. Capturar um erro de design nessa fase custa minutos; captur\u00e1-lo em produ\u00e7\u00e3o custa dias.<\/p>\n\n\n\nFase 3: Tasks \u2014 implementa\u00e7\u00e3o sequenciada e rastre\u00e1vel<\/strong><\/h3>\n\n\n\n
tasks.md<\/code>: uma lista de tarefas discretas, sequenciadas por depend\u00eancia, com descri\u00e7\u00e3o clara do que cada uma deve produzir. O desenvolvedor executa cada tarefa individualmente, acompanha o progresso em tempo real e ajusta antes de prosseguir.<\/p>\n\n\n\n.kiro\/specs\/<\/code> deve ser versionada no reposit\u00f3rio junto com o c\u00f3digo. As specs documentam o contexto das decis\u00f5es tomadas, o que \u00e9 valioso para onboarding de novos desenvolvedores e para manuten\u00e7\u00e3o futura: qualquer pessoa do time pode entender por que o c\u00f3digo foi constru\u00eddo daquela forma.<\/p>\n\n\n\n