O arqueólogo e seu copiloto: Malykhin disciplina o LLM em Java 1.5

Nik Malykhin precisava executar uma base Java 1.5 em hardware moderno. As primeiras respostas do seu LLM pareciam plausíveis, mas não resistiam ao escrutínio. A solução: parar de acreditar cegamente nele e obrigá-lo a se basear em evidências.

Em termos simples

Um LLM aplicado a código legado produz respostas que soam corretas, mas não se encaixam no projeto. A disciplina que funciona: forçar o assistente a trabalhar com base em evidências — código, testes, artefatos — em vez de recorrer à sua memória.

O arqueólogo em ação

Nik Malykhin contou em 16 de julho de 2026 no martinfowler.com sobre a modernização de uma base Java 1.5 para um ambiente recente. O contexto não é comum: as ferramentas modernas de análise e refatoração não gostam de Java 1.5 e muitas nem aceitam o código. Seu primeiro instinto — pedir correções diretamente ao assistente — gerou o que Malykhin descreve como respostas "plausíveis" que "did not hold up in the codebase": parecia bom Java 1.5, mas não correspondia ao repositório real.

A virada é metodológica. Em vez de usar o LLM como redator, Malykhin o utilizou como analista e verificador, ancorando cada etapa no repositório: leitura atenta do código existente, validação de hipóteses por meio de testes e traces de execução, recusa em avançar além do que o código permite afirmar. A mensagem do artigo é simples: modernizar legado com um LLM não acelera o processo como um arqueólogo, ele avança tão devagar quanto, mas com menos lacunas na demonstração.

Por baixo do capô

O padrão recebe vários nomes na instrumentação moderna de agentes — evidence-first prompting, grounded reasoning, retrieval-first — mas segue uma regra comum: toda afirmação do assistente deve estar vinculada a um artefato do repositório (um arquivo, uma linha, um teste). A ausência dessa restrição é o que produz os "falsos positivos" mais custosos de um LLM em código legado: APIs posteriores à versão-alvo, métodos que não existem, imports fantasmas.

E então?

Para equipes que trabalham com legado, o "copiloto" não serve para escrever, mas para encontrar. A verdadeira produtividade vem de fazer o LLM ler, não de deixá-lo adivinhar. O corolário para um CTO: as métricas corretas de um projeto de modernização assistido por IA não são "linhas geradas", mas "hipóteses refutadas pelo próprio código". A diferença entre as duas é a que separa um projeto legado que chega ao fim de um projeto que volta a acumular dívida técnica.