Radar Tech: o problema não é o código da IA, é ninguém saber mais qual é a arquitetura

O debate que mais movimentou as comunidades de engenharia nas últimas 24 horas não foi sobre um bug nem sobre um modelo novo. Foi sobre uma consequência silenciosa do código gerado por IA: ninguém sabe mais qual é a arquitetura do sistema — nem qual era a intenção original.

A tese central é desconfortável e simples. Durante anos, o gargalo era escrever código. Com agentes e copilotos, escrever ficou barato e rápido. Só que cada trecho gerado e aceito carrega uma microdecisão de arquitetura que ninguém discutiu, ninguém registrou e ninguém revisou. Somadas por meses, essas microdecisões formam uma arquitetura que ninguém escolheu — ela simplesmente emergiu.

O sintoma tem nome: fronteira fantasma

O padrão mais citado nos relatos é o da fronteira fantasma. As pastas e o discurso dizem que existem serviços separados; o código diz outra coisa. Um serviço que escreve direto na tabela de outro, um import cruzado que ninguém percebeu, uma dependência circular que "sempre funcionou". A separação existe no slide e no organograma do time, não no acoplamento real.

Quando isso acontece, a documentação para de descrever o sistema. O README descreve o sistema que o time quis; o repositório contém o sistema que existe. Entre os dois, há um desvio que cresce em silêncio até virar incidente — uma migração que quebra um consumidor inesperado, um refactor que derruba uma integração esquecida.

Por que ADRs importam mais agora, não menos

Se o código é gerado em volume, o que sobra como âncora é a decisão explícita. Um ADR (Architecture Decision Record) não documenta o código — documenta por que uma fronteira existe e o que não pode atravessá-la. É o contrato que permite dizer "isto está errado" sem depender da memória de quem escreveu.

A conclusão prática que emerge dos relatos: o time não precisa (e não deve) reescrever o sistema. Precisa reconstruir a intenção — auditar o código que existe, compará-lo com o que foi declarado, classificar os desvios e registrar de volta as decisões que ficaram implícitas.

O que dá para fazer amanhã

Uma auditoria de intenção arquitetural útil não exige ferramenta nova, exige disciplina:

• Inventariar evidências antes de concluir. Árvore de diretórios, manifestos, schema, contratos. Sem artefato, não há afirmação — há inferência, e inferência precisa ser marcada como tal.
• Separar declarado de observado. O ADR antigo é intenção declarada, não prova do que o código faz. Misturar os dois é o erro que produz laudos bonitos e falsos.
• Classificar cada desvio com critério. Alinhado, drift, violação ou lacuna. "Violação" só existe quando há uma decisão registrada sendo contrariada; sem registro, é lacuna — e a lacuna é o achado.
• Escrever o ADR de volta. Toda decisão que o código tomou por omissão merece um registro com status proposto. O modelo propõe; quem decide é o time.
• Priorizar por risco, não por facilidade. E nunca recomendar reescrita big-bang.

O ponto que amarra tudo: com IA escrevendo muito mais código, a arquitetura deixa de ser um artefato de design e passa a ser um artefato de auditoria. Quem mantém a intenção explícita mantém o controle. Quem terceiriza a intenção para o gerador de código descobre o problema no próximo incidente.

Publicamos hoje no catálogo o pacote Auditor de Intenção Arquitetural — um conjunto de 5 arquivos que leva um LLM a produzir esse laudo rastreável, com matriz de desvio, ADRs de reconstrução e plano de regularização. Ele usa exatamente a mesma lógica descrita aqui: evidência antes de afirmação, declaração separada de observação, decisão proposta e não imposta.