Agentes de código tropeçam em sistemas legados sem domínio definido

O autor usa LLMs há anos em engenharia de software: funcionam bem em projetos greenfield e pequenos, mas a qualidade cai acentuadamente em bases legadas, com dependências pesadas, forte acoplamento e dívida técnica. Em um repositório novo, pedir um campo de "status da oferta de emprego" funciona; em um sistema que roda há quatro anos, o modelo inventa a quarta grafia de um conceito que já existe três vezes, porque o código nunca decidiu qual é a real. Sob a profundidade técnica há uma segunda camada, a da linguagem ausente: "o modelo não é o que precisa de atualização. O código não está pronto", e essa prontidão se constrói aos poucos.

Decidir ficou caro; digitar ficou barato

À dívida técnica costuma-se reservar 10% a 20% do orçamento de tecnologia. Esse quinto sempre pagou duas metades: decidir o que mudar e digitar a mudança. A primeira continua cara; a segunda desabou, porque o LLM faz a parte mecânica de uma limpeza (um módulo extraído, mais testes) a um custo que não se parece mais com o de 2020. O que sobra é decidir.

Ele empresta de A Philosophy of Software Design, de John Ousterhout - admitindo distorcer os termos - a dupla estratégico e tático, aplicada à autoria: o estratégico lê o sistema e apura o que deve mudar e por quê; o tático leva a decisão aos arquivos.

Issues, skills e sub-agentes

Ele se envolve por completo na metade estratégica; na tática, é mais revisor do que implementador. Ele cria issues no GitHub após analisar a base, e um sistema de IA as executa com skills e sub-agentes: a skill é um procedimento em markdown carregado quando a tarefa corresponde a ela, para que "resolver uma issue" rode sempre igual; o sub-agente é uma sessão separada, com contexto fresco e função estreita, que devolve um resultado em vez de despejar a transcrição inteira. Dos PRs, ele revisa, aceita ou pede ajustes.

DDD como fundamento

A metade estratégica vale o que vale a linguagem em que está escrita, e aí entra o DDD: a abordagem de Eric Evans, com linguagem ubíqua e bounded contexts, aproximou negócio e técnica; com agentes no circuito, é esse elo que declara necessidades ao modelo e traz o raciocínio de volta.

Cada repositório dele tem um .workflow., manifesto que informa linguagens, diretórios prioritários de leitura e verificações obrigatórias; um bloco nele declara o domínio: bounded contexts, onde vive o glossário de cada contexto e cada aresta com o vizinho. Cada contexto tem ainda um CONTEXT.md, glossário com o significado preciso de cada termo e os sinônimos rejeitados; o mapa de contextos é derivado - um gerador emite um CONTEXT-MAP.md regenerável.

No job-offer-box (backend Rust e frontend web), o backend é dono da linguagem de produto: quando dois contextos criam o mesmo termo, fica com quem detém o estado durável. O frontend é dono só do vocabulário de tela e marca o resto [published], chegando como TypeScript gerado do OpenAPI do backend - o agente sabe que renomear Job Offer no frontend pertence ao backend e quais palavras pode inventar.

A divergência vira issue

Cada aresta é declarada duas vezes, uma por lado - o gerador cruza os pares. A checagem roda como skill em três momentos: ao tocar um manifesto, ao integrar um repositório e antes de mudar algo de que outro contexto depende. Cada divergência é um finding; a skill abre uma issue DDD no repositório do lado errado, com uma fingerprint (tipo de finding mais os dois endereços), e uma reexecução atualiza a mesma issue em vez de abrir outra.

O que vem a seguir

A camada estratégica está de pé: define as fronteiras de um contexto e como ele conversa com os vizinhos; por dentro, cada contexto ainda é código comum. O próximo passo é migrar um contexto por vez a um modelo de domínio real com primitivas de DDD (value objects, aggregates, domain services), para que o código responda o que hoje o modelo adivinha: o que uma palavra significa, quem é o dono, onde o contexto para. Ele promete divulgar o sistema completo.