I started a port of a very old project from assembly and Pascal to Swift and Metal with Codex. While it worked, it kept reporting what it was doing. At one point I realized I did not understand about half of the explanation.
My reaction was to joke that either it was extremely clever or I had become extremely stupid. The more useful response was to ask it to write more simply.
That sounds like a small communication preference. In a port, it is part of the engineering work. I need to understand which behavior is being preserved, which representation is changing and where the agent is making a new assumption. If the explanation hides those decisions behind unfamiliar terminology, I lose a way to review the result.
Old code can contain more than an algorithm. It may depend on integer overflow, a particular floating-point behavior, memory layout or the order in which operations occur. Assembly makes some of those choices explicit. A high-level translation can accidentally smooth them away.
Moving computation to Metal introduces another kind of change. Work that used to happen in one sequence may be distributed across GPU threads. The calculation may be mathematically similar while its storage, synchronization and numerical behavior differ. A successful build says little about whether those differences matter to the output.
I would break the explanation into three ordinary questions: what did this part do before, what does it do now, and how can I compare the two? That is enough structure to make a complicated migration discussable without pretending every low-level detail is simple.
A small known input is particularly valuable. It gives both implementations something specific to process. Intermediate values can then reveal where the results diverge, instead of leaving the whole application as one enormous pass-or-fail test. For visual code, a final image is useful, but a numerical mismatch may become easier to understand earlier in the pipeline.
The port was still in progress when I wrote about it. The interesting moment was not a finished performance result. It was noticing that an agent can move through a technical transformation faster than its owner can comfortably follow the narration.
I want the speed, but I also want the work to remain mine in a practical sense: something I can understand, question and maintain. Asking for plain language is one way to preserve that connection. If an explanation cannot tell me what changed and why, adding more technical words will not make it better.