The IDE Is a Manual Control Loop

The editor is a great place to make a judgment. You can inspect the code, ask a question, redirect an approach, and see the result immediately. That tight loop is useful when the work is ambiguous or the consequence belongs to you. It is a terrible default for work the organization already knows how to perform.

When every file read, command, correction, and approval returns to the engineer, the agent has automated keystrokes without removing coordination. The person still assembles context, notices drift, decides when the evidence is enough, and carries the task across interruptions. The model may type faster. The operating system is still a human sitting at a screen.

That is why impressive editor sessions do not automatically become organizational capacity. They disappear when the operator closes the laptop. Nothing can queue the next task, enforce the same route overnight, or preserve the correction for another worker unless the process exists somewhere beyond the conversation.

An editor makes weak requirements survivable because a person is close enough to fill the gaps. The request says to clean up a flow. The engineer knows which behavior cannot change, which generated file should be left alone, and which test actually catches the failure. The agent borrows that knowledge one intervention at a time.

Move the same task into an unattended route and the missing contract becomes obvious. What may change? What must remain true? Which tools may act? What evidence earns completion? Where should the route stop instead of guessing? If those answers live only in the operator's reflexes, the work was never ready to run without them.

The answer is not to give the agent broader freedom. Write the contract the editor session was quietly supplying. Put repository rules near the code they govern. Turn common operations into stable commands. Name the exit evidence before implementation begins. Ambiguity that changes the consequence should route to its owner, not be smoothed over by a plausible patch.

Once a route is understood, let the factory own it. A bounded task should enter a queue with its specification, receive the context and tools its class of work requires, face independent checks, and return either evidence or a precise refusal. Nobody should have to keep a window open to make the process real.

This does not mean sending every change into a dark room. The route should be more observable than the editor session, not less. Record what context was used, what commands ran, which permissions were exercised, what failed, what changed, and why the gate accepted the result. Unattended work without a durable account is not autonomy. It is deferred surprise.

Keep the editor as an intervention surface. Use it to investigate a new failure, make a product tradeoff, or inspect a consequence the factory cannot yet reduce to a rule. Then capture what the intervention taught. If a person has to perform the same rescue again, the route is collecting labor instead of learning.

Some work should remain close to a person. A change involving irreversible data, a new authority boundary, or an unsettled product decision deserves direct judgment. A narrow refactor with deterministic proof does not. Treating both tasks as interactive editor sessions wastes judgment on one and disguises risk on the other.

Classify the work before choosing the interface. Ask how reversible the change is, whether the requirement has an owner, whether the environment can reproduce the behavior, and whether proof exists outside the builder's control. Those properties should decide the route, the budget, the permissions, and the human gates.

The specific model matters less once the contract is visible. Different workers can compete inside the same boundaries. A cheaper worker can take the routine path. A stronger one can handle uncertainty. A person can enter where a real decision remains. The standards survive all three because they belong to the factory, not the tool currently drawing the screen.

Minutes saved during a coding session are not the measure that changes a business. Count work that moves from a clear request to independently proven software without routine supervision. Count the interventions the route still needs. Then remove whole classes of intervention instead of celebrating faster typing between them.

That shift will remove jobs built around carrying tasks from screen to screen, repeating repository knowledge, and watching machinery that can be governed mechanically. Human judgment does not disappear, but it moves above the loop. People choose the destination, set the acceptable consequences, and decide where the machine has not earned authority.

The IDE will remain a powerful tool. It just cannot be the factory floor. If repeatable delivery depends on an engineer being present inside the interface, you have built a faster workstation, not autonomous capacity. Move the known route into machinery. Bring people back only when there is a decision worth making.