Por décadas, boa parte das ferramentas de desenvolvimento serviu para uma coisa: escrever código mais rápido. IDEs, frameworks, geradores. A IA generativa levou isso adiante, e os agentes deram mais um passo: recebem um objetivo, planejam, usam ferramentas, executam e corrigem o rumo sozinhos.

Gerar código deixou de ser a etapa mais cara. Os problemas de fundo, porém, continuam os mesmos. Um agente pode implementar em minutos um requisito ambíguo, espalhar um padrão ruim por dezenas de arquivos ou repetir a mesma vulnerabilidade em todo o projeto. A capacidade de agir amplia tanto as boas práticas quanto as fragilidades do time.

Assistente não é agente

Autocomplete sugere a próxima linha. Um assistente responde a pedidos, um de cada vez. Um agente recebe um objetivo, divide o trabalho, usa ferramentas, observa o resultado e decide o próximo passo.

Autonomia não é liga-desliga. Um agente pode só sugerir um plano, editar arquivos com aprovação, rodar testes em ambiente isolado ou abrir um pull request. Cada degrau aumenta o benefício possível e o estrago de um erro. A regra que uso: quanto mais autonomia, mais preciso precisa ser o contexto, mais restritas as permissões e mais fortes as verificações independentes.

Duas formas de pedir a mesma coisa

Um exemplo simples mostra a diferença.

Pedido vago: “adicione o novo status ao cadastro”. O agente altera a enumeração, a tela e o banco. Só que não sabe quais transições são válidas, quem pode mudar o status, o que acontece com relatórios, integrações, auditoria e registros antigos. Compila, alguns testes passam, e a regra fica pela metade.

Tarefa com engenharia: a mesma mudança vem com a regra de negócio, os estados de origem e destino, quem pode fazer o quê, critérios de aceite, arquivos envolvidos, exigências de auditoria e testes obrigatórios. O agente encontra uma dúvida sobre registros históricos e pergunta antes de seguir, propõe um plano, faz uma migração reversível, cria testes e atualiza a documentação. O time revisa as evidências e decide.

O segundo resultado não depende de um modelo mais inteligente. Depende de um jeito de trabalhar que deixou intenção, limites e validação explícitos. Uma boa tarefa para um agente é também uma boa tarefa para uma pessoa.

O que entra numa boa tarefa

• O problema e a evidência que o sustenta.
• O comportamento esperado e os critérios de aceite.
• O que pode mudar e o que está fora do escopo.
• Restrições de segurança, dados, desempenho e compatibilidade.
• Os comandos de validação e o formato das evidências.
• Quando parar e pedir decisão humana.

Mais contexto não é contexto melhor. Jogar o repositório inteiro, documentos que se contradizem e instruções velhas só aumenta o ruído. O agente precisa das fontes certas e de saber qual delas manda quando houver divergência.

Confiança vem da evidência, não de quem escreveu

Código gerado por IA passa pelo mesmo sistema de qualidade que qualquer outro: compilação, análise estática, testes, revisão, análise de dependências. Um cuidado extra: o agente pode escrever os próprios testes, mas isso não é verificação independente. Código e teste podem nascer da mesma interpretação errada. Exemplos vindos do negócio, testes que já existiam e revisão humana diversificam a evidência.

Segurança também muda. Agentes leem conteúdo e usam ferramentas, então uma instrução maliciosa escondida em uma issue, um comentário ou uma dependência pode levá-los a vazar dados ou executar o que não deviam. Isolamento, menor privilégio, segredos protegidos e aprovação para operações críticas deixam de ser opcionais. Nenhum agente deveria receber uma credencial mais ampla do que a tarefa exige.

Produtividade não é linha de código

Mais código produzido pode significar mais revisão, mais manutenção e mais defeitos. O ganho real aparece no fluxo de entrega: tempo entre a demanda e o resultado, retrabalho, falhas depois de mudanças, estabilidade. A IA funciona como amplificador. Times com testes, documentação e arquitetura compreensível transformam velocidade em resultado. Times com requisitos ambíguos produzem mais mudanças difíceis de sustentar, só que mais rápido.

Por isso o papel do engenheiro não encolhe. Quando produzir fica barato, ganha valor quem sabe formular o problema, descobrir as regras, decompor o trabalho, verificar e responder pelo resultado. E quem sabe a hora de aceitar, corrigir, rejeitar ou interromper o que um agente fez.

Para ir além

O capítulo 19 do livro Engenharia de Software: Fundamentos e Práticas é dedicado a esse tema: engenharia de contexto, desenvolvimento orientado por especificações (Spec-Driven Development), avaliação de agentes, segurança com MCP, governança proporcional ao risco e o que muda quando o próprio produto usa IA.

Conheça o livro. E se a sua dúvida é como escrever uma tarefa clara, o artigo sobre requisito, regra de negócio e critério de aceite ajuda.