Part one of a series on Ratchet Development, a governed approach to building software with AI agents.
When I started writing this, the system I’m building was eleven days old.
By then it had already grown into a substantial application: research workflows, governed evidence, claims, approvals, permissions, audit history, operator interfaces, external integrations, and thousands of automated tests.
I’m the only human building it. AI agents are writing much of the code.
By the broadest definition, that’s vibe coding. I describe what I need, an agent implements it, I evaluate the result, and we go from there.
But “vibe coding” describes the interface more than it describes the method.
The defining feature of how I build isn’t that I use natural language instead of typing every line myself. It’s that I don’t expect the AI to be consistently right.
If anything, the methodology depends on it being wrong.
AI agents make plausible mistakes. They optimize locally. They infer missing context. They satisfy the visible wording of a request while missing the underlying property. They write tests that pass without always proving what their names claim to prove.
Instead of treating those failures only as defects to correct, I treat them as signals.
Each meaningful failure tells me something about the environment surrounding the agent:
- A requirement was ambiguous.
- A contract was too permissive.
- An architectural boundary existed only in memory.
- A test checked an output without proving the claimed behavior.
- A distinction had not been represented clearly enough.
- A dangerous state was possible because the system relied on convention rather than enforcement.
The immediate defect still needs to be fixed. But the more important question is:
What durable change will make this class of error harder to repeat?
I call this approach Ratchet Development, short for Ratchet Governed Agentic Development.
What is Ratchet Development?
A mechanical ratchet lets movement go one direction while resisting accidental movement backward. Each click advances the mechanism, and the next movement starts from the position the last one created.
Ratchet Development applies that idea to AI-assisted software development.
The basic loop is:
- Authorize a bounded piece of work.
- Implement it with an AI agent.
- Verify the result through deterministic checks and human review.
- Diagnose failures at the system level, not only at the broken line of code.
- Encode the lesson as a durable control.
- Advance with a stronger development environment.
Step five is the one that matters.
A bug fix repairs the present implementation. A ratchet changes what future implementations are allowed to do.
The lesson might become a test, a contract, a database constraint, a permission boundary, an architectural rule, an approval requirement, or a process control. Whatever form it takes, it outlives the current conversation and becomes part of the environment the next agent inherits.
AI fallibility is a source of information
Most conversations about AI coding focus on accuracy.
How often does the model generate working code? How much review does it need? How many hours does it save?
Those questions matter. They also miss another source of value.
A capable coding agent is also a high-speed stress test for how clear the system around it actually is.
Give an agent a vague requirement and it’ll usually pick an interpretation.
Give it two sources of architectural truth and it may follow the wrong one.
Ask it to validate an identifier and it may enforce the expected length without enforcing the expected format.
Ask it to prove backward compatibility and it may compare the current implementation against another call to the same current implementation.
The agent isn’t making random mistakes. It’s showing you the places where the system let an incorrect interpretation stay plausible.
Used carelessly, that produces technical debt at extraordinary speed. Used through Ratchet Development, it becomes governance discovery.
From mistake to ratchet
Here’s a simplified example from my own build.
A validation check claimed to require a complete cryptographic identifier. The implementation counted the characters, but never checked whether those characters actually formed a valid identifier.
The immediate correction was straightforward. But changing the condition was only the repair.
The ratchet was broader:
- The accepted format became structurally explicit.
- Malformed and hostile values went into the test suite.
- The tests proved rejection happened before the value reached the storage boundary.
- Other uses of the same contract could now be checked for drift.
The result wasn’t just a corrected validation statement. The meaning of a valid identifier got harder to reinterpret elsewhere in the system.
Another example involved a compatibility test.
The test compared the output of a serialization function against the output of another call to that same current function.
It passed. It also proved almost nothing about compatibility.
What it showed was that the implementation was deterministic. What it didn’t show was that the current output still matched the historical format expected by existing records or downstream systems.
The correction introduced an independent historical reference and a sensitivity check, proving that meaningful content changes would actually alter the result.
The ratchet was the durable rule behind the correction:
A system cannot prove backward compatibility by using itself as its only witness.
That principle now applies well beyond the original function.
This is what makes the method compound. The point isn’t that one defect disappeared. The environment came away with a stronger definition of validation and a stronger definition of compatibility.
Future agents start from there.
Governance is not something added at the end
The word governance usually brings to mind a committee standing between a developer and a release button.
That’s not what I mean here.
In Ratchet Development, governance is baked into the development environment.
It starts with questions like:
- What source is authoritative?
- Which component owns this behavior?
- What may the agent decide?
- What requires a human decision?
- What must be true before work can advance?
- What evidence demonstrates that it is true?
- How should missing information be represented?
- What happens when verification fails?
- How will the next agent inherit the lesson?
Some of these decisions have to exist before implementation begins. The human still has to understand the domain, define the intended outcome, establish the architecture, and decide where authority belongs.
But other forms of governance get discovered through contact with failure. The agent attempts an implementation. The attempt exposes a missing distinction. That distinction becomes explicit and enforceable.
So governance evolves from evidence. It isn’t an attempt to predict every possible failure in advance. It’s a system for making sure meaningful failures leave the environment stronger than they found it.
Autonomy is not authority
AI agents can have real autonomy inside Ratchet Development. They can inspect an existing codebase, propose designs, create modules, refactor implementations, write tests, diagnose failures, and carry a bounded piece of work from definition through verification.
That’s real autonomy. But autonomy isn’t the same thing as authority.
The agent doesn’t decide what the company is, what the software should mean, which source owns truth, or which risks are acceptable. It doesn’t get to turn its own proposal into accepted system state just because the proposal is plausible.
The human owns intent, domain meaning, architectural direction, and consequential judgment. Deterministic systems own a lot of the acceptance.
A useful summary:
The model proposes. Deterministic systems verify. Humans retain authority.
This separation matters because fluent output can create an illusion of legitimacy. A model can explain its implementation with total confidence. It can generate a clean interface. It can write a test with an impressive name. None of that proves the underlying property.
Acceptance has to come from outside the model. That might be contracts, negative tests, dependency checks, database constraints, runtime verification, permissions, approvals, or human review.
The exact mechanism depends on the risk. The principle doesn’t.
Beyond vibe coding
Vibe coding captures something real about how software gets built now. A person describes what they want. The model produces working code. The loop gets faster, more conversational, and less dependent on manually translating every idea into syntax.
Ratchet Development keeps that speed. What it throws out is the idea that appearance is enough evidence.
The software doesn’t become trustworthy because the interface looks right, the code compiles, or the agent says it’s done. It becomes more trustworthy because the development environment can tell the difference between:
- A proposal and an approved decision
- A passing test and proof of the claimed property
- A valid-looking value and a valid value
- A designed capability and an implemented capability
- An implemented capability and a live-proven capability
- Agent autonomy and operational authority
Those distinctions matter more as agents get better, not less. A weak agent makes obvious mistakes that are easy to reject. A strong agent makes polished mistakes that survive a casual look.
Better models remove some categories of error. They also raise the value of systems that can evaluate results independently of the model’s confidence or how good the output looks.
This is not just more testing
Tests are a big part of Ratchet Development, but they aren’t the methodology.
A test can lock in a bad assumption just as well as a good one. A large suite can prove the wrong property over and over. An agent can write a test that passes precisely because it never reaches the condition it was supposed to exercise.
The goal isn’t maximum test volume. The goal is to change the future operating environment in the right way.
Sometimes the right ratchet is a test. Sometimes it’s a stronger data contract, a database constraint, an architectural boundary, a permission, a source requirement, or a refusal to infer information the system doesn’t actually have.
The control should match the failure. And that takes human judgment. Someone has to decide whether the defect was local or whether it exposed a missing rule that should apply across the whole system. That diagnostic work is one of the most important parts of the methodology.
The human role moves upward
I don’t personally write or inspect every line generated during the build. That doesn’t mean I’ve stopped caring how the system works.
My attention has moved toward questions like:
- What business reality is this representing?
- Who or what owns that reality?
- What may be inferred?
- What must remain explicitly unknown?
- Which decisions can be delegated?
- Which boundaries must fail closed?
- What evidence would make this safe enough to trust?
- What did this failure reveal about the larger system?
The code matters. But the code is one output of a bigger system of intent, authority, verification, and learning.
AI makes it possible for one person to work at that level while still producing a substantial amount of implementation. The leverage doesn’t come only from generating code faster. It comes from being able to put more human attention on the structure around the code.
The ratchet applies to humans too
Ratchet Development isn’t built on the idea that the human is right and the AI is unreliable.
Humans make mistakes too. We misstate requirements. We hang on to assumptions that no longer apply. We overestimate what a test proves. We describe a future capability as if it already exists. We forget why an architectural boundary was put there in the first place.
The same ratchet should apply. When a human decision leads to a meaningful failure, the lesson should outlive personal memory.
The point isn’t to build an environment where nobody can be wrong. The point is to build one where being wrong improves the system. That’s a more realistic goal for both human and artificial intelligence.
The compounding asset is the environment
AI models will keep improving. The coding agent I use today probably isn’t the one I’ll use next year.
The durable asset isn’t only the code an agent produces. It’s the environment future agents inherit:
- Clearer architectural boundaries
- Stronger contracts
- Better negative tests
- More precise definitions of authority
- Preserved failure lessons
- Safer implementation paths
- More honest representations of uncertainty
Each accepted lesson becomes part of that environment. The next piece of work starts with fewer ways to repeat the same mistake.
That’s Ratchet Development. Not software built by pretending AI is reliable. Software built by making AI fallibility useful.
Series
Part 1:
Beyond Vibe Coding: How Ratchet Development Turns AI Fallibility Into Governance
Part 2 (Coming Soon):
The Ratchet Principle: How AI Mistakes Become Better Software
Part 3(Coming Soon):
Autonomy Is Not Authority: The Human Role in Agentic Software Development