Engineering Reliable Coding Agents: Evaluating and Operating the System Around the Model

Imagine you are watching a magic show where a robot assistant is trying to fix a broken toy. You see the robot pick up a screwdriver, turn a screw, and the toy starts working. It looks like the robot is a genius. But what if the robot was actually just guessing, and the toy only started working because a hidden spring inside it happened to snap back into place? Or what if the robot was looking at a picture of the toy from last year, not the broken one in front of it? In the world of computer science, specifically in the field of Artificial Intelligence (AI) and Software Engineering, we are building these "robot assistants" (called coding agents) that write and fix computer code. For a long time, people thought the "brain" of the robot—the AI model—was the only thing that mattered. If the brain was smart, the robot would be reliable. But this paper argues that the brain is just one part of a much bigger machine. The real magic (or the real disaster) happens in the system surrounding the brain: the tools it uses, the memory it keeps, the safety checks it passes, and the humans who watch over it. If the system is messy, even the smartest brain will fail, and if the system is solid, a simpler brain can do amazing things.

This paper, written by Stephanie Jarmak, is like a massive repair manual and a detective's guide for building these AI coding systems. The author conducted a structured review in July and August 2026, analyzing hundreds of studies, real-world engineering logs, and their own experiments to figure out why AI coding agents sometimes fail, even when they seem to be doing great on paper. The main finding is a bit of a wake-up call: You cannot judge an AI coding agent just by looking at its final score or its "brain." Instead, you have to look at the entire "harness" around it. The paper introduces a concept called the "reliability dependency chain." Think of it like a line of dominoes. If the first domino (the way you measure success) is wobbly, the second domino (the grading system) will fall over, which knocks over the third (the recovery plan), and so on. If any link in this chain is weak, the whole system becomes unreliable, no matter how smart the AI is.

The paper argues against the idea that we can just keep making the AI models bigger and smarter to fix all problems. It suggests that many "failures" aren't actually the AI's fault; they are caused by the system around it. For example, if an AI is given a task but the system doesn't give it the right files to read, the AI will fail. Is that the AI's fault? No, it's the system's fault. The paper also warns against "gaming" the system. If you test an AI on a set of puzzles it has already seen before, it might get a perfect score, but that doesn't mean it can solve new puzzles. The author shows that many public scores are inflated because the AI has "memorized" the answers or because the tests weren't strict enough.

To fix this, the paper proposes a new way of building and testing these agents. It's not about finding the "perfect" AI model; it's about building a robust factory. Imagine a factory where a robot builds a car. If the robot drops a part, the factory shouldn't just pretend it didn't happen. It needs a system to catch the drop, record it, and try again without breaking the car. The paper provides a checklist of 206 "reliability records"—basically, rules and tools to make sure the system is safe. These include things like:

• Running tests multiple times: Just like flipping a coin once doesn't tell you if it's fair, running an AI once doesn't tell you if it's reliable. You have to run it many times to see if it's consistent.
• Checking the tools: Making sure the AI isn't using tools it shouldn't have, or that the tools it uses are actually working.
• Human oversight: Having a human check the work, but only at the right moments, so the human isn't overwhelmed.
• Safe recovery: If the AI crashes or makes a mistake, the system should be able to restart without losing progress or causing more damage.

The author is very careful not to say they have "solved" everything. They admit that some of their ideas are based on strong evidence from experiments, while others are based on logical reasoning about how systems should work to avoid disaster. They don't claim that their rules will work for every single AI in the world, but they provide a solid framework for engineers to test their own systems. They emphasize that if you want to trust an AI to write code for a bank or a hospital, you can't just look at its test scores. You have to look at the whole machine, check the dominoes, and make sure the system is built to handle mistakes safely.

In short, this paper tells us that building a reliable AI coder is less about finding a super-genius robot and more about building a super-reliable factory around it. It's a guide for engineers to stop guessing and start measuring, ensuring that when an AI says "I fixed it," it actually means "I fixed it, and I can prove it." The paper concludes that the future of AI coding isn't just about smarter brains, but about smarter, safer, and more honest systems that surround them.