💻 computer science

ProcBench: Evaluating Process-Level Defects and Control Preservation in LLM Coding Agents

This paper introduces ProcBench, a framework that evaluates LLM coding agents by analyzing process-level defects and control preservation through a standardized ontology and risk-based scorecards, offering deeper diagnostic insights than traditional outcome-only benchmarks across multiple datasets.

Original authors: Jiawei He, Jie Jia, Chenbo Liu, Chaoyi Xue, Yapeng Song, Xikai Yang, Dong Sun

Published 2026-05-21

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Jiawei He, Jie Jia, Chenbo Liu, Chaoyi Xue, Yapeng Song, 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

Imagine you are hiring a robot assistant to fix a complex leak in your house.

The Old Way (Current Benchmarks):
Right now, if you ask a robot to fix the leak, you only look at the result: Did the water stop? If the water stops, you give the robot a gold star. If the water keeps dripping, you give it a thumbs down.

But this misses a lot of the story. What if the robot:

Drank your entire water supply before fixing the leak?
Poked the same hole in the wall 50 times before finally finding the pipe?
Forgot where it left its tools halfway through?
Got stuck in a loop, spinning in circles for an hour before finally succeeding?

If the water stops, the old system says, "Great job!" But in reality, the robot was chaotic, wasteful, and hard to control.

The New Way (ProcBench):
The authors of this paper, ProcBench, say: "We need to grade the robot on how it did the job, not just if it finished."

They built a new scoring system that watches the robot's entire journey, like a referee watching a soccer game, not just the final score.

How ProcBench Works (The Analogy)

Think of a coding agent (the robot) as a chef trying to cook a complicated meal.

1. The "Process Defects" (The Kitchen Mess)
ProcBench looks for specific ways the chef might mess up the process, even if the meal eventually tastes okay. They categorize these messes into four main areas:

Context Management (The Cluttered Counter):
- Ghost Context: The chef keeps staring at an old recipe page that's already been summarized, wasting mental space.
- Oversized Rules: The chef is carrying a 50-page manual of rules in their apron that they don't actually need, slowing them down.
- Thrashing: The chef keeps flipping through the fridge, grabbing ingredients, putting them back, and grabbing them again, never settling on a plan.
Tool-Use Efficiency (The Wasted Movements):
- Duplicate Steps: The chef chops an onion, checks if it's chopped, chops it again, checks again, and chops it a third time.
- Dead Steps: The chef opens the oven, looks inside, closes it, and never actually puts the cake in. The action happened, but it changed nothing.
- Long Chains: The chef takes 50 tiny steps to do something that could have been done in 5.
Workflow Architecture (The Bad Kitchen Layout):
- Wrapper Workflow: The chef has a helper who just passes the salt from the chef's hand to the chef's other hand without doing anything useful.
- Context Coupling: The chef and the sous-chef are so tangled up in each other's tasks that if one sneezes, the whole kitchen collapses.
Tool-Ecosystem Consistency (The Confusing Utensils):
- Inconsistent Interfaces: One spoon is labeled "Soup," another is labeled "Liquid," and a third is labeled "Soup (Hot)." The chef gets confused and uses the wrong one.
- Weak Tools: There's a great electric whisk in the drawer, but the chef never finds it and keeps using a fork because the whisk was hidden.

2. The "Control Preservation" (The Safety Switch)
This is the most important part. Even if the robot is making mistakes, can you (the human) still take over?

Interpretability: Can you understand what the robot is doing?
Interruptibility: Can you hit "Pause" without the robot crashing?
Correctability: If the robot makes a mistake, can you fix it without starting the whole meal over?
Reversibility: Can the robot undo a bad step?
Authority Handoff: Can the robot say, "I'm stuck, you take over," and actually let you?

The "Calibrated Scorecard" (The Report Card)

Instead of just saying "Pass" or "Fail," ProcBench gives a detailed report card.

It doesn't just count mistakes; it calculates the risk.
It uses a "calibration" system (like a weather forecast). Instead of saying "It might rain," it says, "There is a 70% chance of rain." This helps you understand how serious a mistake really is.
It gives a score for the Process (how messy the kitchen was) and a score for Control (how safe the kitchen felt).

What They Found

The authors tested this on 200 real-world coding tasks (like fixing bugs in software or building apps) using different AI robots.

It Works: They found that they could reliably spot these "messy kitchen" behaviors.
It Reveals Hidden Flaws: Two robots might both finish the task (Pass), but one did it efficiently and safely, while the other was chaotic and risky. The old system would give them both gold stars. ProcBench gives the chaotic one a lower score.
It's Not Just About the Model: A powerful AI brain (the model) doesn't guarantee a good process. If the robot's "body" (the agent framework) is clumsy, the whole system fails, even with a smart brain.

The Bottom Line

ProcBench is a new way to grade AI coders. It stops us from just looking at the final result and forces us to look at the journey. It asks: "Did the robot solve the problem, or did it just stumble its way to a solution while creating a mess and losing control?"

This helps developers build AI that isn't just smart, but also reliable, safe, and easy to manage.

Technical Summary: ProcBench

Problem Statement

Existing benchmarks for Large Language Model (LLM) coding agents predominantly evaluate final outcomes, such as task completion rates, compilation success, and test pass rates. While these metrics effectively measure aggregate capability, they offer limited visibility into the execution trajectory. In long-horizon coding tasks, an agent may achieve a correct final result while following a brittle, repetitive, inefficient, or weakly controlled path. Such process-level failures—including context degradation, repetitive tool calls, and unnecessarily long execution chains—are often missed by outcome-based metrics. As coding agents become more autonomous, the gap between final performance and execution reliability becomes critical, as many practically significant failures occur during execution rather than at the endpoint. Current research often focuses on qualitative diagnosis or task-specific case studies, lacking a reusable, standardized framework for comparing process quality across different systems.

Methodology

The authors introduce ProcBench, a benchmark-oriented framework designed to evaluate coding-agent trajectories through process defects and control preservation. The methodology operates in four primary stages:

Standardized Trajectory Representation:
To address the heterogeneity of logs across different coding agents (varying formats, tool interfaces, and schemas), ProcBench applies a deterministic mapping $\Psi$ that converts raw execution logs into a unified sequence of standardized events. Each event captures type, payload, tool invocation, return values, observable operations, context state, and structural dependencies.
Defect Ontology and Extraction:
ProcBench structures recurring execution problems into a reusable ontology comprising four dimensions and 11 defect classes:
- Context Management: Ghost Context, Oversized Rules, Context Window Thrashing.
- Tool-Use Efficiency: Duplicate Step, Tool Call Chain, Dead Step, Long Chain.
- Workflow Architecture: Wrapper Workflow, Context Coupling.
- Tool-Ecosystem Consistency: Inconsistent Tool Interface, Weak Tool.
  Evidence is extracted from the standardized trajectory, and continuous evidence scores are computed. Crucially, the framework employs exemption logic to distinguish between semantically appropriate behaviors (e.g., necessary validation reruns) and actual defects.
Calibrated Process Scoring:
Rather than relying on raw detector outputs or hard thresholds, ProcBench maps evidence into calibrated posterior risks ( $p_j = P(y_j=1 | x_j, c)$ ). This calibration step improves the interpretability and comparability of findings across different defect types and task contexts. Risks are mapped to semantic bands (None, Warning, Error) to aid reporting.
Control Preservation Evaluation:
Parallel to defect evaluation, ProcBench assesses Control Preservation, defined as the ability to maintain governability during autonomous execution. This is decomposed into five subdimensions: interpretability, interruptibility, correctability, reversibility, and authority handoff.
Output:
The framework generates a multi-dimensional scorecard reporting defect-level risks, dimension-level process-quality scores, control-preservation scores, and a compact summary score ($PB$). The full scorecard is the primary output, intended for diagnostic comparison rather than simple ranking.

Key Contributions

ProcBench Framework: A benchmark-oriented framework for evaluating LLM coding agents beyond final outcomes using a reusable ontology of process-level defects.
Trajectory-Based Pipeline: A pipeline that standardizes heterogeneous logs and maps defect evidence into calibrated scorecards, moving beyond binary pass/fail metrics.
Control Preservation Axis: The formalization of control preservation as a parallel evaluation axis for governability, distinct from defect burden.
Empirical Validation: An initial study demonstrating that the framework can be instantiated with useful reliability and that calibrated scoring provides more stable semantics than direct thresholding.

Experimental Results

The authors evaluated ProcBench on an annotated set of 200 trajectories drawn from three benchmarks: AndroidBench, TerminalBench, and SWE-bench-Verified. The study covered 11 agent–model configurations across four agent families (Claude Code, Codex CLI, OpenCode, and Qoder).

Instantiation Reliability: Defect classes with strong local observability (e.g., Ghost Context, Duplicate Step, Dead Step) achieved high detection performance (F1 scores ranging from 0.76 to 0.86). Structurally higher-level defects (e.g., Wrapper Workflow, Weak Tool) were more difficult to instantiate, reflecting their dependence on latent workflow structures.
Calibration Quality: Calibrated posterior risk scoring yielded lower Expected Calibration Error (ECE) compared to direct hard-thresholding, particularly in dimensions with heterogeneous evidence like Workflow Architecture and Tool-Ecosystem Consistency. This confirms that calibration improves the empirical interpretability of defect findings.
Cross-System Distinctions: ProcBench revealed meaningful differences in process profiles that outcome-based metrics missed. For instance, while some systems had similar endpoint success rates, they differed significantly in control preservation and fragile-success rates. The study found that process reliability is a property of the combined agent–model system, not just the base model.
Scenario Sensitivity: System strengths varied by benchmark source (e.g., Claude Code performed best on AndroidBench and SWE-bench, while Codex CLI excelled on TerminalBench), indicating that ProcBench captures both global process quality and scenario-specific behaviors.

Significance and Claims

The paper claims that ProcBench provides a structured, complementary layer to conventional outcome-based evaluation. Its primary significance lies in:

Diagnostic Granularity: It distinguishes between "fragile success" and "governed execution," offering insights into how an agent reaches a result, not just if it succeeds.
Improved Interpretability: By using calibrated risk estimation rather than raw thresholds, the framework offers more stable and comparable semantics for benchmark findings.
Governability Focus: By introducing control preservation as a distinct metric, it addresses the critical need for autonomous agents to remain understandable, interruptible, and correctable.

The authors remain modest regarding the scope of their work, acknowledging limitations such as the dependence on process-level annotation, partial observability for certain defect classes, and the need for broader external validation. They emphasize that ProcBench is intended to complement, not replace, existing outcome-based metrics, serving as a tool for structured comparative evaluation in long-horizon settings.