Todos Têm 30% de Código IA. Ninguém Sabe Quem Governa.

Gergely Orosz publicou na semana passada, no The Pragmatic Engineer, um raio-x detalhado de como a Uber usa IA no desenvolvimento. É o tipo de reportagem que Gergely faz melhor que qualquer outra newsletter de engenharia: acesso direto à empresa, dados internos, arquitetura real.

Os números de manchete são conhecidos. 31% do código da Uber é gerado por IA. 92% dos engenheiros usam ferramentas de IA pelo menos uma vez por mês. Custos com IA aumentaram 6 vezes desde 2024.

Mas o número que importa é outro: segundo o próprio CEO Dara Khosrowshahi, apenas 30% dos engenheiros são power users. O restante usa IA de maneira superficial. A adoção mensal é alta. O uso profundo, não.

Isso não diminui o que a Uber construiu. Torna mais interessante.

O Que a Uber Realmente Construiu

A Uber não deu Copilot para os engenheiros e declarou vitória. Construiu uma infraestrutura de governança em quatro camadas:

Camada 1: AI Platform (Michelangelo). A plataforma de machine learning que a Uber já mantinha. Serve como base para tudo que vem depois.

Camada 2: Contexto Interno. Ferramentas que alimentam os modelos com o contexto específico da Uber: repositórios, documentação, padrões de código, histórico de mudanças.

Camada 3: Agentes da Indústria. Claude Code, Copilot, Codex. Ferramentas externas que os engenheiros escolhem conforme sua preferência.

Camada 4: Agentes Especializados. Minion, Autocover, uReview, Shepherd. Agentes internos que automatizam tarefas específicas com supervisão integrada.

A peça central é o MCP Gateway: um proxy centralizado que intermedia toda comunicação entre agentes e endpoints internos. Autenticação, autorização, telemetria, atribuição de custos. Tudo passa por ele. Nenhum agente acessa a infraestrutura sem supervisão.

Gergely documentou dois agentes em detalhe. Autocover gera mais de 5.000 testes por mês e, segundo a Uber, economizou 21.000 horas de desenvolvimento. uReview analisa 90% dos aproximadamente 65.000 diffs semanais, com 75% de taxa de utilidade reportada.

Um ponto de honestidade: todas essas métricas são auto-reportadas. Não há auditoria independente. E a metodologia que define “31% de código gerado por IA” não foi publicada. Contam linhas? Commits? Diffs aceitos? Faz diferença.

Três Empresas, Três Respostas

O que torna esse momento interessante não é a Uber isoladamente. É o padrão que emerge quando você coloca três decisões lado a lado.

Uber: restringir o ambiente. O MCP Gateway centraliza o controle. Os agentes operam livremente dentro de limites definidos pela infraestrutura. A governança é arquitetural. O engenheiro escolhe sua ferramenta; o sistema garante que ela opera dentro das regras.

Stripe: restringir o agente. Como exploramos em O Que a Camada Agêntica da Stripe Revela, a Stripe construiu o Blueprint Engine, um grafo que intercala nós determinísticos e agênticos. O modelo não opera o sistema. O sistema opera o modelo. Seus minions produzem 1.300 PRs por semana, mas cada passo agêntico é cercado por verificações determinísticas que o modelo não pode ignorar.

Microsoft: reagir ao problema. Satya Nadella declarou em abril de 2025 que 20 a 30% do código da Microsoft era escrito por IA. Em fevereiro de 2026, a empresa nomeou Charlie Bell como chefe de qualidade de engenharia. O motivo, segundo pesquisadores internos: desenvolvedores perdem 40% mais bugs quando revisam código gerado por IA.

A Uber e a Stripe construíram infraestrutura de governança antes de escalar. A Microsoft escalou primeiro e depois criou um cargo para lidar com as consequências.

Não é que a Microsoft errou. É que, das três, ela é a única cuja resposta pressupõe que o problema já aconteceu.

O Paradoxo Bottom-Up

A narrativa oficial da Uber é que a adoção foi bottom-up. Engenheiros escolheram suas ferramentas. A plataforma seguiu a demanda.

É verdade. E é incompleto.

O bottom-up só funcionou porque a Uber investiu top-down em infraestrutura. O MCP Gateway não surgiu organicamente de uma decisão individual. Michelangelo não se construiu sozinha. A camada de contexto interno exigiu investimento deliberado de engenharia de plataforma.

O que a Uber fez de diferente foi construir trilhos antes de liberar o trem. Engenheiros podiam escolher qualquer ferramenta. Mas qualquer ferramenta passava pelo mesmo gateway, com as mesmas regras de acesso, os mesmos logs, a mesma atribuição de custos.

Isso resolve um problema que a maioria das empresas ainda não enfrentou: shadow AI no desenvolvimento. Quando engenheiros usam ferramentas de IA sem governança centralizada, cada equipe cria seu próprio padrão. Ou pior: nenhum padrão. A Uber tornou a governança invisível. O engenheiro não “cumpre uma política.” Ele usa a ferramenta que quer, e a governança acontece embaixo.

O Custo de Não Medir

A Uber reportou um aumento de 6 vezes nos custos com IA desde 2024. O que a Uber não reportou: o ROI.

Sabemos que Autocover gerou 21.000 horas economizadas. Sabemos que uReview processa 90% dos diffs. Não sabemos quanto custa operar esses sistemas. Não sabemos se as 21.000 horas compensam o investimento. Não sabemos se os testes gerados por Autocover encontram bugs que testes humanos não encontrariam, ou se são testes redundantes com alto volume e baixo valor.

A ausência dessa conta não invalida a estratégia. Mas revela um ponto cego comum: empresas medem adoção com precisão e resultado com otimismo.

O LinearB analisou 8,1 milhões de pull requests de 4.800 times em 2026. A taxa de aceitação de PRs gerados por IA é 32,7%. A de PRs manuais, 84,4%. Código de IA produz 1,7 vez mais issues pós-merge. Como documentamos em Você Não Está Matando o Code Review, o volume de código aumenta. A confiabilidade não acompanha.

O estudo METR de 2025 acrescenta outra camada: desenvolvedores usando IA foram 19% mais lentos em tarefas de engenharia, mas acreditavam ser 24% mais rápidos. A Veracode testou mais de 100 LLMs e encontrou que 40 a 48% do código gerado contém vulnerabilidades de segurança. A pesquisa Sonar de 2026, com 1.149 desenvolvedores, confirma o quadro: 96% não confiam em código de IA, mas apenas 48% verificam sistematicamente.

Esses dados não significam que IA no desenvolvimento é inviável. Significam que governança não é opcional.

O Que Separa Infraestrutura de Teatro

Existe uma diferença entre ter uma política de governança e ter uma infraestrutura de governança.

Uma política diz: “Todo código gerado por IA deve ser revisado.” Uma infraestrutura garante que ele será revisado, independentemente de quem o produziu, qual ferramenta foi usada, e se o engenheiro leu a política.

A Uber construiu infraestrutura. O MCP Gateway não depende de compliance voluntário. Os agentes especializados não pedem permissão para aplicar verificações. A telemetria não espera que alguém decida ativá-la.

A Stripe construiu infraestrutura. O Blueprint Engine não permite que o agente pule a etapa determinística. O Tool Shed não permite que o agente acesse ferramentas fora do seu escopo.

A Microsoft contratou uma pessoa.

Não é que contratar um líder de qualidade seja errado. Charlie Bell é experiente e competente. Mas um cargo não é um sistema. Um cargo depende da autoridade de uma pessoa. Um sistema opera independentemente de quem está no cargo.

Como exploramos em Governança de IA É Cibersegurança, agentes de IA operam como insiders digitais. Você não controla insiders com memorandos. Controla com arquitetura.

A Pergunta Que Falta

Toda empresa de tecnologia com mais de 500 engenheiros já tem algum percentual significativo de código gerado por IA. A pergunta não é mais “quanto?” É: quem governa?

Não quem deveria governar. Quem governa agora, neste instante, enquanto um agente gera um pull request no repositório mais crítico da sua empresa.

Se a resposta é “ninguém” ou “depende da equipe”, o percentual de código IA é irrelevante. Pode ser 10% ou 80%. Sem governança integrada à infraestrutura, cada ponto percentual é risco acumulado.

A Uber investiu em quatro camadas e um gateway centralizado. A Stripe investiu em separação determinística e escopo de ferramentas. A Microsoft investiu em um cargo executivo.

A maioria das empresas não investiu em nada.

Esse é o ponto cego. Não a falta de IA. A falta de infraestrutura para governá-la.

---

Fontes

• Orosz, Gergely. “How Uber uses AI for development: inside look.” The Pragmatic Engineer, março 2026.
• Stripe Engineering. “Minions: Stripe’s one-shot end-to-end coding agents.” Fevereiro 2026.
• LinearB. “2026 Software Engineering Benchmarks Report.” 2026.
• Microsoft Research. Estudo sobre revisão de código IA. 2026.
• METR. “Measuring the Impact of Early AI Assistance.” 2025.

O Victorino Group ajuda organizações de engenharia a construir a infraestrutura de governança que torna código gerado por IA confiável em escala: contato@victorino.com.br | www.victorino.com.br