Human Control at Machine Speed

Development is where the plan meets the real world—where every design decision has to prove that it is still the right one, and often it is not.

I have spent the past 14 years working at a federal regulatory agency. That experience has left me with a durable conviction about the importance of governance and of recording processes and decisions—not only in regulated sectors, but for any team that intends to preserve continuity and adherence to its processes, whether those processes are defined by internal policy or by law. This is not bureaucratic decoration; it is how institutions remember why they do what they do, and how they remain accountable for it when someone asks—a regulator, an auditor, a court, or simply their own future staff.

A few years ago, I began building software with AI assistance—first to solve specific, everyday problems, and later out of a growing conviction that systems and automation can make work move faster when applied at the right stages. The goal was never to delegate human decisions or human analysis; it was to preserve where that exceptionally scarce resource—human attention—should actually be spent.

In my own development work, the problem was rarely whether the generated code worked. Smoke and integration tests generally showed that the software behaved as expected within the scenarios they covered. The problem was elsewhere: I could no longer explain why certain architectural and implementation decisions had been made. Trying to keep up with the evolution of the codebase consumed a great deal of time and left me with an uncomfortable question: Had I seen everything I should have seen? That discomfort led me to anchor development planning in specifications and to use other AI systems as reviewers, asking them to assess whether generated code adhered to or diverged from those specifications. For a while, that gave me some sense of control over where the system was heading.

It soon became clear, however, that this was neither a robust nor a stable solution. The answers came from probabilistic models and varied with context, interaction framework, model version, and prompt quality, while token consumption per task kept climbing. I also had to send my code outside my own working environment without a level of assurance about confidentiality that met the governance requirements I wanted to preserve. Those conditions were unacceptable for my purposes. That was when I began building a system that could assist my development process through deterministic analysis—with no LLM in the verification path—and give me control over adherence and divergence between specifications and code.

“The specifications were the source of truth for the project’s original intent, while the codebase was that intent expressed in executable form.” That premise did not last long.

One afternoon, I found parallel paths in the pipeline duplicating normalization responsibilities. The obvious fix was to create shared normalization middleware used by all of them. That same afternoon, I found god modules with more than 2,000 lines performing far more responsibilities than I had ever intended for them, and split them into something modular and maintainable. At the end of that difficult afternoon, I looked back at my specifications and realized: what I had built was substantially better than what I had planned.

That happened because development is where the plan meets the real world—where every design decision has to prove that it is still the right one, and often it is not.

I then found myself working in a setting where important decisions about system intent could be recorded either in the specifications or in the code. Neither artifact could be treated, in isolation, as the source of truth. The system I was building needed to confront them on equal terms, surface their agreements and divergences, and return to me the decision about what the divergence meant and what should change as a result.

That kind of bidirectional spec-code analysis became the origin of a broader line of reasoning whose premises gradually became clear:

1. divergence and compliance analysis should be performed by an independent, deterministic engine operating on clear, known, and inspectable rules;
2. analysis should be reproducible: the same specifications and code, evaluated under the same version of the rule set, should produce the same result, reproducible by another party at a later time;
3. significant divergences between plan and implementation—such as gaps, where specified behavior is not implemented, or drifts, where implementation is not reflected in the specifications—must be explicitly surfaced and decided by a person rather than delegated to an LLM;
4. divergences should be decomposed into actionable units and classified by confidence and risk, so that human attention is not diluted across thousands of implementation details while a business-critical contract violation receives the urgency it deserves; and
5. decisions made during human review should produce their own record, including what was decided, when, by whom, and why.

Over the past year, while working on this problem, these engineering decisions gradually converged into something I later formalized and published in August as the Compliance-Driven Development (CDD) Manifesto. I mention it here for transparency, not persuasion: the arguments in this essay should stand or fall on their own.

I have watched the phrase human in the loop spread across both the community and industry. But being in the loop is a position, not an activity. If a person is presented with hundreds of technical decisions and approves them at the rate they arrive, we have human presence without meaningful human authority. The reviewer becomes another component in the pipeline rather than the accountable decision-maker. That is not meaningful oversight; it is rubber-stamping. And the resulting record can be worse than no record at all, because the approval survives and is later read as though it reflected a considered decision.

I have seen this same speed asymmetry described in a BLOG@CACM post by Kostakis Bouzoukas, who called the resulting accumulation verification debt: the liability that grows “when evidence cannot keep up with change.”¹ AI-assisted development has become extraordinarily efficient at accumulating that debt. Production has accelerated dramatically; our ability to verify, judge, and record has not kept pace.

So the useful question is not how to make humans review faster. It is this: At what granularity should human judgment be required, and what evidence should each request for judgment carry in order to support an effective and accountable decision?

The answer to the speed asymmetry is not to make humans review at machine speed. It is to place between production and judgment a deterministic layer capable of reducing, prioritizing, and structuring what actually needs to reach a human. That allows most of the process to continue operating at machine scale while keeping human judgment mandatory at the points where removing it would mean delegating a decision that should not be delegated.

As machine-generated software becomes ordinary, how well can we still reconstruct why a consequential change was made, what produced it, and which human actually decided that it should become part of the system?

Human control at machine speed does not require humans to think at machine speed. It requires a development process in which machine-scale production never quietly becomes a progressive abdication of governance.

References

1. Bouzoukas, K., Verification Debt: When Generative AI Speeds Change Faster Than Proof, BLOG@CACM (January 16, 2026); https://cacm.acm.org/blogcacm/verification-debt-when-generative-ai-speeds-change-faster-than-proof/

Francisco Romeiro is a biologist (MSc. Ecology and Natural Resources) and a Brazilian federal civil servant. Years of building software with AI led him to investigate how humans can remain in control of the development process, work that ultimately resulted in the Compliance-Driven Development discipline (compliancedriven.dev).

You Just Read

Human Control at Machine Speed

© 2026 Copyright held by the owner/author(s).