A IA pode acelerar o trabalho de backend, mas velocidade não é a parte difícil. Difícil é manter o sistema compreensível depois que o código entra. Um backend não quebra porque alguém escreveu uma função devagar. Quebra porque as fronteiras ficam borradas, os contratos viram conhecimento tácito, os testes protegem o comportamento errado e ninguém sabe explicar por que a arquitetura mudou.
Este é o guia que eu uso para tratar a IA como alavanca de engenharia sem deixar que ela vire um atalho por cima da arquitetura.
O problema
Desenvolver com IA muda o custo de escrever código. Não muda o custo de manter esse código. Um backend continua precisando de contratos estáveis, dono claro para cada dado, falhas observáveis e decisões que alguém consiga revisar.
A pergunta não é se a IA consegue gerar um repositório, um endpoint, uma migration ou um teste. É se a mudança gerada respeita as restrições de design que vão manter o sistema operável daqui a seis meses.
Onde os times costumam errar
O erro mais comum é entregar para a IA uma tarefa descrita como implementação, e não como um conjunto de restrições. O time pede uma feature, uma refatoração ou uma suíte de testes antes de dizer qual é a fronteira, quem é dono de quê, o que está fora do escopo, como a mudança pode falhar e com que critério ela vai ser revisada.
Na demo parece produtivo. Em produção sai caro: lógica de domínio duplicada, interfaces de serviço vazando detalhe interno, mocks para todo lado, testes gerados que verificam detalhe de implementação e um código difícil de revisar porque o raciocínio por trás dele nunca foi escrito.
Princípios
- As restrições de arquitetura vêm antes da geração de código.
- O que a IA produz é rascunho, não decisão.
- Na revisão, fronteiras merecem mais atenção do que sintaxe.
- Testes existem para proteger contratos e riscos, não a estrutura que foi gerada.
- Toda mudança feita com IA precisa de uma justificativa que uma pessoa consiga ler: por que esse design é aceitável.
Modelo de decisão
Antes de usar IA num trabalho de backend, escreva o enquadramento da decisão:
- Que fronteira a mudança pode tocar.
- Que fronteira ela não pode atravessar.
- Que contrato precisa continuar estável.
- Que comportamento precisa ficar mais fácil de testar.
- Que tipo de falha tornaria a mudança insegura.
- Que pergunta o PR final precisa responder na revisão.
A IA só recebe instruções de implementação depois que esse enquadramento existe. O prompt deve trazer as restrições, os arquivos existentes, os padrões já aceitos e os critérios de revisão por escrito.
Padrões práticos
Use IA para o primeiro rascunho de adapters, mapeamento de request/response, esqueleto de migrations, testes repetitivos, documentação e comparação de tradeoffs.
Não trate a IA como palavra final sobre fronteiras de domínio, dono da persistência, contratos entre serviços, comportamento sensível a segurança, semântica de concorrência ou estratégia de rollback em produção.
Peça diffs pequenos. Revise cada mudança gerada nesta ordem: primeiro as fronteiras, depois o comportamento e só então o código.
Tradeoffs
A IA rende mais quando o formato do trabalho já está bem delimitado. Rende menos quando o time ainda está decidindo o que o sistema deve significar.
Usar IA cedo ajuda a levantar opções rápido, mas também pode dar uma confiança que não se sustenta. Usar IA depois de definir o design é mais lento no começo, só que produz mudanças mais fáceis de revisar, testar e manter.
O meio-termo pragmático é explorar com IA em notas descartáveis e depois recomeçar, já com as restrições explícitas, antes de escrever código de produção.
Fluxo de exemplo
- Escreva um enquadramento curto de arquitetura para a mudança.
- Peça para a IA apontar riscos, restrições que faltam e prováveis violações de fronteira.
- Revise o enquadramento.
- Peça um plano mínimo de implementação, limitado aos arquivos aprovados.
- Gere ou edite uma fatia de cada vez.
- Depois de cada fatia, rode os testes e leia o diff.
- Peça para a IA revisar o diff final contra as restrições originais.
- Reescreva a descrição do PR de um jeito que uma pessoa entenda.
Checklist
- A fronteira tocada tem nome.
- As fronteiras que não foram tocadas também têm nome.
- O contrato protegido está explícito.
- Os testes verificam o comportamento que importa para quem consome o serviço.
- O código gerado segue os padrões do projeto.
- O PR explica por que esse design é aceitável.
- Quem revisa consegue rejeitar a arquitetura sem ler linha por linha.
Guias relacionados
- Como desenhar fronteiras de backend que aguentam a pressão de produção
- Como eu tomo decisões de arquitetura sem fingir certeza
- Práticas de teste e entrega que protegem o ritmo do time
Leve isto para o seu time
Este tema funciona bem como workshop interno para times que estão adotando desenvolvimento com IA. O que se leva dele não é uma biblioteca de prompts. É um fluxo de engenharia repetível, que deixa o time andar mais rápido sem perder a revisão de arquitetura, a clareza sobre quem é dono de quê e a disciplina de produção.