Spec Driven Development - tornando o vibe coding ainda mais poderoso

Antes de começar

A IDE chamada Kiro já foi abordada no GeekNews.

No entanto, ainda não houve uma apresentação sob a ótica do Spec Driven Development (SDD), a filosofia de metodologia de desenvolvimento que o Kiro busca seguir,

e foi publicado um vídeo muito bom para entender Spec Driven Development, então fica aqui a apresentação.

---

Kiro

• IDE do tipo agente: ajuda no desenvolvimento por linguagem natural, mas com o viés de tratar a “especificação como artefato de primeira classe”.

• Mantém a velocidade do “vibe coding” das IDEs com agente existentes, ao mesmo tempo em que define decisões, suposições e restrições em documentos de especificação.

• Fluxo de trabalho: ao inserir uma ideia, ele já começa gerando três arquivos, requirements / design / tasks. O editor é uma forma que adiciona as abas “Specs / Hooks / Steering” sobre um fork do Code OSS.

  • Specs: estrutura os requisitos (histórias de usuário + critérios de aceitação no formato EAR) e depois conecta implementação, testes e mudanças à especificação.
  • Hooks: monitora mudanças em arquivos/código para acionar o fluxo de trabalho de especificações.
  • Steering: faz check-in de guias da equipe como regras (markdown) em .kiro/, na raiz do repositório — por exemplo, ao adicionar regras de TDD, o comportamento do agente pode ser padronizado.

Por que o Spec Driven é necessário

• Complementa as limitações do vibe coding: quando o código é criado rapidamente por trocas no chat, a base das decisões acaba enterrada no fluxo da conversa, e depois fica difícil entender “o que foi feito e por quê”. O SDD propõe definir primeiro especificações centradas em comportamento, para servir como uma bússola estável.

• Definição de especificação (comportamento, propriedades, invariantes): descreve não a implementação, mas como o sistema deve se comportar — incorporando conceitos de propriedades de safety/liveness e invariantes, mas com a filosofia de torná-los acessíveis por uma sintaxe amigável para desenvolvedores.

Vantagens do SDD

• Visibilidade e reutilização das decisões: a especificação se torna a “origem” das mudanças no código, facilitando review e alinhamento, e mesmo quando a funcionalidade muda, a intenção (behaviors) permanece registrada.

• Especificações vivas e combináveis: cenários de usuário, critérios de aceitação, contratos de interface/dados, desempenho/SLAs etc. podem ser modularizados para reutilização e composição (do serviço ao nível de sistema).

• Aplicação em todo o SDLC: do alinhamento nas etapas iniciais de requisitos e design até o loop de feedback de issues após o deploy — a preocupação aqui é manter review, qualidade e consistência mesmo na era de geração rápida de código com IA.

Demo de SDD

• Para o link com o momento de início da demo no vídeo publicado no Main link, consulte esta URL: https://youtu.be/olMxlFSxydc?si=sei-bBZ0Q0yszaWn&t=1085

Fluxo do SDD

A. Configuração inicial

1. Configuração do projeto - Hooks, Steering, MCP
2. Configuração de TDD (recomendado)
3. Configuração da especificação - escrever a Spec com base no formato EAR (recomendado) (também pode ser gerada automaticamente por IA a partir da análise de um projeto existente)

B. Implementação de funcionalidades

1. Derivação da Spec - refletir/atualizar novos requisitos na Spec
2. Configuração de guardrails (recomendado) - stubs de teste, definição de regras
3. Implementação <-> teste - esta etapa é repetida na maior parte via IA, e o desenvolvedor intervém apenas em pequenos ajustes de código que a IA não consegue corrigir bem

• Depois que a configuração do projeto estiver concluída, a expansão de funcionalidades acontece pela repetição da etapa 'B. Implementação de funcionalidades'

Pontos de atenção

• Não funciona caso a qualidade do documento de Spec não atinja um nível mínimo.
• As regras de referência para o documento de Spec no vídeo não são explicadas em detalhes. (Referência: https://kiro.dev/docs/specs/)
• O uso de TDD é recomendado, mas foi dito que projetos sem TDD na maioria dos casos não perceberam muitos efeitos dessa metodologia.

---

Opinião pessoal

• Uma das metodologias propostas a partir de uma outra perspectiva para aproveitar melhor a IA.
• Documentos sempre trazem muitas vantagens quando são escritos “bem”. No entanto, considerando a experiência prática de que muitos documentos não conseguem ser mantidos adequadamente, parece que a questão principal é o quanto isso conseguirá gerar consenso entre as pessoas.
• No momento atual, a estratégia de desenvolvimento com IA + TDD é uma metodologia com a qual muitos desenvolvedores concordam e que já foi validada até certo ponto. Se a eficácia puder ser comprovada por meio de uma comparação entre o uso isolado de TDD e o uso conjunto com SDD, acredito que ganhará muito mais apoio.