Large language models (LLMs) have become essential tools in software development, widely used for requirements engineering, code generation and review tasks. Software engineers often rely on LLMs to verify if code implementation satisfy task requirements, thereby ensuring code robustness and accuracy. However, it remains unclear whether LLMs can reliably determine code against the given task descriptions, which is usually in a form of natural language specifications. In this paper, we uncover a systematic failure of LLMs in matching code to natural language requirements. Specifically, with widely adopted benchmarks and unified prompts design, we demonstrate that LLMs frequently misclassify correct code implementation as non-compliant or defective. Surprisingly, we find that more detailed prompt design, particularly with those requiring explanations and proposed corrections, leads to higher misjudgment rates, highlighting critical reliability issues for LLM-based code assistants. We further analyze the mechanisms driving these failures and evaluate the reliability of rationale-required judgments. Building on these findings, we propose a Fix-guided Verification Filter that treats the model proposed fix as executable counterfactual evidence, and validates the original and revised implementations using benchmark tests and spec-constrained augmented tests. Our results expose previously under-explored limitations in LLM-based code review capabilities, and provide practical guidance for integrating LLM-based reviewers with safeguards in automated review and development pipelines.
Figures & tables
Figure 1: Workflow of evaluating LLM code conformance on canonical and buggy solutions under three prompting modes, with outputs logged for downstream scoring.
Figure 2: The Full prompt template used in our experiments. It provides the requirement and code, then requests a three-step response.
Category
Explanation
Misread Spec
The model misreads or overlooks key requirement semantics (e.g., interpreting constraint A as constraint B).
Added Requirement
The model introduces constraints not stated in the requirement and rejects the code for violating these hallucinated requirements.
Overthink Edge
The model overemphasizes extreme or unspecified edge cases, despite the requirement not mandating such handling (or the code already covering it).
Assumed Type
The model assumes stricter (or different) input types/formats and rejects the implementation based on those assumptions.
Imagined Runtime
The model speculates about runtime errors (e.g., index error, None handling, exceptions) without concrete evidence from the given code and requirement.
Performance Nitpick
The model treats efficiency/complexity as a hard requirement even when not mentioned, and rejects correct code due to perceived inefficiency.
Table 1: FN reason taxonomy for normalizing the main rationale patterns in those judgments.
Model
Approch
HumanEval
MBPP
Quixbugs
FPR
FNR
FPR
FNR
FPR
FNR
GPT-4o
Direct
2.44
26.2
3.70
35.9
10.9
35.0
Direct + Explain
0.00
58.5
0.00
74.1
5.00
45.0
Full
0.00
73.2
0.20
87.9
5.00
60.0
Gemini-2.0-flash
Direct
8.54
25.6
10.3
34.7
22.5
25.0
Direct + Explain
7.32
23.2
11.1
35.1
22.5
22.5
Table 2: False-positive rate (FPR, %) and false-negative rate (FNR, %) of five LLMs on three benchmarks (HumanEval, MBPP, and QuixBugs) under three prompting approaches ( Direct , Direct+Explain , and Full ). FNR reflects over-correction (rejecting correct implementations), while FPR reflects unsafe acceptance (accepting buggy implementations). Green highlights relatively lower error rates within each model benchmark block, whereas red highlights relatively higher error rates.
Figure 3: Absolute FN and FP counts across prompt settings for GPT-4o and Llama-3.1-8B.
Figure 4: Distribution of perceived fault types in FN rationales (left) and top-4 perceived errors by model (right). Categories include Misread_Spec (spec misinterpretation), Added_Requirement (unstated constraints), Overthink_Edge (boundary overconcern), Assumed_Type (format assumption), Imagined_Runtime (unsupported runtime speculation), Perf_Nitpick (performance critique), Read_Nitpick (style critique), Precision_Error (numeric precision), Logic_Error (algorithmic flaw claim), and Vague_Description (vague unsupported reasoning).
Figure 5: Counts of inconsistent rationales (labeled as contradiction or unclear by a GPT-4o evaluator) under rationale-enabled prompts. Bars compare Direct+Explain vs. Full for each model across HumanEval, MBPP, and QuixBugs, report absolute counts.
Figure 6: Directional breakdown of contradiction cases by model. Each chart shows the fraction of Contradiction_NO (verdict=NO but rationale positive) vs. Contradiction_YES (verdict=YES but rationale negative), center labels report percentages and the total number of contradictions ( n ).
Model
HumanEval
MBPP
QuixBugs
BugMatch
SymMatch
BugMatch
SymMatch
BugMatch
SymMatch
GPT-4o
59.1
98.2
70.8
94.7
58.3
100.0
Claude-4.5
65.0
97.5
75.2
93.3
57.9
92.1
Gemini-2.0
52.0
98.7
67.2
95.8
38.2
91.2
Llama-3.1
44.2
96.8
52.2
96.0
41.7
100.0
Mistral-3.1
50.0
96.8
65.7
94.5
58.3
95.8
Table 3: A2 fault-awareness on buggy instances when the model verdict is correct. We report match rates (%) between the rationale and ground-truth bug type matched and failure symptoms matched.
Figure 7: Example of a symptom is correct but bug type is not matched, the model correctly states the failure symptom, but frames the root cause as Missing Logic (highlighted in red) instead of the ground-truth Value Misuse.
Figure 8: bug-type alignment on TN buggy instances, Bars report the distribution of rationale labels (match, mismatch, not mentioned, unclear) with respect to ground-truth bug types.
Figure 9: Overview of the Fix-guided Verification Filter. When the judge outputs NO with a proposed fix, we execute both the original and fixed implementations on the benchmark tests and generated spec-constrained tests, and update the final verdict according to four executable cases.
Model
Setting
HumanEval
MBPP
QuixBugs
FPR
FNR
FPR
FNR
FPR
FNR
GPT-4o
Full (Before)
0.0
70.7
0.0
88.7
5.0
57.5
Full+Filter (After)
1.8
23.2 ↓ ( 47.6 )
0.4
40.0 ↓ ( 48.8 )
7.5
27.5 ↓ ( 30.0 )
Gemini-2.0-flash
Full (Before)
7.8
25.0
11.1
30.1
22.5
20.0
Full+Filter (After)
6.4
5.8 ↓ ( 19.2 )
10.2
10.2 ↓ ( 19.9 )
22.5
12.5 ↓ ( 7.5 )
Claude-4-5-sonnet
Full (Before)
1.9
46.0
5.3
61.2
5.0
50.0
Table 4: False-positive rate (FPR, %) and false-negative rate (FNR, %) before vs. after applying the Fix-guided Verification Filter under Full prompting. For each Full+Filter row, the FNR cell additionally reports the absolute reduction (percentage points) from the corresponding Full baseline as ↓(Δ) .
Large language models (LLMs) have become integral to modern software development, enabling automated code generation at scale. However, validating the correctness of LLM-generated code remains a critical and largely unsolved challenge. Existing approaches either rely on dynamic consensus across multiple code candidates - making them costly and difficult to scale - or on static reasoning that is susceptible to dynamic bugs and order bias. In this paper, we propose TRAILS~ (Targeted Reasoning Agreement via Inputs and Specifications), an approach that grounds LLM reasoning with concrete (input, output) pairs. TRAILS~ first generates diverse test inputs via category partitioning based on the specification, then executes them against the candidate code and prompts LLMs to assess whether the resulting input-output pairs conform to the specification - without ever reasoning over the code itself. Scores are aggregated across inputs, to determines whether the program is likely correct. We evaluate TRAILS~ on two datasets, LiveCodeBench and CoCoClaNeL, across three LLMs (Qwen3Coder-30B, Devstral-Small-24B, and Olmo3.1-Instruct), comparing against HoarePrompt and a Zero-Shot Chain-of-Thought baseline. TRAILS~ improves Matthew Correlation Coefficient by up to 39% relative to Zero-Shot COT and consistently outperforms HoarePrompt. Beyond accuracy, TRAILS~ demonstrates greater stability across seeded runs, reducing sensitivity to LLM non-determinism, and assigns correct labels to a larger set of unique code samples than competing approaches.
Large Language Models are increasingly used as judges to evaluate code artifacts when exhaustive human review or executable test coverage is unavailable. LLM-judge is increasingly relevant in agentic software engineering workflows, where it can help rank candidate solutions and guide patch selection. While attractive for scale, current practice lacks a principled account of reliability and bias: repeated evaluations of the same case can disagree; small prompt edits can swing outcomes; and seemingly semantics-preserving, human-equivalent perturbations may elicit divergent verdicts. This paper studies LLM-as-a-Judge for code through a measurement-first lens. We analyze two pointwise judging regimes across code generation, code repair task, and test generation, and we systematically probe prompt-induced biases. Our study considers difficulty levels for repeated runs and controlled prompt interventions that isolate one presentation cue at a time, and it evaluates judges using consistency and sensitivity to bias. We find that judge decisions are highly sensitive to prompt biases even when the underlying code snippet is unchanged. Across all three tasks, several biases systematically shift preferences toward the option favored by the prompt, improving accuracy when that option aligns with the gold answer but substantially reducing it otherwise. In some settings, these effects are large enough to change task-level conclusions and alter relative model rankings. These findings show that reported judge performance may reflect prompt artifacts rather than stable assessment ability, posing a direct threat to the validity and reproducibility of code evaluation. We therefore argue that LLM-as-a-Judge studies should report bias sensitivity alongside accuracy and incorporate explicit controls to support more trustworthy model comparison in software engineering.
Large Language Models (LLMs) show promise in automated software engineering, yet their guarantee of correctness is frequently undermined by erroneous or hallucinated code. To enforce model honesty, formal verification requires LLMs to synthesize implementation logic alongside formal specifications that are subsequently proven correct by a mathematical verifier. However, the transition from informal natural language to precise formal specification remains an arduous task. Our work addresses this by providing the NaturalLanguage2VerifiedCode (NL2VC)-60 dataset: a collection of 60 complex algorithmic problems. We evaluate 11 randomly selected problem sets across seven open-weight LLMs using a tiered prompting strategy: contextless prompts, signature prompts providing structural anchors, and self-healing prompts utilizing iterative feedback from the Dafny verifier. To address vacuous verification, where models satisfy verifiers with trivial specifications, we integrate the uDebug platform to ensure functional validation. Our results show that while contextless prompting leads to near-universal failure, structural signatures and iterative self-healing facilitate a dramatic performance turnaround. Specifically, Gemma 4-31B achieved a 90.91% verification success rate, while GPT-OSS 120B rose from zero to 81.82% success with signature-guided feedback. These findings indicate that formal verification is now attainable for open-weight LLMs, which serve as effective apprentices for synthesizing complex annotations and facilitating high-assurance software development.
Md Erfan, Md Kamal Hossain Chowdhury, Ahmed Ryan +1
Department of Computer Science, The University of Alabama, Tuscaloosa, USA · Alabama Water Institute, The University of Alabama, Tuscaloosa, USA