Código é subproduto do entendimento

O “bolsão do entendimento”

A publicação parte de dois episódios recentes: a Conjectura de Jacobian teria sido refutada por um contraexemplo descoberto por um LLM, e uma conversa de Terence Tao com o ChatGPT ganhou repercussão. O interesse do autor está menos na matemática em si do que no formato da interação. Tao começa por um detalhe preciso, faz perguntas estreitas e aprofunda ou redireciona a investigação conforme seu próprio raciocínio avança. Para o autor, essa é a imagem de um especialista usando um LLM em seus próprios termos.

Usuários comuns, em contraste, tendem a formular perguntas amplas, vagas e limitadas pelo próprio nível de compreensão. O LLM então espelha essa formulação superficial, o que pode produzir respostas aparentemente adequadas, mas frágeis nas bordas do conhecimento do usuário. A tese é que os modelos extraem de cada solicitação o máximo de entendimento disponível nela: palavras específicas e termos de um domínio orientam a profundidade da resposta antes mesmo de ela ser montada. “Deixe este código limpo”, por exemplo, oferece menos direção do que pedir uma revisão segundo os princípios DRY.

Perguntas estreitas e entendimento cumulativo

O autor recomenda pedidos curtos, específicos e sucessivos, em vez de instruções extensas que solicitam relatórios abrangentes e podem resultar em muito texto de aparência convincente, mas pouco conteúdo útil. A compreensão deve ser construída por etapas, permitindo que cada resposta informe a próxima pergunta. Em vez de tentar obter imediatamente um produto final, o usuário deveria usar o LLM para esclarecer conceitos, testar interpretações e delimitar problemas.

Segundo o texto, essa compreensão compartilhada é especialmente necessária quando a tarefa exige especificidade. Termos próprios de um domínio e perguntas bem focadas colocam o modelo no contexto adequado; se o usuário não entende algo, pode apresentar o cenário e deixar que o LLM preencha parte do que falta. Ainda assim, a capacidade bruta do modelo não substitui a curiosidade nem o conhecimento necessário para formular boas perguntas. A conclusão intermediária do autor é que curiosidade e precisão importam mais do que simplesmente contar com um sistema capaz.

O código como consequência

Como engenheiro de software, o autor diz ter mudado o foco de pedir código para pedir clareza. No planejamento de funcionalidades, usa o LLM para investigar reaproveitamento, padrões existentes, arquitetura, gargalos, extensibilidade e efeitos sobre outras partes da base. Ao gerar ou revisar código, pergunta sobre casos extremos, desempenho, segurança, permissões, simplificação, funções compartilhadas e consequências posteriores. Na leitura e revisão, explora chamadas de funções, fluxos de usuário, propagação de erros, documentação, testes e possíveis lacunas.

Para documentação, descrições de pull requests e resumos, pergunta sobre implicações para o produto, uso posterior das funções, diagramas de arquitetura e quais engenheiros deveriam ser informados. O valor principal, para ele, está em ampliar seu entendimento do produto em diferentes níveis e por diferentes caminhos: infraestrutura, experiência do usuário, mudanças recentes, problemas abrangentes, melhorias que atravessam componentes, fragilidades arquiteturais e possíveis bugs latentes. Esse entendimento também pode melhorar a documentação e disseminar conhecimento pela empresa.

A conclusão é que, embora seja pago para produzir código, o código permanece um subproduto do entendimento construído com o auxílio do LLM.