78% Das Empresas Têm Piloto De Agente De Código. Menos De 15% Chegam À Produção. Por Quê?

Perdi a conta de quantos pilotos de agente de código eu ouvi alguém descrever com entusiasmo — "resolveu em duas semanas o que a gente ia levar dois meses para fazer" — e que, meses depois, simplesmente somem da pauta. Não tem anúncio de cancelamento, não tem post-mortem, não tem nem uma frase de fechamento. O piloto só para de ser mencionado, e ninguém pergunta o que aconteceu com ele.

Numa conversa recente com outro tech lead, o assunto voltou de forma mais direta. Ele descrevia o piloto de um agente que automatizava parte da revisão de código do time dele, com métricas boas o suficiente para justificar expansão, e perguntou algo que eu não tinha resposta pronta: "por que isso não escalou?". Não era pergunta sobre o agente em si — ele funcionava, dentro do escopo controlado em que foi testado. Era pergunta sobre o que acontece entre um piloto que funciona e uma operação em produção que ninguém decide desligar.

Essa pergunta é o assunto deste post, e vale ser explícito sobre o que ele não é. Já escrevi sobre o mecanismo técnico do que quebra um agente depois de rodando — durabilidade, sandboxing, observabilidade, context rot — e sobre os limites de tratar o ranking de um benchmark específico, o SWE-bench Pro, como veredito de qual modelo é melhor. Este post trata de uma terceira coisa, anterior às duas: por que a maioria das empresas nunca chega a colocar um agente de código em produção de forma séria, o que isso revela sobre como elas avaliam antes de escalar, e o que dá para fazer diferente. É pergunta de gestão e processo de decisão, não de arquitetura.

Vou passar pelos números do funil de adoção, pelo gap documentado entre o que um agente promete em benchmark e o que entrega em produção, por que avaliar um agente como modelo isolado engana quem decide, pelas práticas de avaliação que já resolvem parte desse problema, e por um cenário hipotético de como isso apareceria na cadeira de quem lidera essa decisão.

O Funil Que Ninguém Mostra No Slide De Kickoff

Uma pesquisa conduzida entre fevereiro e março de 2026 com 650 líderes de tecnologia empresarial, em setores como manufatura, serviços financeiros, saúde, varejo e serviços profissionais, chegou a um retrato que ajuda a explicar a sensação de "todo mundo está pilotando, quase ninguém está em produção". Segundo a análise publicada pela Digital Applied em março de 2026, 78% das empresas pesquisadas têm pelo menos um piloto de agente de IA rodando em ambiente controlado, com usuários limitados e output monitorado. Apenas 14% chegaram ao que a pesquisa define como escala de produção: o agente processando mais de 50% do volume-alvo da tarefa, com monitoramento automatizado de qualidade e resposta a incidente definida.

O meio do funil é onde a história fica mais interessante. Do grupo com piloto, 64% já tentou expandir escopo ou volume e esbarrou em algum bloqueio concreto. Desse subgrupo, 72% está parado há mais de seis meses sem caminho claro de resolução. Não é que a maioria desiste no primeiro obstáculo — é que fica presa indefinidamente num estado intermediário, nem cancelado nem em produção, que a pesquisa chama de "expansão travada". Provavelmente era esse o estado do piloto do meu colega, e de boa parte dos pilotos que você também parou de ouvir falar.

A tabela abaixo resume os pontos principais desse funil, segundo a mesma pesquisa:

Etapa do funil	Percentual	O que caracteriza
Piloto ativo	78%	Ambiente controlado, usuários limitados, output revisado por humano
Duração média do piloto antes de travar	4,7 meses	Tempo até o primeiro bloqueio relevante de expansão
Tentou expandir e travou	64% dos que têm piloto	Esbarrou em bloqueio concreto ao aumentar escopo ou volume
Travado há mais de 6 meses	72% dos que travaram	Sem caminho de resolução definido
Produção em escala	14%	Mais de 50% do volume-alvo, com monitoramento e resposta a incidente definidos

A taxa de produção varia por setor: serviços financeiros lidera com 21%, puxado por investimento antecipado em agentes de documentos e compliance — áreas com pressão regulatória prévia para construir monitoramento robusto. Saúde fica no piso, com 8%, refletindo complexidade regulatória e aversão a risco clínico. Manufatura e varejo ficam próximos da média, entre 13% e 16%.

O dado que mais me chamou atenção não foi nenhum número isolado, mas uma constatação sobre investimento: organizações que chegaram à produção não gastavam mais em IA no total — o orçamento agregado era comparável ao das organizações travadas. A diferença estava na alocação: quem escalou gastou proporcionalmente mais em avaliação, monitoramento e equipe operacional dedicada, e menos em seleção de modelo e engenharia de prompt. O gargalo não é dinheiro nem é qual modelo você escolheu. É para onde esse dinheiro foi.

O Gap De 37% E A Variação De Custo De 50x

Existe um número que ajuda a explicar por que um piloto que "funcionou bem nos testes" trava na hora de virar operação real. Uma análise de 2026 da Kili Technology, replicada em análises subsequentes sobre avaliação de agentes empresariais, encontrou um gap de 37% entre a pontuação de sistemas agênticos em benchmark de laboratório e o desempenho real em produção — com variação de custo de até 50 vezes entre diferentes abordagens para atingir a mesma meta de precisão.

Esse gap não aparece porque o modelo é pior do que o anunciado. Aparece porque o que o benchmark mede — acurácia num dataset curado, conclusão de tarefa em single-turn, condições controladas — não é o que a produção estressa. Produção expõe o que o benchmark não cobre: caso de borda, input adversarial, timeout de API upstream, drift de dado, erro que se acumula ao longo de um pipeline de múltiplos passos. Um agente pode pontuar bem numa tarefa isolada e ainda degradar quando essa mesma tarefa é uma entre centenas encadeadas, cada uma dependendo do resultado da anterior.

A variação de custo de até 50x muda a pergunta que muita liderança está fazendo. A pergunta comum é "qual modelo tem melhor desempenho". A mais relevante é "quanto custa atingir o nível de precisão que meu caso exige, com esse harness e essa engenharia de retry ao redor". Duas abordagens podem chegar à mesma meta de precisão com diferença de custo de uma ordem de grandeza — e isso não aparece em benchmark público, que não precifica número de tentativas, contexto recuperado, nem escalonamento humano.

Isso é o que separa este post dos dois anteriores que escrevi sobre agentes e produção. O post sobre o que quebra um agente em produção tratou do mecanismo técnico — o agente perde estado, executa código com acesso demais, falha em silêncio, se perde no próprio contexto. O post sobre o ranking do SWE-bench Pro tratou de um benchmark específico e se ele mede o que promete medir. Este post trata do nível acima dos dois: por que a distância entre o número que aprovou o piloto e o que a operação real entrega em escala é previsível e documentada — e por que a maioria decide escalar sem medir essa distância antes.

Vale reforçar que esse gap não é sinal de modelo ruim. Os modelos de fronteira de 2026 são, por qualquer medida de benchmark isolado, extraordinariamente capazes. O gap existe porque o que se mede num laboratório e o que se opera numa empresa são objetos diferentes — um é a capacidade de resolver uma tarefa uma vez, sob condição favorável; o outro é a confiabilidade de um sistema resolver a mesma classe de tarefa milhares de vezes, sob condição que ninguém escolheu.

Avaliar Um Agente Como Se Fosse Um Modelo Isolado É O Erro De Origem

Uma monografia técnica publicada em agosto de 2026, que revisou 164 trabalhos acadêmicos, 100 registros de prática de engenharia e 29 registros de benchmark sobre agentes de código, resume o problema de origem numa frase que vale citar quase literalmente: agentes de código com IA são comumente avaliados como modelos, mas implantados como sistemas. A confiabilidade em produção depende não só da capacidade do modelo, mas do harness — o arcabouço de execução —, do estado de execução, da recuperação de informação, da gestão de memória e estado ao longo de uma tarefa longa, das permissões que o agente tem sobre o ambiente, das interfaces de revisão humana e da alocação de recursos.

Isso explica um padrão que aparece na pesquisa do funil: muitas falhas aparentes de modelo se originam em outro lugar do sistema. Um agente que "erra a tarefa" pode estar errando porque a ferramenta que ele chama devolve formato inesperado, porque o contexto chegou truncado, porque a permissão sobre um sistema legado é ampla demais, ou porque não existe verificação entre o output do agente e o sistema que consome esse output. Nenhum desses problemas aparece num benchmark que testa só o modelo isolado, porque nenhum existe fora do sistema que envolve o modelo.

Isso conecta com um dos cinco motivos de bloqueio mais citados na pesquisa da Digital Applied: 54% das organizações travadas apontaram ausência de infraestrutura de monitoramento como fator bloqueador. Não é acaso que esse seja o gap mais evitável dos cinco — não exige mudança organizacional nem acesso a sistema legado, só investimento de engenharia sistematicamente adiado, porque um piloto controlado com revisor humano parece funcionar bem sem instrumentação nenhuma. É o tipo de lacuna que documentei ao escrever sobre observabilidade de agentes em produção: sem instrumentação, um problema não só é difícil de diagnosticar, ele fica invisível até virar incidente — um agente que degrada de 94% para 79% de conclusão de tarefa em duas semanas só aparece quando o suporte recebe um pico de reclamação, e nesse ponto o serviço degradado já rodou dentro de um sistema que, no papel, "estava funcionando" porque ninguém media a coisa certa.

Há também uma dimensão organizacional que a monografia destaca: a estrutura que produziu o piloto normalmente não é a que a produção exige. Um piloto nasce de um time de dados trabalhando com um patrocinador de negócio, num projeto com prazo definido; produção é operação contínua, e a transição exige transferência deliberada de responsabilidade, não só um documento de handoff. Quando ninguém possui claramente a qualidade em produção, ela degrada; quando ninguém possui a resposta a incidente, o incidente vira interrupção prolongada. A pesquisa encontrou que organizações que tentaram escalar sem propriedade operacional dedicada tiveram seis vezes mais chance de sofrer incidente que exigiu rollback completo.

Isso reforça por que separar "o modelo é capaz" de "o sistema é confiável" não é exercício acadêmico. É a diferença entre escalar com base numa demonstração controlada e escalar com evidência de que o sistema inteiro — modelo, harness, permissão, monitoramento, propriedade operacional — aguenta o volume e a variedade real de input da produção.

O Que As Avaliações Mais Sérias Fazem Diferente

Se avaliar um agente como modelo isolado é o erro de origem, vale entender o que muda numa avaliação que trata o agente como sistema. O primeiro padrão, presente nos benchmarks mais rigorosos, é verificação baseada em execução real, não em nota subjetiva de similaridade textual. O tau-bench faz o agente manter conversa realista com um usuário simulado enquanto usa APIs de domínio e segue política de negócio, e depois verifica o estado final do banco de dados contra o objetivo — não se a resposta "parece certa", mas se o sistema terminou no estado correto. O SWE-bench, discutido no post sobre seu leaderboard Pro de agosto, roda a suíte de teste real do repositório depois do patch do agente — de novo, execução, não opinião.

O segundo padrão é medir consistência ao longo de tentativas repetidas, não desempenho numa rodada única. O tau2-bench popularizou o pass^k: em vez de contar sucesso quando pelo menos uma entre k tentativas dá certo — a lógica otimista do pass@k comum em benchmark de código —, pass^k só considera a tarefa resolvida se todas as k tentativas tiverem sucesso. A diferença é enorme na prática: um agente que resolve uma tarefa 8 em cada 10 vezes parece forte sob pass@1, mas pode desmoronar sob pass^k, porque em produção o usuário não tem a opção de tentar de novo até dar certo. Um agente com 61% de sucesso numa tentativa única pode cair para perto de 25% quando a exigência é acertar de forma consistente em oito tentativas seguidas — a diferença entre "sabe fazer isso" e "faz isso de forma confiável" mora nesse número.

Um terceiro padrão, reforçado pela literatura de avaliação de agentes de longo horizonte em 2026, é medir como a confiabilidade degrada conforme a tarefa fica mais longa — não assumir que o desempenho numa tarefa curta se sustenta numa de horas. Isso importa porque a maioria dos benchmarks públicos testa tarefas atômicas, resolvíveis em minutos, enquanto o trabalho real que a maioria das empresas quer automatizar — refatorar um módulo, sintetizar um relatório, processar documentos interligados — se estende por horas, com mais chance de acumular erro.

Um quarto elemento é combinar métrica automatizada com julgamento humano, porque nenhuma das duas sozinha produz retrato confiável de prontidão para produção. Juiz automatizado tem viés documentado — preferência por resposta mais longa, viés de posição, tendência a concordar —, e revisão humana pura não escala. A combinação que funciona é revisor humano avaliando amostra estratificada, juiz automatizado avaliando tudo, e a nota humana recalibrando o juiz continuamente.

Um quinto elemento é medir a consistência interna do processo de avaliação entre execuções independentes — a mesma lógica do alfa de Cronbach, coeficiente usado há décadas em psicometria para medir se execuções repetidas de uma medição convergem no mesmo resultado. Aplicado a agente: rodar a mesma tarefa várias vezes, sob as mesmas condições, e perguntar não "o agente acertou", mas "ele converge no mesmo resultado, ou varia de rodada para rodada de um jeito imprevisível". Um agente que acerta uma vez e erra na próxima, com a mesma entrada, não tem confiabilidade mensurável — e nenhuma métrica de acerto único captura isso.

O Que Isso Muda Na Prática Para Quem Lidera Adoção

Vale um exercício hipotético aqui, porque "meça antes de escalar" é fácil de aceitar em teoria e fácil de ignorar sob pressão de prazo. Imagine um head de engenharia com um piloto de agente de revisão de código rodando há quatro meses, aprovação em torno de 85% medida pelo próprio time que construiu o piloto, e uma reunião de orçamento em duas semanas onde a expectativa é apresentar um plano de expansão para toda a organização.

A primeira pergunta que esse líder deveria levar não é "o piloto funcionou" — a resposta já é sim, senão não haveria pauta de expansão. É como esses 85% foram medidos: numa amostra curada pelo próprio time, com revisão humana de cada output, ou numa amostra com casos de borda e o volume real de pull request que a organização gera num dia comum? Se é a primeira, esse número mede capacidade sob condição favorável, não confiabilidade em produção — e a distância entre as duas, segundo o gap de 37%, não é pequena.

A segunda pergunta é sobre o que acontece quando o mesmo agente processa a mesma classe de pull request duas vezes seguidas. Se o resultado varia de forma imprevisível entre rodadas, isso é sinal de baixa confiabilidade interna, mesmo com taxa agregada em 85% — porque esse número pode esconder um agente que erra de forma consistente numa categoria e acerta perfeitamente em outra, o que muda onde a expansão deveria acontecer primeiro.

A terceira pergunta, a mais desconfortável, é sobre propriedade operacional: quem é responsável pela qualidade desse agente às três da manhã, rodando para toda a organização? Se a resposta não existe, a pesquisa do funil sugere que a expansão vai travar de qualquer forma — só que depois de consumir orçamento e credibilidade, em vez de travar antes, quando a decisão ainda é barata de reverter. E se o agente falhar depois de escalado, investigar o que deu errado exige um playbook bem diferente do incidente tradicional — não tem humano específico para entrevistar sobre a decisão, só um rastro de execução que pode nem existir se ninguém instrumentou o sistema antes.

Nenhuma dessas três perguntas exige um mês de trabalho. Exigem admitir, antes da reunião, que a métrica que aprovou o piloto provavelmente não é a métrica que vai sustentar a decisão de escalar — e que descobrir isso antes custa muito menos do que descobrir depois, com a organização inteira dependendo do resultado.

Isso não é exclusivo de agente de revisão de código — vale para qualquer agente que uma organização considere levar de piloto para escala, seja de atendimento, processamento de documento ou automação interna. O padrão que a pesquisa revela, setor após setor, é que a diferença entre travar em 14% e ser exceção não é o modelo escolhido nem o orçamento total. É se a organização tratou avaliação e propriedade operacional como pré-requisito para escalar, ou como algo a resolver depois, sob pressão, quando o problema já tivesse virado incidente visível.

Conclusão

Fico sem resposta fechada para a pergunta que meu colega fez sobre o piloto dele, e acho que essa é a resposta mais honesta que existe hoje. Não porque falte dado — a pesquisa do funil de adoção é razoavelmente clara sobre onde a maioria trava e por quê — mas porque cada organização trava numa combinação diferente dos mesmos cinco gaps, e nenhum artigo genérico substitui o trabalho de descobrir qual combinação específica bloqueia o piloto de alguém.

O que dá para afirmar com alguma segurança é mais estreito. O gap entre benchmark e produção não é falha pontual de um fornecedor ou modelo específico — é padrão documentado e mensurável, replicado dentro da própria empresa quando ela compara o desempenho do piloto com o real seis meses depois. Tratar esse gap como surpresa, quando ele aparece, já é o sintoma do problema: a organização decidiu escalar sem medir o que precisava medir antes.

Não vou fechar isso com uma fórmula de "siga estes passos e chegue à produção". Os dados sugerem que quem chegou lá não encontrou atalho — investiu, de forma desproporcional e antes de precisar, em avaliação, monitoramento e propriedade operacional, exatamente as três coisas que a maioria adia até a pressão de expandir já estar em cima da mesa. Fica então uma pergunta mais modesta para quem está no meio de um piloto agora: se alguém pedisse hoje para você mostrar não a taxa de acerto do seu agente, mas a variação desse acerto entre execuções repetidas da mesma tarefa, você teria esse número? Se não tiver, a pergunta sobre por que o piloto não escalou provavelmente já tem resposta parcial — só ainda não foi medida.

Fontes:

78% Das Empresas Têm Piloto De Agente De Código. Menos De 15% Chegam À Produção. Por Quê?

78% Das Empresas Têm Piloto De Agente De Código. Menos De 15% Chegam À Produção. Por Quê?

O Funil Que Ninguém Mostra No Slide De Kickoff

O Gap De 37% E A Variação De Custo De 50x

Avaliar Um Agente Como Se Fosse Um Modelo Isolado É O Erro De Origem

O Que As Avaliações Mais Sérias Fazem Diferente

O Que Isso Muda Na Prática Para Quem Lidera Adoção

Conclusão

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

eltonjose