Linhas de código ganharam um assessor de imprensa melhor
(curlewis.co.nz)- A avaliação da produtividade de desenvolvedores deve ser feita por métricas de resultado como valor para o cliente, receita e confiabilidade, e não pela quantidade de código
- Os números recentes de divulgação sobre IA para programação de Google, Anthropic, OpenAI e Cursor se concentram todos em alegações quantitativas, como proporção de código gerado ou número de linhas de código
- A antiga alegação do GitHub Copilot de um ganho de 55% na velocidade de trabalho era um resultado verificável, mas a “proporção de código escrita por IA” pode crescer independentemente de haver melhora real
- As pesquisas reais são contraditórias: vão de +26% em taxa de conclusão em Cui et al. até “19% mais lento” da METR e sua posterior revisão, além de levantamentos em que 90% das empresas não medem efeito algum — o efeito no nível organizacional fica em torno de 10%
- A adoção de IA é necessária, mas a medição de desempenho deve se basear em critérios validados como métricas DORA, confiabilidade, velocidade de mudanças significativas, receita e valor para o cliente
O retorno da métrica de linhas de código
- Há 15 anos, o fato de um dos dois desenvolvedores sêniores de uma empresa SaaS ter escrito 40% mais código do que o outro não bastava para considerá-lo melhor
- O que realmente importa é o que foi entregue (ship) e contribuiu para clientes, receita e estabilidade; número de linhas de código e quantidade de PRs são há décadas formas ruins de medição
- Em 2026, os números que a indústria mais destaca se concentram todos na proporção de código escrito por IA
- Google: 75% do novo código é gerado por IA
- Anthropic: cerca de 80% do código de produção mergeado é escrito pelo Claude, e os engenheiros implantam “8 vezes mais código” por trimestre
- OpenAI: da mesma forma, cerca de 80%
- Cursor: “mais de 100 milhões de linhas de código empresarial por dia”
- Todos esses números são alegações de volume, e a “proporção de código escrita por IA” não passa de linhas de código com um discurso de marketing mais sofisticado
- O fato de todas essas empresas serem fornecedoras de IA torna inflar a percepção de adoção um incentivo importante
Antes se falava em resultado
- Alguns anos atrás, o número central era diferente não só em escala, mas em natureza
- A principal alegação do GitHub era que, com o Copilot, as tarefas eram concluídas 55% mais rápido
- Houve muitas críticas, mas isso era uma alegação de resultado (outcome): ousada, passível de refutação e ligada a valor — se estivesse errada, seria possível provar
- As alegações de 2026 são estruturadas para não poder falhar
- “75% do código é escrito por IA” pode ser verdadeiro e continuar subindo sem qualquer relação com melhorias reais, como deploy mais rápido, menos incidentes ou maior satisfação do cliente
- Métricas de volume só decepcionam quando a adoção estagna, e quase todos já concordam que a adoção é real
- As alegações cresceram, mas dizem menos
O que não vai para o outdoor
- O que aconteceu nesse intervalo foi que a evidência de resultado ficou mais complexa
-
Resultados que apoiam a adoção
- Cui et al.: entre cerca de 5.000 desenvolvedores, +26% em tarefas concluídas, com maior melhora especialmente entre desenvolvedores júnior — quase sem margem para controvérsia
-
Evidências na direção contrária
-
A revisão de posição da METR
- Em fevereiro de 2026, a METR praticamente retirou sua posição anterior — a estimativa de acompanhamento se inverteu para ganho de velocidade (speedup), embora com margem de erro muito ampla
- Como os desenvolvedores agora se recusavam a trabalhar sem IA e não conseguiam relatar com confiabilidade o tempo gasto em trabalho feito por agentes, o próprio desenho do estudo foi abandonado
- A posição mais recente: em 2026, é muito provável que a IA acelere os desenvolvedores, mas não é possível medir isso de forma limpa
-
Efeito no nível da empresa
- Pesquisa do NBER com cerca de 6.000 executivos: 69% das empresas usam IA, mas cerca de 9 em cada 10 relatam não ver efeito mensurável em produtividade
- O consenso entre estudos aponta para algo como 10% de melhora no nível organizacional — útil, mas longe de “desenvolvedores não são mais necessários”
- Quem ainda cita apenas os “19% mais lento” também está escolhendo dados a dedo; a pesquisa continua sendo atualizada enquanto a indústria troca o que decide medir
A versão em IA das métricas de vaidade
- O problema não está só nas alegações dos fornecedores de IA
-
Modelos de maturidade e escadas
- Carnegie Mellon SEI e Accenture lançaram há poucos dias o AI Adoption Maturity Model — 5 níveis, 8 dimensões, usando no marketing a estatística de que “95% das organizações não têm retorno”
- O “8 levels of AI-assisted development”, de Steve Yegge, classifica conforme quais ferramentas são usadas e quanta supervisão existe
- Todos os fornecedores de ferramentas lançam sua própria escada de maturidade, e no topo normalmente está “usar mais o nosso produto”
- Essas escadas medem intensidade de adoção e chamam isso de maturidade — é o mesmo substituto, só com outra embalagem
-
Confusão de definição
- Quando a Augment perguntou a 219 líderes de engenharia o que era “AI-native engineering”, surgiram 219 respostas diferentes
-
A dupla face da Anthropic
- Ao mesmo tempo em que sustenta a alegação de “8 vezes mais código entregue”, também apresentou um dos estudos mais rigorosos do ano
- Em um RCT, desenvolvedores assistidos por IA tiveram 17% pior desempenho em compreensão do código que acabavam de lançar, sem ganho de produtividade estatisticamente significativo
- O setor de pesquisa atualiza a visão, enquanto o marketing continua contando volume — as duas coisas podem ser verdade ao mesmo tempo
Por que prestar atenção nisso
- Esses números não são decoração; eles influenciam orçamentos, expectativas de desempenho e planejamento de equipe
-
Demissões justificadas por IA
- Em fevereiro, Jack Dorsey cortou mais de 40% da força de trabalho da Block (4.000+ pessoas), apresentando a IA como argumento central explícito — “equipes menores podem fazer mais e melhor com as ferramentas que estamos construindo”
- Algumas semanas depois, a Atlassian cortou 10% (cerca de 1.600 pessoas), admitindo que “não seria honesto fingir que a IA não muda a composição de habilidades ou o número de funções necessárias”
- No mesmo anúncio, Dorsey disse que o negócio seguia sólido e que a margem bruta estava crescendo
-
Dúvida sobre as alegações de produtividade
- Se “com IA todo mundo fica mais produtivo e, por isso, é preciso menos gente”, então seria preciso ver essa evidência — e o argumento aqui é que ela ainda não existe
- Seria necessário demonstrar que parte da equipe de fato ficou ociosa ou subutilizada; como empresas de produto/SaaS têm roadmaps intermináveis, o normal seria usar a capacidade extra para gerar mais valor ao cliente e velocidade — algo que deveria aparecer em MAU, conversão e receita
- Escolher demitir é um sinal de que a narrativa de produtividade cumpre papel de RP para uma decisão já tomada por outros motivos, como excesso de contratações ou pressão de investidores
- Às vezes cortes com base em eficiência podem ser justificáveis, mas, nesse caso, devem usar os sistemas individuais de avaliação de desempenho que a empresa já opera — e não contagem de tokens, “proporção de código escrita por IA” ou nível em escada de maturidade
- Se o critério de seleção for uma métrica de vaidade, a seleção não passa de “uma loteria maquiada”
Conclusão
- Isto não é anti-IA; a posição é de que todo engenheiro deve usar IA todos os dias
- Seja o nome AI-first ou AI-proficient, é necessário testar com curiosidade novas ferramentas e os modelos mais recentes
- A indústria já absorveu linguagens de alto nível, IDEs, autocompletar, agile e devops; sempre houve quem resistisse com nostalgia, mas no fim todos aderiram
- A diferença desta vez é a velocidade — a adoção de “cloud” podia ser adiada por anos sem matar a empresa, mas IA pode permitir só alguns meses
- A adoção de IA é o ponto de partida, não o placar
- Já se sabe como medir desempenho em engenharia — métricas DORA, confiabilidade, proporção de mudanças significativas e, no fim, receita e valor para o cliente
- Não há motivo para abandonar formas validadas de medição e trocá-las por pontuações de vaidade sobre IA
- A pergunta a fazer em pitches de fornecedores, revisões executivas e no feed do LinkedIn é: “isso é resultado ou volume?”
- A forma de trabalhar deve ser AI-first; a forma de medir deve ser battle-tested
1 comentários
Comentários do Hacker News
Esse fluxo estranho parece ter atingido o auge em fevereiro de 2026 com um post no blog da OpenAI [1]. É um post que apareceu recentemente na front page [2], sobre o processo de criar algo escrito 100% por agentes
Mas não explica o que exatamente é essa coisa, nem que valor ela entrega ao usuário. A descrição mais próxima disso é algo como “este produto foi usado internamente por centenas de pessoas, e também há usuários avançados internos que o usam todos os dias”
Ainda assim, o fato de ter 1 milhão de linhas de código é repetido duas vezes nas primeiras centenas de palavras
[1] https://openai.com/index/harness-engineering/
[2] https://news.ycombinator.com/item?id=48416264
Se tem “1 milhão de linhas de código” e foi “escrito 100% por agentes”, parece mais ainda. Ou então pode ser um menu em JS para a wiki do departamento que, na prática, recria o jquery em MS JScript e o transpila para JS 5
Por mais poderosos que os LLMs sejam, também parece que quase não haveria manutenção possível
https://github.com/openai/symphony
Num podcast, disseram que é um app Electron que os usuários baixam, então fazem novas builds periodicamente. Veja a seção “Autonomous Merging Flow” aqui: https://www.latent.space/p/harness-eng
Fico sempre lembrando de alguém da Microsoft que postou algo como “queremos 1 milhão de linhas de código por engenheiro por mês”. Para a maioria dos engenheiros com quem conversei, isso soou como sátira, mas na verdade não era sátira nenhuma e aparentemente refletia muito bem a atitude de muitos CEOs em relação à geração de código por LLM
Ainda assim, nos últimos meses parece que o entusiasmo exagerado por produzir quantidades de linhas de código impossíveis de manter esfriou um pouco. Visões mais práticas e realistas estão sendo compartilhadas publicamente com mais frequência, e parece que isso está chegando aos poucos até à alta cúpula de algumas empresas de tecnologia. Talvez ainda não esteja tudo perdido
Na prática, a maior parte do código não era testada
1 milhão de linhas por mês / 25 dias por mês / 8 horas por dia / 60 minutos por hora
Isso parece um problemão para quem faz code review
Fazer cada engenheiro gerar 1 milhão de linhas por mês sem pensar em como essas linhas vão dar dinheiro para a empresa, nem em quantos tokens vão ser queimados e a que custo no processo, aparentemente não era um plano tão bem pensado assim
Já dívida técnica não teve o mesmo efeito sobre a gestão. Dívida em geral pode ser um problema, mas costuma ser vista como algo que não precisa ser evitado nem resolvido até realmente virar um problema, então vai sendo sempre adiado
Vi isso acontecer nas duas pequenas empresas em que trabalho. Há alguns meses todo mundo recebeu Claude Cowork e ficou super empolgado; ainda usam todos os dias, mas eu diria que ficaram bem decepcionados em comparação com a mágica que esperavam
Há reclamações de que os resultados são medianos e prolixos, erram até coisas bem básicas, batem o tempo todo no limite de tokens, e muitas vezes é mais rápido fazer manualmente e voltar a resolver na mão
No começo até pode haver um uso inadequado da ferramenta, mas as pessoas estão percebendo que ainda existe uma distância entre o que os CEOs de IA, os vendedores de LinkedIn e os picaretas de suplementos de IA no YouTube dizem e a realidade
Se uma empresa disser “a IA tornou todo mundo mais produtivo, então precisamos de menos gente”, eu gostaria de ver as evidências. Hoje, não acredito que essas evidências existam
Na prática, estão falando besteira e usando IA como desculpa para reverter a contratação excessiva da época da covid. Ao mesmo tempo, isso faz a empresa parecer para os investidores como uma organização mais enxuta e mais eficiente em custos por ter adotado a tecnologia da moda
Eu achava que os investidores se importavam mais com lucro do que com adoção da tecnologia da moda
E uma empresa que diz “nós também usamos a tecnologia brilhante que qualquer idiota no quarto pode usar!” também é uma empresa totalmente sem competitividade
É infinitamente engraçado como, por décadas, nosso setor explicou que “o que fazemos é complexo e leva tempo, então não dá para medir produtividade facilmente”, mas aí apareceu a IA e de repente linhas de código, multiplicadores de N vezes e número de tickets por semana passaram a ser venerados como se fossem métricas úteis ou objetivas
Os motivos para rejeitar métricas como linhas de código não mudaram. O ponto central não é volume de código, mas qualidade do resultado. A IA também herda os mesmos problemas que as pessoas têm. Mesmo assim, por algum motivo estamos jogando fora tudo o que aprendemos, e isso é meio constrangedor
Porque sempre existiram chefes pouco envolvidos, mas agressivos e exigentes. Infelizmente, até chefes cuja principal função é arrancar mais esforço dos funcionários e que não contribuem em coordenação e afins ainda têm valor econômico
Por isso sempre existiu uma nuvem de duas abordagens sobrepostas: desempenho real e medições como linhas de código
A IA oferece todas as ferramentas para satisfazer esse tipo de chefe pouco envolvido, mas cheio de exigências. Então agora vai haver ainda mais gente gostando de usar linhas de código e adição de funcionalidades como métrica. Porque agora isso ficou fácil
Se um desenvolvedor sênior A+ passa 8 meses criando uma funcionalidade e no fim ela não é lançada ou o MVP é descartado, então esse desenvolvedor sênior A+ foi desperdiçado, e a produtividade dele acaba sendo igual à de dois engenheiros B+ no mesmo projeto
Isso é, na prática, um problema bem comum, mas normalmente é ignorado em contratação ou na alocação de recursos em projetos. A IA não deve mudar isso de forma significativa
O time pode até concluir o trabalho muito mais rápido, mas a camada burocrática de cima provavelmente continuará igual, e aí o ganho obtido com programação por IA vira algo mínimo. Para se adaptar à IA, seria preciso reconstruir a empresa de cima para baixo, e isso quase nunca vai acontecer
O empurrão pró-IA no final é estranhamente sem fundamento. Não há motivo, objetivo nem argumento de ganho; é só algo como “simplesmente use IA, desenvolvedores precisam aceitar o novo”
Em textos recentes que li, também vi críticas à IA com contexto curto que no fim acabavam como publicidade de IA, sem nada ligando uma coisa à outra
Investidores e grandes clientes também vão pensar duas vezes antes de assinar contratos importantes
Então é preciso usar IA. Não dá para ficar medindo mesquinhamente custo e benefício. O mundo está indo nessa direção, e se você quer viver de desenvolvimento de software, precisa estar nessa direção também
A parte “desta vez a diferença é a velocidade. Cloud dava para adotar com alguns anos de atraso e ainda sobreviver. IA pode ser questão de meses” é estranha
O autor parece entender que as alegações pró-IA feitas por empresas de IA sobre a indispensabilidade do produto são infalsificáveis, mas logo em seguida recua para um “espera aí, não pense que sou anti-IA”
Em que essa afirmação acima é mais rigorosa do que as alegações de produtividade que o restante do texto critica? Essa ideia de que, se você não adotar IA em poucos meses, não vai “sobreviver”?
Não vira verdade quando é um CEO de IA que diz, e também não vira verdade quando alguém que critica a bobagem de CEOs de IA diz exatamente a mesma coisa por qualquer motivo
Dizer que está demitindo gente por causa da IA deixa margem demais para interpretação e transfere a responsabilidade da decisão de si mesmo para a IA. Na prática, não dá para culpar a IA pelo que o CEO fez. Ele poderia ter requalificado os funcionários para se adequarem à IA, mas não fez isso. Por quê? Talvez porque não fosse por causa da IA
Eu realmente escrevi isso pessoalmente e, ao contrário do que digo em outros lugares, não foi feito como “AI slop”, então talvez eu só tenha ficado “desleixado de um jeito humano” no final
Você tem razão ao dizer que eu não dei sustentação suficiente com base naquela parte do “espera aí”, mas ainda mantenho a ideia de que as pessoas deveriam experimentar IA. Devem testar e descobrir de que forma isso as ajuda. Mesmo entre engenheiros parecidos, havia um espectro muito amplo de formas de extrair valor disso
O custo de realmente testar a ferramenta de forma adequada é quase zero, e a posição “adote de forma intencional e meça com métodos comprovados e tediosos” não é a mesma coisa que “se não adotar, morre”
Quando uma empresa diz que “a IA tornou todo mundo mais produtivo, então precisamos de menos gente”, implicitamente ela está dizendo que não quer se tornar mais produtiva
O que ela quer dizer é que quer a mesma produtividade pagando menos para um grupo menor e mais produtivo
Por que existe esse desequilíbrio entre o dinheiro que o empregador recebe por unidade de produção e o dinheiro que o funcionário recebe?
Se você obtém a mesma produção com menos pessoas, a produtividade da empresa ou do país melhorou
Se forem menos pessoas com a mesma produtividade, então a produção também cairá proporcionalmente, então isso não traz benefício para a empresa e, se houver custos fixos, pode até ser pior
https://www.mckinsey.com/featured-insights/mckinsey-explaine...
Eu vejo linhas de código como algo não muito diferente do tempo passado no escritório. Antes da pandemia, sempre diziam: “se a pessoa não está no escritório, como vou saber se está trabalhando?”
É simples. Basta olhar o que ela contribui para o negócio usando as métricas de resultado que já usamos para avaliar todos os funcionários
Acho que nós, engenheiros, temos grande responsabilidade pelo fato de linhas de código ainda serem tratadas como um ativo, e não como um passivo. Temos orgulho do que criamos, mas, para explicar o quão “grande” algo é, precisamos de uma métrica e acabamos voltando para a métrica mais fácil de contar
Precisamos mudar a terminologia. Em especial, deveríamos usar muito mais expressões como “...e o custo disso foi N linhas de código”. Também deveríamos dizer onde essas linhas de código foram gastas
“Implementei a nova funcionalidade X e só custou 200 linhas”
“Aquele bug foi muito difícil de encontrar, mas no fim custou só 6 linhas de código”
“No caso X fazíamos algo que no caso Y não fazíamos, mas descobrimos que essa distinção em si não era necessária. Então, ao corrigir o problema, economizamos 20 linhas de código ao mesmo tempo”
Linhas de código são o preço que pagamos. Nós não nos gabamos de ter gasto 200 dólares sem dizer o que compramos. Por que fazemos isso com linhas de código?
“Tive que pagar 200 dólares a mais porque me inscrevi tarde” e “Comprei um suporte de luminária de cerâmica artesanal pintado à mão por apenas 200 dólares. O industrializado da Amazon custa mais de 1.200 dólares” são coisas completamente diferentes, e no código correspondem exatamente à mesma diferença