Doze maneiras de errar ao avaliar codificação assistida por IA

 (third-bit.com)
9 pontos por GN⁺ 2 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O valor da codificação assistida por IA é difícil de reduzir a números simples como linhas de código, quantidade de tickets ou satisfação, e a conclusão pode ser distorcida dependendo da forma de avaliação
  • Linhas de código e quantidades de commits, Pull Requests e tickets são apenas medidas de atividade; no momento em que viram meta, tornam-se fáceis de manipular e não distinguem qualidade
  • Taxa de aceitação e taxa de adoção são apenas sinais de que a sugestão pareceu plausível ou de que a ferramenta foi distribuída, mas não garantem precisão, segurança nem manutenibilidade
  • Tarefas de brinquedo, comparações antes/depois sem grupo de controle, comparações entre usuários voluntários e linhas de base fracas dificultam separar o efeito do LLM do viés de seleção
  • Para julgar produtividade, são necessárias métricas em nível de sistema que incluam revisão, depuração, segurança, dívida técnica, gargalos da equipe e mudanças de longo prazo

Objeto da avaliação e premissas

  • Ao tentar comprovar o valor de ferramentas de codificação assistida por IA em relação ao custo de assinatura, tanto linhas de código geradas, quanto tickets concluídos e pesquisas de satisfação de desenvolvedores podem levar a conclusões erradas de maneiras diferentes
  • O ponto central não é o valor da codificação assistida por LLM em si, mas o quão facilmente a forma de avaliar seus efeitos pode falhar
  • A mesma crítica, com pequenas adaptações, também pode ser aplicada a alegações sobre desenvolvimento ágil, desenvolvimento orientado a testes e outras práticas de desenvolvimento de software
  • Isso leva à conclusão de que, se a engenharia de software tivesse adotado de forma adequada os métodos de pesquisa das ciências humanas, estaria muito mais avançada nesse tipo de estudo de fenômeno

Métricas de produtividade equivocadas

  • Contar linhas de código geradas

    • Linhas de código são usadas há muito tempo como métrica substituta de produtividade, que é difícil de medir diretamente
    • LLMs podem produzir mais código, mas isso não garante resultados melhores
    • Uma equipe em que as linhas de código por desenvolvedor aumentaram 40% após adotar LLM pode ter medido verbosidade, não produtividade
    • Uma melhoria que substitui 2.000 linhas de lógica confusa por 200 linhas limpas parecerá perda em uma métrica baseada em linhas de código
    • Mais código aumenta o volume que precisa ser lido, mantido e depurado, e a carga futura deixada pela IA não aparece nessa contagem

  • Contar commits, Pull Requests e tickets

    • Em 2023, a McKinsey propôs medir a produtividade individual de desenvolvedores com base em quantidades de atividades como commits, Pull Requests e code review
    • Como na lei de Goodhart, quando uma medida vira meta, ela deixa de funcionar bem como medida
    • Se a quantidade de commits for rastreada, desenvolvedores passarão a criar commits menores e mais numerosos; se a quantidade de tickets for rastreada, os tickets serão fragmentados
    • Mesmo que os números melhorem, o trabalho subjacente pode não melhorar
    • Atividade não é resultado, e resultado também não se converte automaticamente em valor

  • Tratar taxa de aceitação de sugestões como sinal de qualidade

    • A alta taxa de aceitação de sugestões de assistentes de programação com LLM costuma ser apresentada como evidência de utilidade da ferramenta
    • Taxa de aceitação mede apenas se o código gerado pareceu plausível o suficiente para o desenvolvedor apertar Tab, e não mede precisão, segurança nem manutenibilidade
    • Desenvolvedores sob pressão de tempo aceitam mais sugestões, inclusive sugestões inseguras
    • Um estudo corporativo com 400 desenvolvedores confirmou taxa média de aceitação de 33% e alta satisfação dos desenvolvedores, mas não acompanhou a precisão nem a segurança do código aceito
    • Uma métrica que recompensa o que parece plausível não é uma métrica que recompensa o que é realmente bom

  • Tratar taxa de adoção como métrica de sucesso

    • Dizer que “foi alcançada uma taxa de adoção de 90% de ferramentas de IA em toda a organização de engenharia” é um resultado de compra e distribuição, não de produtividade
    • A taxa de adoção mede apenas se a ferramenta foi instalada e aberta; não informa se as sugestões são úteis, se os desenvolvedores as aceitam sem senso crítico, nem se as sugestões aceitas estão corretas
    • Quando alta adoção se combina com baixa qualidade de sugestão, os desenvolvedores podem gastar tempo gerenciando a ferramenta em vez de obter benefícios
    • Em um estudo da IBM sobre assistentes corporativos de programação com IA, a ferramenta frequentemente gerou aumento líquido de produtividade, mas esse ganho não foi uniforme entre todos os usuários
    • Adoção é mais fácil de medir do que benefício, e justamente por isso é mais fácil de ser reportada

Erros de desenho experimental

  • Cronometrar tarefas artificiais

    • Um estudo amplamente citado sobre o GitHub Copilot concluiu que usuários completaram uma tarefa 55% mais rápido do que não usuários
    • A tarefa era implementar do zero um servidor HTTP em JavaScript, o limite era 90 minutos, e os desenvolvedores não tinham outras obrigações naquele dia
    • O desenvolvimento real de software inclui explorar grandes bases de código que a pessoa não escreveu, entender requisitos ambíguos de tickets, coordenar-se com colegas e participar de reuniões
    • A velocidade em tarefas de brinquedo greenfield não prevê a velocidade nesse trabalho real
    • Em um ensaio randomizado controlado com desenvolvedores experientes de open source, ao contrário da expectativa dos participantes, conceder acesso a ferramentas de IA aumentou em 19% o tempo de conclusão da tarefa

  • Comparações antes/depois sem grupo de controle

    • Se uma equipe começou a usar LLM em janeiro e, em junho, os Pull Requests passaram a ser implantados mais rápido, pode parecer que a ferramenta gerou o efeito
    • Mas, se no mesmo período a empresa contratou 12 engenheiros, refatorou o pipeline de CI e trocou de provedor de nuvem, não é possível separar as causas
    • Sem um grupo que não adotou a ferramenta, é difícil distinguir o efeito do LLM dos efeitos de outras mudanças ocorridas ao mesmo tempo
    • A validade interna exige um contrafactual confiável que permita saber o que teria acontecido sem a ferramenta

  • Comparar adeptos com não adeptos

    • Comparar desenvolvedores que escolheram usar LLM com os que escolheram não usar significa comparar não duas condições, mas dois grupos diferentes
    • Adotantes iniciais tendem a ser mais dispostos a experimentar, mais familiarizados com novas ferramentas e possivelmente já têm alto desempenho em comparação com adotantes tardios ou não adotantes
    • Por causa do viés de seleção, a diferença observada pode refletir características das pessoas, e não da ferramenta
    • Como esse método tem o menor custo de execução, tornou-se um defeito comum de desenho em relatórios da indústria sobre produtividade com IA
    • Em um estudo longitudinal que acompanhou por dois anos o uso do Copilot em uma grande organização de TI, os usuários já eram consistentemente mais ativos do que os não usuários antes mesmo da adoção da ferramenta

  • Comparar IA com ‘nada’

    • Comparar desenvolvedores assistidos por IA com um grupo de controle que não usa ferramenta nenhuma leva a uma linha de base que não existe no trabalho real
    • Mesmo sem um assistente com LLM, desenvolvedores usam documentação, colegas e tempo próprio de raciocínio para resolver problemas
    • A pergunta importante é se a ferramenta com LLM é melhor do que as alternativas que o desenvolvedor já possui, e esse tipo de comparação é raro
    • Escolher uma linha de base fraca faz qualquer ferramenta parecer boa, mas isso não significa utilidade real

Omissões no escopo da medição

  • Medir só a metade fácil

    • LLMs aceleram a geração de código, e essa parte é fácil de medir
    • A metade mais difícil envolve o tempo gasto revisando código gerado por LLM, o tempo perdido depurando sugestões erradas porém confiantes, vulnerabilidades de segurança criadas por código plausível mas inseguro e dívida técnica criada por soluções improvisadas que ignoram o design ao redor
    • Em um estudo sobre código do GitHub Copilot, uma parcela significativa do código gerado continha vulnerabilidades de segurança, e desenvolvedores sob pressão de tempo aceitaram sugestões inseguras com maior frequência
    • Em uma avaliação de 2025 com cinco LLMs principais, nenhum modelo conseguiu produzir código de aplicação web que atendesse aos padrões industriais de segurança
    • Uma análise em larga escala de mais de 300 mil commits escritos por IA mostrou que mais de 15% introduziram pelo menos um problema de qualidade, e quase um quarto deles permaneceu no codebase no longo prazo
    • Se você mede apenas o aumento de entrada e ignora os custos que aumentam junto, isso não é medição; é marketing

  • É preciso medir o sistema, não o indivíduo

    • A velocidade individual de programação é a mais fácil de medir, por isso é frequentemente a escolhida
    • Mesmo que uma ferramenta de IA permita ao desenvolvedor escrever código 30% mais rápido, se o lead time entre ticket e produção da equipe não mudar, então o gargalo não estava na escrita de código
    • Se o volume de código gerado aumenta, aumenta também o volume de código a revisar; se a IA só aumenta a quantidade de código sem ampliar a capacidade de revisão, o cycle time pode piorar
    • Em pesquisa empírica com desenvolvedores profissionais, ferramentas de IA aumentaram a produção de contribuidores menos experientes, mas, para desenvolvedores seniores, a carga adicional de revisão causada por código gerado por IA elevou em 6,5% o trabalho de code review e reduziu sua produtividade em 19%
    • Otimizar apenas uma etapa do pipeline e ignorar o resto é um fracasso de pensamento sistêmico que se disfarça de estudo de produtividade

Distorções dos efeitos ao longo do tempo

  • Perguntar aos desenvolvedores se a produtividade aumentou

    • Resultados de pesquisa como “87% dos desenvolvedores sentem que são mais produtivos com ferramentas de IA” são frequentemente citados como prova de que a ferramenta funciona
    • Autorrelato pode gerar interpretações sistematicamente equivocadas por três motivos
    • Pelo efeito Hawthorne, as pessoas trabalham de forma diferente quando sabem que estão sendo observadas e avaliadas
    • Ferramentas novas produzem um efeito de novidade, em que tudo parece mais rápido simplesmente por ser novo, e essa sensação geralmente desaparece em poucas semanas
    • Por viés de desejabilidade social, respondentes tendem a dar a resposta que acreditam que a pesquisa quer ouvir, especialmente quando a liderança escolheu a ferramenta

  • Medir apenas durante o período do efeito de novidade

    • Se um estudo de quatro semanas encontrou aumento de produtividade, ele encontrou apenas um aumento de produtividade de quatro semanas
    • Desenvolvedores tendem a se engajar mais com uma ferramenta nova no período inicial, então o desempenho observado pode ficar inflado em relação à linha de base de longo prazo
    • Os efeitos realmente importantes aparecem ao longo de meses, não de semanas
    • Degradação de habilidade em tarefas delegadas à IA, dívida técnica acumulada a partir de sugestões erradas e mudanças na forma de colaboração da equipe exigem observação de longo prazo
    • Estudos desenhados para detectar ganhos de curto prazo não dizem o que acontece depois que o estudo termina
    • Em uma análise de 807 repositórios open source que adotaram o Cursor, a velocidade de desenvolvimento aumentou fortemente, mas de forma temporária, após a adoção, enquanto a complexidade do código e os alertas de análise estática aumentaram de forma significativa e persistente

Conclusão para uma interpretação melhor

  • Medir produtividade é algo difícil de reduzir a um único número ou a uma métrica substituta simples
  • Para julgar os efeitos da codificação assistida por LLM, é preciso olhar não só para a velocidade de escrita de código, mas também para revisão, depuração, segurança, manutenção, dívida técnica, gargalos da equipe e mudanças de longo prazo
  • Sem grupo de controle, linha de base realista, controle de viés de seleção, observação de longo prazo e métricas em nível de sistema, é difícil distinguir o efeito das ferramentas de IA do efeito de outras mudanças
  • Valores fáceis de medir são fáceis de reportar, mas valores fáceis não substituem os valores importantes
  • Para avaliar práticas de desenvolvimento de software, é preciso levar mais a sério os métodos de pesquisa das ciências humanas

Principais materiais citados

Leituras relacionadas

1 comentários

 
GN⁺ 2 시간 전
Comentários do Lobste.rs

  • O autor é um dos fundadores do Software Carpentry, então é alguém que pensa em formas melhores de medir produtividade de software desde muito antes do surgimento dos LLMs
    O estudo da METR citado é mais interessante do que pelo motivo que costuma aparecer. Para muita gente, a manchete foi “a IA tornou as pessoas mais lentas”, e isso pode ser refutado com o argumento de que os LLMs no estilo de 2025 ainda estão melhorando
    Mas o resultado mais interessante é que, em retrospecto, as estimativas que as próprias pessoas fizeram não batiam nem na direção com a realidade. Parece haver aí um elemento que a maioria das empresas ignora e que cria uma dificuldade fundamental para qualquer medição
    Nem mesmo a sensação vaga de que uma ferramenta torna as pessoas mais produtivas é confiável. As pessoas não sabem por si mesmas
    O estudo de acompanhamento acabou fracassando na prática por causa de viés de seleção

    The primary reason is that we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI
    O fato de os desenvolvedores se recusarem a trabalhar sem IA pode significar que a ferramenta funciona bem, ou pode significar que, à medida que passam a depender cada vez mais dela, sua capacidade de realizar tarefas mais difíceis se atrofiou completamente

    • Minha hipótese é que as pessoas tendem a depender mais dos LLMs justamente nas partes que realmente não querem fazer, e quando você está fazendo algo que não quer fazer o tempo sempre parece passar muito mais devagar

  • A frase “ferramentas novas parecem mais rápidas porque são novas, e essa sensação normalmente desaparece em poucas semanas” me parece invertida
    Ferramentas novas sempre me deixam mais lento porque eu ainda não estou familiarizado com elas. Claro, dá para ver o potencial de ficar mais rápido, mas ainda não consigo usá-las de forma eficaz

    • Há também outro efeito relacionado. Especialmente as pessoas que se voluntariam para testar ferramentas novas costumam ser entusiasmadas e acabam trabalhando mais fora do horário para compensar as falhas
      Por um tempo isso parece impressionante, mas no fim desaparece naturalmente quando elas voltam ao ritmo normal de trabalho

  • Medir é difícil. Em certo sentido, tentar medir programação assistida por IA pode ser em si um erro
    É claro que ela torna algumas tarefas mais rápidas, e quase certamente existem maneiras de usá-la para ganhar velocidade
    A pergunta mais importante é quais são essas maneiras e o que se perde no processo

    • Produtividade e aumento da velocidade de execução não são a mesma coisa. Mesmo que uma tarefa fique mais rápida, isso pode não ter efeito positivo na produtividade se essa tarefa não era o gargalo ou se o ganho de velocidade vier com custos
      O texto original trata disso como “medir apenas a metade fácil”\n\n- Em resposta à pergunta “se na próxima semana um gerente pedir que você prove que a ferramenta de IA para programação assinada pela empresa vale o preço da assinatura, você mediria linhas de código geradas ou número de tickets fechados?”, o Claude já mede nas faturas linhas de código, taxa de aceitação e uso de tokens
      O número de tickets fechados seria a velocidade da equipe, mas a saída da IA é apenas um dos fatores, e o Jira mede a velocidade do sprint
      De qualquer forma, essa pergunta pode ser facilmente manipulada dependendo do que você acha que o gerente quer como resultado, e provavelmente isso já deve estar acontecendo

  • Acho que o autor deixou de fora uma pergunta muito importante: “que tipo de dano o uso de IA causa?”
    Na minha visão, essa pergunta é mais fundamental do que qualquer outra. Porque dano é muito mais fácil de medir. Basta colocar uma instância de Git forge no ar e ver os crawlers vindo em cima como tubarões sentindo cheiro de sangue
    O fato de scrapers estarem fazendo DDoS na internet inteira é um problema mensurável, e para quem faz self-hosting é uma realidade sentida na prática
    Os supostos benefícios da IA, que já são difíceis de medir corretamente, realmente valem aceitar os danos muito concretos causados pelos crawlers?
    E se somarmos a energia necessária para operar os crawlers e processar essas requisições, os custos de treinamento, os custos de inferência e a necessidade de data centers cada vez maiores?
    Acho muito mais importante perguntar se esses supostos benefícios da IA valem o sacrifício de tudo isso

    • O que sempre me frustra nesse tipo de questão de “deveríamos estar falando sobre X” é que já vi exatamente o argumento oposto em textos sobre danos ecológicos
      Algo como “mesmo que isso não consumisse energia, ainda geraria código ruim, então isso é muito mais importante de discutir”, ou “por que falar de programação, o verdadeiro dano é o uso para vigilância”, e assim a conversa vai sendo desviada