← Latest papers
🤖 AI

What Process Evaluation of Coding Agents Actually Measures: Action, Task, and Step Are Three Different Levels

This paper introduces a measurement framework that distinguishes between action, task, and step levels to demonstrate that current process evaluations of coding agents often conflate semantic relevance with causal contribution, revealing that agent behavior is driven by execution provenance and task-level uncertainty rather than simple code transitions.

Original authors: Jiawei He, Mengyu Shi, Jie jia, Xikai Yang, Dong Sun

Published 2026-08-25
📖 5 min read🧠 Deep dive

Original authors: Jiawei He, Mengyu Shi, Jie jia, Xikai Yang, Dong Sun

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

In the world of software development, a new kind of worker has emerged: the coding agent. Powered by large language models, these programs can read a problem description, navigate a complex codebase, and write the necessary fixes to solve it. For years, the industry has judged these agents simply by whether they succeeded or failed at the end of the day. But as these digital workers become more common, developers have realized that the final result is not enough. They need to know how the agent got there. They want to understand which specific moves helped the task, which ones caused the failure, and whether the process was logical or just a lucky guess. This need has sparked a field of study focused on "process evaluation," an attempt to grade the agent's journey step by step, rather than just its destination.

The core challenge in this field is that people have been treating three very different questions as if they were the same. One question asks what the agent is likely to do next, based on its current situation. Another asks how uncertain the entire task remains as the agent works. The third, and most difficult, asks whether a single specific action actually caused the final outcome to change. For a long time, researchers and tools have mixed these concepts together, assuming that a tool designed to predict the next move could also explain why a step was critical. A team of researchers at Alibaba and Nanjing University decided to untangle these threads. They built a rigorous framework to measure each of these three levels separately, using a method that involves watching the agent work, stopping it, and then restarting it from the exact same point to see what happens.

To do this, the researchers focused on a specific type of task called file localization. Imagine an agent is given a bug report and a snapshot of a software project. Its job is to find the exact files that need to be changed to fix the bug. This setting is perfect for study because the goal is clear and verifiable. The researchers recorded 499 episodes of agents working on real-world software repositories. They then took these recorded sessions and rewound them to various points. From those points, they let the agent run again, sometimes letting it choose its own next move, and other times forcing it to take a different path to see if the final result changed. This allowed them to isolate the effect of individual steps from the noise of the entire journey.

Their investigation revealed that the way agents move through code is not what most people expect. When trying to predict what an agent will do next, the most powerful signal is not the structure of the code itself, such as how files are linked together in a dependency graph. Instead, the agent is driven almost entirely by its own recent history. It looks at the paths it has just seen in the output of its previous tools and uses that immediate context to decide where to go next. The code structure matters less for the immediate next step than the trail of breadcrumbs the agent has just left behind. This finding suggests that the agent is reacting to what it just observed rather than following a pre-planned map of the repository.

The study also uncovered where the uncertainty in these tasks actually lives. Many people assume that the risk of failure comes from a single bad step, like a wrong file choice. However, the researchers found that uncertainty is a property of the entire task, not of individual steps. Some tasks are inherently difficult or ambiguous from the start, while others are straightforward. The variation in whether an agent succeeds or fails is determined by the nature of the specific problem it is solving, not by the specific sequence of moves it makes along the way. This means that trying to pinpoint a single "fatal error" step is often a futile exercise because the outcome was likely decided by the difficulty of the task itself.

Perhaps the most striking discovery concerns how we currently evaluate these agents. Many systems use a "judge," often another large language model, to review the entire history of the agent's work and decide which step was responsible for a failure. The researchers tested these judges by hiding or revealing different parts of the agent's history. They found that when the judge could see the later steps of the journey, it systematically shifted its blame toward the end of the process. This happened even when the later steps had nothing to do with the actual cause of the problem. The judge was not identifying the true cause; it was simply latching onto the most recent evidence that looked relevant. This revealed a systematic bias in current evaluation methods, where the tools used to grade the agents are actually measuring semantic relevance—what looks important in hindsight—rather than certified causal contribution.

The researchers concluded that process evaluation is not a single problem but a collection of distinct challenges. Predicting the next move is a solvable problem driven by recent context. Understanding task difficulty is a matter of analyzing the problem itself. But determining the causal impact of a single step is incredibly difficult and often impossible to measure with the current tools. The study suggests that we must stop treating these different levels as the same. If we want to improve coding agents, we need to use the right tool for the right question, recognizing that a signal that predicts the next move is not the same as a signal that proves a step caused a success or failure. By separating these levels, we can finally understand what our evaluation tools are actually telling us, and what they are merely guessing.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →