Coding agents have improved faster than any other kind of agent.
Teams let them run longer and touch more code every month.
Nobody has proposed turning off git.
They aren't trusted because they stopped making mistakes. They're trusted because with git, even the worst mistake can be undone:
1. Drafts
Work happens on a branch. Nothing touches main until it's merged.
2. A record
Every commit shows what changed, when, and who made it.
3. Undo
Any change can be reverted to the last working state.
4. Checks outside the model
Tests and CI run the same way no matter who wrote the code.
5. A decision the agent can't make
On a protected branch, the agent can only open a pull request. The repository's rules and its reviewers decide what gets merged.
The key idea:
None of this lives in the agent. It lives in the repository the agent calls into. It works the same for a developer, a coding agent, or someone else's agent, and it can't be talked into anything.
Most other fields have pieces of this: drafts in accounting, approvals in ticketing tools, snapshots in databases. What they don't have is all of it, in the system the agent calls.
This is one piece of what I call AI-Oriented Programming (AOP): the model does the work, and the system decides what becomes final.
Coding agents have git to catch their mistakes. What catches the mistakes of the agents in your industry?
#AgenticAI #AIOrientedProgramming
A ten-step agent at 95% accuracy per step gets the final result right about 60% of the time.
Most teams plan to fix that with a better model.
At 99.9% per step, the same agent is right about 99% of the time.
Run it on a million writes a day, and roughly 10,000 records are still wrong. Every day. Each one looks correct.
A better model shrinks the error rate. It doesn't make it zero, and it doesn't make the wrong records look wrong.
A 1% error rate looks great on a slide. On a balance sheet, it's a nightmare.
Does your system have a guard that stops that 1% before it becomes a real record?
And if it doesn't, what does each one cost you?
#AgenticAI #AIOrientedProgramming
Every guardrail added to an agent says the same thing:
we don't trust the model to make this decision.
Yet the model is still the one making it.
The 4 most common guardrails, and what to build instead:
1. LLM-as-a-judge
Gap: the reviewer model can make the same mistakes it is supposed to catch.
Instead: deterministic rule checks in the system, outside any model.
2. Runtime policy enforcement
Gap: it sits in your own agent and covers only the risks someone anticipated.
Instead: rules enforced by the system for every caller, including agents you didn't build.
3. Human confirmation prompts
Gap: the reviewer approves a generated summary, not the change itself.
Instead: approval on the actual change, routed by risk.
4. System-prompt constraints
Gap: they influence behavior but can't enforce it.
Instead: permissions the model has no way to change.
The key idea:
Guardrails around a model that still decides are patches. Move the decision into the system, and the model only proposes.
That is the starting point of AI-Oriented Programming (AOP).
If your team doesn't trust the model to make the final call, why is it still making it?
#AgenticAI #AIOrientedProgramming
Getting an AI agent to work in a demo is easy.
Letting it touch real records is a different story.
Before an agent writes anything that matters, the system around it needs 5 things:
1. Drafts
Every change the agent makes starts as a proposal, not a final write.
2. Rules in the system, not in the prompt
A prompt can be talked around. Rules in the system apply to every caller, including agents you didn't build.
3. Approval on the real change
The approver reviews the actual record: its current value and the proposed one. Not a summary the model wrote.
4. Undo
Anything reversible can be rolled back. Anything that can't be waits for approval.
5. An audit trail
The original request, how the model interpreted it, and what the system did. So every failure can be traced to its source.
The key idea:
Models propose changes. The system decides what becomes final.
This is one piece of what I call AI-Oriented Programming (AOP): build the system around the fact that the model can be wrong, instead of hoping it won't be.
Which of these five does your agent setup have today?
#AgenticAI #AIOrientedProgramming
Most AI agents are built on one idea: take the person out of the control seat and put a model in.
The model makes the decisions. But where does the accountability land?
This isn't a gap a better model can fill. What we need is a different starting point. https://t.co/jfDNKCzgPM
@KanikaTolver Reading your list twice: the human review sits on the packaging intake agent, not on the HR one answering benefits questions.
Curious how you drew that line. The kind of mistake, or who's on the other end?
@0xwhrrari Agreed the prompt was never the durable part. Swap the harness a year from now and you find out what was living inside it.
"Can this order still be cancelled" has to be answered somewhere. Is that somewhere the harness?
@LangChain The variance result is the one I'd build on. When the scorer wobbles, a score that moved between two runs tells you nothing.
When it holds still, a score that moved means the run moved. Has that caught a real regression yet?
@playwrightweb The grep thing is the right call on token cost. The one I'd worry about is a checkout test that greps for "Order confirmed" and passes while the total quietly reads $400 instead of $40. Any way to make it look at what it didn't ask for?
@VaibhavSisinty When someone quits, their account is off the same day. A person owns that.
When a contract goes over $100k, legal reads it before anyone signs. A person owns that too.
Your agent decides on its own. Who owns that one?
I think every kindness we ever built for people is now a bug.
The error that just says something went wrong. The field that quietly trims your input. The list that stops at 50 rows and doesn't say so.
An agent was told to go look some things up. Public data, nothing risky.
It published over 2,000 packages to RubyGems and got code execution on the docs server.
That was May. Someone wrote it up last week.
"Read-only" describes what you asked for, not what it did.
Rules at the center isn't new. Hexagonal architecture said it 20 years ago: domain rules inside, everything else an adapter you can unplug.
What's new is the adapter. It no longer moves data, it generates data — and it gets meaning wrong while staying perfectly well-typed.