O desenvolvimento de software com assistentes e Agentes de IA está mudando rapidamente a relação entre desenvolvedor e código. Uma tarefa que antes exigia horas de implementação pode hoje ser entregue em poucos minutos, muitas vezes envolvendo dezenas de arquivos e centenas ou milhares de linhas de código.

Essa aceleração cria um novo problema. Se a única maneira de validar o trabalho da IA for revisar manualmente cada linha produzida, uma parte importante do ganho de produtividade desaparece.

Por isso, antes de delegar uma tarefa para um agente, existe uma pergunta que deveria vir antes do próprio prompt:

Como vou saber que o resultado está correto sem precisar ler todo o código?

Este artigo ajuda a responder essa pergunta. Boa leitura.

O Novo Gargalo é a Verificação

Durante muito tempo, escrever código foi uma das partes mais trabalhosas do desenvolvimento de software. Com Agentes de IA, essa etapa está ficando progressivamente mais barata e rápida. O gargalo começa a migrar da geração para a verificação.

Não basta um agente informar que concluiu a tarefa. Precisamos determinar se a implementação realmente faz o que deveria fazer, se não introduziu regressões, se respeitou os contratos de dados existentes e se não criou novos problemas de segurança ou arquitetura.

Quanto maior a capacidade da IA para produzir código, maior precisa ser nossa capacidade para avaliar automaticamente aquilo que ela produz.

É Aqui Que SDD Se Torna Importante

Spec-Driven Development, SDD, parte de uma ideia particularmente relevante para esse cenário: antes da implementação, precisamos definir com clareza o comportamento esperado do sistema. Mas, no desenvolvimento com IA, podemos ir além.

Uma boa especificação não deveria responder apenas à pergunta “o que precisa ser construído?”. Ela também deveria responder “como saberemos que foi construído corretamente?”.

Considere uma instrução como:

“Crie um endpoint de uma API para cadastrar clientes.”

Ela parece clara, mas deixa inúmeras decisões abertas. Quais campos são obrigatórios? O email precisa ser único? O que acontece quando o cliente já existe? O endpoint exige autenticação? Qual resposta deve ser retornada em caso de erro? Existem campos que nunca podem aparecer na resposta?

Sem essas definições, várias implementações podem parecer corretas.

Uma especificação melhor transforma essas decisões em comportamentos verificáveis. Ela pode determinar, por exemplo, que nome e email são obrigatórios, que emails duplicados devem retornar HTTP 409, que usuários não autenticados não podem executar a operação e que determinados campos internos jamais devem aparecer na resposta.

Nesse momento, a especificação começa a funcionar como um contrato.

Especificações Precisam Produzir Evidências

O objetivo é transformar requisitos em mecanismos de verificação.

Testes unitários podem validar componentes individuais. Testes de integração verificam a comunicação entre partes do sistema. Testes end-to-end validam fluxos completos. Sistemas de tipos detectam inconsistências estruturais. Static analysis identifica determinadas classes de problemas sem executar o programa. Security scanners procuram vulnerabilidades, dependências problemáticas e configurações inseguras.

Contratos de API podem ser definidos com tecnologias como OpenAPI. Schemas podem validar estruturas de dados. Regras importantes podem ser representadas como invariantes.

Nenhum desses mecanismos garante, isoladamente, que o software esteja completamente correto. Mas juntos eles produzem evidências suficientes para reduzir significativamente a dependência da inspeção manual.

A pergunta deixa de ser:

“Eu li todo o código que a IA escreveu?”

E passa a ser:

“Que evidências demonstram que esta implementação satisfaz a especificação?”

Testes Também Fazem Parte da Especificação

Em muitos projetos, testes ainda são tratados como algo que aparece depois da implementação. Com Agentes de IA, faz sentido inverter parte dessa lógica.

Primeiro definimos o comportamento esperado. Depois estabelecemos critérios de aceitação e mecanismos de validação. Somente então delegamos a implementação. Isso cria um ambiente muito mais favorável para agentes.

O agente implementa uma funcionalidade, executa os testes e recebe o resultado. Se algo falhar, ele analisa o problema, modifica o código e executa novamente as verificações.

O processo deixa de ser apenas geração de código e passa a formar um ciclo de especificação, implementação, avaliação e correção.

Testes Que Passam Não Provam Tudo

Existe, porém, uma armadilha importante.

Todos os testes passarem não significa necessariamente que o software está correto. Significa apenas que a implementação satisfez os testes disponíveis.

Se os testes representarem mal os requisitos, teremos uma implementação tecnicamente aprovada, mas semanticamente errada. Por isso, a qualidade do sistema de avaliação passa a ser tão importante quanto a qualidade do código gerado.

Esse princípio aparece claramente em conceitos como invariantes e Property Based Testing. Em vez de testar apenas exemplos específicos, podemos definir propriedades que precisam permanecer verdadeiras em diferentes condições.

Em um sistema financeiro, por exemplo, uma transferência entre duas contas não deveria alterar a soma total do dinheiro existente entre elas. Em um sistema de pedidos, um pedido cancelado talvez nunca possa retornar ao estado de processamento. Em um sistema de autorização, usuários sem determinada permissão jamais deveriam acessar determinado recurso.

Essas propriedades podem ser verificadas automaticamente em muitos cenários diferentes.

Quanto mais conseguimos transformar requisitos importantes em propriedades verificáveis, menor se torna a necessidade de depender exclusivamente da leitura do código.

CI/CD Como Sistema de Avaliação

O pipeline de CI/CD também passa a ter um papel diferente nesse modelo.

Tradicionalmente, ele é associado a build, testes e deployment. Com Agentes de IA, pode funcionar também como um sistema automatizado de avaliação das mudanças produzidas.

Uma implementação criada por um agente pode precisar passar por build, type checking, testes unitários, testes de integração, testes end-to-end, análise estática, validação de contratos e verificações de segurança antes de ser considerada candidata a integração.

Isso cria uma barreira objetiva entre “o agente terminou de escrever” e “a implementação pode ser aceita”. Essa distinção é fundamental.

A Revisão Humana Continua Importante

Nada disso elimina a necessidade de revisão humana.

Existem aspectos difíceis de representar completamente através de testes: arquitetura, manutenção futura, complexidade desnecessária, escolha de dependências, decisões de segurança, privacidade e impactos sobre outras partes do sistema.

O que muda é o foco da revisão.

Em vez de analisar todas as linhas com o mesmo nível de atenção, o desenvolvedor pode concentrar seu esforço nos pontos de maior risco.

Uma alteração simples em uma interface administrativa não precisa necessariamente receber o mesmo nível de escrutínio de um módulo de autenticação ou de uma rotina financeira.

A revisão passa a ser orientada por risco.

O Desenvolvedor Também Passa a Projetar a Avaliação

Essa transformação modifica o papel do desenvolvedor.

Se uma parcela crescente da implementação pode ser realizada por agentes, aumenta a importância de saber definir requisitos, contratos, restrições, invariantes, critérios de aceitação e mecanismos de validação. Ou seja, o conhecimento do profissional se torna ainda mais importante.

O desenvolvedor deixa de ser apenas alguém que escreve a solução. Ele passa também a projetar o sistema que determinará se a solução produzida é aceitável. Essa talvez seja uma das conexões mais importantes entre SDD e Agentes de IA.

Uma especificação preparada para agentes não deveria terminar simplesmente em:

“Implemente esta funcionalidade.”

Ela deveria estabelecer também quais contratos precisam ser preservados, quais comportamentos devem ser observados, quais condições não podem ser violadas e quais verificações precisam ser aprovadas.

De Code Generation Para Evidence Generation

A primeira fase dos assistentes de programação foi fortemente orientada para Code Generation. A próxima precisa ser também orientada para Evidence Generation.

Não basta receber uma mensagem dizendo que a implementação foi concluída.

Queremos saber que o projeto compilou, os testes passaram, os contratos foram respeitados, as verificações de segurança foram executadas e os critérios de aceitação foram satisfeitos.

Em outras palavras, não queremos apenas código. Queremos evidências de que podemos confiar naquele código.

A Pergunta Que Deve Vir Antes do Prompt

Antes de delegar uma tarefa significativa para um Agente de IA, vale fazer uma pergunta simples:

“Se a IA me entregar esta implementação daqui a alguns minutos, como vou determinar que ela está correta?”

Se a única resposta for “vou ler todo o código e ver se parece certo”, provavelmente ainda falta trabalho na especificação e no processo de validação.

Na era da IA, produzir código está ficando cada vez mais fácil. O desafio passa a ser construir processos capazes de produzir confiança na mesma velocidade.

E, em Engenharia de Software, confiança não deveria ser apenas uma impressão. Deveria ser sustentada por evidências.

Talvez, portanto, antes de perguntar “como faço a IA construir isso?”, seja melhor perguntar:

“Como vou provar que aquilo que ela construir está correto?”

Ensinamos SDD e construção de sistemas com assistentes de programação na prática, passo a passo e de forma profissional aqui:

Formação AI Software Engineer 4.0

Formação Agentic BI 4.0

Formação Forward Deployed Engineer 4.0

Formação Generative AI Engineer 4.0

Se quiser compreender o que é SDD, temos uma série completa aqui mesmo no Blog da DSA:

Spec-Driven Development: A Nova Arquitetura de Engenharia de Software na Era dos Agentes de IA

Equipe DSA