Closing the Loop to Full Autonomy

Written by Mike McGreal, Dendro Logic | Engineering | Published: 17 July 2026

The most important button in my development process now does almost nothing.

When a pull request lands for review on one of my products, I read the summary, glance at the verdict, and hit merge. There is no heroics in it, no line-by-line audit, no bracing myself for what the AI got wrong. It arrives already correct, and I approve it. That anticlimax is not a failure of diligence. It is the entire point.

In an earlier piece I described an agent shipping four features overnight, and argued that what made the output safe to ship was not the model but the machinery around it: feedback loops that catch mistakes, and a memory that stops the agent guessing. This is the sequel to that idea. Once every gate in the build is genuinely enforcing correctness, and once the agent is grounded in what you already know, the last human step – the merge – stops being where quality is decided. It becomes ceremony. And getting to that ceremony deliberately is what “closing the loop” actually means.

What a closed loop looks like

Here is the shape of it on one of my own products.

A foreman process holds the backlog: a ledger of units of work, each with its dependencies and its readiness state. It picks the next unblocked unit and dispatches an autonomous build. The build is not a free-for-all. It runs the full correctness loop I use for everything: specify the change, build it test-first, and have it reviewed by an independent context before it is allowed to call itself done. The agent writes the migration, the access-control rules, the integration tests, the end-to-end tests, and its own implementation notes, and it does not open a pull request until that loop comes back clean.

None of this rests on a single review at the end. The plan is reviewed before any code exists, because a design flaw caught on paper is the cheapest fix there is. The finished code is then reviewed during the build by a fresh independent context. And when the PR opens, a separate review runs again over the whole diff and posts a verdict where I will see it: approve, or hold with the blocking reasons. By the time it reaches me, the work has passed through several independent gates, not one. If it is approved, one tap from me merges it. If it is not, one tap sends it back to be reworked, and the loop goes round again on its own.

Several features have shipped through this loop now, back to back. One of them was a keystone piece: a new domain entity spanning a database migration, row-level security, the UI, and a full test suite including data-erasure compliance – thirteen files, fourteen hundred lines. It came back from its final review as “exceptionally high-quality, robust, and secure,” with four advisory notes and nothing blocking. I read the verdict. I hit merge. That was my entire contribution to that feature’s correctness, and it was the right size of contribution, because everything that could be verified had already been verified.

Why the merge can safely be ceremony

The obvious objection is that a rubber-stamp merge is exactly how disasters ship. It would be, if the stamp were the only check. It is safe here for one reason: correctness is enforced at every gate before the PR reaches me, not concentrated at the end where a tired human is the last line of defence.

That is the inversion. In a normal process, review is a single event at the end, and its quality depends entirely on how carefully one person reads a diff on a Friday afternoon. In a closed loop, the same scrutiny is applied continuously – the plan reviewed before a line of code is written, test-first at the unit, an independent review of the finished slice, a second review over the diff – and each of those gates is a different context or a different model, so none of them is marking its own homework. By the time the work reaches the human, it has already survived several independent attempts to find something wrong with it. The merge is not where the code earns trust. It is where trust already earned gets acknowledged.

And to be clear that this is not blind faith: even in the run I just described, the gates caught a real failure that would have slipped past a lighter process. A change passed every unit test cleanly, and then the live verification step – the discipline of actually running the thing against the real system rather than trusting a green tick – hit a permissions error that only appeared in the real integration. Green was not working. The loop caught it, sent it back, and it was fixed before it ever reached me. That is the gate earning its keep. The merge is ceremony precisely because the gates are not.

The merge is the last small connection that closes the loop. By the time it happens, every gate has already run.

The part that actually matters for solo builders

There is a version of this that is about efficiency, and there is a version that is about survival. For a solo builder, it is survival.

The thing that kills a solo project is almost never a bug. It is stall. You have three products and one of you. Attention moves to whatever is loudest this week, and the other two go quiet. Quiet becomes stale. Stale becomes abandoned, or it becomes a thing you ship six months after the moment for it passed. The graveyard of solo projects is not full of buggy software. It is full of good ideas that lost momentum.

A closed loop is a momentum machine. While I am heads-down on one product, the others are not frozen – the loop is still picking units off their backlogs, building them, reviewing them, and queuing them for a merge I can approve in the gap between two other things. The pace does not depend on my continuous attention any more. It depends on my occasional judgment, which is a far cheaper resource to spend.

This is where the uncomfortable trade sits, and it is worth being honest about it. A slower, more hands-on process would produce work that is, at the margin, more refined. Cleaner in places. Occasionally more elegant than what the loop produces. I am not going to pretend otherwise. But that refinement has a price measured in time, and for getting an idea in front of real users, time is the whole game. No one remembers who came second. The more polished version that arrives after the window has closed is worth less than the good-enough version that arrived while the window was open. When the automated loop is already producing correct, tested, reviewed work, the marginal polish of doing it slower by hand is not free improvement – it is improvement bought with the one currency a solo builder cannot spare.

So the calculus is not “fast and sloppy versus slow and good.” The gates mean the fast path is already good. The choice is between good-and-in-time versus slightly-better-and-too-late, and stated that way it is not much of a choice.

Closed, not locked

None of this means hands off and hope. The loop I have described is full autonomy with a pause button, and the distinction is everything.

The loop opens pull requests. It never merges them. A human approval is always required, and it is the one thing the machine cannot do for itself. Alongside approve, there is a control to send a PR back for rework, a control to pause, and a control to redirect it onto a different unit if I want something else built next. My own comments on a PR are treated as first-class instructions and fed back into the next attempt. The autonomy is real, and it is also interruptible at any point by design.

What has actually happened is not that I lowered the bar on correctness. I raised it, and handed it to something that clears it more reliably than I ever did by hand. I no longer personally check whether the code works, because by the time it reaches me it has been checked far harder than a solo review on a busy afternoon ever could: the plan, the code, and the diff each scrutinised by an independent reviewer, every finding anchored to real evidence before it is believed. That is not caring less about quality. It is trusting a process more thorough than I am, and moving my own attention to where it is now scarcest. I have come off the correctness path and onto the direction path. My job in the loop is to decide whether this is the right thing to build, and whether it should ship. That is judgment, not verification, and judgment is where a human is still irreplaceable. The merge asks nothing of me on correctness because correctness has already been earned, not waived. It asks everything of me on direction, and it always will.

It compounds, too. When I send a PR back, or approve one after leaving a comment, the system distils what I flagged into a durable lesson that every future review inherits. The loop does not just hold its standard. It bends towards mine, a little more each time I use it.

The pattern

If you strip this down to something reproducible, it is not complicated to describe. A foreman that owns a backlog and dispatches work. A build that runs a real correctness loop rather than just generating code. Independent review, by a different context or model, gating the PR. A single human signal to merge, and simple controls to pause, rework, or redirect. And a memory that grounds every step and learns from your corrections. That is the framework, and I would encourage anyone building alone, or leading a small team, to build their own version of it.

The pattern is the easy part. What makes a loop like this earn its trust is everything that accrues inside it with use: the decisions the memory has captured, the gates tuned to the mistakes that actually bite you, the review standard that has learned your taste. You do not copy that. You grow it, by pointing your own loop at your own work.

So I have closed the loop. Not to remove myself from my own products, but to move myself to the one place I am still irreplaceable: deciding what is worth building, and saying yes. Everything the machine can already prove, it now owns. Everything it cannot – the judgment, the direction, the taste – is still mine, and there is finally enough room to spend my attention there.

The button does almost nothing now. That is how I know the rest of it is working.

Related Dendro Logic writing

• Shipping While We Sleep – the machinery of loops and memory that makes unattended, overnight building safe to ship.
• Agile Is the Bottleneck Now – why a delivery process built around the cost of writing code measures the wrong thing once that cost collapses.