Published: Apr 8, 2026
This is the third post in a series. The first was about two problems blocking autonomous AI coding assistants. The second was about the asymptotic promise of agentic coding.
In those posts I talked about non-determinism and the feeling that real autonomous coding stays just out of reach. I think I’ve figured out why.
The trade-off nobody talks about
If you want an AI coding agent to be really efficient, you have to let it loose. Give it access to your file system. Let it run shell commands. Let it make decisions without asking you first. The more freedom you give, the more it can do for you.
OpenClaw is the clearest example of this philosophy. It’s an open-source personal AI assistant that can read and write files, run shell commands, browse websites, send emails, control APIs - all from simple chat commands. It’s not a coding agent specifically, but the mindset is the same: give the AI broad access and let it figure things out. It exploded to over 200,000 GitHub stars in two months. People love it because it actually does things instead of just explaining how to do them.
But here’s what keeps me up at night: that same freedom means the agent can also truncate your production database. Or leak your credit card data. Or send an email to your CEO that you didn’t write.
The value scales with the freedom. But so does the risk.
Non-determinism amplified
This connects directly to the non-determinism problem from my first post. When you constrain an agent - review every change, approve every command - the non-determinism is bounded. The agent might produce different code each time, but you catch the bad outputs before they do damage.
When you let the agent loose, non-determinism compounds. Each autonomous decision the agent makes is a coin flip you didn’t supervise. Most of the time, the coin lands right. But the one time it doesn’t, it’s not a wrong variable name in a code review - it’s a destructive action on a live system.
This is fundamentally different from the abstraction leaps we’ve seen before. When we moved from assembly to C, the compiler was deterministic. A bad abstraction might produce slow code, but it wouldn’t randomly decide to format your hard drive.
The security add-on tells the story
Nvidia released NemoClaw - a security add-on with sandboxing built specifically for OpenClaw deployments. Think about what that means. The tool is so useful that people want to run it in production. And it’s so risky that a major company built a product just to contain the blast radius.
That’s the trade-off in a nutshell. We need freedom for value and containment for safety, and those two pull in opposite directions.
Why the asymptote exists
I think this is why agentic coding feels asymptotic. The reward curve and the risk curve scale together. Every step toward more autonomy delivers more value but also more exposure. At some point, the risk becomes unacceptable, and you pull back. You add guardrails. You require approval steps. And those guardrails eat into the very productivity gains that made the tool valuable in the first place.
So the curve approaches but never reaches the line - not because the technology isn’t good enough, but because the trade-off is structural. Better models don’t eliminate it. They just move both curves up together.
So what do we do?
I don’t have a clean answer. But I think the path forward looks something like:
Make the safe zone bigger without making the free zone smaller. Better sandboxing. Smarter permission models. Ways to give agents room to work without giving them the keys to production.
The teams that figure this out - the right boundary between freedom and containment - will get the most out of agentic coding. The rest of us will keep toggling between “too constrained to be useful” and “too free to be safe.”
Where do you draw the line? I’d love to hear about it.