
Why AI-Built Software Needs an Accountability Apparatus
Better models don’t remove the need to bound an agent’s authority — they increase it. The case for treating AI as delegated labour that needs an accountability apparatus outside itself.
When you hire an architect, you don’t rely on them being good. You rely on licensure, liability insurance, building codes, and inspectors — an accountability apparatus that exists entirely outside the architect.
AI labour has none of that. Ranex is my attempt to build the missing apparatus: the code, the inspector, and the record.
This is the argument behind the whole project, and it’s deliberately not the argument you usually hear.
The framing that gets weaker every year
Here’s the deal: the more capable the agent, the larger its blast radius — so bounded authority matters more, not less.
Most tooling in this space rests on a premise like:
AI is unreliable, therefore you need guardrails.
I don’t build on that, because it’s a bet against the models improving. And they will improve. They’ll need fewer retries, understand larger repositories, write better tests, and hallucinate dependencies less often. Any product whose value comes from compensating for temporary model deficiencies is on a clock.
The framing that gets stronger
The premise I actually build on:
Trust is the wrong axis. What matters is whether claims can be independently established.
Follow the chain:
- AI is nondeterministic delegated labour.
- Actions have consequences.
- Therefore authority must be bounded.
- Claims require independent evidence.
- Consequential transitions require deterministic gates.
A ten-times-better model doesn’t break a single arrow in that chain.
The thought experiment
Suppose we get a coding model that’s correct 99.999% of the time. It understands the whole repository, writes excellent tests, understands security, rarely hallucinates, and can deliver six months of engineering overnight.
Would you hand it production database admin, deploy keys, npm publish rights, payment credentials, and customer PII, with the instruction “do whatever you think is appropriate”?
I wouldn’t. And notice why — not because I doubt its competence. Because its blast radius grew. The more capable the agent, the less comfortable unbounded authority becomes.
This isn’t a hypothetical position. Sandboxing, constrained network access, approval requirements for higher-risk actions, and agent telemetry for auditing are how serious coding agents are already deployed. Capability is increasing at the same time execution controls are increasing. Those aren’t contradictory trends; they’re the same trend.
Separation of duties survives intelligence
Imagine an AI genuinely better at software engineering than any human alive. Why should the same actor be able to:
define success
implement solution
modify verification
run verification
declare success
publish result
Intelligence doesn’t solve separation of duties. Banks don’t abandon accounting controls when they hire smarter accountants. This is why no self-approval is an invariant in Ranex rather than a configurable policy.
Provenance matters more as generation gets cheaper
If agents produce far more code than humans inspect, the useful question changes shape. It stops being “did someone review line 912?” and becomes:
What requirement caused this code to exist, what agent created it, what authority did it have, what tests established conformance, what exact artifact was evaluated, and what allowed it to ship?
That’s a supply-chain and verification problem, not an LLM-quality problem. It doesn’t get solved by a better model — it gets solved by binding evidence to artifacts and keeping a record nothing rewrites.
The green light that proves nothing
The deepest version of this problem isn’t about AI at all.
While building Ranex I hit two states worth sitting with. In one, 37 of 47 checks were green while secrets remained readable. In another, all 47 were green while the gate had actually run none of them.
The issue in neither case was “was the AI smart enough.” It was:
Does this green light actually prove the proposition we think it proves?
That problem exists with AI, humans, CI systems, security scanners, tests, and auditors. It’s the reason I think the durable idea here is meaningful evidence — not guardrails, not linting, not hallucination detection. I wrote up the specific incidents in the slice log.
What this means for the shape of the tool
If the thesis is right, then Ranex shouldn’t care which coding agent you use. The worker port is replaceable by design; the kernel stays outside the loop regardless of what fills it. Better AI creates more autonomous labour, more autonomous labour creates more delegated authority, and more delegated authority increases the value of a trustworthy boundary around it.
That’s the version I’m building. It’s pre-release and honest about it — but the thesis is the part I’m most confident in.
Questions people actually ask
Why do AI coding agents need governance if models keep improving?
Because the problem is authority, not capability. The more capable an agent becomes, the larger its blast radius — so bounded authority matters more, not less. Better models do not remove the need for separation of duties.
Isn’t ‘AI is unreliable’ the real argument for guardrails?
That argument gets weaker every year. The durable one is that claims require independent evidence: AI is nondeterministic delegated labour, actions have consequences, so authority must be bounded and consequential transitions gated.
What is the difference between trusting AI and verifying it?
Trust is a prediction about future behaviour. Verification is a statement about a specific artifact. Ranex is built on the second because it holds regardless of how good the model gets.
Try it. Break it. Tell me what broke. The kernel is MIT-licensed — if you find a hole in the code that decides pass or fail, that is a contribution.
About the Author
Anthony Garces
Founder of Ranex. Coding since 2015, starting as a PHP developer. Years of building with AI coding assistants taught me the failure that matters: the AI reports success whether or not the work is done. Ranex is my answer — the judge built outside the loop.