Só 33% dos desenvolvedores confiam nas respostas de IA: como fazer o agente trabalhar com base em especificações

"Vamos adotar IA e, em seis meses, metade do time não será necessária": o autor da análise publicada no Habr ouve esse tipo de afirmação com frequência demais de gestores. Eles imaginam que o agente recebe a tarefa em um único prompt, escreve o código, testa sozinho e faz o deploy, e que às pessoas só resta clicar em Merge. A realidade é outra.

Suponha que você peça ao agente para acelerar o processamento de reembolsos em uma loja. Ele remove uma leitura "desnecessária" repetida no banco de dados, os testes passam, mas, com requisições paralelas, o cliente recebe de volta mais dinheiro do que pagou. Aquela leitura protegia uma regra de negócio, e ninguém contou isso ao agente.

Por isso, na pesquisa Stack Overflow 2025, apenas 33% dos desenvolvedores confiam nas respostas de IA. O autor propõe uma solução: trabalhar com especificações (SDD, spec-driven development). Primeiro se descreve o que o código deve fazer; depois o código é escrito e verificado contra essa descrição.

Para isso, ele usa o framework OpenSpec.

Por que a demo engana

Na demo, o agente monta um CRUD ou acelera uma consulta SQL em cinco minutos. Esse tipo de tarefa não tem histórico, e é evidente como é o resultado correto. Em um sistema real, há integrações e regras que não estão registradas em lugar nenhum: o agente não sabe qual cliente lê aquele campo. O que falta, ele completa por conta própria, e o código fica plausível, mas não necessariamente correto.

Os números do Stack Overflow 2025 confirmam isso. 84% dos desenvolvedores usam ou pretendem usar IA, mas 33% confiam na precisão das respostas e 46% não confiam. A queixa mais comum, em 66% dos casos, é de soluções que estão quase certas, mas não totalmente; já 45% dizem que depurar código gerado leva mais tempo. Os autores do relatório DORA 2025 chamam a IA de amplificadora: nas equipes fortes, ela reforça os pontos fortes; nas fracas, os problemas.

Há um teste simples para gestores: antes de planejar cortes, conduzir com IA uma tarefa real da própria equipe do início ao fim, ou seja, projetar a funcionalidade, descrever os requisitos, obter o código, revisar e levar até a produção. Em poucos dias fica claro que a IA acelera o trabalho, mas decidir se o resultado está correto continua sendo tarefa de uma pessoa.

Especificações em vez de tickets de uma linha

Um ticket de uma linha o agente completa por conta própria; com uma especificação completa, com restrições e casos de borda, ele trabalha dentro de limites definidos. O GitHub Spec Kit, lançado em código aberto em setembro de 2025, segue uma abordagem parecida. Seu principal mantenedor, Manfred Riem, comparou o agente a um estagiário muito capaz e rápido, que precisa de um escopo técnico claro e de um mentor.

O OpenSpec é um framework leve: as especificações ficam no repositório, junto do código, em Markdown comum. Ele é compatível com mais de 30 ferramentas, incluindo Claude Code, Cursor e GitHub Copilot. A pasta openspec/ tem três partes: specs/ descreve como o sistema funciona hoje; changes/ guarda as mudanças propostas (proposal, design, tasks e deltas de requisitos); e config.yaml traz o contexto do projeto, que é repassado ao agente na criação dos artefatos.

Os requisitos são escritos com as palavras-chave SHALL/MUST e cenários GIVEN/WHEN/THEN. Por exemplo, em um reembolso parcial: a soma de todos os reembolsos de um pedido MUST NOT exceder o valor pago, e uma nova requisição com a mesma chave de idempotência não cria um segundo reembolso. O ciclo tem três comandos: /opsx:propose cria o plano, que é revisado antes de qualquer código ser escrito; /opsx:apply implementa as tarefas; /opsx:archive incorpora os deltas às especificações principais. A tarefa seguinte já começa com um retrato atualizado do sistema.

Contexto, invariantes e skills

O agente chega ao projeto toda vez como um novato no primeiro dia. Por isso, convém manter junto do código uma descrição do sistema: limites do produto, processos de negócio, pipelines de CI/CD, glossário e invariantes, isto é, regras que não podem ser violadas em nenhuma refatoração. Os invariantes são os mais subestimados, e daí vem a história dos reembolsos. O glossário resolve um problema parecido: o analista escreve "cancelamento", mas o código tem Refund, Reversal e Cancellation, e, sem um dicionário, o agente escolhe ao acaso. O autor sugere incluir a atualização do contexto na Definition of Done, ao lado dos testes.

Skills são instruções reutilizáveis, como "como fazemos uma migração aqui" ou "como revisamos um PR". A skill review-against-spec confronta cada cenário do delta com o código e os testes, verifica se os invariantes não foram enfraquecidos e devolve uma lista de divergências, sem fazer correções por conta própria. Diante do pedido "veja se está tudo certo", o agente costuma responder que sim; o checklist o obriga a procurar problemas. A palavra final na revisão continua sendo de uma pessoa.

Pessoas e o ciclo de bugs

Especificações não substituem competência: um júnior vê um código que compila e passa nos testes, enquanto um desenvolvedor experiente enxerga ali uma condição de corrida ou um invariante violado. Um sinal de alerta é o funcionário que serve apenas de intermediário: repassa o ticket ao agente e envia o resultado para revisão sem ler. Nesse caso, toda a verificação recai sobre o líder, que vira um gargalo.

Durante a adoção, é preciso um mentor com experiência em SDD: ele configura regras e skills e ensina o time a escrever especificações e a revisar código gerado por IA. O autor o compara a um scrum master: o papel é temporário, mas, sem ele, a metodologia se dissolve em um "mas nós já temos o Cursor".

O autor também alerta contra o antipadrão "uma pessoa, quatro papéis": analista de negócios, analista de sistemas, desenvolvedor e testador na mesma pessoa. Cada papel verifica os demais, e, sem treinamento e sem checagem externa, essas verificações desaparecem. E a IA implementa uma especificação fraca tão depressa quanto uma boa.

Sem processo, a cada bug em produção a equipe reescreve partes do sistema e gera novos bugs. A saída é, depois de cada erro, descobrir o que faltou ao agente: contexto, uma regra ou uma verificação na skill. O que faltava é escrito e passa por revisão, como um PR comum. Se apenas o código for corrigido, o agente repetirá o mesmo erro na próxima funcionalidade.