Hoje o desenvolvimento mudou, já que a LLM consegue escrever código mais rápido do que um desenvolvedor. Mas como garantir que o código gerado seja coerente, bem escrito e faça o que tem que ser feito?

Velocidade sozinha não resolve isso. Se o prompt não deixa claro o que é o projeto, como ele se organiza e até onde a entrega vai, a LLM completa as lacunas do jeito dela. O diff sai grande e cedo. O custo aparece depois: código que não conversa com o restante do sistema, decisões implícitas espalhadas pelo repositório, e retrabalho no meio da sprint.

Com o SDD fica mais fácil de criar entregáveis bem feitos. Não porque a IA passe a “pensar melhor”, e sim porque o trabalho de critério acontece antes do primeiro pedido de implementação.

O que não delegar

Quando eu não delego para a IA decisões arquiteturais, stack e escopo (o que fazer e como fazer), ela me entrega resultados muito bons.

Quando eu delego, o padrão é outro. Em arquitetura, a IA tende a propor estrutura genérica ou misturar estilos (camadas, pastas, responsabilidades) que não batem com o que o time já usa. Em stack, ela puxa libs, padrões e versões pelo que é comum no treino — não pelo que está travado no projeto. Em escopo, ela amplia: implementa o “bonitinho completo” em vez do PBI da vez.

O resultado técnico costuma ser código que compila e até passa em teste local, mas gera PRs difíceis de revisar, conflitos com o que já existe e discussão tarde demais sobre decisões que deveriam ter sido tomadas fora do chat.

O Fluxo na Prática

Hoje meu fluxo de desenvolvimento é criar bem as specs e só então implementar com a ajuda da IA.

Na prática, isso vive em algo como uma .spec/ (ou equivalente no repo):

  • O que é o projeto — problema, limites e o que fica de fora. Sem isso, a IA inventa produto no meio do código.
  • Arquitetura usada — módulos, fronteiras e responsabilidades já acordadas. Serve de mapa para a implementação não “redesenhar” o sistema a cada feature.
  • Stack escolhida — o que usamos de fato. Evita PR com dependência nova sem consenso.
  • Decisões documentadas (ADRs) — o porquê de X e não Y. Quando a mesma dúvida volta no code review, a ADR já responde.
  • Escopo da entrega (epic / features / PBIs) — o recorte do que entra agora. É o contrato da fatia que a IA vai implementar.

Com as specs no lugar, consigo fazer a implementação com a ajuda da IA de partes “pequenas” que viram entregáveis sólidos. O pedido deixa de ser “faz o sistema” e passa a ser “implementa este PBI dentro destas regras”.

Os Benefícios

Partes pequenas viram PRs menores. Isso muda o review: o reviewer consegue comparar o diff com o PBI e com a spec, em vez de reconstruir a intenção a partir de trezentas linhas misturadas.

Testes de comportamento também ficam mais fáceis de fazer. Se o escopo diz o que a feature deve fazer (e o que não deve), o teste tem um alvo claro. Sem isso, você acaba testando o comportamento que a IA inventou — e chamando isso de “cobertura”.

No meu caso, SDD melhorou o código e as entregas por esse caminho: critério antes do prompt, fatias pequenas na implementação, PRs e testes alinhados com o que foi combinado.