Os ganhos de produtividade das ferramentas de IA para programação são reais. O que esses ganhos ainda não demonstram é uma melhoria proporcional na qualidade do software, no julgamento de produto ou no aprendizado organizacional. Vale a pena entender esse descompasso antes que a conta chegue.
Principais constatações:
- O CEO da Anthropic estima o impacto das ferramentas de IA na produtividade em cerca de 15–20% — um número conservador, vindo de alguém que teria todos os motivos para alegar mais. Os próprios engenheiros da Anthropic relataram, por conta própria, um aumento de 50%. A diferença de 30 pontos entre os dois números é o ponto de partida para uma conversa mais honesta sobre o que essas ferramentas de fato fazem.
- Um estudo controlado randomizado mostrou que desenvolvedores experientes trabalhando em codebases complexas, para as quais haviam contribuído por anos, ficaram mensuravelmente mais lentos com ferramentas de IA — embora ainda acreditassem estar mais rápidos.
- O Goldman Sachs não encontra relação significativa entre adoção de IA e produtividade no nível agregado da economia, apesar dos ganhos reais em casos de uso específicos e direcionados.
- O risco não está nas ferramentas. Está na pressão competitiva que faz a adoção criteriosa parecer um risco — e a adoção descuidada parecer ousadia.
- O atrito de construir junto — sessões de grooming, code reviews, o desenvolvedor que diz "esses requisitos se contradizem" — produzia algo além de software. Os agentes de IA não reproduzem esse subproduto.
O que significa "vibe coding" — e por que a definição importa?
A confusão começa na palavra. Em fevereiro de 2025, Andrej Karpathy cunhou o termo "vibe coding" em um tweet — uma descrição informal de um fluxo de trabalho de fim de semana em que você se entrega totalmente à IA, aceita todos os diffs sem ler e deixa de se importar se entende ou não o código. Ele delimitou o conceito explicitamente para projetos descartáveis.
O que veio depois é instrutivo. O próprio Karpathy passou a dizer que prefere "agentic engineering" para trabalho sério — não porque tenha recuado da programação assistida por IA, mas porque acredita que a prática merece supervisão, rigor e ofício. Em uma entrevista de março de 2026 no podcast No Priors, ele disse que não digitava uma linha de código desde dezembro.
Enquanto isso, Gene Kim e Steve Yegge publicaram Vibe Coding: Building Production-Grade Software (2025), definindo uma prática profissional rigorosa sob o mesmo nome, com prefácio de Dario Amodei. Em outros contextos, o termo circula como xingamento, como bandeira de orgulho, como descrição de democratização e como quase sinônimo de desenvolvimento assistido por IA em geral.
O caos de definições importa porque permite que práticas muito diferentes circulem sob o mesmo rótulo. Um time que usa IA com revisão disciplinada, ownership claro e verificação cuidadosa pode soar parecido com um time que aceita o que é gerado com pouca análise. O termo é escorregadio; as escolhas de governança, não.
Este post não é uma crítica ao desenvolvimento assistido por IA. É uma pergunta sobre o que acontece quando a pressão cultural para adotar rápido, adotar amplamente e anunciar transformação faz organizações acreditarem que estão tomando o caminho cuidadoso quando, na prática, estão tomando o descuidado.
O que as evidências mostram sobre produtividade com IA na programação?
As estimativas mais confiáveis são mais modestas do que sugerem as manchetes — e o descompasso entre percepção e realidade impressiona.
Dario Amodei, falando no Dwarkesh Podcast em fevereiro de 2026, deu provavelmente a estimativa mais honesta disponível, vinda de quem tem interesse direto no jogo. Ele cravou o impacto das ferramentas de IA na produtividade em cerca de 15–20% — uma estimativa deliberadamente conservadora de alguém que teria todos os motivos para alegar números maiores.
Um estudo interno da Anthropic, publicado no fim de 2025 e baseado em pesquisas com 132 dos próprios engenheiros da empresa, identificou ganhos de produtividade auto-relatados em torno de 50%. São medições diferentes — uma é uma estimativa ampla de produtividade; a outra são ganhos auto-relatados por engenheiros de uma empresa de IA com acesso antecipado privilegiado às ferramentas — mas vale parar diante dessa diferença. Os dois estão medindo coisas diferentes — e nenhum dos números é preciso. Uma diferença de 30 pontos entre duas estimativas grosseiras apontando em direções opostas ainda diz alguma coisa, principalmente quando a maioria das decisões de headcount baseadas em IA é construída sobre produtividade percebida, e não sobre algo avaliado de forma independente.
O estudo controlado randomizado da METR — entre os estudos independentes mais rigorosos sobre ferramentas de IA para programação realizados até hoje — focou exatamente o contexto mais relevante para líderes de engenharia: desenvolvedores experientes trabalhando em codebases grandes, complexas e maduras, para as quais haviam contribuído por anos. Nesse cenário, os desenvolvedores que usaram ferramentas de IA foram 19% mais lentos do que sem elas, apesar de preverem antes uma aceleração de 24%. Mais revelador ainda: depois de concluído o estudo, eles estimaram que a IA os havia tornado 20% mais rápidos — enquanto os dados objetivos mostravam o oposto.
A METR faz questão de observar que essa constatação pode não se generalizar para além do seu contexto. As ferramentas de IA podem ter desempenho diferente para desenvolvedores menos experientes, em codebases desconhecidas ou em projetos greenfield. Mas o descompasso de percepção — a desconexão sistemática entre quão rápido os desenvolvedores acreditam estar trabalhando e quão rápido realmente estão — se aplica de forma muito mais ampla. É esse descompasso, mais do que a desaceleração em si, que explica boa parte do que move o atual debate sobre produtividade com IA.
Economistas do Goldman Sachs, em uma análise do quarto trimestre de 2025, concluíram que "não há relação significativa entre produtividade e adoção de IA no nível agregado da economia". A mesma análise identificou ganhos de produtividade de cerca de 30% em casos de uso específicos e localizados — programação de software e atendimento ao cliente. A história de produtividade com IA é real em pontos isolados. Ainda não é a transformação ampla que se anuncia.
O que as evidências atuais sustentam é mais estreito do que o hype e do que a reação contrária. Ferramentas de IA para programação podem produzir ganhos significativos em contextos específicos. E também criam um descompasso recorrente de percepção, em que a aceleração subjetiva supera a melhoria medida. O que as evidências ainda não estabelecem é que produzir código mais rápido se traduz, de forma confiável, em ganhos proporcionais de qualidade de software, julgamento de produto ou aprendizado de equipe.
Como a narrativa das demissões se sustenta diante das evidências?
Algumas das empresas mais barulhentas em cortar headcount por causa da produtividade com IA são também aquelas em que as evidências são mais frágeis.
A Klarna é o caso mais instrutivo — reportado integralmente pela Fortune. A empresa afirmou que seu assistente de IA fazia o trabalho de 700 agentes de atendimento ao cliente. Em poucos meses, os clientes reclamavam das respostas genéricas e da falta de suporte humano, e a empresa retomou as contratações. O CEO Sebastian Siemiatkowski foi direto sobre o que aconteceu: "Como o custo, infelizmente, parece ter sido um fator de avaliação predominante demais… o que se acaba tendo é qualidade mais baixa." A Klarna não é prova de que estratégias de substituição por IA sempre fracassam. É um exemplo vívido do que se perde quando o volume atendido é confundido com a qualidade entregue.
A Klarna é o caso mais documentado — mas não está isolado. Ao longo de 2025 e 2026, várias empresas anunciaram reduções de headcount impulsionadas por IA enquanto analistas e pessoas de dentro apontavam para a explicação mais simples: o excesso de contratações da pandemia. Em quase todos os casos, o mercado recompensou o enquadramento via IA, independentemente disso.
Um estudo da IBM com 2.000 CEOs descobriu que apenas um em cada quatro projetos de IA entrega o retorno sobre o investimento prometido. Ainda assim, quase dois terços dizem que o medo de ficar para trás os leva a investir antes mesmo de entender claramente o valor.
Vale parar e pensar nessa última estatística. O principal motor do investimento em IA não é a evidência de retorno — é a ansiedade sobre o que acontece se os concorrentes se moverem mais rápido. Essa ansiedade é compreensível e, em alguns contextos, racional. Mas cria as condições para um tipo particular de autoengano coletivo: organizações anunciando transformações impulsionadas por IA não porque a transformação aconteceu, mas porque anunciá-la é competitivamente necessário. A narrativa viaja mais rápido do que os resultados.
E, quando os resultados ficam claros, a narrativa já moldou decisões de contratação, expectativas de investidores e compromissos estratégicos difíceis de desfazer.
As ferramentas são reais. A narrativa está fazendo um trabalho que as ferramentas não estão.
Por que produzir código mais rápido não é a mesma coisa que software melhor?
Esta é a pergunta mais importante — e ela importa para além do debate sobre produtividade.
Abra o app do Claude no seu iPad. Funciona. E, se você usar com frequência, fica claro que é um produto que não foi pensado a fundo da perspectiva de quem segura um iPad nas mãos e quer que algo pareça certo.
Isso não é, em primeiro lugar, um problema de geração de código. É um problema de julgamento: alguém precisou decidir o que o app deveria ser, como deveria ser usá-lo e o que faria você abri-lo em vez de recorrer ao navegador. Geração de código melhor pode acelerar a implementação, mas, sozinha, não resolve essa camada de decisão. Resolvê-la exige atenção sustentada ao que outros seres humanos efetivamente vivenciam — e esse tipo de atenção é lento, incerto e não dá para "vibar" para a existência.
Quando produzir fica barato e rápido, a pressão econômica para pensar com cuidado antes de construir diminui. Dá para lançar algo plausível em poucos dias e iterar. O efeito cumulativo é que essa lógica desestimula ativamente o investimento em compreensão genuína do usuário — aquela que faz um software valer a pena ser usado. Por que passar semanas em pesquisa de usuário cuidadosa quando você pode lançar e ver no que dá? O problema é que "ver no que dá" só gera aprendizado útil se você já tiver definido o que está procurando e por quê. Sem isso, o que é lançado revela menos do que se espera, e consertar o que se descobre custa mais do que o planejado. Quando isso fica claro, as decisões já foram tomadas. É o mesmo instinto em outra forma: otimizar pelo que é visível e rápido, adiar o que é lento e difícil de medir.
Essa tendência — otimizar pela métrica empolgante e negligenciar o mecanismo que a viabiliza — não é nova. Quando um cliente reclamou dos freios de seu carro de corrida Type 35 nos anos 1920, Ettore Bugatti teria respondido: "Faço meus carros para andar, não para parar." A frase tem cerca de 100 anos. O pensamento que ela representa, evidentemente, é eterno. Os carros da Bugatti eram lindos, potentes e notoriamente subfreados. Iam muito rápido — até que não iam mais.
Em 2023, Gene Kim e Steven Spear publicaram Wiring the Winning Organization, um estudo de organizações de alto desempenho que batizou o antídoto: slowification. Tirar tempo para planejar, preparar e construir entendimento compartilhado antes de executar não é o oposto de velocidade — é o que torna a velocidade sustentável. As organizações que investiram em preparação deliberada superaram consistentemente aquelas que tratavam cada momento de deliberação como um custo a eliminar. Kim foi adiante e coautorou Vibe Coding: Building Production-Grade Software — defendendo exatamente esse tipo de prática rigorosa e deliberada. O princípio que ele identificou em 2023 se aplica diretamente à forma como esse desenvolvimento deve ser conduzido.
O teto da produção subiu. O do entendimento, não.
Não é um padrão novo. Cada geração de ferramental melhor — linguagens mais expressivas, frameworks mais ricos, infraestrutura em nuvem — tornou mais barato e rápido construir coisas sem entendê-las. O movimento low-code prometeu democratizar a criação de software e, em grande medida, entregou softwares rápidos de criar e frustrantes de usar. As ferramentas de IA para programação são a manifestação mais poderosa desse padrão até hoje — não sua invenção.
A distância entre o que as organizações conseguem construir e o que de fato entendem foi reproduzida em cada nível de abstração. Agora está sendo reproduzida mais rápido do que nunca.
O que se perde quando agentes de IA substituem desenvolvedores humanos?
O julgamento que torna o software bom nunca esteve apenas com os product managers. Era distribuído — pelo time, no atrito de construir junto.
Nem todo atrito é valioso. Parte dele é burocracia, latência e arrasto evitável. Mas parte é onde o entendimento coletivo se forma — e a onda atual de automação facilita remover ambos de uma vez só.
Isso não é puramente teórico. Em comunidades de engenharia neste exato momento, algo aparece de forma consistente na maneira como os desenvolvedores descrevem a própria experiência: entregando mais rápido, sentindo-se mais produtivos e perdendo, em silêncio, a noção do que o sistema está realmente fazendo e por quê. A pesquisa acima confirma isso no nível macro. A conversa também.
Quando um desenvolvedor questionou em uma sessão de grooming — "Não consigo construir isso porque dois desses requisitos se contradizem diretamente" — a organização foi forçada a encarar algo que vinha conseguindo evitar. Esse desconforto não foi uma falha do processo de planejamento. Foi o processo de planejamento funcionando. O requisito tinha sido escrito de uma forma que parecia coerente até que alguém realmente tentasse implementá-lo. A confusão do desenvolvedor era o espelho da organização.
Quando um code review acontecia entre uma pessoa sênior e uma júnior, ambas saíam com algo que não tinham antes. A júnior aprendia a pensar sobre uma classe de problemas. A sênior precisava articular algo que antes só sabia tacitamente — e o ato de articular afiava o conhecimento. A conversa era o aprendizado. O código era o seu resíduo.
Essa distinção importa mais do que pode parecer. Michael Polanyi passou a carreira tornando-a precisa. "Sabemos mais do que conseguimos contar", escreveu ele em The Tacit Dimension — e o corolário é que o que conseguimos contar é sempre menos do que aquilo que de fato sabemos.
O entendimento construído pela prática é diferente, em natureza, da informação adquirida pela leitura ou por instrução. Você não consegue ler até saber como um sistema complexo falha sob carga, ou como um determinado tipo de usuário esbarra em um determinado tipo de confusão. Tem que ter estado lá — ter segurado o modelo, visto-o quebrar e construído a compreensão revisada a partir dos destroços da anterior.
É isso que a sessão de grooming e o code review estavam produzindo, como subproduto do atrito, quer alguém tenha nomeado isso ou não.
Um agente de IA não produz esses subprodutos. Ele segue em frente sem reclamar. A obediência do agente não é evidência de que seus requisitos estavam claros. É evidência de que o agente não reclama.
Você pode revisar o código de um agente de IA. Não pode ter aquela conversa com ele. O agente não vai levar a revisão adiante como entendimento. O desenvolvedor júnior que teria sido formado por anos desse tipo de troca cada vez menos é contratado. E a organização que substituiu essas trocas por código gerado removeu um mecanismo do qual talvez nem soubesse depender — um que fazia algo bem diferente de produzir software.
A pergunta que vale a pena fazer
A métrica relevante não é apenas o quanto mais rápido você está entregando. É se os ganhos em produção estão sendo acompanhados por ganhos em clareza, julgamento e aprendizado.
Isso não é uma crítica às ferramentas de IA. Bem usadas — com a supervisão, o ofício e o julgamento que Karpathy, Kim e Yegge defendem —, essas ferramentas são genuinamente valiosas. A pergunta é se o momento atual está criando as condições para esse tipo de uso. A ansiedade competitiva, a pressão para entregar antes de pensar, a sensação crescente de que desacelerar para entender algo é uma forma de baixo desempenho: nada disso é produzido pelas próprias ferramentas. É o ar cultural que hoje as cerca.
Pilotos de corrida sabem que freios não servem para diminuir a velocidade. Servem para permitir o comprometimento — para tornar possível atacar mais forte nas curvas porque você confia na sua capacidade de parar se algo der errado. O atrito que os times estão removendo em nome da velocidade era, muitas vezes, exatamente isso: não overhead, não ineficiência, mas o mecanismo que tornava possível andar rápido em primeiro lugar. O praticante rigoroso de desenvolvimento assistido por IA sabe disso. A organização tomada pela ansiedade competitiva, em geral, não.
Entregar mais código não é a mesma coisa que construir software melhor — e nunca foi. Código sempre foi um artefato — o resíduo visível do entendimento que o produziu, não o entendimento em si. O que mudou não é a confusão entre artefato e entendimento. É o quão rápido e barato ficou sustentar essa confusão em escala.
A pergunta que vale a pena fazer — com honestidade, especificamente, sobre o seu próprio time — é qual tipo de adoção você está, de fato, fazendo. Essa pergunta costuma se beneficiar de um olhar de fora — de alguém que já viu os dois tipos e sabe o que procurar.
Essas perguntas não têm respostas limpas — e quem afirma o contrário provavelmente não está fazendo-as com seriedade suficiente. Na DoiT, trabalhamos lado a lado com centenas de líderes de engenharia e tecnologia navegando exatamente essa tensão — descobrindo o que manter, o que mudar e o que estavam prestes a perder sem perceber. Descobrimos que as perguntas certas, feitas com as pessoas certas, costumam produzir respostas melhores do que qualquer framework. Se você está enxergando algo que a gente não está, ou conduzindo isso de uma forma que está dando certo, a gente vai gostar de saber.
Perguntas frequentes
Quais são os diferentes significados de "vibe coding"? O termo tem pelo menos três significados distintos em uso atualmente. No sentido original — cunhado por Andrej Karpathy em fevereiro de 2025 —, descrevia um fluxo de trabalho informal, baseado em entrega total, apropriado para projetos descartáveis. Gene Kim e Steve Yegge, em seguida, definiram uma prática profissional séria sob o mesmo nome em seu livro de 2025, Vibe Coding: Building Production-Grade Software, enfatizando rigor, supervisão e ofício. No uso comum, também serve como sinônimo geral de desenvolvimento assistido por IA e, alternativamente, como pejorativo para a adoção descuidada de IA. O caos de definições importa: quando o mesmo termo descreve tanto a aceitação irrefletida do output da IA quanto a engenharia agentic disciplinada, fica muito difícil ter uma conversa significativa sobre o que cada time está realmente fazendo.
As ferramentas de IA para programação podem aumentar a produtividade sem melhorar a qualidade do software? Sim. As evidências sugerem que já estão fazendo isso em escala. Ferramentas de IA podem aumentar de forma mensurável o output de código e encurtar ciclos de entrega sem melhorar o julgamento que define o que vai ser construído, a clareza dos requisitos ou a profundidade do entendimento do usuário por trás do produto. O Goldman Sachs identifica ganhos reais de produtividade em programação como caso de uso específico. O que ele não encontra — e o que as evidências mais amplas ainda não mostram — é que esses ganhos se traduzam em melhorias proporcionais de qualidade de software ou de resultados de produto.
O que o estudo da METR sobre IA na programação realmente encontrou? O estudo controlado randomizado da METR de 2025 testou 16 desenvolvedores experientes em 246 tarefas reais em codebases open source grandes, maduras e que eles conheciam bem. Os desenvolvedores que usaram ferramentas de IA levaram 19% mais tempo para concluir as tarefas do que sem elas, apesar de preverem antes uma aceleração de 24% e ainda acreditarem, depois, que tinham sido mais rápidos. A METR observa que a constatação é específica desse contexto e pode não se generalizar para desenvolvedores menos experientes ou codebases desconhecidas. O descompasso de percepção — acreditar sistematicamente que a IA está ajudando quando os dados mostram o contrário — é a constatação mais amplamente aplicável.
Por que existe um descompasso tão grande entre a produtividade auto-relatada e a medida com IA? Dois pontos de dados ilustram o descompasso por ângulos diferentes. Em sua aparição no podcast em fevereiro de 2026, Dario Amodei estimou o impacto das ferramentas de IA na produtividade em cerca de 15–20%. Já um estudo interno da Anthropic do fim de 2025 mostrou que os próprios engenheiros da Anthropic relataram, por conta própria, um aumento de produtividade de 50% — uma medição diferente, mas a diferença entre as duas é instrutiva. O estudo da METR encontrou um padrão de percepção semelhante: os desenvolvedores acreditavam que a IA havia acelerado seu trabalho em 20%, enquanto a medição objetiva mostrava uma desaceleração de 19%. A análise da própria METR sobre o descompasso aponta vários fatores: a programação assistida por IA exige menos esforço cognitivo e parece mais rápida mesmo quando não é; os desenvolvedores podem estar confundindo facilidade com velocidade; e o tempo gasto revisando, corrigindo e ajustando código gerado por IA normalmente não entra nos auto-relatos.
O que aconteceu quando a Klarna substituiu agentes de atendimento ao cliente por IA? A Klarna substituiu cerca de 700 funções de atendimento ao cliente por um assistente de IA desenvolvido em parceria com a OpenAI, alegando que a IA realizava trabalho equivalente. Em poucos meses, os clientes reclamavam das respostas genéricas e da falta de suporte humano, à medida que os agentes de IA tinham dificuldade com interações complexas, sutis e emocionalmente carregadas. O CEO Sebastian Siemiatkowski reconheceu o erro de forma direta: "Como o custo, infelizmente, parece ter sido um fator de avaliação predominante demais… o que se acaba tendo é qualidade mais baixa." A empresa retomou a contratação de equipe humana de atendimento em 2025. O caso é instrutivo não apenas como história de fracasso, mas como ilustração do que se perde quando a métrica é volume atendido, e não entendimento demonstrado.
O que é slowification e por que ela importa para times de software? Slowification é um conceito do livro de 2023 de Gene Kim e Steven Spear, Wiring the Winning Organization. Descreve o investimento deliberado em planejamento, preparação e entendimento compartilhado antes da execução — desacelerar para se mover mais rápido e de forma mais confiável depois. A pesquisa deles em organizações de alto desempenho mostrou que esse era um diferenciador consistente: os times que aplicaram slowification superaram consistentemente aqueles que tratavam cada momento de deliberação como custo. O princípio se aplica diretamente ao desenvolvimento de software: a sessão de grooming, a pesquisa de usuário cuidadosa, o code review que parecia lento muitas vezes faziam exatamente isso — produzir o conhecimento compartilhado do qual a execução confiante depende.
As ferramentas de IA podem aumentar o output e, ao mesmo tempo, reduzir o entendimento? Sim — e essa é, possivelmente, uma pergunta mais importante do que se elas aumentam a produtividade. Output e entendimento são produzidos por mecanismos diferentes. Código é produzido pela execução; entendimento é produzido pelo atrito de resolver problemas em conjunto — o desenvolvedor que questiona requisitos contraditórios, o code review em que um engenheiro sênior precisa articular algo que antes só sabia tacitamente, a sessão de grooming em que um time descobre que o que parecia uma especificação clara não é. Os agentes de IA seguem adiante sem gerar esses subprodutos. Não reclamam, não pedem esclarecimento, não levam a conversa adiante como aprendizado. Uma organização pode entregar mais software enquanto, simultaneamente, perde a noção do que seus sistemas estão fazendo, por que foram construídos como foram e do que seus usuários realmente precisam. O output sobe. O entendimento que deveria acompanhá-lo não acompanha o ritmo.
O Goldman Sachs concluiu que a IA não tem impacto na produtividade? Não exatamente. Os economistas do Goldman Sachs, na mesma análise do quarto trimestre de 2025, não encontram relação significativa entre adoção de IA e produtividade no nível agregado da economia. A mesma análise identificou ganhos de produtividade de cerca de 30% em casos de uso específicos e localizados — programação de software e atendimento ao cliente sendo os dois mais citados. O quadro é de ganhos reais em contextos específicos que ainda não se traduziram em melhoria ampla de produtividade econômica. Essa distinção importa para como as organizações devem pensar seus investimentos em IA: a adoção direcionada, em contextos onde os ganhos estão bem evidenciados, é diferente de tratar a IA como um multiplicador de produtividade de propósito geral.