Como ler código: passadas focadas vencem a leitura linear

Por que código não se lê como um livro

Sean Goedecke argumenta que a leitura linear, do início ao fim, não funciona para código, mesmo sendo o modelo natural de leitura de textos em inglês. Ele aponta três diferenças estruturais. Primeira: o texto em inglês é organizado para o leitor humano, enquanto o código é organizado para ser executado por um computador - a ordem é determinada por fatores não humanos, e o autor não pode reordenar linhas apenas para facilitar a introdução ao leitor. Segunda: texto em inglês é lido como produto final, mas engenheiros passam a maior parte do tempo lendo diffs, ou seja, mudanças sutis em código existente, e não programas novos. O autor compara a ler rascunhos sucessivos de um artigo, consumindo apenas frases alteradas. Terceira: código é estruturalmente mais complexo que textos literários - dependências gramaticais de um livro costumam estar limitadas a um parágrafo, enquanto dependências de código podem atravessar todo o repositório. Ele também nota que bases de código grandes são mais longas: War and Peace tem cerca de 600.000 palavras, enquanto bases modernas têm esse número em linhas.

O problema: leitores ruins por padrão

Para Goedecke, programas grandes são complexos demais para uma única pessoa compreender totalmente, de modo que ler código é sempre um processo de compromisso: decidir o que compreender a fundo e o que passar por cima. A maioria das pessoas lê mal porque tenta percorrer o código como um livro e perde o fluxo de execução, ou lê só o diff e perde o significado das partes não editadas, ou desiste diante da complexidade e apenas adivinha.

O método: passadas focadas

A inspiração vem de um artigo sobre leitura de artigos de matemática, que descreve a técnica de "dyadic scanning": em vez de leitura sequencial lenta, fazer várias passadas - primeiro a estrutura geral, depois a subestrutura, por fim os detalhes.

Aplicado a código, isso significa ler fora de ordem. O autor escolhe um caminho importante (por exemplo, o caminho feliz da funcionalidade do diff) e rastreia quais funções chamam quais outras, para sentir o fluxo. Só depois disso presta atenção no que essas funções realmente fazem. Ele costuma fazer múltiplas passadas, cada uma seguindo um fio diferente: pega uma função ou dado e rastreia como é usada, espalhando-se por vários pontos de chamada, inclusive fora do diff. Em diffs pequenos, usa ctrl+f; em diffs grandes, abre no editor e navega com ctrl+click. A regra central é foco absoluto no que está sendo examinado no momento - todo o resto é tratado como caixa-preta.

Só quando se sente confiante sobre o diff ele o lê linearmente de ponta a ponta. Essa leitura final serve menos para aprender a estrutura (já conhecida) e mais para capturar trechos estranhos que escaparam às passadas anteriores; se algo aparecer, ele volta às passadas. Apesar de parecer lento, cada passada é rápida, porque não envolve decifrar cada linha.

Por que IA não elimina a leitura

Goedecke rejeita duas ideias comuns: a de que LLMs produzem código de alta qualidade sem supervisão, e a de que basta pedir a um LLM revisor para ler o código por você.

Sobre a primeira, ele reconhece que a qualidade depende de contexto: para ferramentas de uso próprio, talvez não seja preciso ler. Mas, tendo lido bastante código gerado por IA neste ano, afirma que erros grandes são rotineiros. Eles não são bugs - o código geralmente faz o que a IA queria -, mas problemas de alinhamento. Exemplo recente: uma mudança pequena para passar um valor extra pelo código existente virou um diff de três mil linhas, porque o agente notou uma condição de corrida e construiu maquinaria complexa para "corrigi-la" - condição que era inofensiva por design, sem impacto no cliente.

Sobre a segunda, o problema é o mesmo: mesmo sem erros técnicos, os valores técnicos do LLM não serão os seus nem os da sua empresa. Usar LLMs para ajudar a ler é possível, mas o resultado precisa ser revisado cuidadosamente, e o código em si também deve ser lido.