Claude Code não está tornando seu produto melhor

• O efeito de produtividade dos agentes de código não é uniforme e se divide em uma curva em K; a métrica central não é linhas de código por hora, mas se a velocidade de melhoria do produto por engenheiro realmente aumentou
• Dax, Karri Saarinen e David Cramer não são críticos de IA, mas não estão convencidos de que agentes de código aumentem claramente a velocidade de melhoria do produto; Cramer vê os LLMs aumentando a complexidade e o inchaço e desacelerando a velocidade no longo prazo
• Se o Claude Code tivesse dado uma vantagem exclusiva à Anthropic por 7 meses, a diferença para os concorrentes deveria ter se ampliado de forma composta; porém Codex, Cursor, Cognition e Factory continuam competitivos, o que sugere que o gargalo talvez não seja a produção de código
• Uma boa cultura de engenharia trata linhas de código não como ativo, mas como custo; à medida que aumentam os recursos e as integrações, também crescem a superfície de bugs, as dependências e as funcionalidades ao redor, e a complexidade aumenta não de forma linear, mas composta
• Na fronteira da qualidade do produto, mais importante que escrever código rápido são gosto, compressão, remoção e capacidade de dizer não; o Claude Code é útil para ir do zero ao nível de um Camry, mas não faz artesãos da Ferrari criarem Ferraris mais rápidas

---

Curva de produtividade em K

• O ganho de produtividade com agentes de código não é uniforme e se divide em uma curva em K
  • Engenheiros seniores mostram aumento mensurável de produção desde o ponto de inflexão dos LLMs em 2023
  • A produção de engenheiros juniores quase estagnou ou diminuiu
  • A métrica importante não é linhas de código por hora, mas se a velocidade de melhoria do produto por engenheiro de fato está subindo
• A programação com agentes reduz o tempo para criar Pull Requests em tarefas específicas
  • Repetem-se alegações como “processamos 6 anos de backlog em um trimestre”, “fizemos o backend em 3 dias com Cursor” e “Claude Code foi totalmente programado com Claude”
  • Mas continua sendo outra questão saber se a velocidade de produção de código equivale a métricas como melhora da qualidade do produto

Sinais de alerta de engenheiros que fazem bons produtos

• Dax, Karri Saarinen e David Cramer não são críticos de IA, mas ainda não estão convencidos de que agentes de código aumentem claramente a velocidade de melhoria do produto
  • Dax está criando opencode.ai
  • Karri Saarinen é CEO da Linear
  • David Cramer criou a Sentry do zero e a levou a uma escala de US$ 10 milhões por mês
• David Cramer considera que os LLMs hoje não geram ganho líquido de produtividade
  • Eles reduzem a barreira de entrada, mas criam software complexo difícil de manter
  • Ao que tudo indica, desaceleram a velocidade no longo prazo
  • Ele aponta como problemas a “falta de desempenho em desenvolvimento incremental dentro da complexidade”, a “falta de capacidade real de simplificação e de criação de interfaces idiomáticas” e as “técnicas desleixadas de geração de testes” dos LLMs
  • No fim, a conclusão é que a maior parte disso é inchaço (bloat)
• Dax afirma que ainda não encontrou com clareza a melhor forma de usar agentes de código
  • Enquanto isso, do lado de fora há muitas alegações como “todo PR é gerado por IA”, “velocidade sem precedentes” e “processamos 6 anos de backlog”
  • Na prática, todos eles enfrentam dificuldades para aumentar a velocidade real de melhoria do produto

A vantagem exclusiva do Claude Code não aparece como diferença

• Se o Claude Code foi totalmente programado com Claude, a velocidade de melhoria do produto deveria ter acelerado
  • Mesmo que o uso do Claude Code aumentasse em apenas 1,5x a velocidade de melhoria do produto, uma equipe que o usasse desde o início deveria ampliar a distância para os concorrentes com o passar do tempo
  • Como a produtividade de engenharia é uma função composta, a diferença deveria crescer a cada trimestre
• A situação real do mercado não mostra esse tipo de diferença composta
  • O Codex foi lançado alguns meses depois do Claude Code, mas já compete em termos de funcionalidades
  • O movimento comercial da Cursor é forte
  • Cognition e Factory também continuam fechando contratos empresariais importantes
  • As pessoas ainda discutem qual ferramenta é melhor
• O principal contraexemplo é que, se a Anthropic teve exclusividade do Claude Code por 7 meses, então, caso houvesse uma vantagem real de velocidade de produto, a diferença para os concorrentes já deveria ter ficado grande demais para ser alcançada
  • O Codex já deveria ter se tornado irrelevante, mas não foi o que aconteceu
  • Se a vantagem composta não aparece, é bem provável que o gargalo da qualidade do produto não fosse o código
• Os possíveis contra-argumentos reforçam a mesma conclusão
  • Mesmo que houvesse ganhos, a dívida de complexidade pode tê-los consumido
  • A equipe de engenharia da Anthropic pode ser grande demais, diluindo o ganho marginal por engenheiro
  • Mas, ainda assim, o gargalo deixa de ser a produção de código e passa a ser outro fator mais difícil

Linhas de código não são ativo, são custo

• Uma boa cultura de engenharia trata linhas de código não como produto gerado, mas como despesa
  • Escreve-se código para funcionalidades importantes, e não se escreve para as que não são importantes
  • A base de código se parece menos com um ativo no balanço e mais com um passivo
• A tinychat, subsidiária de software da comma.ai, fazia soar um alarme quando a base de código passava de certo tamanho e comemorava código removido
  • Cada linha de código é uma superfície de bug
  • Cada função vira dependência da próxima função
  • Cada recurso cria recursos ao redor
• A área de superfície do produto se expande como um fractal
  • Ao adicionar integração com Slack, você passa a precisar de integração com Teams e de um caminho alternativo por email
  • Ao adicionar notificações, é preciso refazê-las para mobile, SMS e políticas de MDM empresarial
  • Ao adicionar suporte a MFA, é preciso compatibilidade com Duo, Okta e SAML
  • A complexidade cresce não de forma linear, mas composta
• A Linear tem 178 pessoas, 6 anos e ARR de US$ 100 milhões
  • O Jira é 56 vezes maior que a Linear em esforço acumulado de engenharia, mas aparece 6 pontos abaixo em pontuação de qualidade percebida pelo consumidor
  • O ponto central é que qualidade e massa da base de código não são a mesma coisa
• Em uma escala como a do Facebook, a capacidade de produzir código de UI rapidamente não é o gargalo
  • Um engenheiro experiente consegue fazer um mockup do feed do Facebook em um dia
  • A restrição real é reduzir a quantidade de linhas de código necessária para entregar essa experiência a bilhões de pessoas com uptime sob qualquer carga e latência
  • A função de recompensa não é produção, mas compressão
  • Nesse tipo de trabalho, agentes de código não conseguem avaliar trade-offs de longo prazo nem têm uma teoria do sistema

O verdadeiro gargalo é empurrar a fronteira das boas ideias de produto

• Na fronteira da melhoria de qualidade do produto, o limite não é quão rápido se escreve código, mas quão rápido se conseguem ter ideias boas o bastante para empurrar essa fronteira
• A diferença entre Jira e Linear não está em quem desenhou caixas melhores
  • A Linear tinha uma visão criativa específica sobre como um software de gestão de projetos deveria ser sentido, e executou isso com disciplina ao longo de anos
  • Essa qualidade não vem de throughput de tokens; ela vem de gosto e da decisão de construir menos
• A alegação de “processamos 6 anos de backlog” não é tão impressionante quanto parece
  • Backlogs cheios de funcionalidades CRUD e ferramentas internas combinam bem com o tipo de tarefa que agentes de código aceleram
  • Ao mesmo tempo, esse tipo de trabalho não empurra a fronteira do produto
  • Um produto não melhora só porque foi lançado mais rápido; ele melhora quando aquilo que foi lançado faz o usuário se importar mais
• Agentes de programação com IA ajudam produtos a ir do zero ao um e chegar mais rápido à fronteira de qualidade
  • Eles reduzem o tempo até a primeira versão funcional
  • No trabalho de estágio inicial, o ganho de velocidade realmente existe
• Mas há um custo
  • A base de código cresce mais rápido do que a qualidade
  • A dívida técnica se acumula de forma composta
  • A velocidade ganha agora é comprada com um custo que terá de ser pago depois

Camry para todos, Ferrari para ninguém

• O gargalo das equipes na fronteira não são agentes de código, mas pessoas com gosto
  • A capacidade de se tornar excelente “tirando coisas”, como Linear e Sentry, existe em pessoas específicas
  • Nan Yu, da Linear, e Kelly Johnson, da Skunk Works, são citados como exemplos
  • A equipe selecionada de Kelly Johnson criou o SR-71, ainda citado 60 anos depois como a aeronave tripulada com entrada de ar mais rápida
  • O Blackbird não foi rápido porque produziu mais plantas, mas porque Johnson tinha uma teoria sobre o que não deixar entrar
  • O gosto para remover, comprimir e rejeitar não está em nenhum roadmap de modelo de fronteira e se torna ainda mais valioso à medida que o piso sobe
• Se você já está na fronteira, não está claro se dobrar o gasto de P&D com consumo de tokens cria valor econômico
  • Diz-se que os engenheiros da Ramp praticamente dobraram sua remuneração no último ano em gasto com tokens
  • É difícil verificar se o produto da Ramp realmente ficou melhor
  • Se você já é o número 1, sua taxa de vitória fica quase fixa, e virar “número 1 com vantagem maior” é difícil de medir
  • Para mudar esse julgamento, seriam necessários dados de taxa de vitória ou de lucro e prejuízo da Ramp
  • Como cliente da Ramp, o autor afirma não perceber diferença concreta entre hoje e o ano passado
• O Claude Code pode ajudar qualquer um a criar um concorrente do Camry, mas não ajuda artesãos da Ferrari a fazer Ferraris mais rápidas
  • É muito útil para ir do zero ao nível de um Camry
  • O custo de produção de software que não está no topo provavelmente cairá muito
  • Em troca, muito caos e dívida vão se acumular nas vigas da fábrica, e no fim alguém terá de limpar isso

[GN⁺]

Opiniões no Lobste.rs

• A complexidade cresce exponencialmente e talvez até mais rápido que isso. Então, algo que até pessoas que temem a singularidade da AGI às vezes deixam passar é que, não importa quão inteligente seja uma pessoa, modelo ou agente, quando ideias, sistemas, projetos, codebases ou conjuntos de funcionalidades crescem, acabam batendo numa parede de complexidade que sobe abruptamente
  Todo projeto de software vai relativamente bem no começo, mas em algum momento o crescimento exponencial da complexidade passa a dominar tudo. Boa arquitetura, design e qualidade apenas adiam esse ponto; se pessoas competentes projetarem bem e cuidarem da qualidade, talvez consigam aguentar 10 vezes mais em tamanho, funcionalidades, desempenho e fator “uau”, mas no fim ainda vão bater na parede
  A ajuda de LLMs permite criar funcionalidades e código de um certo nível, em geral de qualidade mediana, muito mais rápido. Ou seja, isso também significa chegar muito mais rápido a essa parede. É útil para crescimento, experimentação e tarefas de baixa complexidade que eram relativamente fáceis, mas consumiam tempo; não é o que vai permitir criar coisas inéditas ou projetos grandes e complexos. Para isso, o necessário são melhorias que contenham a complexidade, e os LLMs atuais não oferecem isso direito

  • É um problema clássico. Quando causa e efeito vêm em sequência imediata, o ganho imediato aparece com facilidade, mas quando existe um intervalo de tempo entre causa e efeito, os efeitos negativos ficam muito mais difíceis de enxergar
    http://bastiat.org/en/twisatwins.html
    O custo de usar agentes de código não aparece diretamente e, acima de tudo, vem da perda de entendimento coletivo sobre como o sistema funciona
  • Ainda assim, a organização hierárquica oferece um caminho para administrar complexidade em grande escala. Na natureza também vemos estruturas extremamente complexas surgirem desse jeito. É possível construir sistemas em que unidades independentes se combinam para formar estruturas maiores
    Como sistemas robustos precisam resistir a impactos e se adaptar por conta própria, cada parte deve poder falhar de forma independente e ter danos localizados. Se você organiza o sistema como subsistemas aninhados, surgem unidades parecidas com células que conversam entre si e executam trabalho. Essas unidades funcionam como subcomponentes estáveis, sem precisar conhecer os processos internos das outras células
    Cada camada pode se auto-organizar e manter resiliência dentro do seu próprio escopo, sem ficar travada pelo que acontece em outro lugar. Isso é, na prática, encapsular a complexidade incidental por trás de interfaces e criar abstrações em que essas interfaces carregam significado. É melhor ver as camadas como o tecido conjuntivo que conecta os componentes de um sistema grande
    Erlang OTP é um bom exemplo dessa abordagem em software, compondo sistemas grandes a partir de processos isolados que trocam mensagens entre si. Mesmo que um processo individual morra ou falhe, isso não derruba o sistema inteiro
  • Acho que “conter a complexidade” exige decisões, opiniões e, às vezes, oposição ou conflito
    Se você pedir a alguém para implementar algo, essa pessoa pode responder coisas como “isso é complexo demais”, “isso vai explodir daqui a um ano”, “isso não é compatível com o que o time Y está fazendo” ou “não temos gente suficiente para implementar isso”. Essa última frase pode ser literalmente verdade ou uma forma indireta de dizer “não dá”
    A chance de um LLM responder assim é muito baixa. Principalmente porque eles são ajustados para serem otimistas e educados. Além disso, como essa tendência é necessária para aumentar engajamento, também não parece muito provável que sejam ajustados de outra forma
    Isso parece parecido com o problema de LLMs ajudarem usuários a cometer suicídio. Mesmo sendo algo bastante evidente, os LLMs fizeram isso com frequência. Projetos morrerem por complexidade descontrolada é muito menos evidente do que isso, então não há muito motivo para esperar que os LLMs façam melhor nesse ponto no curto prazo

• A linha de raciocínio do tipo “se usar Claude Code realmente gera uma vantagem real de velocidade no desenvolvimento de produto, e a Anthropic teve exclusividade por 7 meses, então a diferença entre Claude Code e todos os concorrentes deveria ser impossível de fechar; o Codex deveria ser irrelevante. Mas as pessoas ainda discutem ativamente qual dos dois é melhor” não parece muito sólida
  Claude Code é um bom software, mas não é algum tipo de magia estranha de AGI que torna competição impossível

  • Além disso, o Codex também foi feito com vibe coding, então a comparação fica meio engraçada também por esse lado. Ter começado alguns meses antes talvez não signifique muita coisa. Muitos dos recursos adicionados vêm do que usuários reais fazem com a ferramenta
    Não é como se o Claude Code tivesse um roadmap completo desde o início e a principal barreira fosse a velocidade de escrever código. A barreira principal são as ideias. Todo mundo ainda está descobrindo isso na prática
    Só passei os olhos pelo texto, então é difícil falar com profundidade, mas mesmo deixando de lado o problema de usar maiúscula no começo das frases, a maior parte pareceu prosa escrita por LLM, então eu não tive vontade de ler

• Até agora, os erros dos agentes tendem a se acumular de forma multiplicativa
  Se você cria uma API que tecnicamente funciona, mas exige um pouco de código extra no uso, o resultado é mais código, mais lugares para duplicação, ramificações e bugs. Aí, de forma fractal, ainda mais código não muito bom acaba sendo escrito
  Um agente uma vez projetou uma struct em que o campo id era opcional. Esse campo só era necessário por causa de um único construtor que ele mesmo havia escrito. Depois disso, ele escreveu incansavelmente duas versões do código, uma para quando havia id e outra para quando não havia, e ainda criou caminhos alternativos desajeitados para o caso sem id. Esses caminhos alternativos eram, claro, complexos e frágeis. Quase todos os usos da struct e até coisas que dependiam dela foram contaminados, e no fim o construtor sem id nem era usado. Metade da codebase poderia ter sido apagada facilmente
  Eu realmente não sei se isso pode ser consertado com instruções suficientes do tipo “se você está fazendo algo idiota, pare de cavar”, e se para a programação ficar “resolvida” faltam só alguns hacks, ou se isso é um problema de longo prazo de um papagaio estocástico, que continua exigindo custos exponencialmente crescentes para obter melhorias lineares. Enquanto os erros se acumularem com juros compostos, o crescimento composto no fim vai cobrar seu preço

  • Já vi algo muito parecido acontecer com desenvolvedores humanos. Acho que uma das características que separam os melhores desenvolvedores é a tendência de parar, subir um nível e olhar de fora
    Às vezes isso inclui até o processo de negócio. Um desenvolvedor que conhece bem o domínio pode, em vez de passar meses implementando uma solução técnica, perguntar: “em vez de continuar cavando, não dá simplesmente para mudar o processo?”. E às vezes a resposta é “claro, isso é fácil”
    Acho que os LLMs também vão acabar ficando melhores nisso. Eles já costumam encontrar esse tipo de coisa com bastante frequência quando você pergunta diretamente algo como “essa abordagem não parece boa; dá para pensar em uma alternativa?”. Só que, no momento, o sucesso e a falha ainda são inconsistentes, e depois que já fizeram uma dessas besteiras, a chance de perceberem isso sozinhos enquanto fazem outra tarefa sem relação é baixa
    Também há um trade-off aí. As pessoas já reclamam que os modelos pensam demais sobre os problemas e queimam tokens. Quando um desenvolvedor tem experiência e intuição sobre “como o código para resolver certo problema deveria parecer”, ele naturalmente sabe quando é hora de parar e reconsiderar. Talvez agentes também ganhem esse tipo de intuição com treinamento melhor

• Seria bom ver uma versão atualizada com dados de depois do ponto de inflexão de novembro de 2025