Ratchet Governed Agentic Development
A governed approach to building with AI agents.
Ratchet Governed Agentic Development, or Ratchet Development for short, is an approach to AI-assisted software development in which agents operate inside defined boundaries, important outputs are independently reviewed and deterministically verified, and meaningful failures can become proportionate controls that future work inherits.
The goal is not to prevent AI agents from ever making mistakes. It is to build an environment that learns from those mistakes without quietly surrendering authority to the agents themselves.
The model proposes. Deterministic systems verify. Humans retain authority.
Ratchet Governed Agentic Development
Why this approach exists.
AI coding agents can produce work that is fast, coherent, and impressively complete.
They can also misunderstand a requirement, fill in a missing product decision, write tests around their own interpretation, and provide a convincing explanation of why the work is finished.
The problem is not simply that AI makes mistakes.
The harder problem is that an incorrect implementation can still look deliberate. Its code, tests, comments, documentation, and completion summary may all agree because they all inherited the same assumption.
Traditional review often waits for the work to look wrong.
Agentic systems can make wrong work look increasingly finished.
That changes what the surrounding environment has to do.
Coherence is not proof
Clean code, passing tests, and a plausible explanation can all support the same incorrect interpretation.
Autonomy is not authority
An agent may decide how to implement an approved change. It should not silently decide what the change is allowed to mean.
Fixing the output is not always enough
A code correction solves the immediate incident. A durable control can make the same class of failure harder to repeat.
The core principle
Once a system has learned something important, future work should not have to rediscover it from scratch.
A verified failure can expose something missing from the environment:
-
A requirement was ambiguous.
-
A test proved an adjacent property.
-
An invalid state was structurally possible.
-
A source claim could not be corroborated.
-
An approval boundary existed only as an instruction.
-
A human workflow had drifted away from its original purpose.
Ratchet Development asks what should change around the work so the lesson becomes more durable than a conversation, completion summary, or project note.
Verified
failure
Something meaningful went wrong, and the available evidence proves what happened.
Proportionate response
The failure is diagnosed before deciding whether it deserves a durable control.
Stronger
inheritance
Future work begins with less uncertainty, fewer repeated decisions, or a clearer refusal boundary.
The Ratchet Loop
Authorize → Build → Verify → Diagnose → Encode → Inherit
The Ratchet Loop is the operating cycle at the center of the methodology.
It begins before the agent writes code and continues after the immediate bug has been corrected.
Inheritance does not mean permanence.
A control may later be narrowed, superseded, or retired as the system changes.
The lesson should remain durable even when the mechanism does not.
Define the approved change, its exclusions, the decisions that govern it, and the evidence that would prove completion.
Allow the agent to work autonomously inside the approved boundary without redefining that boundary.
Confirm that the available evidence proves the intended property, not merely something nearby.
Determine why the failure looked reasonable, survived its checks, or reached review.
Place the smallest useful control at the layer that owns the problem.
Let future work begin inside the stronger environment created by the lesson.
What makes the approach governed
Authority remains explicit
The agent can propose, implement, and test. Humans still define product meaning, acceptable risk, approval, release, and when the work should stop.
Evidence survives the output
Important claims should remain connected to the sources, tool records, artifacts, hashes, or operating state that support them.
Verification is separate from generation
The system producing an output should not be the only system deciding whether the output is trustworthy.
Controls remain proportionate
A meaningful failure may earn a test, contract, constraint, permission boundary, human checkpoint, or no durable control at all.
Autonomy inside a boundary
The agent can decide
- How to structure an approved implementation
- Which internal technical approach best satisfies the contract
- How to organize code and tests inside the authorized slice
- Which implementation alternatives to propose
- Which uncertainties need to be surfaced
The architect retains
- What the system is supposed to mean
- Which source owns a decision
- What remains out of scope
- Which tradeoffs are acceptable
- Whether the evidence is sufficient
- Who may approve or release the result
- Whether the work should continue
Allowing an agent to act does not give it authority over the meaning of the work.
What can become a ratchet?
A ratchet is not one specific kind of control. The correct form depends on what failed and which layer owns the problem.
Regression test
A known failure becomes an executable case the system must continue passing.
Typed contract
An input or output shape becomes explicit rather than remaining open to interpretation.
Database constraint
A state that should never exist becomes structurally impossible.
Permission boundary
An action requires the correct actor and authority rather than relying on a prompt instruction.
Provenance requirement
A source, citation, or claimed tool action must be corroborated by an observed record.
Hash-pinned approval
Authority applies to exact content rather than to a mutable label or filename.
Real-operator checkpoint
A user-facing workflow must be exercised with the real artifact and normal operator path before deeper hardening continues.
Documentation ownership rule
One fact receives one authoritative home so future work does not have to reconcile several versions.
What Ratchet Development is not.
| It is not | It is |
|---|---|
|
A way to prevent every AI mistake |
A way to learn proportionately from meaningful failures
|
|
Maximum governance around every task
|
Governance scaled to risk, reach, and consequence
|
|
A collection of better prompts
|
An environment of prompts, contracts, evidence, permissions, verification, and human authority
|
|
A zero-human development workflow
|
A workflow that concentrates human judgment where it cannot be encoded
|
|
Automatic rule accumulation
|
Controls that can be kept, narrowed, superseded, or retired
|
|
A claim that agents should have no autonomy |
A distinction between implementation autonomy and product authority
|
|
A universal algorithm for the correct decision |
An operating discipline that makes judgment more explicit and reviewable
|
The two ways Ratchet Development can fail
Under-ratcheted
A consequential failure remains repeatable, undetectable, or dependent on someone remembering it manually.
Proportionate
The smallest useful control addresses the verified failure at the layer that owns it.
Overengineered
The control creates more context, cost, rigidity, or architecture than the lesson justifies.
The next task should inherit a stronger environment, not a heavier one.
The human failure mode.
The architect can remain in the loop while leaving the decision.
Long AI-assisted sessions create an imbalance.
The agent can continue producing coherent work, tests, explanations, and plausible next steps after the architect’s attention has begun to decline.
The workflow therefore cannot depend entirely on the architect recognizing the moment when active direction becomes passive continuation.
Structural interruptions include:
- Bounded work defined before the session
- A hard stop when the current acceptance criteria are met
- Real-operator evidence before deeper hardening
- An independent reread before the next substantial slice
- Separate authorization for the work that follows
These are decisions made while the architect is alert that remain binding when the architect is tired.
Built is not the same as operating.
A method can be sophisticated in source and immature in use.
Ratchet Development separates several kinds of truth.
Operating reality
Built → Deployed → Exercised → Operational cadence
Where does the capability exist, and how repeatedly is it used?
Trust qualities
Reviewed | Verified | Governed
What scrutiny, proof, and authority surround it?
Change over time
Ratcheted | Compounding | Revalidated
Does the environment improve through use, and do accumulated controls continue earning their cost?
A route that exists only in source is built, not deployed.
A deployed workflow that no operator has completed is not exercised.
One successful demonstration is not operational cadence.
An empty schema does not compound.
How I currently work.
Claude Code
Production implementation
Claude Code writes code, runs tests, performs approved refactors, and implements bounded build slices.
Human
Architecture and final authority
I define product intent, system boundaries, governing decisions, acceptance criteria, priorities, and what is authorized or shipped.
OpenAI Codex
Independent review and prompt compilation
Codex critiques the architecture and implementation, investigates failure history, and compiles the next prompt without writing into the production repository.
The second Codex writes in the OS, it is contaminated.
The separation is not about one model being better than another. It preserves an independent critique function outside the production path.
Foundational reading
These eight essays form the current foundation of Ratchet Development.
They explain why the approach exists, how authority and verification work, how the Ratchet Loop operates, where the methodology can fail, and how to assess whether the surrounding system is actually being used.
Future case studies, application guides, and field notes are available in the complete Ratchet Development article archive.
Foundations
Why it exists
Beyond Vibe Coding: How Ratchet Development Turns AI Fallibility Into Governance
Why plausible AI output needs more than informal review, and why failure should improve the environment rather than disappear into another prompt.
The core principle
The Ratchet Principle: How AI Mistakes Become Better Software
The central idea behind failure-driven improvement: meaningful lessons should strengthen the starting point inherited by future work.
Authority and method
The authority model
Autonomy Is Not Authority
Why agents can work autonomously inside a boundary without becoming the authority over product meaning, approval, or release.
The operating method
The Ratchet Loop: How AI Mistakes Become Durable Controls
The six-step cycle for moving from bounded authorization through implementation, verification, diagnosis, and durable inheritance.
Practice
The working setup
Claude Code Builds. Codex Reviews. I Retain Authority.
How I separate production implementation, independent critique, and architectural authority in my current development workflow.
Limits and calibration
When Ratchet Development Becomes Overengineering
How the same instinct that strengthens a system can create excess process, bad controls, and architecture larger than the lesson that earned it.
Human and operational reality
The human failure mode
The Architect’s Trance
How sustained work with AI coding agents can turn active direction into passive continuation, and why the workflow has to interrupt itself.
The operational maturity profile
Built, Deployed, Exercised: A Maturity Profile for AI-Assisted Systems
Why architecture, deployment, real use, operational cadence, trust, compounding, and revalidation must be assessed separately.
FAQs
Ratchet Development, formally Ratchet Governed Agentic Development, is an approach to AI-assisted software development in which agents operate inside defined boundaries, important outputs are reviewed and verified, human authority remains explicit, and meaningful failures can become proportionate controls that future work inherits.
The Ratchet Loop is the six-step operating cycle inside the methodology:
Authorize → Build → Verify → Diagnose → Encode → Inherit
It describes how a bounded assignment moves through implementation and verification, then turns meaningful failures into improvements future work can inherit.
Read the full Ratchet Loop explanation →
No.
A durable control should be added only when the failure is verified, the diagnosis is supported, the risk justifies it, and the proposed control belongs at the layer that owns the problem.
Some failures need one local regression test. Some need a database constraint or permission boundary. Others need a clearer instruction, a human decision, or no permanent mechanism at all.
Regression tests are one important kind of ratchet.
Ratchet Development applies the same broader principle to the environment surrounding AI agents, including contracts, database states, permissions, evidence, provenance, approvals, real-operator checkpoints, and decision boundaries.
No.
The methodology depends on meaningful agent autonomy inside authorized boundaries. The distinction is between allowing an agent to decide how to implement approved work and allowing it to decide what the product is supposed to mean.
No.
Claude Code and OpenAI Codex are part of my current working setup, not requirements of the methodology. The important principle is separating generation, critique, verification, and final authority rather than relying on one system to perform every role.
No.
It is an operating discipline for designing the environment around agentic work. Its controls may appear in prompts, code, tests, contracts, permissions, architecture, review processes, or human checkpoints.
That remains an area to formalize.
My current workflow has one architect and one final decision-maker. Permissions can define who may act, but they do not resolve disagreement among several architects or determine how delegated authority should be superseded.
Shared authority, decision ownership, and disagreement are important untested boundaries.