The archaeologist and his copilot: Malykhin disciplines the LLM on Java 1.5

In plain terms

A LLM unleashed on legacy code produces answers that sound right but don't fit the project. The approach that works: forcing the assistant to work from evidence - code, tests, artifacts - rather than from its memory.

The archaeologist at work

Nik Malykhin recounted on July 16, 2026, on martinfowler.com his modernization of a Java 1.5 base to a recent environment. The context is not common: modern analysis and refactoring tools do not like Java 1.5, and many refuse entry. His first reflex - asking the assistant directly for fixes - produced what Malykhin describes as "plausible" answers that "did not hold up in the codebase": it looks like good Java 1.5, but it does not match the actual repository.

The pivot is methodological. Instead of using the LLM as a writer, Malykhin used it as an analyst and verifier, anchoring each step in the repository: careful reading of the existing code, validation of hypotheses on tests and execution traces, refusal to go faster than what the code itself allows to assert. The message of the article is simple: modernization of legacy with a LLM does not go faster than an archaeologist, it goes as slowly, but with fewer holes in the demonstration.

Under the hood

The pattern has several names in the modern tooling of agents - evidence-first prompting, grounded reasoning, retrieval-first - but it relies on the same rule: each assertion of the assistant must be backed by an artifact from the repository (a file, a line, a test). The absence of this constraint is what produces the most costly "false positives" of a LLM on legacy: APIs posterior to the target version, methods that do not exist, ghost imports.

So what

For teams that touch legacy, the "copilot" is not used to write, it is used to find. The real productivity comes from making the LLM read, not letting it guess. The corollary for a CTO: the good metrics of an AI-assisted modernization project are not "lines generated" but "hypotheses refuted by the code itself". The difference between the two is that between a legacy project that succeeds and a project that goes back into debt.