Most software development treats a bug as a thing to fix. Find the defect, correct the code, run the tests, and move on.
When working with AI, that same approach does not always go far enough.
When an agent gets something wrong, it is important not only to identify the bug, but also to ask what was missing from the environment that allowed the mistake to look reasonable, pass its checks, and reach review in the first place.
Fixing the code addresses the immediate problem. Strengthening the environment can make the same kind of mistake harder to repeat.
That is the idea behind the Ratchet Loop.
From software ratchets to agentic systems
The idea of a ratchet is already familiar in software development. Regression tests preserve behavior that has been proven to work. Quality gates help keep known standards from slipping backward. Controls are often added after a real failure exposes a weakness that was not fully understood beforehand.
The underlying principle is simple: once a system has learned something important, future work should not have to rediscover it from scratch.
Inspired by those established ideas, I have been exploring how the same principle applies to the wider environment surrounding AI coding agents.
An agent can misunderstand a requirement, fill in a missing product decision, rely on the wrong source of authority, write tests around its own interpretation, and then provide a convincing explanation of why the work is complete.
The failure may not live in one function or line of code. It may exist in the relationship between the prompt, implementation, tests, permissions, and review process.
I call this broader approach Ratchet Governed Agentic Development, or Ratchet Development for short.
The lesson might become a regression test, but it might also become a typed contract, database constraint, permission boundary, provenance requirement, approval gate, or clearer definition of what an agent is authorized to decide.
Fixing the bug is only part of the job
AI coding agents can produce work that is impressively coherent. Even an incorrect implementation may be clean, documented, and supported by passing tests. The explanation may sound reasonable because, based on the agent’s interpretation of the assignment, it is.
The implementation, tests, comments, and completion summary can all inherit the same incorrect assumption. Everything agrees because everything originated from the same misunderstanding.
That does not necessarily mean the agent produced careless work. It may have implemented a reasonable interpretation of an unclear assignment or written a test that proved something close to the real requirement without actually proving it.
Correcting the defect is still necessary. But there is usually another question worth asking:
What could be added or changed so this class of failure is easier to catch next time?
The answer should be proportionate. A local bug may only need a regression test. A state that should never exist may need a database constraint. An authorization failure may belong in the permission system rather than in another prompt.
The goal is not to create more process every time something goes wrong. It is to make the lesson more durable than a conversation, completion summary, or project note when the risk justifies it.
The six steps of the Ratchet Loop
The process I have been using can be described in six steps:
Authorize → Build → Verify → Diagnose → Encode → Inherit
1. Authorize
Before implementation begins, define the boundary. What is changing? What is out of scope? Which existing decisions govern the task? What would prove the work is complete?
The agent still needs room to solve normal engineering problems. The distinction is between deciding how to implement an approved change and deciding what that change is allowed to mean.
Many failures begin when an agent fills in a missing decision and that reasonable assumption becomes embedded in both the implementation and the tests.
2. Build
The agent implements the approved slice. It can choose internal structures, write tests, update documentation, and work through normal technical decisions without waiting for approval at every step.
That autonomy is part of what makes AI-assisted development useful. But when the work reaches an architectural, product, or authority decision that has not been made, the safer response is to surface the uncertainty rather than silently resolve it.
The model can propose a direction. It does not gain authority simply because it can implement it.
3. Verify
A green result is only useful when the check is aimed at the property I actually intended to prove.
A concurrency test might show that two callers cannot both win while failing to prove that the full transition is atomic. A compatibility test might run the current serializer twice and prove determinism while saying nothing about compatibility with the previous version.
Both tests can pass while leaving the important question unanswered.
Verification may involve tests, schema validation, permission checks, database constraints, content hashes, independent review, or human judgment. The goal is not merely to produce evidence. It is to make sure the evidence corresponds to the claim being made.
4. Diagnose
Once a problem is found, I try to understand why it was able to survive.
Was the assignment unclear? Was an important decision missing? Did the test prove an adjacent property? Did the verifier trust data supplied by the thing it was supposed to verify?
This is where a ratchet can become counterproductive. A new rule is not automatically an improvement. If the diagnosis is wrong, the system may become more rigid without becoming more correct.
The goal is to identify the underlying condition that allowed the failure, then decide whether a durable control is justified.
5. Encode
Once the cause is understood, I try to place the smallest useful control at the layer that owns the problem.
A narrow defect may need a regression test. An invalid state may need a database constraint. A recurring input problem may need a typed contract. An unauthorized action may need a permission boundary. A model’s claim that it read a source may need corroboration from the actual tool record.
Where the risk justifies it, I try to move important rules out of model interpretation and into deterministic enforcement.
“Do not approve your own work” is an instruction. “Approval requires a different authorized actor” is a boundary.
“Do not change approved content” is an instruction. “Production must verify that the current content hash matches the approved hash” is enforcement.
6. Inherit
The next task should begin in a slightly stronger environment than the previous one did.
A future model may not know the story behind the control. A new developer may never read the original failure analysis. But the regression test still runs. The contract still validates. The permission check still refuses. The database still rejects the invalid state.
That is where the approach begins to compound. The system accumulates not only features, but also evidence about how it can fail and controls shaped by those failures.
Most of the gates were earned
Many controls in my own system were not designed perfectly in advance. They appeared because the system demonstrated a weakness.
An agent claimed it had read a client file when the observed tool history showed that it had not. That led to a requirement that claims about source access be corroborated by the actual read record.
Fabricated citations led to stronger provenance checks. A downstream phase reinterpreted approved content instead of consuming the exact approved artifact, which led to hash-pinned approvals. Client-facing outputs shipped with placeholders or collapsed into thin renders, which led to content-existence and fidelity checks.
Those controls were responses to specific failures, not attempts to make the system look more sophisticated.
Ratchet Governed Agentic Development is not about automatically turning every mistake into another rule. It is about using verified failures as evidence, diagnosing them carefully, and deciding whether a proportionate control can improve the environment future work inherits.
Memory is useful. Enforcement is stronger.
I still rely heavily on decisions, operating instructions, notes, and failure history. They preserve context and help both humans and agents understand why the system works the way it does.
But some lessons are important enough that documentation alone is not the right final form.
“Remember not to do this again” is useful guidance. A control that detects or prevents the same failure is stronger.
Not every issue needs a database constraint or global architectural rule. Sometimes the right answer is a clearer instruction, a local test, or no permanent control at all.
The important part is choosing deliberately rather than assuming that correcting the current output has solved the underlying problem.
Building a better starting point
This approach does not make AI agents, reviewers, or humans infallible. That is not what I am trying to achieve.
The goal is to make meaningful failures produce more than cleanup.
A verified incident can improve the prompt, test suite, contract, architecture, permission model, provenance system, or review process inherited by the next piece of work. Over time, the system becomes a record of survived failure.
The agent can still move quickly. The work can still remain flexible. But the environment becomes a little better at recognizing paths that have already caused trouble.
That is the Ratchet Loop:
Authorize the work. Build inside the boundary. Verify the intended property. Diagnose why the failure survived. Encode the smallest durable control. Let future work inherit it.
Fixing the bug solves the immediate problem.
Building the ratchet improves the next starting point.