Verification Has a Clock

Change is a constant. Dylan has been singing "The Times They Are a-Changin’" since 1964, and for software engineering, The Song Remains the Same in 2026. Some of the ideas we are discussing, such as software factories, are not entirely new. Software-factory concepts date at least to the late 1960s. Hitachi established its Software Works in 1969, followed by related initiatives at NEC, Toshiba and Fujitsu during the 1970s. These organisations applied standardisation, reuse, tooling and quality control to software production, but did not have the technologies needed for today's level of automation, orchestration and verification.

Unsurprisingly, over the past few years, I have observed a shift in my role in software development. This is not necessarily a change about job roles or scopes, but how adopting agentic development tools and workflows have shifted the responsibilities from implementing changes to planning the features and execution, designing the boundaries, making decisions about how to verify the work and have confidence in the outcomes and evaluating whether the results satisfy the requirements.

I have been exploring this change using two related systems that are positioned at two different points on the autonomy dial. The first system is a coffee roasting agent built to automate roasts by controlling a Hottop coffee roaster which is able to roast 250g coffee at a time. The second one is the coding agent topology that builds it. The development system started with me creating plans, passing messages and prompts between agents and now it coordinates a larger part of the work itself using predefined topologies without me having to pass messages. I retain the responsibility for direction, designing evaluations, verification judgement and supervised real hardware sessions.

I use the term "agent" as a closed-loop, goal based system and not as a synonym for the language model used by the system. In the roasting system, the LLM acts as an advisor and has no direct access to the hardware. In the development system, the coding agents can plan, implement and review changes, before consulting me with evidence for evaluation. The cost of wrong decisions is why these two systems have different appetites for autonomy. In this experiment, two important factors to decide on autonomy are the time it takes to identify a mistake and whether or not the mistake can be corrected.

Thinking in continuums is not new to me. In the mid-2000s, I was conducting augmented reality research and Paul Milgram and Fumio Kishino's reality / virtuality continuum concept stayed with me over the years. In early 2020s, I ended up working in the automotive industry and came across the Society of Automotive Engineers (SAE) levels of driving automation including a Level 3, where a person might be required to resume control after they have stopped observing the driving situation closely. Milgram's continuum provides the shape of the argument and the SAE framework exposes the handover problem that becomes more evident as autonomy increases. Autonomy is not simply an on and off switch or a slider we can adjust as we feel like. The handover process matters as much as the autonomy level.

Fast forward to the mid-2020s, and software engineering domain is facing the same questions. Addy Osmani makes the distinction between agency, how far one agent goes before returning, from orchestration, how many agents are working and who is responsible for coordinating them. His framework considers the verification available, the risk involved and whether an action can be reversed, including how quickly we can identify that something went wrong and whether we can undo it.

I agree with that framing because it is a grounded perspective that provides clarity at a time when hype cycles can take over engineering concepts and discourse. It is also important to discuss what happens if the system cannot wait for verification, and whether a person can obtain enough context before the consequences start. In physical systems, verification has a clock. The clock in this case is measurable and not metaphorical.

On my Hottop roaster, roast traces suggest that there is a 25 to 35 second gap between the time a command alters the heating element power and the time change is visible to the bean temperature sensor. Given this is an electric roaster that uses old kettle style heating elements, this kind of thermal lag is expected. Sending more commands to change power means that these commands are applied before even the previous adjustments come into effect.

In contrast, software has a different property: user facing consequences can remain dormant behind a gate while evidence builds up. Of course there is a cost involved in waiting due to branches drifting or dependencies / assumptions changing over this period. In addition, urgent / time critical work has own clock. The cost manifests itself as integration risk as opposed to a physical process that already started changing and irreversible. If by accident you get those Jamaica Blue Mountain roast too dark, you are going to regret every sip.

When the attempt isn't cheap

Referring back to the first essay Cheap Tokens, Cheap Attempts in my Industrial Revolution series, the argument is that cheap attempts make judgement scarce while expensive attempts make restraints scarce. If building another candidate is cheap, then the decision on which output to keep becomes the judgement. This argument is easily justified for work that can be kept inside a branch, a draft or a simulation until someone has checked and verified.

However, this is not the full picture. A database migration can destroy information, while a trade can clear before anyone reviews the reasoning behind it. In case of the coffee roaster, the heat can continue through the system even after the command has been reversed due to thermal lag. In such cases, the evidence can be perfectly clear but it becomes available too late to prevent the consequences.

This is the reason cheap attempts make judgement scarce, while expensive attempts make restraint scarce. For expensive attempts, the judgement decides what the agent should be allowed to do in the first place.

The following three questions help make decisions about autonomy:

1. How cheaply can we verify the result?
2. What can happen before that verification arrives?
3. Will a human still have the time and context to take control?

We can use verification cost to determine how far an agent should go. The cost, reversibility and takeover time together help determine whether the agent should be allowed to go there at all.

The point of this argument is not to choose the lowest possible autonomy. We can set the boundaries too tight as well as too loose, so both sides need attention. If every reversible action needs verification, then the advantage of cheap attempts disappears, as we the humans become the coordination bottleneck as described in The Factory Was the Real Invention. The aim is to ensure authority sits where a mistake can be detected, contained and recovered, as opposed to defaulting to a person for each decision.

The landscape has a different job

The environment and the codebase play an important role in deciding what kind of autonomy we can give to the agents. I have previously discussed the importance of codebase preparation so that the agents can operate safely in Better Ground, Not a Better Model. The tests, boundaries, the rules, review and independent evidence make bad attempts easy to reject. when an action has consequences before the evidence is available, the terrain agents operate under has a different job. It should contain what the action is capable of doing, which means the autonomy boundaries are enforced by the surrounding system and not just an instruction asking model to play nice.

The roaster has been a modest but useful way to learn this. The agent comprises a deterministic controller that owns the control loop, a language model that returns a typed advice, and a safety policy that determines if an advice should be acted on or not. The build has been delivering delicious coffee through supervised hardware runs for the past few months. A review of fourteen completed roasts as of 25 July 2026 has illustrated that the advisor has recorded 162 decisions and requested 23 drops. The policy has rejected 10 because the roast was not within the allowed development window and following the advice would mean underdeveloped - grassy tasting coffee. The boundary was not ceremonial; it changed what the machine did.

The boundary is necessary because of the timing. The advisor is quick and response latency formed a part of the model evaluation run. The advisor returned a recommendation with a median of 2.24 seconds across 162 decisions, which means the model was not the slow part of the loop. The roaster, on the other hand, was the slow part. In one run, the bean temperature needed 77 seconds to reach its target while around 30 seconds were spent waiting for a heat change to be effective at the bean probe. With the cut happening at second 75, this left roughly 45 seconds in which a meaningful decision could be made. A faster model can't recover the time lost due to the roaster's thermal lag.

When I started the experiment, I expected that eventually I would reduce the role of large language model (LLM) and use more deterministic approaches as I completed more roasts and collected more data. The supervised runs repeatedly led me to reduce the model's authority rather than increase it. The initial design allowed the LLM to advise on heat, fan and drop decisions throughout the roast. In about 5 weeks, that role had shrunk to one decision: requesting an early drop when the roast was within 3% of the drop target. To avoid overroasting, a deterministic rule forced a drop at the target and a hard ceiling forced the drop at 196 °C. The code refers to this principle as "earlier, never later".

Further experiments allowed the LLM advisor to recommend fan levels but only by influencing a controller owned command. The model still had no access to hardware tools and could not write commands directly. Its influence has increased without expanding the authority.

As I have done more roasts, some of these provided evidence that some settings were wrong, leading to a narrowing of the LLM's authority. The original design was letting the LLM guess while the system could actually measure it first hand. Authority moved to whichever side could be verified. An important distinction is that the roasting agent has not become less autonomous; what supplied the autonomy has changed. Physical runs on the hardware revealed boundaries that the tests and diagrams have missed. Widening the LLM's authority had to be supervised and gradual.

An expensive attempt can teach us that a clever design was wrong; however, the invoice will be due immediately. There is a cost associated with a fixed boundary that the model can't pay: it is possible that one of the blocked drop requests could have led to a better roast, but the policy has prevented us from observing that possibility. In a reversible domain, it would be ok to let the model try and examine the results. However the price of an irreversible loop is that the boundaries only widen after evidence is gathered and never on the model's prediction in the moment.

Orchestration around software engineering tasks can go much further because the economics are different. The work can be divided into isolated branches, verified by specialised reviewers, and can be evidenced by test results, logs and the diff against the original code. In this setup, exploring the codebase is a readonly task that returns information and can almost run unsupervised. Because implementation happens inside a branch, with a review standing between the changed code and its merge into the target branch, this part can also have more autonomy. However, merging or releasing the feature requires strong evidence, and authority moves closer to humans as the consequences move closer to users and become harder to reverse.

It is important to acknowledge that such a gate can be slower than the physical loop. In my experience, within limits, this is a wait worth paying. As an example, there was an issue in the review workflow where the workflow could complete before the final code review verdict landed following the final commit. This meant a change could be merged before the final review was complete. Once the workflow was fixed, the median time from opening a pull request (PR) to merging it increased from only 6 minutes to slightly over an hour. And was this price worth paying? Absolutely. One of the first benefits was catching a change that deleted 673 line test file whose name suggested it was dormant. However, the test file included 11 live fault-path tests that should not have been discarded. I am not generalising this argument to say a slower verification process is safer than a fast one. My point is that the ordering differs; one system can hold the consequence until the evidence arrives and another system cannot.

As mentioned earlier, these two systems appear together because one of them builds the other. The agents writing the control laws for the roaster and reviewing its safety code run at a high autonomy setting, though not an unattended one. The topology routes the work as opposed to deciding what the work should be. The LLM inside the roast pilot agent has no direct authority. I work on both in the same afternoon and place them at two very different points on the dial because the cost and timing of being wrong are very different.

Autonomy belongs to the decision and its surrounding controls, not permanently to the agent, and as evidence changes, the boundary can move in either direction.

The handoff is part of the system

This is the warning I remember when I think of the SAE framework. Consider the middle of the dial where the machine appears to own the loop and something goes wrong. At that point, the human discovers that they owned it all along, but what can they do now without having paid attention or prepared for takeover? An SAE Level 3 study reported that non driving tasks required more time to complete a takeover and, depending on the task, reduced sensitivity to changes in the driving situation. Such problems cannot be solved by a dashboard and an override button alone.

Similarly, two operator recovery failures on the roaster exposed the same design mistake, and neither of them was about the model. On the first supervised run, the emergency stop worked and forced heat to 0 through the safety path. However, when the run finalised, a terminal-run guard began rejecting every operator action while the machine was physically running with heat cut off. That meant there was no way to stop the fan or drum, or to issue an emergency stop a second time. The only remaining option was to cut the power. The architecture required the emergency stop to be available from every phase, and the implementation appeared to satisfy that requirement up to the point where it was needed. The LLM was not even in use; it was paused so that the deterministic loop could be validated first. In this instance, the handover mechanism was not correctly specified.

The second failure was in the interface rather than the state machine. A start form silently failed to advance to the roast UI while the roaster was already preheating, leaving a live machine with no dashboard and no emergency stop anywhere on the screen. The API still exposed the emergency stop, so I issued a command through it instead. What was missing was not the authority but the path to authority.

Both failures shared a common denominator: the model's authority boundary held and the model behaved, but the human override path failed. That path tends to be the part that is designed last and exercised least.

Designing handoff is an integral part of designing autonomy. Who owns the loop? What evidence causes control to transfer? How much time is available, and has the person receiving control retained enough context to make a useful decision? When those answers are vague, "human in the loop" is the agentic version of "plug and pray" rather than a safety mechanism.

For a handoff to be credible, it has to survive both volume and changing consequence. If a person receives more approvals than they can inspect, the process becomes a rubber stamp. The route back has to be manageable, with clear escalation and enough evidence to reconstruct what happened without being overwhelmed. In code, the same action becomes less reversible as it moves from a branch to merge to production. Advice from the LLM in the roasting agent only becomes consequential when the controller turns into a command. This means the organisation has to decide who may widen the autonomy boundary, what evidence is sufficient, when a second pair of eyes is required and who remains accountable. Those are decisions about authority, even when disguised as choices about tooling.

The cost of being wrong sets the boundary

The important question to ask anyone introducing agents into a team is not "What autonomy level have you reached?" It is whether the autonomy chosen for each decision matches the cost and timing of being wrong.

The boundary is not decided purely on cost. The organisation decides where to place it, but it is the consequences that determine whether the choice is defensible or not.

A high degree of autonomy might be reasonable for a bounded task with strong tests and a mature review gate. On the other hand, when an action is costly, delayed or hard to reverse, the right decision could be to keep the model as advisory and provide a deterministic control around it, or require a person to approve the action before it crosses the boundary. Neither approach is more advanced; each is simply better matched to the problem at hand.

When the surrounding system makes being wrong visible and recoverable before the consequences become irreversible, higher autonomy can be a multiplier. When the environment cannot provide that, turning the dial further is not progress. It is moving authority past a point it cannot be defended anymore.

Sources

The earlier software factories

• Michael A. Cusumano, "The Software Factory: A Historical Interpretation," IEEE Software 6(2), 1989, 23-30. The article traces software-factory concepts to the 1960s and documents their institutional development in Japan, beginning with Hitachi Software Works in 1969.

The historical continuums

• Paul Milgram and Fumio Kishino, "A Taxonomy of Mixed Reality Visual Displays," IEICE Transactions on Information and Systems E77-D(12), 1994, 1321-1329. Open-access discussion and reproduction of the original continuum: David Skarbez et al., "Revisiting Milgram and Kishino's Reality-Virtuality Continuum" (2021). The continuum connects completely real and completely virtual environments, with mixed-reality forms between them.
• SAE International, J3016: Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles. NHTSA's public explanation of the six levels covers Levels 0 to 5 and the Level 3 conditional-automation handoff.
• Lichao Yang et al., "The Identification of Non-Driving Activities with Associated Implication on the Take-Over Process," Sensors 22(1), 2022, 42. An open-access SAE Level 3 study of how non-driving activities affected situation awareness and takeover time.

The coding-agent discussion

• Addy Osmani, "Agentic Autonomy Levels" (2 July 2026). Separates agency from orchestration and ties safe autonomy to verification, risk, reversibility, measurable stopping conditions, independent evidence, escalation and budget.

Further context

• Steve Yegge, Gas Town. The public implementation of a multi-agent coding orchestrator.
• Miikka Holkeri / Swarmia, "Five levels of AI coding agent autonomy, and why higher isn't always better" (19 March 2026). A task-oriented autonomy scale based on how much work the agent completes before returning.
• Jim Reavis / Cloud Security Alliance, "Leveling Up Autonomy in Agentic AI" (28 January 2026). Autonomy considered alongside risk, reversibility and permissions.

The build

• The roaster interface and hardware safety boundary: coffee-roaster-mcp.
• The agent harness and deterministic control boundary: roastpilot-agent.
• Cecilia Margaretha Botha, "A model-based control system design for a coffee roasting process" (2018). An experimental rotating-drum study that characterised coffee roasting as a lag-dominant first-order-plus-time-delay process with an average dead time of twenty seconds. Different equipment, so this supports the process-lag principle rather than the Hottop-specific estimate.