El arqueólogo y su copiloto: Malykhin disciplina el LLM en Java 1.5

Nik Malykhin debía ejecutar una base de Java 1.5 en hardware moderno. Las primeras respuestas de su LLM eran plausibles, pero no se sostenían en el repositorio. La solución: dejar de creerle ciegamente y obligarlo a respaldarse en pruebas.

En términos sencillos

Un LLM lanzado sobre código heredado produce respuestas que suenan correctas pero no encajan con el proyecto. La disciplina que funciona: forzar al asistente a trabajar a partir de pruebas —código, tests, artefactos— en lugar de desde su memoria.

El arqueólogo en acción

Nik Malykhin contaba el 16 de julio de 2026 en martinfowler.com su modernización de una base Java 1.5 hacia un entorno reciente. El contexto no es común: las herramientas modernas de análisis y refactorización no soportan bien Java 1.5, y muchas ni siquiera lo aceptan. Su primer instinto —pedir correcciones directas al asistente— generó lo que Malykhin describe como respuestas "plausibles" que "did not hold up in the codebase": parecen buen Java 1.5, pero no coinciden con el repositorio real.

El cambio es metodológico. En lugar de usar el LLM como redactor, Malykhin lo empleó como analista y verificador, anclando cada paso en el repositorio: lectura atenta del código existente, validación de hipótesis mediante tests y trazas de ejecución, rechazo a avanzar más rápido de lo que el propio código permite afirmar. El mensaje del artículo es simple: modernizar legacy con un LLM no va más rápido que un arqueólogo, va igual de lento, pero con menos agujeros en la demostración.

Bajo el capó

El patrón tiene varios nombres en la herramienta moderna de agentes —evidence-first prompting, grounded reasoning, retrieval-first— pero se basa en una misma regla: cada afirmación del asistente debe respaldarse en un artefacto del repositorio (un archivo, una línea, un test). La ausencia de esta restricción es lo que produce los "falsos positivos" más costosos de un LLM en legacy: APIs posteriores a la versión objetivo, métodos que no existen, imports fantasma.

¿Y entonces?

Para los equipos que trabajan con legacy, el "copiloto" no sirve para escribir, sino para encontrar. La verdadera productividad viene de hacer que el LLM lea, no de dejar que adivine. El corolario para un CTO: las buenas métricas de un proyecto de modernización asistido por IA no son "líneas generadas", sino "hipótesis refutadas por el propio código". La diferencia entre ambas es la que separa un proyecto legacy que llega a buen puerto de uno que vuelve a generar deuda técnica.