Quando a AI escreve o código, o trabalho do engenheiro muda de lugar

O contrato aceitava INACTIVE como status de um cliente. Pedi a uma AI que propusesse como incluir um cliente inativo em uma API Mule de laboratório. A resposta foi devolver 200 com o novo cliente, dentro do formato previsto pelo RAML. Parecia uma mudança simples e consistente. Mas o contrato não dizia se um cliente inativo deveria aparecer naquela consulta.

A AI percebeu essa lacuna e a registrou como uma suposição. Esse é o ponto mais interessante do exercício: ela não entregou uma resposta absurda. Entregou uma resposta plausível para uma pergunta que eu ainda não tinha fechado. O esquema dizia como representar INACTIVE; não dizia qual comportamento o negócio esperava.

A decisão revelou um erro que já estava lá

Decidi que, nessa API, um cliente inativo deve produzir um erro de negócio. Aplico nos meus projetos e exemplos uma convenção que reserva 400 para erros de negócio, 404 para uma rota inexistente e 500 para falhas de sistema. É uma escolha de contrato, não a única semântica HTTP possível: outra API poderia usar 404 para um recurso não encontrado. Aqui, separar erro de domínio de erro de roteamento mantém a distinção que quero oferecer aos consumidores.

Ao aplicar essa regra, encontrei um problema anterior à proposta da AI. A versão inicial devolvia 404 para um identificador válido sem cliente correspondente. Corrigi esse caso para 400 junto com o novo caso do cliente inativo. A tarefa era adicionar CUST-002; a decisão de contrato exigiu revisar também CUST-999, que já existia nos testes. O trabalho mudou de lugar: antes de escrever o novo ramo do fluxo, precisei definir a regra e encontrar os comportamentos existentes que ela afetava.

O registro da proposta guarda o que a AI sugeriu antes da mudança. O registro do experimento mostra a decisão, a revisão e os resultados. No exercício, a AI fez uma proposta somente de leitura e apontou a ambiguidade. Eu defini a regra; depois, o contrato, o código e os testes foram alterados.

Seis casos MUnit parametrizados passaram. Entre eles estão o cliente inativo CUST-002 e o cliente desconhecido CUST-999, ambos com 400, além da falha de sistema com 500. Isso confirma o comportamento do handler nesses cenários. Os testes não exercitam o listener nem o roteamento HTTP; a resposta de ponta a ponta para uma rota inexistente ainda precisa ser verificada. O tutorial na wiki guarda os passos para reproduzir e examinar essa evidência.

Onde cada um entra

Posso usar a AI para investigar o contrato, encontrar perguntas ausentes, propor caminhos, escrever código e sugerir testes. Neste exercício, ela propôs o 200 e apontou a dúvida sobre a visibilidade do cliente inativo.

Meu papel começa antes de aceitar uma proposta: entender o problema com quem responde pelo produto, escolher a regra que vale para esta API e explicitar suas consequências. Continua depois: conferir o diff, selecionar casos que possam contrariar a solução e decidir se a evidência basta para entregar. A AI pode ajudar em cada uma dessas tarefas, mas a decisão de aceitar o comportamento e seus riscos continua com as pessoas responsáveis pelo sistema. O guia de revisão de código gerado por AI do GitHub também orienta verificar testes, contexto e intenção, além do código em si.

Velocidade sem a regra certa

Uso a AI como assistente para transformar uma ideia em uma primeira versão que posso testar e melhorar. Para mim, esse é o valor da velocidade: experimentar uma proposta cedo, enquanto ainda posso mudar de direção.

Essa agilidade só vira valor quando a solução atende à regra certa. No meu exercício, a AI tornou visível uma lacuna do requisito; se eu tivesse aceitado o 200 apenas porque cabia no RAML, teria levado a lacuna para o código. O relatório DORA de 2025 descreve a AI como um amplificador das práticas de uma organização. É uma boa forma de ler o episódio: a ferramenta acelerou uma interpretação possível, enquanto a qualidade da decisão dependia do processo ao redor dela.

O que pude observar foi onde uma proposta plausível exigiu julgamento: a regra faltava no requisito, e fechá-la revelou um erro que já existia. Quando a primeira versão do código fica mais fácil de produzir, o engenheiro precisa ser ainda melhor em dizer o que ela deve fazer, como verificar isso e pelo que está disposto a responder.