Todo time de engenharia que eu converso est\u00e1 usando IA. Ningu\u00e9m debate mais isso.<\/p>\n\n\n\n
O que ningu\u00e9m est\u00e1 falando \u00e9 que cada dev no mesmo time est\u00e1 usando de um jeito diferente.<\/p>\n\n\n\n
Dez devs. Dez setups diferentes. Dez arquivos de regras diferentes. Dez h\u00e1bitos de prompting diferentes. Mesmo codebase, mesmos tickets, mesmo sprint – dez abordagens diferentes de como a IA toca no c\u00f3digo.<\/p>\n\n\n\n
Um dev tem um CLAUDE.md meticuloso com decis\u00f5es de arquitetura, conven\u00e7\u00f5es de teste e regras de estilo de c\u00f3digo. O dev do lado n\u00e3o tem nada – s\u00f3 intui\u00e7\u00e3o e uma context window em branco. Os dois entregam c\u00f3digo. Os dois passam no review. A inconsist\u00eancia \u00e9 invis\u00edvel at\u00e9 que deixa de ser.<\/p>\n\n\n\n
A IA n\u00e3o criou esse problema. Ela amplificou o que j\u00e1 estava quebrado: a falta de padr\u00f5es compartilhados de engenharia que s\u00e3o realmente aplicados.<\/p>\n\n\n\n
Zero visibilidade.<\/strong> Voc\u00ea n\u00e3o sabe como seu time usa IA. Quem segue boas pr\u00e1ticas. Quem n\u00e3o segue. O que \u00e9 revisado. O que vai pra produ\u00e7\u00e3o no escuro. Engineering managers t\u00eam dashboards pra frequ\u00eancia de deploy, cobertura de testes, cycle time de PR – mas zero visibilidade sobre como a IA est\u00e1 moldando o c\u00f3digo que o time escreve todo dia.<\/p>\n\n\n\n Zero consist\u00eancia.<\/strong> Mesmo ticket, dez abordagens diferentes. Um dev pede pra IA escrever testes primeiro. Outro pula testes e pede a implementa\u00e7\u00e3o. Um terceiro d\u00e1 todo o contexto arquitetural pra IA. Um quarto n\u00e3o d\u00e1 nada. O output varia absurdamente – n\u00e3o porque a IA \u00e9 inconsistente, mas porque os humanos s\u00e3o.<\/p>\n\n\n\n E n\u00e3o \u00e9 s\u00f3 sobre c\u00f3digo diferente. \u00c9 sobre onde no codebase a mudan\u00e7a acontece, qual deveria ser o escopo, por que essa abordagem e n\u00e3o outra. Tem mil jeitos de resolver o mesmo problema. A IA vai executar qualquer um deles com a mesma confian\u00e7a. Sem um padr\u00e3o compartilhado de como o time toma essas decis\u00f5es, cada PR gerada por IA vira um peso no review. Algu\u00e9m precisa desfazer, refazer ou remodelar um trabalho que estava tecnicamente correto mas arquiteturalmente errado. Isso \u00e9 retrabalho em escala, e se acumula r\u00e1pido.<\/p>\n\n\n\n Conhecimento vai embora.<\/strong> Quando um dev sai, o contexto dele, os padr\u00f5es, os atalhos, saem junto. As regras que ele construiu, os prompts que refinou, as decis\u00f5es arquiteturais que codificou no setup local – tudo vai embora. O pr\u00f3ximo contratado come\u00e7a do zero. Isso j\u00e1 era problema antes da IA. Agora \u00e9 pior, porque a quantidade de conhecimento impl\u00edcito no setup de IA de um dev \u00e9 massiva e completamente n\u00e3o-documentada.<\/p>\n\n\n\n A rea\u00e7\u00e3o \u00f3bvia \u00e9 “s\u00f3 crie um arquivo de regras compartilhado”. \u00c9 por a\u00ed que a maioria dos times come\u00e7a. E tamb\u00e9m onde a maioria dos times para.<\/p>\n\n\n\n Um arquivo de regras compartilhado num repo resolve o problema de formato, mas n\u00e3o o problema de enforcement. Ningu\u00e9m checa se os devs realmente usam. Ningu\u00e9m sabe se est\u00e1 atualizado. Ningu\u00e9m sabe se o dev que entrou m\u00eas passado sequer sabe que o arquivo existe.<\/p>\n\n\n\n E regras s\u00e3o s\u00f3 o come\u00e7o. E quanto a quais modelos s\u00e3o aprovados? E quais fases do trabalho deveriam usar IA e quais n\u00e3o? E o custo? E as decis\u00f5es arquiteturais que deveriam restringir como a IA gera c\u00f3digo no seu codebase espec\u00edfico?<\/p>\n\n\n\n Padronizar IA num time de engenharia n\u00e3o \u00e9 um arquivo. \u00c9 um sistema. E a maioria dos times n\u00e3o tem um.<\/p>\n\n\n\n Eu penso nisso em tr\u00eas camadas:<\/p>\n\n\n\n Camada 1: Contexto compartilhado.<\/strong> Todo dev trabalhando no mesmo codebase deveria come\u00e7ar com o mesmo contexto base. Decis\u00f5es de arquitetura, conven\u00e7\u00f5es de c\u00f3digo, estrat\u00e9gia de testes, regras de depend\u00eancia – isso n\u00e3o \u00e9 opcional, e n\u00e3o deveria depender de setup individual. Se seus ADRs existem mas s\u00f3 duas pessoas sabem onde est\u00e3o, eles n\u00e3o existem.<\/p>\n\n\n\n Camada 2: Guardrails.<\/strong> Nem tudo deveria ser delegado pra IA. Algumas decis\u00f5es exigem julgamento humano. Alguns caminhos de c\u00f3digo s\u00e3o cr\u00edticos demais pra gera\u00e7\u00e3o sem supervis\u00e3o. O time precisa definir onde a IA adiciona valor e onde adiciona risco – e aplicar essa distin\u00e7\u00e3o, n\u00e3o s\u00f3 documentar.<\/p>\n\n\n\n Camada 3: Visibilidade.<\/strong> Voc\u00ea precisa saber o que est\u00e1 acontecendo. N\u00e3o vigil\u00e2ncia – sinal. Quais partes do codebase s\u00e3o tocadas pela IA. Quais padr\u00f5es est\u00e3o emergindo. Onde est\u00e3o as inconsist\u00eancias. Sem isso, voc\u00ea est\u00e1 gerenciando um processo que n\u00e3o consegue ver.<\/p>\n\n\n\n A maioria dos times n\u00e3o tem nenhuma dessas camadas. Alguns t\u00eam uma Camada 1 parcial. Quase ningu\u00e9m tem Camada 2 ou 3.<\/p>\n\n\n\n O que eu acho que a maioria das pessoas n\u00e3o percebe: a vantagem competitiva da IA em engenharia n\u00e3o \u00e9 velocidade. Velocidade \u00e9 table stakes. Todo mundo fica mais r\u00e1pido.<\/p>\n\n\n\n A vantagem est\u00e1 em qu\u00e3o consistentemente e confiavelmente voc\u00ea usa ela em todo o time. O time que entrega r\u00e1pido com padr\u00f5es compartilhados vai superar o time que entrega r\u00e1pido com dez abordagens diferentes – porque o segundo time est\u00e1 acumulando inconsist\u00eancia invis\u00edvel que se comp\u00f5e ao longo do tempo.<\/p>\n\n\n\n Caos mais r\u00e1pido continua sendo caos. S\u00f3 demora mais pra perceber.<\/p>\n\n\n\n N\u00e3o estou vendendo solu\u00e7\u00e3o aqui. Estou descrevendo um problema que vejo em todo lugar e que acho subexplorado.<\/p>\n\n\n\n A ind\u00fastria passou os \u00faltimos dois anos falando sobre adotar IA. A pr\u00f3xima conversa precisa ser sobre governar ela. N\u00e3o de um jeito burocr\u00e1tico e pesado de compliance – de um jeito pr\u00e1tico, engineering-first. Contexto compartilhado, guardrails claros, visibilidade b\u00e1sica.<\/p>\n\n\n\n Todo time que adotou IA sem padronizar est\u00e1 rodando um experimento sem controles. Alguns desses experimentos v\u00e3o dar certo. Alguns n\u00e3o. Os que n\u00e3o derem v\u00e3o ser muito caros de consertar – porque a d\u00edvida t\u00e9cnica de uso inconsistente de IA \u00e9 invis\u00edvel at\u00e9 ser sist\u00eamica.<\/p>\n\n\n\n A pergunta n\u00e3o \u00e9 se seu time deveria usar IA. \u00c9 se todos deveriam usar da mesma forma.<\/p>\n\n\n\n Acho que a resposta \u00e9 \u00f3bvia.<\/p>\n","protected":false},"excerpt":{"rendered":" Todo time de engenharia que eu converso est\u00e1 usando IA. Ningu\u00e9m debate mais isso. O que ningu\u00e9m est\u00e1 falando \u00e9 que cada dev no mesmo time est\u00e1 usando de um jeito diferente. O problema que ningu\u00e9m admite Dez devs. Dez setups diferentes. Dez arquivos de regras diferentes. Dez h\u00e1bitos de prompting diferentes. Mesmo codebase, mesmos […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-521","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"yoast_head":"\nPor que isso \u00e9 mais dif\u00edcil do que parece<\/h2>\n\n\n\n
O que realmente precisa acontecer<\/h2>\n\n\n\n
A vantagem competitiva real<\/h2>\n\n\n\n
Isso n\u00e3o \u00e9 sobre ferramentas<\/h2>\n\n\n\n