In modernizing the old system, Copilot first organizes the evidence

The first time I pulled a Java project from the 1.5 era onto a modern machine, the first thing that popped up was not the code problem, but the evidence problem. Whether the build can be reproduced, whether the test output is the same, whether the failure point comes from the JVM, the image, or the source code, these things determine how to proceed earlier than “start refactoring”. The biggest fear when modernizing old systems is not that the changes are slow, but that it is impossible to tell what happened after the changes.

Fix the scene first, then the subsequent actions will be meaningful. The most valuable thing in that step is not the completion in the IDE, but a box that can be run repeatedly: the old JDK, old build tools, old entrances, and old test commands are all locked into Docker. Commands like the following are not pretty, but they work:

docker run --rm -v "$PWD":/src -w /src legacy-jdk8 \
  sh -lc './gradlew test 2>&1 | tee logs/baseline.log'

This command has only one function: to fix “today’s failure” into replayable evidence. Without it, every subsequent success might just be the result of circumstances that happened to be forgiving. The role of Copilot here is also very clear. It is not to replace judgment, but to help sort out traces: repeated errors in long logs, paths that echo each other in build scripts, and several recurring entries in old tests can all be used for a rough screening first. What is sifted out is not a conclusion, but a map to start with.

When it comes time to actually go under the knife, the area of ​​change must be very narrow. The easiest way for old projects to overturn is to change the package name, build, entry, and test all at once. In the end, you can’t even tell which step broke the system. A more stable approach is to seize the smallest gap first: for example, cover the old entrance with a layer of adapters, first allow the new tool chain to stand outside the old world and see the structure clearly, and then slowly move in. Copilot is very suitable for handling this kind of mechanical work: filling imports, moving configurations, extracting repeated fragments, and generating temporary test skeletons. Let the model do these things, and the efficiency is indeed high; but it is still up to people to decide whether this seam should be cut and what behavior should be preserved after cutting.

It is also easy to be deceived by appearances when it comes to testing. Passing the old test does not mean that modernization is safe, it only means that certain historical behaviors have not been broken up yet. The tests of many old projects are more like behavioral snapshots than business semantic specifications. Green is just green and cannot be directly interpreted as “understanding the system”. One of the most important actions during the transformation is to add new, narrower test boundaries to each small incision, so that the test gradually changes from “historical legacy” to “current constraints”. Copilot can help break down old assertions, complete templates, and roll out duplicate test shells. However, what semantics should be maintained in the test and the model cannot make decisions for the system.

In archaeological modernization, the most reliable division of labor is actually very simple: the environment and logs are responsible for nailing the facts, Copilot is responsible for moving bricks and translating, and people are responsible for deciding which history should be retained and which history should be cut off. Once a model is arranged to explain the system’s past, it often makes guesses more convincing than evidence; putting it back into the position of evidence management and mechanical organization, it becomes more like a truly useful assistant.