I’ve been spending a lot of time lately inside tools like Claude and Cursor. And to be clear, I think they’re incredible. You can prompt your way into a working function, a Terraform snippet, even a full pull request faster than ever before. It genuinely changes how engineers build.
But the moment you move from creating code to running it in production, something shifts. That same confidence starts to feel more like guesswork.
I was reviewing a suggested fix recently that, on the surface, looked completely reasonable. Clean diff, good structure, even referenced what seemed like the right practices. But I still had to stop and validate it. I checked documentation, dependencies, side effects, how it might impact other resources, whether it aligned with policy. Twenty minutes later, I still wasn’t fully confident that applying it wouldn’t break something downstream.
That’s the part no one talks about. The suggestion is fast. The validation is not.
We’ve quietly accepted a new cost in engineering workflows. AI gives us probabilistic answers, and we absorb the burden of verifying them. Every “fix” comes with hidden work. You validate it, adjust it, test it, and often rewrite parts of it anyway. And increasingly, you’re also paying for it in tokens just to get to something usable.
I call this the probabilistic tax.
It shows up in wasted time, in extra cost, and in unnecessary friction. There was a recent piece on ZDNet discussing AI code review agents charging around $25 per pull request just to analyze issues, and that’s before you even get a reliable fix out of it. So now you’re paying to analyze, paying again to generate a fix, and still spending engineering time to validate the result. On top of that, you’re waiting minutes for something you’re not entirely sure you can trust.
At some point, we have to ask: Are we actually saving time, or just shifting where we spend it?
The reality is that generative AI is very good at creating code, but most of engineering is not about creating something new. It’s about maintaining what already exists. It’s about debugging, securing, aligning with policies, and making sure changes don’t introduce unintended consequences. Production systems don’t operate in probabilities. They operate in constraints. Policies need to be enforced exactly, dependencies need to resolve predictably, and changes need to be safe consistently.
“Usually correct” doesn’t work in that world.
This is where the diminishing returns start to show up. The first part feels magical, but the last mile is where you pay for it. You wait for the review, you validate the output, you fix what’s off, you rerun everything, and you still don’t have complete confidence. The system helped you get started, but it didn’t actually finish the job.
That gap is exactly what pushed us to build Open Remediation Language.
We weren’t looking to build another layer that suggests fixes. There are plenty of those already. The problem wasn’t detection, or guidance. It was execution. We needed a way to take policy intent and turn it into deterministic, production-safe changes directly in code.
ORL is designed to do exactly that. It maps policies to code transformations and operates on real syntax, not generated text. The output isn’t something you have to interpret or double-check line by line. It’s a merge-ready change that aligns with how your systems are supposed to behave. And because it’s deterministic, it doesn’t come with the same token costs or latency you see with generative loops. That’s time and cost savings with consistent safety.
What started with Infrastructure as Code quickly expanded beyond it. Because the problem isn’t limited to IaC. It exists in cloud configuration, in application code, and in dependency management. Anywhere AI is suggesting fixes, engineers are still burdened with making those fixes safe.
That’s the gap ORL is closing. Not by trying to make AI better at guessing, but by constraining it to execute correctly consistently.
AI in engineering is clearly moving from recommendation to action. That shift is already underway. The real question is whether we continue to rely on systems that are inherently probabilistic, or whether we start building systems that can operate within the deterministic requirements of production environments.
Because at scale, this isn’t just a philosophical difference. It shows up in engineering hours, in infrastructure risk, and in very real dollars spent on tokens and rework.
I’m not tired of AI. I’m tired of paying for uncertainty.
