Setting the cursor
Trading delayed correction against delay itself
In a previous essay I argued agents allow us to choose whether to pay for comprehension and do something ourselves, or to borrow that comprehension by delegating to an AI. That “comprehension cursor” is an ownership boundary between us and the agent.
I can now reduce the risk of being late on a project by increasing the share of the work I delegate to agents. The price I pay is a gradual increase in my cognitive debt, the gap between what I have shipped and what I understand. For critical pieces, I might instead choose to retain ownership and a thorough understanding. The difference between those two cursor placements is how quickly I can identify and correct errors.
For instance, when coding in C++ I sometimes joked that my job was being proven wrong by a compiler all day. Indeed, just like any model, my internal understanding of a system cannot be calibrated if it never risks contradiction. Otherwise it’s not much better than astrology.
So the “comprehension cursor” is not really about who writes the code (the agent or the human) but when and where we accept being checked and corrected. When we delegate nothing, our internal model is tested continuously, through many small decisions, challenged by the type system, the tests, the executions. As we delegate more, our model is tested later, at selected checkpoints (maybe at the diff/PR level). If we delegate everything, reality can still expose errors, but the signal no longer calibrates us: we formed no expectation of our own for it to revise.
Because calibration requires attention, and attention is capped, continuous correction everywhere is no longer a sensible default: attempting to cover all the code regions risks diluting attention where it matters the most. Thanks to agents, we don’t have to: we can set the comprehension cursor region by region, focusing our attention on the most critical modules and delegating execution of the rest.
I deliberately offer no metrics or units here, as they would instantly become bad targets: this allocation is a judgement call, not something that can be programmatically optimised. Allocating judgement itself requires judgement, and as we move up the ladder — function, file, module, project, job, career — evidence generally arrives later, noisier, and is harder to attribute. High on the ladder we only consent to being corrected slowly.
To summarise, setting the cursor is done region by region, by answering two questions:
Q1, the epistemic clock: how long will we likely stay wrong, and at what cost? A proxy for this can be how quickly mistakes in this region have historically become visible and attributable—for example through bug-fixes, reverts, and incidents linked to earlier changes.
Q2, the survival clock: what is the cost of being late — of missing the time to market? We can estimate this using runway, committed dates, the cost of delay.
I deliberately offer no formula for converting these signals into a cursor position: although evidence can inform each clock, their relative importance remains a judgement call.
Each clock pulls the cursor in one direction. When they pull in the same direction, cursor placement is easy. When they conflict, judgement is what resolves the conflict.
Here are the tradeoffs:
As an illustration, let’s consider Kent Beck’s “3X” framework (eXplore, eXpand, eXtract).
A startup begins in eXplore mode, where the aim is to discover what creates value for its customers by testing many hypotheses very quickly. In that mode, the founders will probably delegate code to an agent because being fast is more important than being exactly right: the implementation needs only enough fidelity to test the hypothesis so the survival clock dominates. Indeed, most of that experimental code will not survive, whether written by a human or an LLM. However, they retain judgement not only over which hypotheses to test, but over whether the implementation and measurement actually test those hypotheses.
In the eXpand phase, scale problems start to appear. This is the phase where the clocks conflict most sharply because the cost of delay remains acute and the cost of remaining wrong rises due to scale, dependencies, and increasingly irreversible choices. To solve the bottlenecks, some design and architectural changes will be necessary: the founders will want to keep human judgement involved in identifying which architectural choices are “one-way doors” and keep a deep understanding of the trade-offs they are making. Other areas are well-understood and gradually stabilising: routine work in these areas can be delegated more aggressively.
When the startup reaches the eXtract phase, there might be standard operating procedures, which can be automated by agents. Humans should still preserve understanding and judgement of the system’s key invariants.
Even after you make a deliberate choice about where to place the cursor, the environment will actively try to move it:
deadlines, judgement erosion, and convenience push it to the right;
sunk-cost fallacy, gold-plating, rabbit-holing push it to the left.
How to maintain the cursor in the position we want is the subject of the next essay.