A maioria dos times está usando IA pra gerar legacy code mais rápido — e achando que está sendo produtivo · rafaelnicoleti

Vou compartilhar um problema que provavelmente você já viu no seu time — e a solução que construí e testei nos últimos meses.

O problema

O dev abre o Claude/Copilot e digita:

"cria um service de pagamento em Java"

Recebe isso:

@Service
public class PaymentService {
    public void processPayment(double amount) {
        // lógica genérica sem contexto
    }
}

Compila. Testes passam. Vai pro code review. É rejeitado.

Não sabe o que é autorização vs captura. Não tem idempotência. Não segue Hexagonal. Não fala a linguagem do domínio. O dev gastou mais tempo no ciclo gerar → revisar → rejeitar → refazer do que se tivesse escrito na mão.

Mas o problema real aparece em escala. Quando o time inteiro faz isso por 3 meses, o resultado é:

Domain model com anotações de JPA no meio das regras de negócio
Repository chamado direto na camada de apresentação
Serviço de autorização que conhece detalhes de persistência
Bounded contexts acoplados sem ninguém saber por quê

É legacy code gerado em velocidade de startup. A IA não errou — ela fez o melhor que podia com zero contexto.

Por que isso acontece

Observei um padrão nos times que acompanho como Head de Engenharia:

O dev sênior que entende o domínio gera código excelente com IA. O dev que não entende gera código que parece correto mas quebra em produção.

A IA não nivela o time. Amplifica a diferença que já existe.

E o motivo é simples: o conhecimento de domínio e as decisões arquiteturais vivem na cabeça de 2-3 pessoas. Cada dev passa o contexto pro chat da IA do seu jeito, toda vez, do zero. Não existe infraestrutura de conhecimento.

O modelo que construí

Em vez de treinar devs pra "promptar melhor", transformei o conhecimento em infraestrutura que a IA consome automaticamente:

1. Knowledge Base versionada no repositório

Não é Confluence. São arquivos Markdown do lado do código:

payment-domain.md — o que é autorização, captura, estorno. Quais estados um pagamento pode ter. Quais invariantes existem.
architecture-reference.md — Clean Architecture + Hexagonal. O que vai em cada camada. O que é proibido.
ubiquitous-language.md — a linguagem do domínio que todo código precisa falar.

A IA lê esses arquivos antes de gerar qualquer código. O contexto não depende de quem está digitando o prompt.

2. Skills especializadas

Instruções que codificam "como o time faz X":

Uma skill pra modelar domínio (aggregates, value objects, domain events)
Outra pra gerar adapters hexagonais (gateway, persistência, mensageria)
Outra pra code review (verifica se o código segue os padrões)

Cada skill tem o contexto certo pro problema certo. Não é um prompt genérico que tenta fazer tudo.

3. Agentes com domínio embutido

O agente já sabe que:

Autorização e captura são operações separadas
Idempotência não é opcional em pagamentos
Domain layer não tem dependência de framework
Toda transição de estado segue a state machine definida

O dev pede "implementa o use case de autorização" e o agente gera:

@RestController
public class PaymentController {
    private final AuthorizePaymentUseCase authorizePayment;

    @PostMapping("/payments")
    public PaymentResponse process(@RequestBody PaymentRequest request) {
        return authorizePayment.execute(
            AuthorizePaymentCommand.of(request)
        );
    }
}

Use case no controller, não repository. Porque o agente sabe que isso é proibido nesse contexto.

Resultado prático

Dev junior entra no time e, na primeira semana, gera código que respeita a arquitetura. Não porque ele sabe tudo — porque o contexto não depende dele.

O ciclo muda de:

~~abrir chat → explicar tudo → gerar → rejeitar → refazer~~

Para:

abrir chat com agente especializado → pedir → receber código dentro do padrão → review passa

O que documentei

Testei esse modelo com um sistema de referência chamado PayCore — plataforma de pagamentos com DDD + Clean Architecture + Hexagonal. Escolhi pagamentos porque não dá pra ser vago: autorização duplicada ou captura fora de sequência custa dinheiro real.

Documentei todo o modelo numa série de 7 volumes. Código real em Java. Zero pseudocódigo. Cada conceito construído capítulo a capítulo no mesmo sistema — do domínio modelado até o agente especializado rodando.

Se quiser ver: https://books-ia-first-eng.vercel.app/

Queria ouvir de vocês: como tá a experiência de usar IA no dia a dia do time? Cada dev passa o contexto do jeito dele? Montaram alguma estrutura? Ou é cada um por si e Deus por todos?