Loop Engineering works best for solopreneur-style new products — when you built it from scratch and hold the whole design
Last time I wrote an autonomous-loop skill called omh-issue-loop for Hermes Agent (Hand it an issue, get back a PR). Give it a single GitHub issue URL, and it delegates implementation to Codex CLI and review and behavior verification to Claude Code CLI, stopping on a review-ready PR.
This development style is commonly known as Loop Engineering. Agents run the implement-verify loop; humans handle plan, substrate, and the final merge call. It is a division of labor, not a tool.
After running the loop daily for a while, one thing has become obvious: Loop Engineering is not universal. The repositories where it works cleanly and the ones where it grinds are separated much more sharply than I expected. And where it works most cleanly is on a solopreneur-style new product, one you spun up from scratch and whose full design still lives in your head.
This post is about why it works there, where it stops working, and what to put in place on day one of a new product so the loop can spin cleanly.
The three preconditions Loop Engineering demands
At the end of the last post I wrote that human time had moved almost entirely to “the substrate the loop runs on” and “planning the issue.” The other side of that observation is: if either of those is weak, the loop does not really run.
Broken down a bit more, Loop Engineering needs at least three preconditions.
- It is clear who owns the specification, and that person can write the issue.
- The verification substrate (tests, types, lint, CI) actually fails when something breaks.
- The decision loop closes, meaning the reviewer, the merge decider, and the person who requested the work share the same sense of what “done” means.
On a solopreneur-style new product, all three are satisfied automatically. You own the spec, you built the verification substrate, and you also merge. Because every decision channel closes back to the same person, there is no gap for the channels to drift from each other.
In repositories where any of these is broken, the loop can spin without actually judging anything.
Where Loop Engineering does not work
Let me start with the negative cases, because they make the positive case for a new product sharper by contrast.
A large existing codebase
Trying to run Loop Engineering on a codebase that has been alive for ten years usually stalls first on the verification substrate. Tests exist but no longer fail when something breaks, lint is enabled on only some directories, types exist but are shot through with any.
In that state, a PR that clears the five review gates only guarantees that it cleared the gates. It does not guarantee that no regression was introduced, because gates cannot judge what the substrate does not measure. You can stack more gates and the answer does not change.
There is a path to enabling Loop Engineering here. But the first step is not to start feeding new issues into it: it is to raise the floor of the verification substrate. Get that order wrong and you accumulate bad merges very quickly.
Distributed decision-making
Another setting where it stops working is when the person who finalizes the scope of the issue, the person who requests the implementation, the reviewer, and the merger are all different people.
Loop Engineering treats the issue as the single authoritative scope. Nothing outside the issue gets implemented, and anything that drifts from it halts the loop. That design implicitly assumes the person who wrote the issue is also the person who accepts the result.
When decisions are distributed, what is written in the issue, what reviewers expect, and what the merger judges by all drift subtly. The gates pass, and then a reviewer says “this is not what I had in mind.” Loop Engineering, today, does not have a circuit for absorbing that temperature gap.
You can, of course, front-load consensus so that everyone is aligned by the time the issue is written. Then the loop can run. But you have loaded the cost onto the issue-writing step, which changes the whole cost model of the loop.
A verification substrate that looks alive but is not
The worst case is a repository where tests pass, lint passes, and CI is green, yet there are large classes of bugs that only appear in production. Loop Engineering there becomes a machine for continuing to believe that a broken verification substrate is a working one.
In the last post I wrote “a failed review is not a clean result.” But verification that never fails in the first place cannot be caught by that rule. You have to repair the substrate before you turn on the loop, or every clean run stacks another layer of unjustified confidence.
What makes a solopreneur-style new product special
Turning that around: a solopreneur-style new product is special for Loop Engineering because four things hold simultaneously.
1. Specification authority closes to one person
You started it from scratch, so you know why the feature is needed, what is inside and outside scope, and why the alternatives were rejected. Writing an issue becomes the act of externalizing the design that already lives in your head. Because no consensus step is involved, writing is fast, but anything you did not write down does not travel.
That structure fits Loop Engineering unusually well. If you want the agent to do what you meant, being in a state where you can write your intent down without residue is the shortest path. On a solopreneur-style new product, you can reach that state without paying any coordination cost.
2. You get to shape the verification substrate on your own terms
Early on, the choices about tests, types, lint, and CI are entirely yours. No legacy commitments, no cross-team negotiation. You set test granularity, type strictness, lint rules, and CI failure conditions at the level you personally want the loop to be judged at.
Loop Engineering can only delegate as far as the verification substrate can judge. Being able to set that ceiling high while nobody else has an opinion is a huge lever. Raising the ceiling later is the same kind of retrofit as tightening types after the fact, and the cost multiplies.
3. The decision loop closes at merge
As above, Loop Engineering leaves only the merge decision to humans. When the merger, the issue author, and the person who knows the intended feel of the feature are the same person, the criteria for review click into place completely.
Judgments like “the issue says X, but given the actual point of this feature, the implementation should really be Y” (the kind of feel that never fully fits into the text of an issue) happen entirely inside your own head. Not having to transmit that feel to anyone else generates a surprising amount of leverage.
4. You control the granularity of every issue
A secondary but practically important point: you decide how big each issue is.
Loop Engineering caps combined fix attempts at 10 (last post). That cap implicitly assumes issues are sized to be tractable. Put five features into one issue and 10 fix rounds will not converge.
On a new product, the granularity call is yours alone. You can decide, from the start, “this issue is sized so it lands in a single PR.” Since you are not slicing large pre-existing problems, the granularity design cost is small in the first place.
What “development proceeds as intended” actually means
I have been saying “development proceeds pretty much as I intended.” Let me unpack what that actually contains, because it has at least three layers.
The intent is implemented as-is
The surface reading is: the diff that comes back matches what the issue says. On a solopreneur-style new product this holds a high fraction of the time, for a simple reason. You hold all the context behind what is written in the issue, so there are fewer omissions in the first place.
Even when there is an omission, you spot it immediately during review. On someone else’s issue, telling apart “an omission” from “an intentional spec choice” takes time. On your own issue, you do not hesitate.
When it diverges, you know why immediately
The next layer is what happens when what comes back diverges from the intent. As a solopreneur, the moment a divergent implementation appears, you can immediately classify the cause: was the issue written badly, did the agent interpret it strangely, or was the intent itself not really settled?
Because you can classify it, the next action is decided on the spot. If the issue was written badly, fix it and re-run. If the agent’s interpretation was off, tighten the prompt restrictions. If the intent was not settled, stop and redesign. The smoothness of that fork is a big part of what “proceeds as intended” feels like in practice.
The intent itself gets sharper
There is a deeper layer. Once you have been writing issues for the loop for a while, more things have to be decided before you write. As I mentioned last time, the decisions you used to defer with “I’ll figure it out as I code” all get pulled forward.
On a solopreneur-style new product, that pull-forward becomes the shape of the design itself. When the issue is not written for consensus with others but for explaining the plan to yourself, the number of times you catch yourself thinking “wait, how does this actually work” while writing goes up sharply.
“Proceeds as intended” is not only that the implementation matches the intent. It is also that the intent itself is sharper than it used to be.
What to put in place on day one
If you plan to run Loop Engineering on a solopreneur-style new product, there are a handful of things worth putting in place on the very first day of the repository. You can add them later, but every day you delay is a day the loop runs at a lower verification bar.
AGENTS.md and CLAUDE.md
AGENTS.md and CLAUDE.md are the files where you write per-repository instructions for agents. The Loop Engineering preflight reads the validation commands and restrictions from here, so put the following in on day one.
- The exact commands for build, test, lint, and format.
- Which files are in scope and which are off-limits.
- How to handle generated files (committed, or not).
- The rules for adding dependencies.
- The convention for commit messages and PR titles.
On a new product, many of these will not be settled yet. Still, write the current best guess down explicitly rather than leaving it blank. Agents treat “not written” as “free to decide however,” so writing a provisional rule is qualitatively different from leaving a gap.
One failing test and a working CI pipeline
You will not write many tests on day one, but the state “one test exists that actually fails when broken” is worlds apart from “no tests.” A single test is weak as verification content, but it proves that CI actually runs and that failures actually reach the agent. The wiring is there.
At the same time, add the CI workflow file on day one. Later, growing test coverage is just adding lines to it, and you never have to schedule a “day for setting up CI.”
Issue templates
The Loop Engineering preflight uses the issue snapshot as the sole authority. A vague issue produces a vague output, so add GitHub issue templates on day one.
The fields I am using right now are:
- What are we solving, and why now?
- What is in scope and what is out of scope, listed explicitly.
- Acceptance criteria, in a verifiable form.
- Which code will be touched and which code should stay untouched.
- If there are alternatives, which is chosen and why the others are not.
For a solopreneur, going through these fields is itself an act of design. Treat the template as a way to force your own thinking into a procedural shape, not as something aimed at other humans.
Decide up front whether signoff is required
The signoff_required flag from the last post is worth deciding on day one of a new product. If it is a personal project and signoff is not needed, say so in AGENTS.md or CLAUDE.md. If you plan to open-source it later and require DCO, set up a gh signoff-style wrapper from the beginning.
Switching mid-way forces you to reconcile the policy of every earlier commit after the fact. Loop Engineering operates under the discipline that “a configured account is not necessarily an active session,” and the policy itself changing is just as fragile a source of drift.
Watch for the signs it is stopping working
Even on a solopreneur-style new product, as the product grows, the effectiveness of Loop Engineering degrades. When any of the following start showing up, it is a cue to stop and re-examine the design.
- The same review finding keeps resurfacing inside the loop, and more issues fail to converge in 10 rounds.
- Reviews pass but bugs start appearing after merge.
- It becomes harder to size an issue to fit in a single PR.
- Validation commands grow to the point where AGENTS.md no longer matches reality.
- You can no longer hold the entire design in your head alone, and issues start showing omissions.
These are all signs that one of the three preconditions is beginning to crack. Specification authority is starting to spread, the verification substrate is starting to exceed what it can judge, or the decision loop is no longer closing.
If you push the loop through this stage anyway, it drifts into the state of “spins cleanly but is not actually judging anything.” The right move is to run Loop Engineering while consciously protecting the scope it can still judge, or to deliberately reintroduce human review for the parts that have outgrown the substrate.
In other words, Loop Engineering is a tool that runs at maximum efficiency while a new product is still new. Its cost curve shifts as the product matures. Reading it as “the free lunch will always be there” is what breaks you later.
Wrapping up
Loop Engineering is the style of development where you hand an issue to AI agents and get a review-ready PR back. Agents run the implement-verify loop; humans focus on plan, substrate, and merge.
For this style to work, you need clarity on who owns the specification, a verification substrate that actually fails on breakage, and a decision loop that closes at merge. Large existing codebases, distributed organizations, and repositories with a hollowed-out verification substrate rarely have all three, so the loop tends to spin without any real judgment happening inside it.
A solopreneur-style new product, on the other hand, satisfies all three automatically. You own the spec because you started from scratch, you can set the verification substrate high because nobody else has an opinion yet, and the merge decider is the same person who wrote the issue. That is why the design intent of Loop Engineering pays off there the most, and why “development proceeds as intended” feels so tangible.
It is not permanent. As the product grows, one of the three preconditions will crack. The job is to catch the signs and switch modes (protect the scope the substrate can still judge, or reintroduce human review) instead of running the loop past the point where it means something.
Put differently: Loop Engineering is a tool that gives you maximum leverage on a solopreneur-style new product right now, at the stage where it is still new. If you know you are in that stage, going all-in on it is the right investment to make.
That’s all from breaking down what separates the repositories where Loop Engineering works from those where it does not, and confirming through daily practice that a solopreneur-style new product is where it works best, from the Gemba.