No Human in the Loop. Only AI Acting on Your Intent.

Posted on by

There’s a big trend right now in agentic engineering. Set up your loops and workflows, let the AI agents do the implementation, and you review at the end. Or at a few key points. Sign off that the quality is there and the tests you threw at it pass.

Table Of Contents[ Hide ]
  1. What the loop should look like
  2. Tests passing doesn’t mean your intent passed
  3. One service, written several ways
  4. Filling the gaps with assumptions
  5. Weaker evidence than it looks
  6. Why agents are different from people
  7. Ten agents, ten amplifications?
  8. The people who review less
  9. The blueprint is what source code used to be
  10. Intent steering the ship
  11. References

Somehow we’ve worded this to say AI isn’t veering off track, because there is a “human in the loop” who checks that all the tests passed, the code review is acceptable, and the product meets the functional requirements.

I don’t think that’s how it works. Or at least it’s not how it works for me at snapWONDERS. When my AI agents are going, I am not a human in the loop. The AI goes autonomously, with checkpoints throughout, and the agents follow my intent based on my blueprints. AI should not be making assumptions, setting itself the goal of just getting the tests passing, or making a practical decision on my behalf and running off with it. Where my blueprints don’t fully cover something, we stop and confirm the intent. I oversee the intent.

For me, with agentic engineering, the end goal is important. We definitely want AI to implement autonomously, with agents building in collaboration with each other, all tests passing and the quality high. But it is more important that every building block, every direction, follows my intent. I wrote another article about this, where I found sub-agents unhelpful. When they spawned off, I had no visibility of what was done, what exactly their intent was, and whether they performed their sub-tasks the way I intended.

There’s no human in the loop. There’s only AI acting on human intent, under my lead-driven synthesis.

What the loop should look like

If you want to keep the phrase, this is what it needs to mean for the work we do. Whenever AI is generating code or designing something and isn’t fully across the intent, it should stop and ask what was intended. It can even suggest how the gap should be resolved, if you want that, so the intention gets settled.

I can see the argument against this: it isn’t scalable, or you’ll get prompted a million times for what the intent is. That was true in the early days. But you do get better at covering all your intents. The blueprint is an agile process. It includes the gaps we know about and the gaps we don’t know about yet, and with AI running the iterations at speed, it keeps evolving: gaps closed, new gaps found, and each one found goes back into it.

And if you don’t want to decide now and hold up the work, you can still state your intention as a black box: details provided later, to be covered in the blueprint. The agents take it as far as they can, then report that they’re blocked on the black box and ask what I intended for it. Because the black box is in the blueprint, and the blueprint always wins, nothing can quietly fill it in and call the job done.

Software engineering blueprint that is all revolving around a black box component

Tests passing doesn’t mean your intent passed

What I keep seeing is this. AI agents deliver. The solution works. The tests pass. And it still doesn’t wholly contain what I meant, because somewhere along the way a decision got made that I wasn’t part of. In software engineering there are many ways to solve something, and many of them can work, but we need the right solution. Sometimes that’s measured carefully, sometimes it’s chosen from experience, and sometimes it comes from a whole myriad of reasons. All of that is part of your intent.

One service, written several ways

Here is one that happened to me. I had several agents building different components of the system. I had defined the intent well, what should happen. Tests all passed, and functionally they were working. Even the code review passed. But each agent was working independently, progressing at different rates and at different stages. It was only while I was reviewing different parts as they came through that I spotted a common piece of logic, such as a lookup service, a resolving service or a mapping service, written differently for each component, when it should be unified as a single component shared across all of them.

I caught that one in review, which is exactly the thing that doesn’t scale. So the blueprint got corrected, and that should be the last time a person has to spot it. Then a broadcast message went to all agents about the newly documented service and its intent, asking each one to check whether it affects them, and if so, resolve it.

BTW, I should add, the golden rule I have is that when the code disagrees with the blueprint, the blueprint is always right. The blueprint is the intent of how everything works, and everything must match it.

Then it was a matter of adding new rules for building new offerings. A decent-sized piece of code that should be modularised, and isn’t specifically covered in the blueprint, should be flagged, with a question on what the intention is around that gap.

My agents do collaborate with each other, and if a rule change is unclear, several of the affected agents will come back asking about my intent. I don’t reply to all of them, since my intent is in the blueprint. I engage with the one agent that is most relevant to my intent, and expect that agent to fully update the blueprint after confirming the full intent. Then I expect that agent to work with the other affected agents, acting as the mediator of my intent.

Filling the gaps with assumptions

Another common issue is the assumptions an agent makes when the context around my intent was a little too brief. The AI agent simplifies things and fills the gap with whatever it thinks the end goal is. It just needs the tests to pass, then assumes the work is fully finished, when that’s not my intent at all. Passing the tests and shipping is one goal of many, but it isn’t the intent of our offerings. I don’t want to ship only for us to find out in production that we have a gap. In these circumstances the agent should stop and flag it: the blueprint doesn’t cover this intent in full, or we have gaps, or the whole context is incomplete.

A classic example was when I needed a special forensic analysis on images, and asked for it as a starting point. My full intent was for the analysis to work across the wide range of image formats that support it, but at the time I was hung up on the technicalities of that particular analysis. The agent implemented it, all the tests passed, and it thought we were done. Only through further testing did I find it worked for JPEG files only, and every other format did nothing. That gap should have stopped the agent and come back to me as a checkpoint, instead of turning up later in testing. Because I hadn’t spelt out which image formats it should support, the agent targeted one format, and that covered only part of my intent. JPEG being the most common image format on the market should not have made it the only format needed. What about PNG and GIF, which have been around for a long time too? Or newer formats like WebP?

Weaker evidence than it looks

It is good engineering to have tests that pass, validating your thinking, your parameters, the expected behaviour, what you think is right. But an agent can write those tests too. Simon Willison said in May he can knock out a repository with comprehensive tests in half an hour, and can’t tell by looking whether it’s as good as one built with care.

And AI agents grade themselves generously. Ask one whether its own work meets the brief and it will usually say yes. So “the tests pass” and “the agent says it’s done” are both weaker evidence of intent than they look. A human who only checks those two things at the end is checking the wrong things.

“Human in the loop” has a trap in it as well. If the human’s job is to approve each step, they stop reading. Mitchell, Ghosh and Passi describe this as approval fatigue in a paper this year. They cite a study of developers who treated the agent’s plan as a faithful stand-in for what it actually did, and who assumed that code which passed its unit tests was correct.

That’s the difference between my checkpoints and an approval click. An approval click asks “is this OK?” about something already done. My checkpoints ask “what do I actually want here?” before it’s built.

Why agents are different from people

With people, watching over every step is about the worst management you can do. People earn room by building a track record, owning their mistakes and carrying your standards into the next job.

An AI agent has none of that. It has no reputation to protect and it can’t take accountability for what it did. Next session it doesn’t remember what you corrected last time unless you wrote it down somewhere it will read.

And have you tried correcting an AI? Or venting your frustrations at it (oh wait, it’s a machine, don’t do that)? You get the same apology every time, with an explanation of how it happened, and it sounds cringingly shallow.

So the reason we trust people to work on their own doesn’t apply to agents. The trust has to come from somewhere else, and that somewhere is your intent, written down and checked.

Ten agents, ten amplifications?

The goal of an AI agent is to amplify what you do. So if I have ten agents running, I expect ten amplifications of me. Lead-driven, each one carrying my intent.

The catch is my attention. It doesn’t multiply by ten. If I personally check every step of ten agents, each one gets a tenth of me, and I become the bottleneck. Addy Osmani writes about this as the orchestration tax. Rachel Laycock at Thoughtworks says the same thing: human attention is now the bottleneck.

So the amplification can’t come from me watching every step. It comes from two things.

First, the blueprints. Intent written down once so every agent inherits it: design documents, rules, tests that fail the build when the code drifts. The blueprint, with my intent in it, is really what I’m building, and the code is produced from it. That’s the golden rule from earlier: the blueprint is always right. I wrote about how that works in How a Corrected Rule Stays Corrected.

Second, the checkpoints. They go exactly where the blueprints run out. When an agent reaches a decision my documents don’t cover, a design choice, a trade-off, something that changes what the result means, it stops and we confirm the intent together. That’s where my attention goes, every time. Once it’s decided, it goes into the blueprints, so the next agent doesn’t have to ask.

So the number of agents I can run is set by how much of my intent is written down well enough for them to work against, not by how many I can start. And the written intent grows every time a checkpoint gets answered.

This works for me. It’s how I build snapWONDERS, with many AI agents working in parallel, each on its own piece of work in its own copy of the code. They only stop for me when they hit a decision my blueprints don’t cover.

When they talk to each other, I expect to be able to see it. Not reading every message, but able to see who told whom what, and whether it still follows my intent. And if my intent isn’t fully captured in the blueprint, why haven’t they stopped to elaborate on it, as I described earlier?

The risk is real and it’s been measured. Researchers studying “inherited goal drift” found, in simulated tasks, that an agent picking up a weaker agent’s work can inherit that agent’s drift, and that how well a model obeys its instruction hierarchy doesn’t tell you much about whether it will drift. One agent makes a quiet choice, the next builds on it, and nothing downstream notices because it all still compiles and passes.

The people who review less

To be fair, not everyone agrees with me. Simon Willison wrote in May that he no longer reviews every line his agents write, even for production work, and so far it’s been holding up. He also said he’s uncomfortable about it and might get burned. Andrej Karpathy, who put the name “agentic engineering” forward, has said he hasn’t typed a line of code since December 2025 and now delegates most of his coding to agents.

I don’t think they’re wrong for the work they do. I think it depends on what “correct” means.

If there’s a clear, mechanical way to check the result, let the loop run. A benchmark, a format conversion, a backlog of small fixes with a test that can’t be gamed. That’s what loops are good at.

If “correct” is a judgement call, it’s different. Security boundaries. Anything where a policy or a design decision is the answer. Forensic scoring, in my case, where the code has to do what the design says, not just produce a number. There’s no test that holds all of that. The only thing that does is the person who had the intent.

The blueprint is what source code used to be

So what does the blueprint actually mean for the offerings you are building? The blueprint is the DNA, the essence, the formula, the magic of your offerings. This is what you need to be protecting. Agents should be able to read the blueprint and regenerate the assets, the binaries and everything else from it.

It’s a poor analogy, but long ago we wrote assembly code. Then libraries came along, collections of ready-made functions sitting on top of the assembly, each doing something useful. We wrote code in higher-level languages to do something with what those libraries provided. Our code conveyed our intent, and the compiler produced the machine code from it. We stopped caring which instructions it produced, as long as they ran well and did what the code said. The blueprint is the next step up. It carries our intent, an AI agent produces the code from it, and the code produces the end result.

If you’ve read about spec-driven development, the blueprint is my version of the spec. What I’m adding is what happens where the spec runs out, and that’s where the checkpoints and the black boxes come in.

Intent steering the ship

So this is what agentic engineering means to me. It’s what I called lead-driven synthesis in Beyond Vibe Coding: The Era of Lead-Driven Synthesis: at every point where an AI is amplifying what you can do, your intent is the thing steering it.

For me that means the blueprints carry my intent, so every agent inherits it. Where the blueprints run out there’s a checkpoint, and whatever I decide there goes back into the blueprint. Anything I haven’t decided yet is marked as a black box, and the agents stop at its edge. I keep the agents where I can see them, and I know which work can run on its own and which can’t.

I don’t see myself as the human in the loop because, from my standpoint, I am not in the loop. Rather, I am orchestrating AI agents to ensure they’re acting on my intent.

If you’re running AI agents on real work, I’d like to hear where you put your checkpoints.

References

Kenneth Springer is the founder of snapWONDERS, a digital forensic analysis platform for images and video. Every forensic check on the platform goes through the same discipline: a locked design, automated tests and a person’s review decide what ships. snapWONDERS forensic analysis — no account required.

Leave a Reply

Your email address will not be published. Required fields are marked *