Seu time entrega código com quatro ferramentas de IA diferentes. Talvez cinco. O cara do backend jura por Claude Code, a galera do frontend vive no Cursor, o estagiário descobriu o GitHub Copilot na faculdade e nunca mais largou, e alguém da engenharia de plataforma instalou o JetBrains AI na surdina. Todo mundo é produtivo. O código compila. O CI passa. Ninguém questiona o arranjo.

Mas o negócio é o seguinte: sua codebase agora parece um romance escrito por quatro ghostwriters que nunca se conheceram. Cada frase está gramaticalmente correta. O livro, como um todo, não faz sentido nenhum.

A divisão agora é oficial

Em 10 de abril de 2026, a JetBrains publicou sua pesquisa AI Pulse — mais de 10.000 devs profissionais, oito linguagens de programação, ponderação estatística. O número que importa aqui: Copilot com 29%, Claude Code e Cursor empatados com 18%, JetBrains AI com 11%. Noventa por cento dos desenvolvedores usam pelo menos uma ferramenta de IA no trabalho.

Isso não é uma ferramenta ganhando. São todas ganhando dentro da mesma organização.

E aqui é onde fica interessante: cada ferramenta trouxe seu próprio arquivo de instruções — um documento de configuração que diz à IA como escrever código pro seu projeto específico. Claude Code lê CLAUDE.md. Copilot lê copilot-instructions.md. Cursor lê .cursor/rules/*.mdc. O Codex CLI da OpenAI lê AGENTS.md (agora sob a Linux Foundation, adotado por mais de 60.000 projetos open-source). Windsurf lê .windsurf/rules/*.md. Gemini CLI lê GEMINI.md.

Seis ferramentas. Seis formatos de config. Cada uma ignora silenciosamente as outras. Como o TokenCentric observou numa comparação de março de 2026: "Um desenvolvedor trabalhando em cinco projetos com três ferramentas de IA pode estar mantendo quinze arquivos de configuração."

Como quatro IAs escrevem quatro codebases diferentes

Cada IA tem uma personalidade. Claude Code favorece tratamento explícito de erros e composição funcional — funções pequenas, tipos claros, verboso mas previsível. Copilot espelha a média estatística do GitHub — ele escreve código do jeito que a maioria do código open-source parece, o que significa mediano em todos os sentidos. Cursor alterna automaticamente entre modelos (Claude, GPT, seus próprios fine-tunes), misturando estilos no meio de um pull request dependendo de qual modelo cuidou de qual arquivo.

Nada disso está errado. Esse é o problema. Um linter — ferramenta que verifica violações de estilo no código — pega typos e formatação. Ele não pega o fato de que seu serviço de autenticação trata erros com blocos try-catch, seu serviço de pagamento usa Result types, e seu serviço de notificação retorna null. Três abordagens, todas válidas, todas passando no CI (Integração Contínua — testes automatizados que rodam antes do código ser mergeado), todas criando uma codebase que ninguém consegue navegar sem um mapa.

O estudo em larga escala mais recente sobre qualidade de código IA — o relatório de dezembro de 2025 da CodeRabbit, ainda os melhores dados disponíveis quatro meses depois — quantificou o estrago em 470 pull requests do GitHub: código gerado por IA teve 1,7× mais problemas no geral, 3× mais problemas de legibilidade e 2,66× mais inconsistências de formatação do que código humano. E isso mediu a saída de uma única ferramenta. Codebases multi-ferramenta empilham essas inconsistências umas sobre as outras.

O momento de iluminação que ninguém queria

O resultado não são bugs. Bugs são encontráveis. O resultado é incoerência arquitetural — um termo que Martin Fowler circundou em 7 de abril de 2026 no seu ensaio sobre "harness engineering", onde definiu a equação: Agent = Model + Harness. O harness é tudo que envolve o modelo de IA — os arquivos de config, as guardrails, as instruções. Fowler admitiu: "Ainda temos muito a fazer para descobrir bons harnesses para comportamento funcional."

Tradução: ninguém resolveu isso ainda.

Greg Foster, CTO da Graphite, colocou de outro jeito num post no Stack Overflow de 26 de março: engenheiros humanos "absorvem implicitamente o contexto da codebase" enquanto codam. Eles percebem que o resto do serviço usa Result types, então usam Result types também. Agentes de IA não absorvem nada — seguem o que o arquivo de config manda, ou pior, o que os dados de treino sugerem.

O preço da bagunça

Nenhuma ferramenta existente pega isso. ESLint verifica sintaxe. Prettier verifica formatação. Code review pega bugs. Nenhuma delas sinaliza "esse arquivo foi claramente escrito por uma IA diferente da que escreveu o arquivo ao lado".

E não espere que os vendors resolvam isso voluntariamente. Se o Cursor tornasse suas regras compatíveis com a config do Claude Code, facilitaria a troca de ferramenta. Fragmentação é um fosso competitivo, mesmo que acidental.

Projetos da comunidade estão tentando compensar. O rule-porter, que apareceu no GitHub em fevereiro de 2026, converte entre formatos de config; o rulesync, surgido na mesma época, tenta unificá-los. Ambos reportam taxas de conversão limpa de aproximadamente 75%. Os 25% restantes são onde mora a intenção arquitetural, e ela se perde na tradução.

Addy Osmani, do Google, alertou em fevereiro de 2026: "Quanto mais limpa sua arquitetura, menos a IA alucina abstrações bizarras." O inverso também é verdade: quanto mais bagunçada sua codebase multi-IA, mais estranha cada contribuição subsequente da IA se torna. Entropia se acumula.

O que fazer a respeito

Se seu time roda múltiplas ferramentas de IA — e estatisticamente, roda — você precisa de uma coisa: um documento de estilo único e agnóstico de ferramenta que toda IA leia. Não seis arquivos de config. Uma fonte canônica de verdade sobre como sua codebase trata erros, estrutura APIs, nomeia coisas e organiza dependências. Depois, um pre-commit hook — uma verificação automatizada que roda antes do código ser salvo — que imponha esses padrões independentemente de qual IA escreveu o código.

O padrão AGENTS.md, agora sob a Linux Foundation, é o mais próximo de um formato universal. Não é perfeito, mas é o único com apoio cross-vendor.

O novo normal

Sua codebase agora tem mais autores IA do que humanos. Andrej Karpathy disse sem rodeios lá em 26 de janeiro de 2026: "Você não está escrevendo código diretamente 99% do tempo… você está orquestrando agentes." Beleza. Mas orquestras precisam de um maestro, e precisam de uma partitura. Agora, a maioria dos times tem quatro músicos tocando de quatro partituras diferentes em quatro tonalidades diferentes — e a plateia ouve "compila" e assume que é música.

Alguém precisa escrever a política editorial antes que o repositório escreva uma por você. E não vai ser bonita.