FINDING DIRECTIONImagine a future where source code is no longer the primary version of a program. AI generates and modifies machine-oriented instructions directly, adapting them to the hardware, available resources, and changing demands. The software runs faster and more efficiently because its structure no longer needs to make sense to a person. A human-readable version is produced only when someone asks for one.
When the software fails, we ask AI to diagnose it. When we want to know what changed, AI reconstructs an explanation. When we need to verify its security or understand a decision, AI examines the same work and reports what it finds. AI has become the builder, maintainer, and interpreter of software no person can read directly.
What happens when we lose understanding? Do we give up our control with it?
This is not how software works today. Source code remains available, even when an agent writes it. But agents can already complete a large change in less time than it takes a person to understand what changed.
We may need a different kind of access to understand the work.
[ FIELD NOTE / CONTROL ]
Control depends on our ability to inspect what happened and intervene in what happens next.
A Tool for the Job
When I was rebuilding the forks on my ’94 Yamaha Virago, I needed to remove a nut on the outside of each fork tube. The nut turned, but the bolt inside the tube turned with it. To remove it, I needed to reach deep inside the fork and hold the bolt’s recessed Allen head stationary while I loosened the nut from the outside.
Socket extensions could reach the bolt, but the Allen-head socket I needed would not fit inside the tube. I found a nut whose outside dimensions fit the recessed Allen head and welded it to a three-foot length of rebar. Then I welded a T-handle to the other end.
The tool gave me access to the bolt head, allowing me to hold it still and separate the fork legs from the tubes. It was built for one job, but this kind of access is often what lets us understand and work on a part hidden inside a larger machine.
[ FIELD NOTE / ACCESS ]
Useful access is specific. It reveals the part we need to observe, test, or change.
A Working Model
Imagine an agent rewrites the synchronization engine in an application. To understand the change, I ask it to build a small interface with two simulated phones and a server between them. I edit the same record on both phones while one is offline, reconnect it, and step through what happens next. At each step, the tool shows the message being sent, the state stored on each device, the function handling the event, and the rule that resolves the conflict. I can delay, duplicate, or reorder messages and watch the result change.
That tool would teach me how the code works by letting me operate the conditions it was built to handle. If I can predict what will happen before advancing to the next step, I have developed a working model of the synchronization process.
[ FIELD NOTE / PREDICTION ]
Prediction turns understanding into something we can test.
Geoffrey Litt describes a similar approach using agent-written explanations, quizzes, custom debuggers, and small interactive worlds. His examples point toward several kinds of tools, each suited to a different gap in understanding.
Explanations and Maps
A pull request tells us what changed in the order the files happen to appear. An explanation can reorganize that material around how the change works. It can begin with the relevant background, establish the purpose of the change, trace the main path through the code, and connect each implementation detail to the larger design.
An architecture map can show which components now depend on one another. A data-flow diagram can follow a value from input to storage. A timeline can place asynchronous events in the order they occur.
[ FIELD NOTE / RELATIONSHIPS ]
The relationships between the parts can be difficult to hold in your head even when each part is readable.
A short quiz can reveal whether the explanation worked. Useful questions ask us to predict behavior: What happens if this request arrives twice? Which component owns the state after a failure? What runs next? A correct prediction shows more understanding than recognizing a description we just read.
Instruments and Simulations
Some code only makes sense while it is running. Debuggers, profilers, network traces, and runtime visualizations expose information the source cannot show on its own. A tool made for one change can select the state and events that matter, keeping the investigation focused.
Simulations go further by letting us change the conditions. We can slow the network, remove a service, increase the load, corrupt an input, or move backward through a sequence. The synchronization tool would be one of these temporary environments, giving someone a place to develop an intuition for one part of the software.
The representation must remain connected to actual behavior. A diagram generated from a description can repeat the agent’s assumptions. A useful instrument draws from runtime events, measurements, and tests we can change ourselves.
[ FIELD NOTE / EVIDENCE ]
When AI writes the software and explains how it works, we need runtime evidence to verify both.
Shared Tools
Understanding a change is rarely an individual problem. If every developer has a private conversation with an agent, the team can leave those conversations with different explanations of the same software. The tool should become a shared artifact people can inspect, question, and revise together.
The synchronization tool could live beside the pull request, with failure scenarios saved for the team and comments attached to the step where someone has a question. Everyone could inspect the same behavior and compare their conclusions in one place.
The tool for the motorcycle gave me enough access to finish the repair myself. Tools tied to actual software behavior could preserve that same access when source code no longer can. We should still be able to see what the machine is doing so we can act on it.