Autor do Habr lista cinco decisões que o engenheiro toma antes do código gerado por AI

Um dos bugs mais incômodos na lógica de pagamentos parece inofensivo: verificar se a operação está com status PENDING, mudá-la para SUCCESS e creditar o saldo. Se dois webhooks chegam ao mesmo tempo, ambos enxergam PENDING, ambos passam na verificação, e o usuário recebe o dinheiro duas vezes. O autor de um material recente no Habr encontrou esse erro no próprio marketplace. Ele escreveu o código sozinho, sem AI.

Esse exemplo serve de base para a pergunta central: se hoje um agente implementa um processador desse tipo em minutos, quem define as restrições que não aparecem na descrição funcional? Em seguida, o autor analisa cinco situações de um marketplace e de uma plataforma multimarca e termina com um checklist de 12 perguntas que vale responder antes de gerar o código.

Onde a especificação não diz nada

O agente cumpre bem o que está descrito. A frase «ao receber um webhook de sucesso, creditar o saldo» é satisfeita formalmente tanto por uma implementação correta quanto por uma vulnerável. A diferença só aparece sob carga paralela e não é visível em testes de uma única thread.

Isso não é uma característica dos modelos de linguagem, e sim de qualquer especificação que omite requisitos não funcionais. Uma pessoa costuma preencher essa lacuna com experiência e com a lembrança de incidentes passados. O agente não tem de onde tirar esse contexto se ele não for informado de forma explícita.

O autor destaca cinco áreas em que essas decisões precisam ser tomadas com antecedência:

• idempotência de pagamentos: o que conta como requisição repetida e onde isso é garantido;
• migrações de dados: a ordem das alterações e o comportamento do sistema em estados intermediários;
• entrega de mensagens entre instâncias do serviço: o que acontece se o destinatário for o errado ou estiver indisponível;
• integrações com provedores: como o sistema se comporta diante de repetições, atrasos e respostas fora do padrão;
• arquitetura de marcas: o que é comum a todas as marcas da plataforma e o que é configurado separadamente.

O autor apresenta a lista completa das 12 perguntas no artigo original. Cabe uma ressalva: o anúncio não traz detalhes das soluções, então o que vem a seguir descreve como esses problemas costumam ser resolvidos no mercado, e não as conclusões do autor.

Como isso costuma ser resolvido

Para o caso dos webhooks, o conjunto de medidas típicas é conhecido. Uma chave única do evento ou uma chave de idempotência da requisição. Uma atualização condicional atômica do tipo «mudar para SUCCESS somente se o status ainda for PENDING», com verificação do número de linhas afetadas. Um bloqueio do registro durante a transação. Qualquer uma dessas medidas transforma o «verifiquei, depois gravei» em uma única operação indivisível.

Com migrações e mensagens, a lógica é parecida. As alterações de esquema precisam funcionar enquanto as versões antiga e nova do serviço convivem. A entrega precisa definir de antemão se perdas e duplicatas são aceitáveis. Essas decisões afetam a estrutura do código, e por isso tomá-las depois da geração já sai caro: será preciso reescrever, e não apenas acrescentar.

Como usar na prática

Ao entregar uma tarefa a um agente, vale anexar a ela um bloco curto de restrições. O que deve continuar verdadeiro em caso de chamada repetida? E em duas chamadas paralelas? E em caso de falha parcial de um provedor externo? E ao publicar uma nova versão ao lado da antiga?

Também é útil pedir ao agente que, além de escrever o código, liste as suposições que fez sobre concorrência e ordem dos eventos. A divergência entre as suposições dele e as suas é a forma mais rápida de revelar uma falha na especificação.

Por fim, os testes. Para os fluxos de pagamento, é necessário ao menos um teste com requisições simultâneas; do contrário, a verificação de correção fica no nível do «parece certo». Foi exatamente assim que o processador da história do autor se apresentava: a lógica parecia correta e só quebrava em uma condição de corrida.

As conclusões do material valem também para o código escrito por humanos. A AI acelera a implementação, mas as decisões sobre os invariantes do sistema continuam precisando ser tomadas antes dela, e quem as toma é o engenheiro.