No artigo anterior, explicamos o que é Spec-Driven Development (SDD) e como a metodologia entra na forma de trabalhar que estamos construindo na Pitang.

Para desenvolver com IA, alguém precisa entender o problema, definir os requisitos, orientar a implementação e conferir se o resultado atende ao cliente. É para organizar esse trabalho que usamos SDD na nossa esteira agêntica de desenvolvimento. 

Aqui na Pitang, temos testado ferramentas e abordagens diferentes para descobrir como aplicar o SDD em demandas de tamanhos variados. Parte do que aprendemos circula no Intervalo Técnico, um encontro interno em que alguém estuda um tema a fundo e apresenta o resultado para colegas de outras equipes, que perguntam, discordam e contam o que viram nos próprios projetos. 

Foi lá que apresentei um estudo que conduzi no Pitang Labs comparando abordagens de SDD em tarefas de desenvolvimento assistido por IA. Eu queria saber se processos com mais etapas de especificação e planejamento entregam resultados melhores. Para isso, medi tempo de execução, consumo de tokens e qualidade do código. Abaixo conto como montei os experimentos e o que encontrei. 

Como colocamos diferentes abordagens de SDD à prova?

Criei uma aplicação de gerenciamento de projetos com quadro Kanban. Queria algo relativamente simples, mas com situações parecidas com as de um sistema real. 

Defini seis tarefas, distribuídas em três categorias: 

• Correções de bugs: um erro de fuso horário e um problema de cache em que o usuário continuava com acesso mesmo depois de ter a permissão revogada. 

• Novas funcionalidades: arquivamento de projetos e implementação de notificações. 

• Refatorações: mudanças na organização do código existente para facilitar a manutenção. 

Algumas tarefas tinham requisitos fechados e outras deixavam espaço para interpretação. O pedido de notificações não dizia quais eventos deveriam gerar aviso nem quem deveria recebê-lo. Essa lacuna acabou sendo útil, porque mostrou o que cada abordagem fazia quando faltava uma decisão. 

Quais ferramentas e abordagens foram comparadas? 

Entraram no estudo Spec Kit, OpenSpec, Compozy e Superpowers, além de outras abordagens baseadas em instruções e etapas de planejamento. Cada uma organiza a especificação, as perguntas de esclarecimento, a execução e a revisão de um jeito próprio. 

Como referência, usei o modo de planejamento do Claude Code, que chamei de baseline. Nele, a IA propõe um plano, que pode ser revisado e ajustado antes da implementação. O resultado passa pelas mesmas verificações das outras abordagens. 

O baseline também é uma forma de SDD, só que mais enxuta. O estudo compara, portanto, níveis diferentes de estruturação dentro do próprio SDD. 

Como avaliamos os resultados? 

Usei três critérios para comparar as abordagens: 

• Tempo de execução: quanto tempo cada abordagem levou para concluir a tarefa. 

• Consumo de tokens: o esforço computacional envolvido nas interações com os modelos. 

• Qualidade do código: se a implementação resolvia o problema, respeitava os requisitos e deixava intacto o que não devia ser alterado. 

Toda entrega passou por checagem de tipos, lint e testes. Também analisei as alterações no código por meio de revisão cega, sem saber qual abordagem tinha produzido cada resultado. Fiz essa revisão porque uma implementação pode passar em todas as verificações automáticas e ainda assim alterar um comportamento que deveria continuar igual. 

Por que o experimento teve três versões? 

A primeira rodada teve 36 execuções.

Na segunda, tive dificuldade para controlar as condições de execução e os modelos, e por isso descartei os números. Os problemas me ajudaram a redesenhar o experimento.   

Na terceira, ampliei o conjunto de abordagens, fixei as versões das ferramentas, automatizei etapas e separei melhor planejamento e implementação. Foram 162 execuções, com três repetições para cada combinação de tarefa e abordagem. Com as repetições, deu para ver quanto cada abordagem varia de uma execução para outra. 

O que aprendemos com os experimentos? 

1. O nível de planejamento precisa acompanhar a complexidade da demanda 

Nas tarefas pequenas e médias, o baseline teve qualidade competitiva e gastou menos tempo e menos tokens. Mais etapas e mais documentos não trouxeram ganho proporcional nesse tipo de demanda. 

Uma correção pontual, com escopo claro, pode ser bem conduzida com uma especificação curta, desde que exista plano e validação. Em projetos corporativos com muitas regras de negócio, integrações e dependências, em que as decisões precisam se manter ao longo do tempo, documentação consistente e critérios de aceite claros fazem diferença. 

2. Esclarecer requisitos pode evitar implementações equivocadas 

Na tarefa de notificações, algumas abordagens pararam para pedir esclarecimentos. O Superpowers fez perguntas em parte das execuções. O baseline, nesse cenário, seguiu sem perguntar. 

Quando o pedido tem lacunas, a IA as preenche por conta própria. O código pode funcionar e mesmo assim fazer algo diferente do que o cliente esperava, e em um projeto real isso vira retrabalho. Decidir quais eventos geram aviso e quem recebe cabia às pessoas, e essa decisão deveria estar tomada antes de o agente começar. 

3. Código que passa nos testes ainda precisa ser revisado 

Algumas implementações passaram em todas as verificações automáticas, mas trouxeram alterações desnecessárias ou mudanças capazes de afetar comportamentos existentes. Por isso a revisão técnica continua necessária, principalmente em sistemas que já estão em operação. 

4. A consistência importa tanto quanto o melhor resultado 

Os resultados mudaram entre as repetições. Algumas abordagens oscilaram bastante e outras foram mais constantes. Para escolher uma ferramenta, é preciso considerar como ela se comporta ao longo das execuções, junto com qualidade, tempo e consumo de recursos. 

Existe uma ferramenta de SDD melhor para todos os projetos? 

Com este estudo, não dá para eleger uma vencedora. O baseline se destacou nas tarefas pequenas e médias, mas o experimento usou uma única aplicação, uma única stack e tarefas que cabem em uma sessão de trabalho. Ele não mediu o valor da documentação na manutenção de longo prazo nem o comportamento das abordagens em projetos grandes, que é onde especificações detalhadas ajudam a guardar o contexto e as decisões tomadas. 

A escolha depende do caso. Para uma correção pontual, um fluxo enxuto costuma bastar. Para um sistema crítico, compensa investir mais em documentação, planejamento e verificação. 

Como esses aprendizados contribuem para a engenharia de software na Pitang? 

Boa parte do que desenvolvemos envolve regras de negócio complexas, integrações e requisitos que mudam de cliente para cliente. Nesses projetos, a entrega precisa corresponder ao que foi combinado, e o SDD é a forma como organizamos isso na nossa esteira agêntica. Estudos como os do Pitang Labs ajudam a decidir quando usar mais ou menos estrutura. 

Apresentar o estudo no Intervalo Técnico para mais de 80 colegas foi uma das partes de que mais gostei. O pessoal fez perguntas e trouxe experiências de outros projetos, e saí de lá com reflexões que eu não teria sozinho. É o tipo de troca que mais valorizo na Pitang. 

Desenvolver com IA exige método e critério para aplicá-lo 

Nos testes, o volume de especificação que funcionou variou com a tarefa. Nas correções pontuais, um plano curto bastou. Em projetos críticos, que o estudo não cobriu, rastreabilidade e critérios de aceite claros ajudam a evitar ambiguidades caras. 

Com ou sem IA, cabe a quem desenvolve entender o problema e verificar se a solução faz o que foi pedido. Na Pitang, seguimos experimentando, compartilhando o que aprendemos e aprimorando nossa forma de desenvolver software com IA.