Claude Code Te Faz Mais Rápido. Mais Rápido Constrói o Produto Errado Mais Rápido.

Ethan Ding escreveu uma frase em maio que líderes de engenharia deveriam fixar acima dos dashboards: o Claude Code não está deixando seu produto melhor. Está deixando seu código mais rápido. São afirmações diferentes, e a confusão entre as duas é hoje o erro de medição mais caro dentro de organizações de engenharia.

Agentes de código colapsam um eixo. Colapsam a velocidade de produzir código que compila, passa nos testes e parece o código que um engenheiro sênior teria escrito. Não colapsam o eixo do julgamento sobre o que deveria ser construído, quando parar de construir, ou se o que está sendo construído valia a pena no início. Esses dois eixos são independentes. Tratá-los como o mesmo eixo é como times geram gráficos lindos de velocidade ligados a produtos que ninguém queria.

Esse é um argumento diferente daquele feito em Modo Auto do Claude Code e em Dívida Cognitiva. Aqueles posts examinaram segurança e atrofia de habilidade. Este aqui trata de um modo de falha mais silencioso: entregar o produto errado, mais rápido, com commits mais limpos.

A Métrica Que a Maioria dos Líderes Está Usando

Velocidade de pull requests. Linhas de código por desenvolvedor por semana. Story points fechados. Tarefas entregues por sprint. Essas métricas existiam antes dos agentes de código. A IA tornou todas elas dramaticamente mais fáceis de inflar.

O padrão se repete entre os times com quem trabalhamos. Um líder testa o Claude Code ou ferramenta similar. Throughput dispara. O primeiro mês parece transformador. Seis meses depois, o roadmap cresceu 40 por cento, a base de código cresceu mais que isso, o peso de on-call subiu, e a taxa de conversão do produto não se mexeu.

A métrica de throughput era real. Também era irrelevante para a pergunta que o líder de fato queria responder, que era se o produto estava ficando melhor.

Ding crava o ponto: engenheiros sêniores e produtos em estágio inicial vêem os maiores ganhos brutos de velocidade, porque ambos os grupos têm a maior razão entre “sei exatamente o que digitar” e “sei o que deveria existir”. Quando você já sabe o que construir, um agente que digita mais rápido é alavanca enorme. Quando você não sabe, o agente te ajuda a construir a coisa errada de forma mais eficiente.

O Custo de Carregamento Que Ninguém Desconta dos Ganhos

Software tem peso. Cada feature entregue vira feature que precisa ser mantida, monitorada, suportada, depreciada e eventualmente removida. Agentes de código reduzem o custo de escrever a feature. Não reduzem, e podem aumentar, o custo de carregá-la.

Três forças se acumulam. A primeira é a superfície. Agentes são excelentes em adicionar capacidade. São medíocres em removê-la. Bases de código sob desenvolvimento intensivo com agentes tendem a crescer mais rápido que bases sob desenvolvimento puramente humano, porque o custo marginal de adicionar uma feature caiu enquanto o custo marginal de remover uma não.

A segunda é a complexidade interna. Agentes produzem código que funciona. Nem sempre produzem código que se encaixa. Uma função escrita pelo Claude Code em uma sessão fica ligeiramente diferente de uma função escrita pelo Claude Code em outra sessão, mesmo quando ambas fazem coisas parecidas. Multiplique isso por um ano de desenvolvimento assistido por agentes e você tem uma base com a superfície de um time sênior e a coerência interna de uma licitação terceirizada.

A terceira é a deriva de dependências. Agentes alcançam bibliotecas. Alcançam as bibliotecas que apareceram com mais frequência nos dados de treinamento. Essas bibliotecas podem não combinar com os padrões do seu time, com sua postura de segurança ou com seus padrões existentes. Cada alcance é uma pequena deriva. Deriva acumula.

Nada disso aparece em um gráfico de velocidade. Aparece dois anos depois, quando o time que entregou rápido em 2026 não consegue se mexer em 2028 porque o custo de carregar o que construíram comeu o orçamento de construir qualquer coisa nova.

O Gargalo Pouco Discutido

O ponto central de Ding é o que mais merece atenção. O gargalo da qualidade do produto nunca foi a velocidade de digitação. Era gosto. Era julgamento sobre o que construir. Era a disciplina de dizer não a features que iam compilar, entregar e degradar o produto. Agentes não ajudam em nada disso. Ajudam em tudo o que está depois dessa decisão.

Isso reformula uma pergunta comum de executivos. Líderes perguntam “como tiramos mais do Claude Code”. A pergunta melhor é “agora que o Claude Code removeu a restrição de digitação, qual é a restrição de fato”. Para a maioria dos times, a restrição real é o julgamento de produto, que está nas mãos de poucas pessoas, escala mal, e já era o gargalo antes da IA chegar. Remover a restrição de digitação não resolveu esse problema. Tornou-o mais visível.

Os times com alavancagem desproporcional usando agentes de código são os times com julgamento de produto forte, gosto articulado, definição precisa de “pronto”, e disposição de deletar código maior que a disposição de adicionar. Para esses times, agentes são multiplicadores. Para o resto, agentes são amplificadores do que já era verdade.

Se seu produto estava à deriva antes do Claude Code, o Claude Code vai ajudá-lo a derivar mais rápido.

A Ressalva da Fonte

Esse argumento sintetiza o texto do Ethan Ding, que é opinião editorial, não estudo controlado. Ding não apresenta dados estatísticos. Apresenta um padrão observado por ele e pelos líderes com quem conversa. Concordamos com o padrão porque ele bate com o que vemos em projetos de cliente e com o que nossos próprios dados sobre produtividade de IA mostraram entre os 60 por cento ungovernados. Mas a força da afirmação é a força do reconhecimento de padrão, não da análise de regressão. Trate como tal.

O padrão ainda tem implicações práticas.

Faça Isso Agora

Audite a métrica de ROI de IA que sua organização está usando hoje. Se ela mede throughput (PRs, linhas, tarefas, stories, velocity), você está medindo algo que a IA infla sem medir se o produto está ficando melhor. Troque.

A substituição é desconfortável porque é mais difícil de calcular. Métricas de resultado como taxa de ativação, curva de retenção, volume de tickets de suporte, conversão para pago e taxa de adoção de feature são as métricas que dizem se o time está construindo a coisa certa. Essas métricas não respondem limpa ao throughput. Respondem ao gosto, ao julgamento, à disposição de matar features. Agentes de código não movem essas métricas diretamente. Movem throughput, que às vezes correlaciona com resultado e às vezes correlaciona inversamente.

Escolha três métricas de resultado que importam para seu negócio. Acompanhe mensalmente contra o gasto com ferramentas de IA e contra a contagem de features entregues. Se métricas de resultado estão paradas ou caindo enquanto a contagem de features sobe, você está na armadilha. A correção não é mais agentes. É menos features, julgamento mais afiado sobre o que construir, e orçamento explícito para deleção.

A pergunta de CFO para IA em 2026 não é “quanto mais rápido estamos entregando”. É “as coisas que estamos entregando estão deixando o produto valer mais”. Agentes de código ajudam na primeira pergunta. São silenciosos na segunda.

Fontes

Ethan Ding. “Claude Code Is Not Making Your Product Better.” Maio de 2026.

A Victorino ajuda líderes de engenharia e produto a medir ROI de IA por resultados, não por throughput: contato@victorino.com.br | www.victorino.com.br