2026-09-17

Autonomy Stops Where Observation Stops

An agent cannot take responsibility for a system it cannot see. Give it half the environment and you get half the autonomy, no matter how capable the model is.

Every blind spot becomes human work

Most codebases show agents a flattering version of reality. The repository is visible. The test suite is runnable. A development server may even start. Then the real product disappears behind accounts, integrations, production-shaped data, background jobs, timing, permissions, and user behavior the agent cannot reproduce.
The agent can still produce code in that environment. It just cannot own the consequence. When a failure depends on an external service or a particular state transition, a person has to recreate the conditions, explain what happened, and judge the repair. The machine did the typing. The human remained the driver.
That is why better generation alone does not create a self-driving codebase. Autonomy grows when the factory can observe the same surfaces that determine whether the product works. Wherever observation ends, handoff begins. Wherever handoff begins, the organization is still paying somebody to close the loop by hand.

Visibility is useless without an action path

Logs and dashboards do not make a system agent-legible by themselves. The worker needs a stable route from a signal to the exact revision, environment, input, and state that produced it. Then it needs bounded tools to reproduce the failure, change the artifact, and collect new evidence.
A console full of errors is merely a larger pile of context if the agent cannot tell which ones matter. A trace is only useful when it can be connected to the code that ran and the conditions around it. A browser tool is theater when authentication, test data, or a third-party boundary blocks the path that users actually take.
The factory has to turn observation into verbs. Reproduce this incident. Restore this state. Exercise this integration. Compare this behavior before and after the change. Those routes should be narrow, repeatable, and safe enough to run without a person rebuilding the stage for every attempt.

A failure should improve the route

A useful failure does more than produce a patch. It reveals what the factory could not see or prove. Maybe the test data hid a production shape. Maybe the environment could not exercise a permission boundary. Maybe the acceptance check watched the response code while the real defect lived in a background effect.
Capture that gap with the repair. Add the reproduction, the fixture, the probe, or the gate that would have exposed the problem earlier. The next agent should inherit a wider field of view. If the same class of failure still needs the same human explanation next month, the code changed but the factory learned nothing.
This is where memory becomes operational. A warning in a chat transcript is easy to lose and impossible to enforce. A reproducible scenario and a mechanical refusal survive the session. They also make cheaper workers more useful, because the environment carries knowledge the model no longer has to rediscover.

Measure closed loops, not generated patches

Patch volume is a terrible measure of autonomy. A factory can generate thousands of changes while people still choose the bugs, assemble the context, rescue failed runs, review every line, and watch production for the consequences. That is assisted typing at industrial scale.
Measure the loops that close without routine intervention. How often can the system detect a meaningful failure, reproduce it, propose a repair, prove the behavior under independent conditions, release within its authority, and watch the result? When it cannot, record which missing capability forced the handoff.
That record gives investment an order. Do not make every environment perfect. Fix the visibility gaps that repeatedly return valuable work to people. Build the next tool or fixture where it removes an entire class of intervention, then prove that the intervention actually disappeared.

Move people above the observation loop

People should decide which outcomes matter, which risks are acceptable, and what evidence earns authority. They should not spend their days copying error messages, restoring test accounts, narrating the same system behavior, or checking whether a familiar repair held. Those are repeatable operations. They belong in the factory.
Some engineering and coordination jobs are built around exactly that work. As codebases become legible to agents, those jobs will shrink or disappear. The remaining human role is not to hover over the machine. It is to choose the destination, define the boundaries, and judge consequences the system cannot reduce to a stable rule.
Our position is simple: the self-driving codebase arrives one closed loop at a time. Give the factory eyes, but also give it a safe route from what it sees to what it may do. Then make every failure sharpen that route. Autonomy does not begin when the agent writes more code. It begins when fewer consequences have to be explained by a person.
In response to Towards Self-Driving Codebases by Detail.