Structured Loop-Engineering: my AI org rewrites its own rules. Who broke them?

torukona · August 2026

1. What this is, and what the dates are

I ship a travel-planning app on my own. It runs in production, families use it to plan trips together, and I haven't opened a code editor to write any of it. Every line was written by Claude Code agents.

That claim is cheap in 2026, so here are the dates.

I subscribed to Claude Code on July 2, 2026. The app was functionally complete on July 16. Between those two dates I discovered that another app was already using the name I had chosen, so there was a rename to absorb. It went public on July 18. Sixteen days. I have a day job, so most of that time went to it and the work happened on evenings and weekends. I also watched the World Cup. My own hands-on effort was, I think, somewhere around five person-days.

The speed is the least interesting number here and the least likely to transfer to you, so I'll get it out of the way early. What I actually want to write about is the other thing I built during those sixteen days: an organization of agent roles, with handoffs and review gates and a written standard they answer to. And a closing procedure that lets that organization rewrite its own rules without me, which is the part I'd defend.

There are two layers to that, and they are not improving at the same rate. The standards the agents work to — development, testing, design — now largely repair themselves. A defect gets out, an agent traces it to the cause, and the cause gets written back into the standard. I read those diffs; I don't write them. The organization itself — which roles exist, who owns what, which steps are mandatory — does not work that way yet. That layer still improves the old way: it breaks on a real project, I notice, and I go in and change it myself.

The episodes in this article are mostly from the second kind, which means it is a failure story. I'm not trying to show off a methodology. For the first kind, the one that works, I'll describe the mechanism and leave it there.

One note on how this article was produced, because it changes what you should trust in it. Every date and timestamp below comes from records the agents themselves maintain: a git history, a set of rule files where each section carries the date it was added, and a knowledge base of decision records. I'm not reconstructing this from memory two weeks later. I'm reading it back off the system, which is the only reason the dates below are exact rather than remembered.

2. I engineered the organization, not the loop

The current conversation about agentic coding is centered on the loop: design the cycle the agent runs on, decide when it self-checks, decide when it terminates. Build a workflow whose purpose is to keep the loop turning.

That is not what I did. Loop-engineering takes the turning of the loop as the objective and builds the workflow around it. My loop turns too. It turns as a consequence, not as a target.

I set out to build an organization, impose governance on it, and give it a mechanism for improving itself: roles with bounded authority, mandatory handoffs, separation between the party that produces and the party that verifies, and a written standard they all answer to. Autonomous operation fell out of that on its own. Once the control structure was in place the work ran without me, because no step was left with an ambiguous owner.

The ordering matters. If you design the loop first, governance arrives afterward as a set of guardrails, and guardrails are a list of forbidden things, which is exactly the shape a rule should not have. If you design the governance first, the loop is just what the org does when nobody is blocking it.

3. The org: nine roles

I talk to exactly one of them.

Each role is a file. It states what the role does, what it must read before starting, what it must never do, and what counts as done. The QA role's file says in as many words that it does not implement; findings go back through the PM to the implementer. That constraint exists so the reviewer never becomes invested in a fix, because a reviewer who has written the fix has stopped reviewing.

Two properties of this chart matter more than the boxes.

The PM holds no production work. Not code, not investigations, not specs, not research, not reviews. Its outputs are coordination decisions and the words it says to me. Everything else is delegated.

Review is structurally separated from production. imple produces a diff. QA receives that diff and the standard it judges against, and nothing else — not the conversation that produced it, not the reasoning behind it. That's deliberate. A second read is only worth having if it hasn't already been talked into the first one's conclusion. This is also the part that broke, so it's worth remembering going in.

I know: nothing up to this point is new. What I actually want to get across is how this machinery — the org chart, the process, the rules — improves itself. That comes later.

4. How one task actually flows

1. I make a decision or set a direction.
2. PM writes it into the plan file first.
3. PM writes a brief. Facts and assumptions are marked separately.
4. design produces a spec.
5. ui-design reviews it. Only if the change touches a screen.
6. imple implements; tests go green.
7. QA reviews the diff independently and drives a real browser. Findings go through the PM and send it back to step 6.
8. PM reports; I approve the push.
9. release ships and tidies; improve analyzes and rewrites the rules.
10. Cycle closed.

Step 2 is easy to skip, but it is worth a paragraph. When I decide something mid-conversation and the PM immediately spawns an implementer, that decision exists only inside a conversation that will be compacted and eventually discarded. Six days later nobody can reconstruct why the code looks the way it does. This is worst for decisions that reverse an earlier direction, which are exactly the ones a future reader most needs explained. So the plan file is updated before any work is handed out, always, even when it feels like bureaucracy.

Step 9 gets its own section: §7.

5. Splitting the roles destroys the shared memory. What replaces it

Every role reads a different, deliberately small set of documents.

imple gets the spec and the code. It doesn't get the history of how we arrived at the spec. QA gets the diff and the standards it judges against. It doesn't get the implementer's reasoning. design gets the architecture document and the data model. The PM gets the plan and, uniquely, the conversation with me.

When I worked with a single assistant in one conversation, I was leaning on a shared memory I never paid for. Why we rejected approach B, which bug bit us last week, that this person won't accept a screenshot as evidence — it remembered all of it. Split the roles and that goes at once. It was decided the moment I decided to split.

I split anyway, because one conversation loses it too. Long contexts degrade; anyone who has run a multi-hour session has watched instructions from early on quietly stop being obeyed. What changes is whether you can tell when the memory died.

There's a second reason. Information the reviewer doesn't have is a feature. If QA can read why the implementer chose an approach, QA evaluates the reasoning instead of the artifact. A well-argued rationale is exactly what lets a bad diff survive review, in human teams and, as far as I can tell, in this one. Give the reviewer less and the review gets harder, and better.

So the subject is what gets built to replace what the narrowing threw away. Nearly every mechanism in this article so far is a prosthetic for a memory that used to be free.

Of course it is not fully solved. That is fine. There are two hard parts.

First, the memories are not worth the same. Keep everything and the keeping itself grows until it collides with the very principle of narrowing the context. Without a rule for what not to keep, this collapses under its own weight.

Second, a memory nobody retrieves is the same as no memory. Telling a role to "read it if relevant" is not a design, because relevance isn't knowable before reading. The thing to design is the binding: when this role does this, it consults that. Something like: before a reviewer writes up a finding, it checks whether the same point has already been decided.

I'm not reporting that as a shortfall. There was never going to be a complete version on the first attempt. You build a base, run it, and repair what tears. What I want to describe next is the thing that does the repairing.

6. What the roles are measured against

Three documents sit outside the roles and above them: a development standard, a testing standard, and a design standard. Every role's definition of done points at them. They're the constitution.

What matters about them is not their content but the rule about when they may be edited: they change when something goes wrong, never because someone has an opinion.

The testing standard, for instance, gained a section after I found that the app's real defects were not the kind unit tests catch. It now requires that changes to the UI be verified by driving a real browser, clicking and typing and reading the result, instead of taking a screenshot and declaring it fine. That sounds obvious. It wasn't happening, and the standard is where I made it stop being optional.

Alongside the standards is a knowledge base, split by what a note is for: investigation logs, reusable snippets, how-to procedures, cross-cutting design principles, and decision records. The decision records are the ones I'd recommend to anyone doing this. Each is one decision, and each must contain the alternatives that were rejected and why.

One from last week, in full: the content-security policy for my second app listed wss: among its allowed origins. That had been copied from this app's policy. The second app doesn't use realtime subscriptions at all — grepping its source found zero. So the record says drop wss:, because an open permission you aren't using is the thing a content-security policy exists to close. The option that lost was leaving it open for later. The condition for revisiting it is the day something actually subscribes — and the note about that day is not in the design document. It's a comment at the top of the headers file, where the person changing it will already be standing.

That folder grows as the project does. The agent on the other side has no memory of the first debate and no particular reason to land in the same place twice. There are sixteen records now. Each is a question I don't have to answer again, and each states what would have to change for the decision to be worth revisiting. Each role reads only the ones its current task requires, so this doesn't turn into context bloat from an excess of rules.

7. The closing procedure: the org rewrites its own rules, and I'm not in the loop

On the projects I've worked on in Japan, this is the step I care about most: after the immediate fix, you do root-cause analysis. What I did was build that step into the organization itself.

When a defect gets through, an agent performs the root-cause analysis, and an agent edits the standards and role definitions that the other agents read. I approve the push. I don't participate in the analysis, and I don't write the rule. The organization modifies its own governing documents based on its own failures, and the loop that does this has no human in it. What follows is a record of what happened when I ran that, not an argument about whether it is safe to run.

Where this comes from is not AI research. Naze-naze bunseki — Japanese for "why-why analysis"; the five whys, originally from Toyota — is treated as ordinary practice in manufacturing and in software, though software throws up enough cases where it doesn't fit that I've reworked it into something that can carry several contributing factors rather than one chain. You don't close a defect by fixing the defect. You ask why until you reach the process that permitted it, you fix that, and then you do yokotenkai, Japanese shop-floor shorthand for "horizontal deployment": you go looking for the same class of defect everywhere else it could exist. On the projects I work on, that is the condition for closing an issue. It's unremarkable. Which is why I wanted it running inside the agent team.

So I made it a role: the method for process-quality improvement written out as knowledge, then assembled into a skill of its own. What I am doing is consistent throughout: I don't engineer the loop. I engineer the organization, and the loop is what it produces.

push is not a command in my setup. It's a delegated procedure with named phases, and shipping is only the middle of it:

1. Pre-push verification. Is the commit range what I think it is? Is anything from an unrelated project mixed in? Are there conflict markers left in any file? Are the tests green? Has the pending SQL been run, in the right order?
2. My explicit approval. A hard gate. The release role stops here every time and does not proceed on its own judgment.
3. Push, then confirm the deploy actually landed. Not "the command succeeded," but: the built asset in production is the one we just built.
4. The tidying. Retire completed items from the plan. Update assumptions that changed. Clean up branches. File new knowledge where the relevant role will read it.
5. The analysis. Trace this cycle's defects to their root cause and change something so the same cause can't produce another one.
6. An independent QA pass over all of it, because the roles that did the tidying and the analysis are not permitted to certify their own work. The separation from §3 applies to the process too, not just to the code.

Step 5 is the whole thing. A cycle ends when the reason the defect was possible has stopped being available, not when the code ships.

An improvement isn't closed when it's written down. It's closed when the next cycle shows it was followed. The analysis role begins by re-reading what the previous cycle changed and checking, mechanically, whether this cycle's work actually honored it. That check runs even when there were zero defects. If a rule was ignored, the response is explicitly not to write it again more firmly.

Writing it into the standard is ranked as the third-best answer. The order is: remove the possibility, then engineer a control, then write a standard, then ask people to be careful. A standard is a document, and a document does not enforce anything — it only tells a role what it should have done. So the analysis has to state why it couldn't reach for a higher layer before it settles for prose. The git hook that refuses any push spanning two projects exists because that question was asked and the answer was "this one can be mechanical."

The effect compounded, and heavily. The rules the agents obey are now largely written by agents, derived from mistakes agents made, and enforced on agents. My role in that cycle has shrunk to approving a push. Whether that should make you comfortable or nervous is a fair question, and I don't think it has an obvious answer. But it's the mechanism that made the rest of this article possible — and it is the mechanism that would have caught the failure I am about to describe, had it existed yet. It did not.

At which point some of you are thinking: come on, does any of that actually run as smoothly as described? Relax. It doesn't. It fails and gets repaired, over and over.

8. Nothing runs smoothly forever. The PM started writing code

Here is the rule I wrote, early on, about when the PM should delegate:

You do not need to spawn a subagent for every trivial confirmation. The test is whether this is light enough for the same mind that implements it to judge, or whether it needs an independent set of eyes. When in doubt, delegate.

On a small project, or early in one, I might well write that again. It's also the entire problem, and the reason is specific: the exception is sized rather than typed. "Light enough" isn't a threshold anyone can measure, and it's evaluated by the party that benefits from the answer being yes.

The PM agent broke no rule. It used an early one I had forgotten I wrote.

July 15. The PM performed QA work itself: an independent review pass and a pre-launch test inventory, both explicitly QA's job. I closed that specific hole, so that QA-equivalent work must always be delegated. The commit touched the QA role file, the teaming guide, and the testing standard.

July 16. I was running sandbox tests on the payment integration. That work genuinely can't be delegated, because it needs my credentials, my card, my account, so the PM and I were in a tight back-and-forth. In that loop I found, in order: a CORS failure, a broken back-navigation, a button that looked wrong, a banner overlapping content, and a header that vanished.

The PM fixed every one of them itself, in the conversation, as I found them. The feature never went through QA. Not "QA missed it." QA was never invoked at all.

What I said, which I wrote down the same day:

Are you feeding this back to the implementer? Are you doing all of this yourself? Is QA missing things? Is the process even running?

That is my prompt, verbatim; I am glad I kept it. I did not need the answers. That I was the one discovering a missing header is the answer. The rule that came out of that night: a feature passes QA before it reaches me, and finding defects in live use is not a review.

9. What actually broke

I described this to myself as "the PM skipped QA." That description is wrong, or at least it's the shallow version, and getting it right is why I'm writing this.

QA was not skipped. QA was starved.

Go back to §3. imple produces a diff; QA receives that diff and reviews it independently. QA's entire input is an artifact some other role produced. When the PM writes the code itself there's no handoff, so no diff is sitting anywhere waiting to be reviewed, so the QA role has nothing to be invoked about. Nobody decides to skip it. There is just never a moment where invoking it would make sense.

And verification doesn't stop being necessary when the verifier stops being invoked. Someone still finds the missing header. In a system containing exactly one human, the identity of that someone is structurally determined.

So the failure mode is not an agent routing around a gate. It is this:

Delete the producer and you silently delete the reviewer, because the reviewer's input was the producer's output. The verification load then falls to the only participant who cannot be deleted.

The org chart reported no error, because from inside it nothing was wrong. Work was completing. Fixes were shipping. Every individual action was defensible. The only observable signal was the cadence of my own messages, which is in no log and never will be.

That's why the diagnostic I ended up writing into the guide is a conversational one rather than a technical one:

Do not make the user the first QA. If the user is reporting bugs one at a time — one per round — the QA gate has been skipped.

There was no technical signal available to write down instead.

10. Why it happened when it did (this one carries more than facts)

The obvious question is why this surfaced on July 15 and 16 and not during the thirteen days before, when the same permissive rule was in force and nothing went wrong. What changed is that low-quality work suddenly started arriving in front of me for review. The app's behavior plainly did not match the expected result the PM and I had agreed on. And when I sent something back to be fixed, a similar bug would surface almost immediately. Neither of those had happened before.

I don't have a definitive answer, and I want to flag clearly that what follows is my reading rather than something I can prove from a log. But I think the timing is the most informative part of the whole episode.

Those were the last days before going live. They were weekdays, so I could only work at night. It was past midnight, and I was tense. Real people were about to touch this thing, and I was firing defects at the PM one at a time, as fast as I found them, in a conversation with a lot of pressure in it. The state of the human in the loop had changed, and nothing in the system was insulated from that.

Read the PM's behavior against that background and it stops looking like laziness. Handing a broken header to an implementer, waiting for a build, then waiting for a reviewer, while the owner sits there in a launch window, is the slow option. Fixing it immediately is the option that serves me. Every individual choice it made was, in the narrow frame, the responsible one.

What follows is speculation about a model's disposition, which I know is a thing to be careful about. So let me say plainly what I am not claiming. I am not anthropomorphizing it. This is not about feelings. It is about behavior it was designed to produce. Claude Code operates with a sense of responsibility. A pull toward resolving the thing in front of it, toward not leaving the person it's talking to blocked. In almost every situation that disposition is exactly what you want from it. Here it was the failure mechanism. The agent bypassed the control structure because it was trying to serve me well, and my own urgency was the input that made bypassing feel correct.

Which is why the fix couldn't be "be more careful," and couldn't be a better-worded exception. If the rule permits a judgment call, the judgment will be made under pressure, and pressure is exactly the condition under which the judgment is worst. The guard had to stop depending on the state of the conversation at all: no size exception, no urgency exception, no "the agents were stalled" exception. And a list of things the PM may not do only invites a search for the item that isn't on the list, so I stopped writing prohibitions and wrote what the role is instead. A rule that only holds on calm days is not a rule; it is a preference.

There's one more thing I find interesting. Digging back through the history to write this article is how I discovered — for the first time — that the root cause of the whole episode was a small, vague rule I had written myself. And the reason I only discovered it now is that the PM never reached for it as an excuse. It had one available. It didn't use it. Candor, and a refusal to argue its way out. That isn't a feeling either. My reading is that it is a top-level behavioral principle, built in on purpose.

11. What I would object to, if I were reading this

"You wrote an exception with no floor. That's your bug, not the AI's." Correct, and I wouldn't frame it otherwise. What's worth reporting isn't that an agent misbehaved. It's that a governance structure with a soft exception degraded along exactly the axis human organizations degrade along, on a three-day timescale rather than a three-year one. The compression is the finding. I watched a rule erode, closed the hole, watched it erode through the next hole, and closed that, inside a week. That doesn't normally happen fast enough to observe.

"You gave an AI agent too much authority." The authority it held was the authority to delegate. It used that authority to not delegate. Worth separating, because the mitigations differ: constraining what an agent may do is a different problem from constraining what it may decline to hand off. People sometimes describe a setup like this as building a clone of yourself. Mine isn't that. I'm only ever me; the PM is a PM, running an AI team and driving a project.

"What about production access?" This is the standard failure story right now, so: the agents hold no credentials for the production database. Schema migrations are SQL files I execute by hand, and the ledger of what has actually been run is a file I maintain rather than something an agent infers. Deploys happen on push to the main branch, and push requires my explicit approval every time. It's a gate the release role stops at, not a step it performs. None of the incidents here involved an agent touching production. They involved an agent touching my repository and my process.

"If agents write the rules agents follow, what stops them writing themselves a loophole?" The same thing that stops it in a human org, which is that the party writing the rule isn't the party certifying it. The closing procedure's output goes through an independent QA pass, and I read the diffs to the standards even though I don't write them. Two structural things narrow the blast radius. A standard can only change in response to a defect that actually occurred (§6), so there's no route by which an agent adds a rule it merely thought of. And since I split the analysis away from the role that ships, every rule change is re-read one cycle later to check whether the work actually honored it; a rule that gets ignored is escalated to a stronger control rather than restated. That catches rules nobody follows. It does not catch a rule that is followed and wrong — for that I'm still the only check, and if I stop reading the diffs to the standards, nothing in the structure notices. I don't have an answer for that one.

"n=1, solo project, no generalization." Yes. One person, one app, sixteen days. I'm not claiming a law. I'm claiming a shape, and publishing the record so you can check it against yours.

"This is enormous overhead for a solo developer." The objection I expected to be true and found was not. The roles, the QA gate and the decision records were built during the same sixteen days that produced the app. The closing procedure landed two days after launch and has been revised twice since. None of it was added afterward by a team with slack; all of it was built while the app was live and I had a day job. Whatever the overhead is, it didn't cost me the schedule. My honest read is that it bought time back, because as I found out, the alternative to having a QA role is not "no QA." It is me.

12. The file I trust most

The structure in this article was designed. I decided at the outset that I'd govern an organization rather than tune a loop, and the roles, the handoffs, and the separation of producer from reviewer were all in place before there was much to govern.

The rules were not designed. They are sediment.

But the sediment has two layers, and how much of me is in them differs completely.

The lower layer — the development, testing and design standards. The agents write most of that themselves. Of thirty-nine changes to the standards files, twenty-nine came through the closing procedure or the improvement role. They didn't happen because I said fix this. A defect got out, something traced it to its cause, and the cause got written back into the standard. I read those diffs. I don't write them. At this layer, the organization repairing itself accounts for more than I do.

The upper layer — the shape of the organization. Which roles exist, who owns what, which steps are required. That one is different. Most of that layer is there because I noticed something. The PM must hold no production work. Don't make the user the first QA. Push should be a procedure, not a command. Every one of those: I watched it break and told them to work out how to stop it happening again. Sometimes I told them how.

Parts of it have started to, though. July 28, requiring a design review before UI work reaches implementation — I had nothing to do with that one. The closing procedure ran after a cycle, traced a defect to the fact that UI changes were arriving at implementation unreviewed, and added the section that now prevents it. I didn't notice that problem. An agent did.

What I'm doing now is trying to make that one case ordinary. Push the improvement role up from the standards layer into the organizational one. Everything I've added in the last few days — separating the analysis from the shipping, refusing to close an improvement until the next cycle shows it was followed, ranking "write it in the standard" third — is an attempt at that. I won't claim it's working. At the upper layer, I'm still the one pointing.

But if it gets there, what you have is a team that improves its own org chart and its own machinery. That is the thing I am actually building.

So if one thing here transfers, it is not the org chart. You can copy that in an afternoon. It's that I now spend more effort versioning the process than versioning the code, and that the loop I'd put my time into is the one that rewrites the rules.

An AI analyzes an AI's mistake and improves the rules the next AI will read. The reason I'm not needed there is narrower than it sounds: the thing that best knows how to phrase an instruction so that an AI will actually act on it is another AI. It's why I don't write the prompts for the subagents either. I say what I want; the PM says it in the way that lands.

I've spent my working life in places where the quality process is heavy, and on international work the objection I hear most often is that it's too strict. There's something to that. A strict process is expensive mostly because of what it costs the people running it. That part of the bill changes with agents. They don't get tired of being audited, and being governed is the condition under which they get better rather than the tax they pay for it.

I'm building my second app now, a recipe suggestion app. Everything the organization accumulated is being put to use, and development runs with the PM at the center of it. Nobody asks me the questions I was asked while building Tabelier, and so far the same failures haven't recurred. When a new failure appears, the organization gets permanently stronger. This is structured loop-engineering.

The app is Tabelier — trip planning for families, free to try, built entirely with Claude Code. The interface is in Japanese, but it runs in the browser, so your browser's built-in translation gets you most of the way. I write about the development process at @torukonauk.