Археолог и его штурман: Малыхин приручает LLM для Java 1.5

Ник Малыхин должен был запустить базу Java 1.5 на современном оборудовании. Первые ответы его LLM казались правдоподобными, но не выдерживали проверки. Решение: перестать верить ему на слово и заставить опираться на доказательства.

Простыми словами

LLM, выпущенный на унаследованный код, даёт ответы, которые звучат правильно, но не соответствуют проекту. Рабочая дисциплина: заставлять помощника работать на основе доказательств — кода, тестов, артефактов — а не из своей памяти.

Работа археолога

26 июля 2026 года Nik Malykhin рассказывал на martinfowler.com о своей модернизации Java-базы 1.5 до современной среды. Контекст необычен: современные инструменты анализа и рефакторинга плохо работают с Java 1.5, и многие просто отказываются с ним взаимодействовать. Его первый порыв — напрямую просить помощника о исправлениях — привёл к тому, что Malykhin описывает как ответы «правдоподобные», но «не выдерживающие проверку в коде»: это выглядит как хороший Java 1.5, но не соответствует реальному репозиторию.

Перелом произошёл на уровне методологии. Вместо того чтобы использовать LLM как писателя, Malykhin использовал его как аналитика и проверяющего, опираясь на каждый шаг в репозитории: внимательное чтение существующего кода, проверка гипотез на тестах и трассировках выполнения, отказ идти быстрее, чем это позволяет сам код. Послание статьи простое: модернизация legacy с LLM не идёт быстрее, чем у археолога, она так же медленна, но с меньшими пробелами в доказательствах.

Под капотом

Этот подход в современном инструментарии агентов называют по-разному — evidence-first prompting, grounded reasoning, retrieval-first — но у него одно общее правило: каждое утверждение помощника должно основываться на артефакте репозитория (файл, строка, тест). Отсутствие этого ограничения порождает самые дорогостоящие «ложные срабатывания» LLM на legacy-коде: API более поздних версий, несуществующие методы, мнимые импорты.

Что делать

Для команд, работающих с legacy, «копилёт» не предназначен для написания, а для поиска. Реальная продуктивность заключается в том, чтобы заставить LLM читать, а не гадать. Следствие для CTO: правильные метрики проекта по модернизации с помощью ИИ — это не «строки, сгенерированные», а «гипотезы, опровергнутые самим кодом». Разница между этими двумя подходами — это разница между проектом legacy, который завершится успешно, и проектом, который снова обернётся техническим долгом.