Part three of a series on Ratchet Development, a governed approach to building software with AI agents.
AI agents are writing a substantial amount of the software I’m building. They inspect the repository, follow existing patterns, propose designs, write modules, create tests, diagnose failures, and carry bounded pieces of work through verification.
Which raises a fair question:
If the agent is doing so much of the implementation, what is the human doing?
The short answer is that the human role moves upward. The work shifts from manually expressing every instruction in code toward defining what the system means, how its parts are allowed to interact, what evidence is enough, where authority belongs, and which risks are acceptable.
The agent can have real autonomy inside that system. It shouldn’t have unbounded authority over it.
That distinction is central to Ratchet Development, short for Ratchet Governed Agentic Development.
Autonomy and authority are different things
Autonomy is the ability to act without getting a separate instruction for every step. An autonomous coding agent can:
- Inspect relevant parts of a codebase
- Determine which files need to change
- Follow established patterns
- Propose an implementation
- Write and revise code
- Add tests
- Run verification
- Diagnose a failure
- Continue until a bounded objective is complete
Authority is the right to decide what the system should mean, or what consequences are acceptable. Authority covers decisions like:
- Which source owns a particular truth
- Which component owns a behavior
- What may be inferred from missing information
- Which actions require approval
- What level of evidence is sufficient
- Which architectural tradeoffs are acceptable
- Whether a live external action may occur
- Whether a proposal may become accepted system state
- Whether a discovered failure deserves a permanent rule
An agent can be autonomous inside a task without owning any of those decisions. Confusing the two is where a lot of the risk in agentic software development comes from. Restricting both gives you a glorified autocomplete.
Ratchet Development tries to keep substantial implementation autonomy while keeping authority explicit.
The human does not disappear
The idea that AI replaces the programmer usually assumes programming is mostly the act of typing code. Typing code is part of software development. It isn’t the whole job.
Before a system can be implemented, someone has to decide:
- What real-world process is being represented?
- Which concepts deserve their own identities?
- What states can exist?
- What transitions are valid?
- Which transitions are dangerous?
- Who may initiate them?
- Which data is authoritative?
- What should happen when evidence is missing?
- What must remain deterministic?
- What can safely be probabilistic?
- What does success mean operationally?
These aren’t syntax questions. They’re domain, architecture, governance, and risk questions.
AI can help work through them. It can spot inconsistencies, suggest structures, compare alternatives, and expose gaps. But the system still needs an owner. The human stays responsible for what the software means.
The agent should own implementation freedom
Keeping authority human-owned doesn’t mean micromanaging every change. Constant step-by-step direction would kill most of the value of agentic development anyway.
The agent should be free to make ordinary implementation decisions inside a defined boundary. For a bounded piece of work, it can decide:
- How to organize local helper functions
- Which existing abstraction to reuse
- Which tests are needed to exercise the expected behavior
- How to sequence a refactor safely
- Which error caused a failing suite
- What small supporting changes are required to complete the authorized task
The human shouldn’t need to prescribe every file edit. That just recreates traditional implementation work through a slower interface.
The productive boundary:
The human defines the objective, constraints, authority, and acceptance conditions. The agent determines how to implement within them.
This is really just delegation, the same as in any working organization. A leader who specifies every keystroke hasn’t delegated. A leader who hands over unlimited authority with no boundaries has abdicated.
Bounded work is the unit of autonomy
The agent’s freedom gets safer when work is cut into bounded slices. A slice should make a few things clear:
- The objective
- The relevant architectural context
- The actions currently authorized
- The constraints that must remain true
- The evidence required for acceptance
- The point at which the agent must stop
This keeps one kind of task from quietly turning into another. A request to investigate a problem doesn’t automatically authorize implementation. A design doesn’t automatically authorize a migration. A hermetic test doesn’t automatically authorize a live external call. A successful local change doesn’t automatically authorize rewriting an architectural boundary.
These distinctions can sound procedural, but they’re what protect the value of autonomy. The agent can move fast because it knows the territory it’s allowed to act in. Without those boundaries, every action either becomes dangerous or needs constant human supervision.
The model proposes
A generative model is exceptionally good at proposing things. It can propose:
- An implementation
- A refactor
- A schema
- A classification
- A test strategy
- A diagnosis
- A migration path
- A user-facing explanation
- A set of possible next actions
Proposal is where probabilistic systems shine. They can synthesize incomplete context, spot patterns, and generate viable options far faster than a human could produce each one by hand.
The mistake is letting proposal collapse straight into truth. A model-generated classification is still a classification proposal. A generated architectural explanation is still an interpretation. A passing test written by the model is still evidence that has to be evaluated. A plausible “all done” message is not proof that the task is complete.
The system needs boundaries between:
- Proposed and accepted
- Generated and verified
- Observed and inferred
- Designed and built
- Built and live-proven
- Available and authorized
Those boundaries lower the risk that fluent output gets mistaken for authority.
Deterministic systems verify
Ratchet Development isn’t just a relationship between one human and one AI agent. There’s a third participant: the deterministic environment.
That environment might include:
- Data contracts
- State machines
- Test suites
- Negative tests
- Database constraints
- Dependency checks
- Permission systems
- Provenance requirements
- Approval records
- Hash verification
- Migration checks
- Runtime assertions
- Audit history
These systems don’t replace human judgment. They keep every decision from depending on human attention. A contract can reject malformed state whether or not a person notices. An architecture check can catch a prohibited dependency before it becomes accepted design. A database constraint can hold an invariant when both the agent and the human miss it. A permission boundary can deny an action even when the generated code tries it.
Which gives you a useful operating principle:
The model proposes. Deterministic systems verify. Humans retain authority.
Each part has a different job. The model supplies range and speed. The deterministic system supplies consistency and enforceable boundaries. The human supplies meaning, judgment, and legitimate authority.
The architecture is neurosymbolic-inspired
My system is not a neurosymbolic model. I’m not claiming to have trained a model that internally combines neural and symbolic reasoning.
The architecture is influenced by a similar split of responsibilities, though. I use neural systems where ambiguity, interpretation, synthesis, and generation are valuable. I use explicit symbolic structures where consistency, identity, provenance, authority, and verification matter.
The neural layer can inspect context and propose an answer. The symbolic layer can determine:
- Whether the referenced objects exist
- Whether the source is authoritative
- Whether the state transition is valid
- Whether the actor has permission
- Whether the required evidence is present
- Whether approval has been granted
- Whether the output matches the contract
- Whether history remains intact
This separation makes the intelligence layer replaceable. A better model might produce stronger proposals. A weaker model might produce more rejections. Neither one should be able to silently redefine identity, rewrite provenance, grant itself authority, or turn uncertainty into accepted truth.
Ratchet Development happens at the boundary between those layers. Neural fallibility exposes missing symbolic structure. The resulting contract, test, permission, or architectural rule is what makes the lesson durable.
The human owns the operating model
The most important thing I bring isn’t knowledge of a programming language. It’s the model of the organization and the work the software is meant to do.
A business operating system has to represent questions like:
- How work enters the organization
- How priorities are determined
- Which roles make which decisions
- What evidence those decisions depend on
- How actions are approved
- How outputs are reviewed
- What happens when the normal process fails
- How outcomes become future learning
An AI coding agent doesn’t independently know the right answers. It can propose patterns based on what it’s seen elsewhere. That can be useful. It can also be dangerously generic.
The operating model has to come from contact with the real domain. The human domain architect decides what gets preserved, automated, challenged, or redesigned. Once those decisions are explicit, the agent can turn them into software at extraordinary speed. Without them, the agent can only produce a polished approximation of what similar software usually looks like.
The human owns architectural law
Software architecture isn’t just a map of modules. It’s a map of authority and responsibility.
Architecture answers questions like:
- Which component owns a concept?
- Which direction may information flow?
- Which layer may make a decision?
- Which dependencies are permitted?
- Where is uncertainty represented?
- Which records are append-only?
- What is canonical, and what is a derived view?
- Where must actions fail closed?
An agent can help implement and test these rules. It shouldn’t quietly invent them while solving a local task.
A locally convenient dependency can violate system ownership. A quick reuse of an existing field can corrupt identity. A new status value can collapse two states that were supposed to stay distinct. A small implementation decision can turn into an architectural decision without announcing itself.
Human authority means spotting which choices are local and which ones change the meaning of the system. Architectural law can then be encoded so future agents don’t depend entirely on the human catching every violation.
The human owns ambiguity
Agents are good at resolving ambiguity. That’s both a capability and a risk.
When information is missing, a model will usually infer the most plausible completion. In creative work, that’s often useful. In governed systems, plausible completion can turn into fabrication.
The human has to decide where inference is allowed. For example:
- Whether a missing value means false, unknown, unavailable, or not applicable
- Whether two similar names refer to the same entity
- Whether a weak signal is sufficient to create a finding
- Whether absence of evidence should affect a decision
- Whether a proposed action is reversible
- Whether a live integration may be tested safely
The answer shouldn’t be left to whichever interpretation the current agent happens to find most natural. Ambiguity is often where authority hides. Making it explicit is one of the human’s highest-leverage jobs.
The human owns risk
Not every error carries the same consequence. A formatting defect on an internal page is a different thing from:
- Sending an external message
- Modifying a client system
- Publishing content
- Changing access permissions
- Deleting evidence
- Approving a strategic recommendation
- Replacing a historical identifier
- Triggering a financial action
Agent autonomy should scale with consequence. Low-risk, reversible actions can be delegated broadly. High-impact, hard-to-reverse actions should require stronger evidence, narrower permissions, and explicit approval.
The human sets those boundaries. The model shouldn’t decide how much authority it deserves based on how confident it feels about the current answer.
Stronger agents make this distinction more important
It’s easy to govern a system that fails loudly. The code breaks. The answer is incoherent. The interface plainly doesn’t work.
More capable agents produce more convincing output. They write cleaner code, generate better tests, explain their reasoning more fluently, and follow local patterns more closely. That raises productivity. It also makes surface-level review less reliable. A polished mistake can look identical to correct work until the underlying property gets tested independently.
As agents get more capable, governance doesn’t become less relevant. It shifts from catching obvious defects toward verifying meaning, authority, evidence, and system-wide consequences. The better the agent gets at implementation, the more valuable the human becomes at defining what should be implemented and what would count as proof.
The human role becomes systems architecture
The emerging role isn’t just “person who prompts an AI.” It pulls together several jobs:
Domain architect
The human models the real organization: its concepts, decisions, workflows, and exceptions.
Authority designer
The human decides which actors and systems may propose, approve, mutate, publish, or execute.
Systems architect
The human sets ownership, boundaries, dependencies, contracts, and failure behavior.
Evaluator
The human judges whether the evidence actually proves the claimed property.
Risk owner
The human decides where autonomy is appropriate and where actions have to stop for approval.
Institutional memory steward
The human decides which lessons have to survive, and how architectural intent stays available to future agents.
This work is different from manually writing every implementation. It isn’t less technical. It’s technical at a different layer.
Human judgment must also be governed
The human isn’t automatically right either. A person can misdiagnose a failure, hang on to an obsolete rule, authorize an unsafe shortcut, or mistake confidence for evidence. That’s why Ratchet Development doesn’t put all its trust in the human.
Important decisions should leave records. Claims should stay connected to evidence. Approvals should be explicit. Architectural changes should be deliberate. Historical state shouldn’t be silently rewritten. Verification should be reproducible where possible.
The objective isn’t human control for its own sake. It’s legitimate, inspectable authority, paired with mechanisms that make both human and agent mistakes visible.
The goal is directed autonomy
The best agentic environment is neither wide open nor suffocating. Too little autonomy turns the agent into a slow interface for manual programming. Too much authority lets plausible local choices redefine the system.
The target is directed autonomy:
- The objective is clear.
- The scope is bounded.
- The architecture is explicit.
- The agent has room to implement.
- Deterministic controls evaluate the result.
- Consequential transitions require legitimate authority.
- Failures become ratchets.
That structure lets one human direct a lot more implementation than would otherwise be possible. The leverage doesn’t come from removing the human. It comes from concentrating human attention where it’s worth the most.
A different kind of software development
Agentic software development changes the visible act of building. The human might type less code. The agent might produce entire modules, tests, migrations, and interfaces.
But the underlying responsibilities don’t disappear. Someone still has to decide what the system is, what it knows, what it may do, and what evidence is enough to trust it.
Ratchet Development makes that separation explicit. The agent can act. The deterministic environment can verify. The human keeps authority.
That’s not a limitation on agentic development. It’s what makes substantial agent autonomy usable in the first place.
Series
Part 1:
Beyond Vibe Coding: How Ratchet Development Turns AI Fallibility Into Governance
Part 2:
The Ratchet Principle: How AI Mistakes Become Better Software