A Regra dos 65%: Por Que a IA em Produção Está Se Tornando Mais Código

Tomaz Tunguz, investidor da Theory Ventures, publicou em fevereiro de 2026 uma análise que deveria incomodar qualquer pessoa entusiasmada com agentes autônomos. Ele revisou 14 workflows de IA em produção na sua equipe ao longo de seis meses e contou os nós. O resultado: 65% executam como código determinístico. Sem chamada de LLM. Sem inferência. Código puro.

A proporção varia. 29% dos workflows não fazem nenhuma chamada de LLM. 36% são entre 67% e 91% código determinístico. Apenas 14% são totalmente agênticos.

Antes de interpretar esses números, duas ressalvas. Primeiro, são 14 workflows de uma equipe de venture capital. Não é um estudo de mercado. Segundo, alta proporção de código determinístico pode indicar imaturidade das ferramentas de IA, não uma verdade permanente sobre arquiteturas de produção. É possível que, em dois anos, esses mesmos workflows sejam 80% agênticos.

Dito isso, a telemetria conta uma história que vale examinar. Porque o que Tunguz encontrou na sua equipe espelha o que equipes de engenharia maiores estão construindo por conta própria.

O Padrão Stripe

A Stripe publicou no seu blog de engenharia os detalhes da sua arquitetura de agentes. O modelo se chama “minion” e faz merge de mais de mil pull requests por semana sem código escrito por humanos.

A estrutura é reveladora. Cada workflow é um blueprint que alterna entre nós determinísticos e nós agênticos. Os nós determinísticos fazem o trabalho previsível: clonar repositórios, executar linting, rodar CI, formatar código. Os nós agênticos lidam com o que exige julgamento: interpretar a intenção de uma tarefa, decidir qual arquivo modificar, gerar o código propriamente dito.

Dois detalhes merecem atenção.

Primeiro, existe um limite deliberado de duas rodadas de CI por workflow. Se o agente não consegue produzir código que passe no CI em duas tentativas, o workflow falha e escala para um humano. Não é uma limitação técnica. É uma decisão de governança. A Stripe decidiu que o custo de um agente insistindo indefinidamente é maior que o custo de envolver um engenheiro.

Segundo, os agentes acessam mais de 400 ferramentas MCP via uma camada interna chamada Toolshed. Mas o acesso não é aberto. Cada blueprint define exatamente quais ferramentas estão disponíveis para cada nó. O agente não escolhe suas ferramentas. O blueprint escolhe.

Isso é orquestração, não autonomia. A IA resolve problemas dentro de limites que código determinístico define e impõe.

A Portabilidade Inconveniente

Jason Lemkin, fundador do SaaStr, trouxe um dado que complementa a história. Uma empresa SaaS com mais de 100 milhões de dólares em receita recorrente anual, que opera com agentes de IA como produto central, se recusa a oferecer contratos de mais de um ano.

O motivo? Entre 50% e 80% da migração de prompts entre plataformas acontece por copy-paste. Os prompts não são proprietários. A lógica de negócio está nos prompts, e prompts são portáteis.

Para operações, a implicação é direta. Se sua vantagem competitiva está nos prompts que alimentam seus agentes, você não tem vantagem competitiva. Prompts são texto. Texto se copia.

A vantagem real está no que Tunguz e a Stripe estão demonstrando: a orquestração determinística ao redor dos prompts. Os blueprints. Os limites de retry. As regras de escalonamento. A seleção de ferramentas por nó. Esse código não se copia com facilidade, porque depende de contexto operacional específico.

Há uma ressalva importante. A portabilidade de prompts pode ser um fenômeno transitório. Modelos futuros podem exigir instruções tão específicas que a migração entre plataformas se torne impraticável. Mas hoje, em março de 2026, a evidência aponta para o contrário.

O Teste da Produção

A evidência mais dura vem de quem opera agentes no dia a dia.

Workpath e Aboy publicaram resultados de mais de mil revisões manuais de sessões de agentes em produção. Três descobertas se destacam. Usuários utilizaram apenas 5 de 50 ferramentas disponíveis. Metade dos pedidos eram para operações em massa que o sistema não suportava. E, nas palavras dos autores, “tudo falhava silenciosamente.”

O problema não era a IA. Era a camada ao redor da IA.

Ferramentas demais sem curadoria. Ausência de operações básicas que os usuários precisavam. Falhas sem feedback visível. São todos problemas de engenharia de software, não de modelos de linguagem.

Cursor, que opera um dos maiores ambientes de agentes de codificação, reporta que 35% dos seus PRs internos vêm de agentes autônomos, com crescimento de 15x no uso. Mas o que viabiliza essa escala não é a qualidade do modelo. É a infraestrutura determinística de validação, CI e escalonamento que envolve cada agente.

O Que 65% Realmente Significa

Como exploramos em A Mudança de Fase na Engenharia de Software, a inversão 80/20 de Karpathy mostrou o que muda no nível individual: o engenheiro passa de escrever código para dirigir agentes. A regra dos 65% mostra o que muda no nível organizacional: a maioria do trabalho de operar IA não é IA.

É código. É orquestração. É governança traduzida em regras de execução.

A Fábrica de Software Mais Governada levou essa ideia ao extremo: nenhum humano escreve código, nenhum humano revisa código, mas a infraestrutura de validação é tão rigorosa que o resultado é mais governado, não menos. O StrongDM Factory é um caso extremo, mas ilustra o princípio: quando você remove o humano da execução, o que sobra precisa ser determinístico.

A convergência entre Tunguz, Stripe, StrongDM e Cursor aponta para um modelo operacional que poucos estão discutindo. As conversas sobre IA em produção se concentram em qual modelo usar, como escrever prompts melhores, quanto contexto fornecer. Essas perguntas importam. Mas representam 35% do problema.

Os outros 65% são engenharia.

Implicações Para Quem Opera

Se você está montando ou expandindo operações com agentes de IA, três princípios emergem dessa evidência.

Invista em orquestração antes de investir em modelos. A Stripe não faz merge de mil PRs por semana porque tem um modelo melhor. Faz porque construiu blueprints que definem exatamente o que cada agente pode e não pode fazer. Como vimos em Times de Agentes, o trabalho do engenheiro muda de escrever código para projetar ambientes de execução. A regra dos 65% confirma essa mudança no nível de sistemas inteiros.

Defina limites de falha explícitos. O limite de duas rodadas de CI da Stripe não é conservadorismo. É economia. Um agente que tenta indefinidamente consome recursos, gera ruído e atrasa o feedback para o engenheiro. Defina quando o agente para e quando o humano entra. Documente. Meça.

Trate falhas silenciosas como defeitos críticos. A descoberta da Workpath e Aboy de que “tudo falhava silenciosamente” é o tipo de problema que escala de forma invisível. Se um agente falha e ninguém sabe, o sistema parece funcionar enquanto acumula débito operacional. Observabilidade não é opcional.

Nada disso é contrário à adoção de IA. É o que torna a adoção sustentável. Os 65% de código determinístico não são um sinal de que a IA falhou. São um sinal de que a engenharia aprendeu a usar IA direito.

Fontes

Tunguz, T. “The Rise of the Deterministic Node.” Theory Ventures Blog. Fevereiro 2026.
Stripe Engineering. “How We Built Stripe’s Agentic Coding Architecture.” Stripe Dev Blog. 2026.
Lemkin, J. “AI SaaS and the One-Year Contract Problem.” SaaStr. 2026.
Cursor Blog. “Agent Usage in Production.” Cursor. 2026.
Workpath & Aboy. “Lessons from 1,000+ Agent Session Reviews.” 2026.

Victorino Group ajuda organizações a construir a camada de operações que torna IA em produção sustentável: contato@victorino.com.br | www.victorino.com.br