L'archéologue et son copilote : Malykhin discipline le LLM sur du Java 1.5

In plain terms

Un LLM lâché sur du code hérité produit des réponses qui sonnent justes mais ne collent pas au projet. La discipline qui marche : forcer l'assistant à travailler à partir de preuves - code, tests, artefacts - plutôt que depuis sa mémoire.

L'archéologue au travail

Nik Malykhin racontait le 16 juillet 2026 sur martinfowler.com sa modernisation d'une base Java 1.5 vers un environnement récent. Le contexte n'est pas commun : les outils d'analyse et de refactoring modernes n'aiment pas Java 1.5, et beaucoup refusent l'entrée. Son premier réflexe - demander directement des correctifs à l'assistant - a produit ce que Malykhin décrit comme des réponses "plausible" qui "did not hold up in the codebase" : ça ressemble à du bon Java 1.5, mais ça ne correspond pas au dépôt réel.

Le pivot est méthodologique. Plutôt que d'utiliser le LLM comme rédacteur, Malykhin l'a utilisé comme analyste et vérificateur, en ancrant chaque étape dans le dépôt : lecture attentive du code existant, validation d'hypothèses sur les tests et les traces d'exécution, refus d'aller plus vite que ce que le code lui-même permet d'affirmer. Le message de l'article est simple : la modernisation legacy avec un LLM ne va pas plus vite qu'un archéologue, elle va aussi lentement, mais avec moins de trous dans la démonstration.

Under the hood

Le pattern porte plusieurs noms dans l'outillage moderne des agents - evidence-first prompting, grounded reasoning, retrieval-first - mais il repose sur une même règle : chaque affirmation de l'assistant doit être adossée à un artefact du dépôt (un fichier, une ligne, un test). L'absence de cette contrainte est ce qui produit les "faux positifs" les plus coûteux d'un LLM sur du legacy : APIs postérieures à la version cible, méthodes qui n'existent pas, imports fantômes.

So what

Pour les équipes qui touchent à du legacy, le "copilote" ne sert pas à écrire, il sert à retrouver. La vraie productivité vient de faire lire l'LLM, pas de le laisser deviner. Le corollaire pour un CTO : les bonnes métriques d'un projet de modernisation assisté par IA ne sont pas "lignes générées" mais "hypothèses infirmées par le code lui-même". La différence entre les deux, c'est celle entre un projet legacy qui aboutit et un projet qui repart en dette.