一度きりではなく体験型で移行する

It worked, but I could not tell what happened

Here, migration means moving software to a different framework or configuration. The speaker previously asked an agent to handle a framework migration as a script that ran everything at once. The script appeared to work successfully.

However, the speaker did not develop a feel for what the script had actually done. Even though the migration looked complete, he did not understand well enough what changed, or in what order. This does not mean that the migration necessarily failed. It means that a working result and understanding the process are different things.

With a one-shot approach, the agent performs many operations together. A person can check the final state, but the decisions and changes along the way become hard to see. If you see only the result, you lack material for making your own decisions when a similar problem appears next time.

Turn the migration into a microworld

So the speaker did not make the migration only a script for shipping. He had an agent build a small environment where he could experience the migration. This is a microworld. A microworld is an environment that deliberately bounds a subject and lets people understand how it works by operating inside it.

This environment had the following features:

1. Put the old site and the new site side by side.
2. Advance the migration one step at a time with a "Next" button.
3. Show the commands run at that stage.
4. Show files moving in the file tree.

In other words, the agent advances the process automatically, but people do not have to wait until the end. Each time they press the button, they can connect the old state, the new state, and the operation that was performed. The design lets them follow the migration without carrying out every step by hand.

Figure 1. A screen for migrating a website. The source and destination sites are shown side by side. Watch 00:14:15 in the video

Evidence for Figure 1. The screen places a terminal and progress display beside previews of the source and destination sites. This supports the explanation of checking a migration step by step. However, this screen alone does not establish the specific framework names or internal operations.

Visible iteration builds understanding

This method is not a choice between "automation or understanding." It keeps the automation, divides the work into small stages, and shows each stage to a person.

For example, suppose that files move at one stage and another command runs afterward. A person can check that operation and the difference between the old and new sites at the same time. This creates a connection: "After this operation, this part changed." As these connections build up from stage to stage, a feel for the migration as a whole develops.

Figure 2. A screen showing terminal migration logs and the source and destination file trees. You can check the file structure and progress at the same time. Watch 00:14:26 in the video

Evidence for Figure 2. The migration screen displays terminal progress messages and the source and destination file trees. Therefore, it is not a diagram explaining the entire inside of the migration. But it clearly shows a design where "the commands that ran" and "the file changes" can be observed in the same scene.

Breaking the process into stages also makes problems easier to think about. You can see at which stage the state changed instead of examining only the final state. This is similar to the debugger in the previous chapter, which showed an interpreter's processing on a timeline. Both present a hard-to-see internal process in sequence.

However, the migration environment is not only for investigating bugs. Its purpose is to divide a large migration into units that people can understand.

Figure 3. A screen showing the control for moving to the next migration stage and the content-collection command run at that stage. You can follow the progress while viewing the site preview. Watch 00:14:32 in the video

Evidence for Figure 3. The migration control screen has advanced to the next stage, while the terminal command and website preview are shown together. This presentation shows the migration as an ordered task rather than one opaque operation. The plan does not establish the meaning of the specific command or the exact file operations.

Is the purpose shipping or understanding?

In this example, we can think of software as having two different purposes.

• Software for shipping completes the migration until the product can provide its functions to users.
• Software for understanding shows states and processes so that people can learn how the system works.

An agent can be asked to write only the code that completes the migration. But that was not all the speaker wanted. He also had the agent create a temporary UI (user interface) for understanding the migration.

Here, "temporary" means that it does not need to be a product feature supported for a long time. It is enough for the UI to be useful while people learn, check, and make decisions about the migration. This makes it possible to add the displays needed for understanding more freely than in a normal product screen. The important point is that the agent creates not only a completed change, but also an environment where people can learn from the change.

Example: If a team migrated a site

This is an example showing the idea, not a specific team procedure described by the speaker.

Suppose a team is moving a site to a new configuration. If they run only one script, it may be difficult for the team to share the decisions along the way, even when the new site appears at the end. In a staged environment, one person can confirm, "We are moving these files and running this command now." Another person can look at the same stage and ask questions there.

This is not a way to slow the migration down by doing it manually. The agent advances the process and shows people the important stages. It combines the speed of automation with the understanding that comes from seeing the process repeatedly.

What this example shows

A script that runs everything at once is convenient for obtaining the final result. However, the result alone may not provide enough material for understanding what happened. When you have a comparison of the old and new sites, commands for each stage, file movement, and progress displays, you can follow the migration process.

This example does not say, "Do not automate migrations." It says that even an automated change should provide a way for people to experience its process. Then people can let the agent do the work while deepening their understanding without becoming detached from the system.

This also connects to the debugger microworld from the previous chapter. An agent can write not only code that ships a change, but also an environment that helps people understand the change and participate in the next decision. Automation and understanding are not opposites. By designing visible iteration, you can achieve both at once.