Os LLMs tornaram-se quase perfeitos na geração de código, mas isso não é o fim da história. O fato de o código ser formalmente correto não significa que não esteja introduzindo abstrações desnecessárias, criando duplicatas ou simplesmente tomando decisões ruins no geral. Esta não é uma observação inovadora; a maioria das pessoas que fez vibe-coding em um projeto percebeu que cada recurso adicional às vezes pode levar a uma explosão de linhas de código (LOC). Isso resulta em uma perda de agência humana, porque em projetos que adicionam milhões de LOC por mês, é difícil para os humanos acompanhar. Algumas pessoas podem dizer que isso não é um problema, porque confiam em seus agentes para lidar com isso. Tenho más notícias para você: os agentes também não conseguem realmente lidar com a desleixo.

Vindo de uma formação em física, sempre tive uma abordagem experimental/quantitativa para resolver problemas. Quando comecei na Earendil, com a tarefa de descobrir como medir a desleixo do código, meu instinto natural foi primeiro mergulhar na literatura e depois verificar o que outras empresas estavam fazendo. Para ser franco, com exceção de alguns artigos de pesquisa perspicazes, fiquei decepcionado com o quão "baseado em vibes" o setor parece no momento. Em minha pesquisa e no X, fui constantemente bombardeado com mensagens como "Agentes de codificação de ponta a ponta", "IA que não apenas sugere código — ela o entrega" ou "Avaliação em nível humano sem custo em nível humano". Que, como todos os bons contos, têm um fundo de verdade. Os LLMs são capazes de escrever código quase perfeitamente correto. Isso se deve à escalabilidade e verificabilidade do código. É bastante simples deixar os LLMs gerarem código e depois deixar esse código ser verificado por testes ocultos, o que resulta em um sinal de recompensa claro. Em nítido contraste com isso, verificar a 'desleixo' desse código frequentemente requer intuição e bom gosto humanos, e é uma tarefa extremamente difícil em geral.

Acho que a melhor maneira de ilustrar por que isso acontece é passar pelas possíveis maneiras de medir a desleixo. IA como juiz: Esta é provavelmente a maneira mais comum de avaliar a qualidade do código no setor e, pelas minhas observações, raramente funciona. A maneira mais ingênua de fazer isso, ou seja, perguntar aos modelos quão bom é o código em uma escala de 1 a 10, é basicamente equivalente a um gerador de números aleatórios. A abordagem mais sofisticada, ou seja, tentar dar ao modelo juiz duas soluções A e B, e então deixá-lo decidir qual prefere, tem a desvantagem de o modelo mudar sua preferência quando você renomeia as soluções. Estou sendo um pouco sarcástico aqui e o efeito não é tão pronunciado com modelos maiores, mas o ponto principal ainda se mantém. Pedir aos LLMs que julguem o código que escrevem não substitui uma avaliação adequada. Embora existam algumas abordagens interessantes com rubricas ou os LLMs escrevendo testes, elas ainda estão longe de realmente eliminar a desleixo.

Humanos julgam a IA: Se ignorarmos o fato de que há uma enorme diversidade na qualidade dos engenheiros de software, esta seria a melhor solução para garantir que o código permaneça legível por humanos. Com a desvantagem de que isso não é escalável para treinar IA ou ter grandes benchmarks com vários provedores de modelos e harnesses. O método mais simples: Em minha pesquisa e testes, simplesmente pegar a mudança no número de LOCs tem sido uma métrica surpreendentemente eficaz para a desleixo, com a ressalva irônica de que se começássemos a otimizar para isso, deixaria de ser uma medida significativa. As próximas duas medidas me foram apresentadas pelo artigo Slop Code Bench, e pareciam promissoras porque conseguiam separar bases de código legadas do slop de LLM muito bem. Verbosidade: Tenta medir a quantidade de linhas duplicadas e desnecessariamente verbosas. Erosão: Tenta medir quanto da massa de uma base de código está concentrada em algumas funções grandes e complexas.

Entidades-chave: Empresas: Earendil