AI accelerated, senior led: how I actually use agentic tooling
Every prospect asks it eventually, and most of them ask it sideways. "So, do you use AI?" Then a pause. What they actually want to know is simpler and much more reasonable:
If a machine wrote it, who checked it?
It is a fair question. I am one person. I ship faster than one person used to ship. Someone paying for four weeks of work is entitled to know where the speed came from, and whether it came out of the part they care about.
So here is the honest answer, with a worked example I am building at the moment.
"I review everything" is not an answer
The easy reply is that I review all of it before it goes out. Which is true. It is also worth nothing, because everybody says it, and nobody can show you the mechanism.
A promise is not a gate. A gate is something that stops the work moving until a condition is met. If my review is a habit rather than a step, then on the Friday I am tired it quietly does not happen, and nothing in the system notices.
So I stopped treating review as a discipline and started treating it as infrastructure.
Most AI tooling gates the wrong thing
Look at how agent tools ask for permission today. The agent wants to run a command, or write a file, or call an API. It stops and asks. You get a yes or a no.
That gate is useful. I use it every day. But look at the unit it operates on: an action, and the answer is a boolean.
That is the right shape for "may I delete this directory". It is the wrong shape for almost everything that has value. When a machine drafts a database migration, a client email, an architecture note or a pricing page, "yes" and "no" are both bad answers. The real answer is nearly always:
This is mostly right. The second paragraph is wrong. Fix that bit, keep the rest, and ship the version I edited.
You cannot say that to a yes/no prompt. So what happens instead is what always happens. You say yes, make a mental note to fix it later, and later never comes. Or you say no, and the good ninety percent gets thrown away with the bad ten.
The unit of review should not be the action. It should be the artifact. And the thing that continues downstream should be the version you edited, not the version the machine proposed.
The worked example: Interlock
I am building a tool called Interlock. An interlock is the mechanism that stops a machine running until a required condition is satisfied. A microwave will not fire with the door open. That is an interlock.
It does one thing. A job runs on a schedule, produces something, and stops until a person reads it, edits it, and approves it. What continues is what that person edited.
The loop looks like this:
schedule fires
|
v
agent step runs on my machine, under my own model subscription
|
v
approval step the artifact lands in a web inbox and waits for me
|
v
http step the EDITED artifact is POSTed onward
The steps are just a list. An approval gate in the middle of a chain behaves exactly like one at the end. There is no branching, no conditionals, no directed graphs. That complexity is deliberately out.
At the approval step I get five choices, not two:
| Action | What happens |
|---|---|
| Approve | Goes forward untouched |
| Amend and approve | My edited version goes forward |
| Reject and block | The run stops dead |
| Reject, request improvements | Re-runs against the previous draft, plus my notes |
| Reject, request a new draft | Re-runs from scratch, with my notes |
Those middle three are the whole point. "Amend and approve" is the one that does not exist in a permission prompt, and it is the one I use most. "Request improvements" is the one that keeps the good ninety percent.
Two decisions that fell out of it
The work runs on my machine, under my own subscription. Interlock never holds a model credential. A small runner on my own hardware polls the planner over outbound HTTPS, runs the step, and uploads the result. Nothing ever dials in.
I built it that way for a boring commercial reason, which is that a flat subscription beats metered billing. But the consequence matters more to a client than it does to me: prompts and content never transit anybody else's service. When the work involves a client's draft, their spec or their data, the list of third parties who saw it is empty. That is a much easier sentence to write to a data protection officer than the alternative.
It also makes the model a detail. From the planner's point of view a step is a command that produces a file. Swapping one model to another is editing a string.
The diff is kept. What was proposed, what I changed it to, and when. Not because anyone audits me, but because the difference between those two things is the only real measure of whether the machine is any good at a given job. If I am rewriting every draft, the prompt is wrong. If I am approving everything untouched, I should look harder.
Why this has anything to do with your build
Interlock gates articles. Your project is not an article. The shape transfers anyway, because the shape is the point.
On a build, the same idea shows up as the things I have always done and now do more deliberately:
The spec is written before the code, by me. The scoping sprint produces it. No agent decides what a system is for. That decision is the expensive one, and it is the one you are paying a senior engineer to make.
Tests come before the implementation. A test written first is a gate in exactly the sense above. The work does not proceed until a condition is satisfied, and the condition is one I wrote, not one the machine chose for itself.
Every diff is read before it lands. Not skimmed. Read. This is the step that machine speed makes tempting to skip, which is precisely why it is the one to make structural.
The automated checks run on every change. Tests, linting, a security scan, a code smell pass. Cheap, boring, and they do not get tired on a Friday.
The honest summary is this. AI accelerated means the typing is faster and the boring parts are cheaper. Senior led means every decision that matters and every line that ships went past me. The speed comes out of the mechanical part. It does not come out of the judgement, because that is the part you are actually buying.
Where it actually is
I said I would be honest, so: Interlock is not finished.
What works today: the workflow runs on its schedule, the agent step executes on my paired runner, the artifact reaches the inbox, all five reviewer actions work, reminders chase me when something has been sitting too long, and the run history says what happened and what failed.
I am not selling Interlock. It is a tool I built for myself because I wanted an answer to "who checks it" that was a mechanism rather than a promise. If it turns into a product, that will be a separate conversation, and it will not happen until it has been boring and reliable for a long time.
If you are weighing this up
The question behind "do you use AI" is a question about risk, and it deserves a concrete answer rather than reassurance. Mine is: the decisions are gated, the gates are structural rather than a matter of my mood, and the reviewer is a senior engineer who will still be here when it breaks.
If you have a build in mind, start with the scoping sprint. One week, £1,950 + VAT, and you get the spec, the architecture, the delivery plan and a fixed-price quote. If we go ahead with the build, the full amount is credited against it. If we do not, everything the week produced is yours to take elsewhere.