There is a simple way to test whether an AI assistant is ready for production.
Don’t ask it to generate code. Ask it to fix Log4Shell across a real system.
That is where most approaches break down.
Log4Shell was never a detection problem. The industry responded quickly. Every scanner flagged it, every dashboard lit up, and every security team knew exactly where they were exposed. On the surface, this looked like success. In reality, it only exposed a deeper issue that has been sitting underneath security tooling for years.
Fixing Log4Shell was not one change. It was thousands of decisions spread across different services, environments, and dependency trees. Some applications required version upgrades. Others needed mitigations. Many required both. None of these changes could be applied blindly because each one had the potential to introduce instability into production systems.
This is where the gap becomes obvious.
This is the gap ORL is designed to close. Not by improving suggestions, but by executing remediation in a deterministic, repeatable way.
Most AI assistants can generate a suggested fix. In isolation, many look correct.
Production environments are not isolated. They are interconnected, inconsistent, and full of edge cases.
Probabilistic output does not account for that complexity. It cannot guarantee that the same issue is resolved the same way across systems, or that fixes will not introduce new risk.
As a result, the burden stays with the engineer.
We wanted to approach this problem from a different angle. Instead of focusing on whether AI can suggest a fix, we focused on whether it can execute remediation in a way that holds up in real environments.
We used Log4Shell as a proof point because it represents the kind of complexity that most tools struggle with. The scenario involved more than 20 rules, multiple Java dependency patterns, and a combination of version upgrades alongside mitigation changes. This is the type of problem that typically requires coordination across teams and extended timelines.
The outcome is what matters.
The full remediation was completed in under 24 hours across a large codebase. More importantly, the changes were applied deterministically. The same inputs produced the same outputs every time, which removes ambiguity and eliminates the need for repeated validation. Each change was aligned to defined policies, ensuring that fixes were not only technically correct but also consistent with how the organization manages risk.
All of this work was delivered directly into developer workflows as pull requests. Engineers could review, test, and merge the changes in the same way they handle any other code contribution. There was no separate system to interpret, no additional translation layer, and no need to manually reconstruct fixes from suggestions.
This is the difference between generating guidance and executing remediation.
What we are showing with ORL is not theoretical. It is a practical execution layer that translates policy intent into deterministic code transformations. It operates across infrastructure, application code, and dependencies, which reflects how real systems are built and maintained.
The industry has spent years improving how quickly we can identify issues. More recently, we have focused on using AI to generate recommendations faster. Neither of these efforts address the core bottleneck, which is the ability to apply fixes safely and consistently at scale.
If AI is going to operate in production, it has to move beyond suggestion. It has to execute in a way engineers can trust.
There is a straightforward way to evaluate that.
Ask it to fix Log4Shell across a real system.
Not identify it. Not suggest a fix.
Fix it.
This is what that execution looks like: https://youtu.be/TD6_6yi4qrI
