Repository-level issue resolution benchmarks have become a standard testbed for evaluating LLM-based agents, yet success is still predominantly measured by test pass rates. In practice, however, acceptable patches must also comply with project-specific design constraints, such as architectural conventions, error-handling policies, and maintainability requirements, which are rarely encoded in tests and are often documented only implicitly in code review discussions. This paper introduces design-aware issue resolution and presents \bench{}, a benchmark that makes such implicit design constraints explicit and measurable. \bench{} is constructed by mining and validating design constraints from real-world pull requests, linking them to issue instances, and automatically checking patch compliance using an LLM-based verifier, yielding 495 issues and 1,787 validated constraints across six repositories, aligned with SWE-bench-Verified and SWE-bench-Pro. Experiments with state-of-the-art agents show that test-based correctness substantially overestimates patch quality: fewer than half of resolved issues are fully design-satisfying, design violations are widespread, and functional correctness exhibits negligible statistical association with design satisfaction. While providing issue-specific design guidance reduces violations, substantial non-compliance remains, highlighting a fundamental gap in current agent capabilities and motivating design-aware evaluation beyond functional correctness.
Figures & tables
Figure 1. A motivating example illustrating the resolution process of a realistic issue, along with relevant code review threads and the design constraints embedded in the discussion.
Figure 2. Overview of the construction pipeline of SWE-Shield
Benchmark
Repository
#Iss.
#Cons.
Avg. Patch Lines
Lang.
SWE-Shield verified
django
182
590
12.99 (max 156)
Python
sympy
54
132
SWE-Shield pro
ansible
84
480
197.92 (max 2,028)
Multi (Py,Go,etc)
teleport
73
331
flipt
62
149
openlibrary
40
105
Table 1. Distribution and Characteristics of Repositories and Issues in SWE-Shield
Dataset
Agent
DSR (%)
DVR (%)
DNR (%)
Pass (%)
P&S (%)
P&V (%)
F&S (%)
F&V (%)
SWE-Shield pro
SWE-agent (Gemini-2.5-Pro)
41.50
39.92
18.58
13.44
4.74
8.70
36.76
49.80
SWE-agent (Kimi-K2)
40.71
43.08
16.21
18.18
7.51
10.67
33.20
48.62
SWE-agent (GPT-5)
39.13
41.11
19.76
30.43
13.83
16.60
27.27
42.29
SWE-agent (Claude-Sonnet-4.5)
50.20
37.15
12.65
42.69
22.53
20.16
27.67
29.64
SWE-Shield verified
Lingxi-v1.5 (Kimi-K2)
32.64
43.39
23.97
70.25
25.62
44.63
7.02
22.73
Sonar Foundation Agent (Claude-Sonnet-4.5)
39.17
36.67
24.17
73.75
30.00
43.75
9.17
17.08
Table 2. Overall performance and outcome distribution of different agents on SWE-Shield
Agent
p -value
Cramér’s V
SWE-agent (Kimi-K2)
1.0000
0.0000
SWE-agent (Gemini-2.5-Pro)
0.5468
0.0379
SWE-agent (GPT-5)
0.4290
0.0497
SWE-agent (Claude-Sonnet-4.5)
0.5611
0.0365
Live-SWE-agent (Gemini-3.0-pro)
0.2858
0.0685
Lingxi-v1.5 (Kimi-K2)
0.0718
0.1157
Table 3. Statistical relationship between functional correctness and design satisfaction on SWE-Shield.
Figure 3. Venn Diagram for Violated Design Constraints of Different LLMs.
Figure 4. An example of design-constraint violation in Django #13410.
Figure 5. Comparison of DVR Before and After Constraint-Guided Refinement.
Figure 6. An example of design-constraint violation in Django #50909.
Repository-level issue-resolution benchmarks such as SWE-bench evaluate submitted patches primarily based on whether they pass the correctness tests, leaving the runtime performance of different test-passing patches largely unexplored. Evaluating patch performance is essential but challenging since designing performance workloads for each benchmark instance is costly. However, these benchmarks already provide a natural candidate: the built-in FAIL_TO_PASS (F2P) tests, which exercise the behavior affected by the issue fix. We therefore investigate whether the provided F2P tests can be repurposed to evaluate patch performance. Overall, we choose four frontier models, Claude Opus5, GPT5.6, DeepSeek V4 Pro, and Qwen~3.8 Max, paired with SWE-agent to resolve the pre-filtered measurable corpus from verified splits of SWE-bench and SWE-bench-Live, yielding 262 cases with at least two different correct solutions, including the developer ground-truth patch. We then measure each solution's runtime performance in instruction count and wall-clock time on the native F2P test, and use Welch ANOVA instead of the RSD proposed in prior work as a more robust statistical discrimination criterion. We find that this methodology exhibits notable discrimination capability in runtime performance and identifies performance differences among patches in almost half of the instances. Our empirical study shows that the runtime performance of generated patches is independent of the issue resolution rate of LLMs, with nearly reversed model rankings. The case study also shows that the performance analysis reveals architectural regression in some patches that the correctness evaluation overlooked. These findings suggest that resolution rate does not adequately characterize LLMs' capability for repository-level issue resolution, motivating future evaluations to consider patch performance alongside it.
Han Peng, Xing Hu, Feifei Niu +2
The State Key Laboratory of Blockchain and Data Security, Zhejiang University, China and Hangzhou High-Tech Zone (Binjiang) Institute of Blockchain and Data Security, China · Graz University of Technology, Austria
SWE-bench-like benchmarks are widely used for evaluating LLM's issue resolution capability. They typically follow a common construction pipeline: each PR (Pull Request) is paired with its linked issue by extracting issue references from the PR description; the issue description is used as the problem statement, and the PR patch serves as the test oracle. However, due to the inherent complexity of developing and maintaining large repositories, such PR-Issue pairings are often misaligned in practice. In this work, we systematically study SWE-bench Verified instances, finding that 13.6% exhibit misalignment across five patterns in eleven fine-grained scenarios. To enable reliable and scalable construction of those benchmarks in the future, we propose PAIChecker, a multi-agent system for checking PR-Issue misalignment in SWE-bench-like benchmarks. Specifically, PAIChecker adopts a three-phase design that combines specific pattern identification, cross-agent label synthesis, and code-level validation, thereby enabling more accurate, generalizable, and progressively verified detection. Experiments on SWE-Gym and SWE-bench Multilingual show that PAIchecker achieves the best performance across all four LLM backbones, reaching up to 92.12% and 91.67% binary accuracy, respectively.
Recent advances in frontier large language models have enabled code review agents that operate in open-ended, reasoning-intensive settings. However, the lack of standardized benchmarks and granular evaluation protocols makes it difficult to assess behavior of code review agents beyond coarse success metrics, particularly for tasks where false positives are costly. To address this gap, we introduce CR-Bench, a benchmarking dataset, and CR-Evaluator, a fine-grained evaluation pipeline for code review agents. Using these tools, we conduct a preliminary study evaluating both a single-shot agent and a Reflexion-based agent across two frontier models. We find that code review agents can exhibit a low signal-to-noise ratio when designed to identify all hidden issues, obscuring true progress and developer productivity when measured solely by resolution rates. Our analysis identifies the hidden trade-off between issue resolution and spurious findings, revealing a frontier that constrains effective agent design. Together, CR-Bench and CR-Evaluator provide a timely foundation for studying and developing code review agents as LLM-based systems transition from controlled benchmarks to real-world software engineering workflows.