Todo time de engenharia que eu converso está usando IA. Ninguém debate mais isso.

O que ninguém está falando é que cada dev no mesmo time está usando de um jeito diferente.

O problema que ninguém admite

Dez devs. Dez setups diferentes. Dez arquivos de regras diferentes. Dez hábitos de prompting diferentes. Mesmo codebase, mesmos tickets, mesmo sprint – dez abordagens diferentes de como a IA toca no código.

Um dev tem um CLAUDE.md meticuloso com decisões de arquitetura, convenções de teste e regras de estilo de código. O dev do lado não tem nada – só intuição e uma context window em branco. Os dois entregam código. Os dois passam no review. A inconsistência é invisível até que deixa de ser.

A IA não criou esse problema. Ela amplificou o que já estava quebrado: a falta de padrões compartilhados de engenharia que são realmente aplicados.

Três coisas que quebram

Zero visibilidade. Você não sabe como seu time usa IA. Quem segue boas práticas. Quem não segue. O que é revisado. O que vai pra produção no escuro. Engineering managers têm dashboards pra frequência de deploy, cobertura de testes, cycle time de PR – mas zero visibilidade sobre como a IA está moldando o código que o time escreve todo dia.

Zero consistência. Mesmo ticket, dez abordagens diferentes. Um dev pede pra IA escrever testes primeiro. Outro pula testes e pede a implementação. Um terceiro dá todo o contexto arquitetural pra IA. Um quarto não dá nada. O output varia absurdamente – não porque a IA é inconsistente, mas porque os humanos são.

E não é só sobre código diferente. É sobre onde no codebase a mudança acontece, qual deveria ser o escopo, por que essa abordagem e não outra. Tem mil jeitos de resolver o mesmo problema. A IA vai executar qualquer um deles com a mesma confiança. Sem um padrão compartilhado de como o time toma essas decisões, cada PR gerada por IA vira um peso no review. Alguém precisa desfazer, refazer ou remodelar um trabalho que estava tecnicamente correto mas arquiteturalmente errado. Isso é retrabalho em escala, e se acumula rápido.

Conhecimento vai embora. Quando um dev sai, o contexto dele, os padrões, os atalhos, saem junto. As regras que ele construiu, os prompts que refinou, as decisões arquiteturais que codificou no setup local – tudo vai embora. O próximo contratado começa do zero. Isso já era problema antes da IA. Agora é pior, porque a quantidade de conhecimento implícito no setup de IA de um dev é massiva e completamente não-documentada.

Por que isso é mais difícil do que parece

A reação óbvia é “só crie um arquivo de regras compartilhado”. É por aí que a maioria dos times começa. E também onde a maioria dos times para.

Um arquivo de regras compartilhado num repo resolve o problema de formato, mas não o problema de enforcement. Ninguém checa se os devs realmente usam. Ninguém sabe se está atualizado. Ninguém sabe se o dev que entrou mês passado sequer sabe que o arquivo existe.

E regras são só o começo. E quanto a quais modelos são aprovados? E quais fases do trabalho deveriam usar IA e quais não? E o custo? E as decisões arquiteturais que deveriam restringir como a IA gera código no seu codebase específico?

Padronizar IA num time de engenharia não é um arquivo. É um sistema. E a maioria dos times não tem um.

O que realmente precisa acontecer

Eu penso nisso em três camadas:

Camada 1: Contexto compartilhado. Todo dev trabalhando no mesmo codebase deveria começar com o mesmo contexto base. Decisões de arquitetura, convenções de código, estratégia de testes, regras de dependência – isso não é opcional, e não deveria depender de setup individual. Se seus ADRs existem mas só duas pessoas sabem onde estão, eles não existem.

Camada 2: Guardrails. Nem tudo deveria ser delegado pra IA. Algumas decisões exigem julgamento humano. Alguns caminhos de código são críticos demais pra geração sem supervisão. O time precisa definir onde a IA adiciona valor e onde adiciona risco – e aplicar essa distinção, não só documentar.

Camada 3: Visibilidade. Você precisa saber o que está acontecendo. Não vigilância – sinal. Quais partes do codebase são tocadas pela IA. Quais padrões estão emergindo. Onde estão as inconsistências. Sem isso, você está gerenciando um processo que não consegue ver.

A maioria dos times não tem nenhuma dessas camadas. Alguns têm uma Camada 1 parcial. Quase ninguém tem Camada 2 ou 3.

A vantagem competitiva real

O que eu acho que a maioria das pessoas não percebe: a vantagem competitiva da IA em engenharia não é velocidade. Velocidade é table stakes. Todo mundo fica mais rápido.

A vantagem está em quão consistentemente e confiavelmente você usa ela em todo o time. O time que entrega rápido com padrões compartilhados vai superar o time que entrega rápido com dez abordagens diferentes – porque o segundo time está acumulando inconsistência invisível que se compõe ao longo do tempo.

Caos mais rápido continua sendo caos. Só demora mais pra perceber.

Isso não é sobre ferramentas

Não estou vendendo solução aqui. Estou descrevendo um problema que vejo em todo lugar e que acho subexplorado.

A indústria passou os últimos dois anos falando sobre adotar IA. A próxima conversa precisa ser sobre governar ela. Não de um jeito burocrático e pesado de compliance – de um jeito prático, engineering-first. Contexto compartilhado, guardrails claros, visibilidade básica.

Todo time que adotou IA sem padronizar está rodando um experimento sem controles. Alguns desses experimentos vão dar certo. Alguns não. Os que não derem vão ser muito caros de consertar – porque a dívida técnica de uso inconsistente de IA é invisível até ser sistêmica.

A pergunta não é se seu time deveria usar IA. É se todos deveriam usar da mesma forma.

Acho que a resposta é óbvia.