Paper deep dive
On the Robustness of LLMs' Internal Representation of Code Correctness
Francisco Ribeiro, Sohaila Abdulsattar, Renata Gonzalez, Mahmoud Kassem, Sarah Nadi
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 96%
Last extracted: 8/12/2026, 1:14:50 AM
Summary
This paper systematically investigates the robustness of internal representations of code correctness in Large Language Models (LLMs). It evaluates how different design choices—specifically direction construction methods (PCA vs. mean-difference), prompt framings (neutral, concept, function), and hidden-state read-out locations—affect the accuracy of detecting correct vs. incorrect code. Additionally, it tests whether isolating specific faults via controlled mutations improves signal quality. Results indicate that no single configuration is universally best and that controlling for incidental differences does not significantly improve the correctness signal's transferability.
Entities (14)
Relation Signals (14)
OpenCoder-8B-Instruct → isevaluatedon → BigCodeBench
confidence 98% · We evaluate on the same two benchmarks: ... BigCodeBench... We use the same four instruction-tuned LLMs... OpenCoder-8B-Instruct
CodeLlama-7B-Instruct → isevaluatedon → BigCodeBench
confidence 98% · We evaluate on the same two benchmarks: ... BigCodeBench... We use the same four instruction-tuned LLMs... CodeLlama-7B-Instruct
OpenCoder-8B-Instruct → isevaluatedon → HumanEval
confidence 98% · We evaluate on the same two benchmarks: HumanEval... We use the same four instruction-tuned LLMs... OpenCoder-8B-Instruct
CodeLlama-7B-Instruct → isevaluatedon → HumanEval
confidence 98% · We evaluate on the same two benchmarks: HumanEval... We use the same four instruction-tuned LLMs... CodeLlama-7B-Instruct
Mistral-7B-Instruct-v0.3 → isevaluatedon → HumanEval
confidence 98% · We evaluate on the same two benchmarks: HumanEval... We use the same four instruction-tuned LLMs... Mistral-7B-Instruct-v0.3
Mistral-7B-Instruct-v0.3 → isevaluatedon → BigCodeBench
confidence 98% · We evaluate on the same two benchmarks: ... BigCodeBench... We use the same four instruction-tuned LLMs... Mistral-7B-Instruct-v0.3
Qwen-2.5-Coder-7B-Instruct → isevaluatedon → HumanEval
confidence 98% · We evaluate on the same two benchmarks: HumanEval... We use the same four instruction-tuned LLMs... Qwen-2.5-Coder-7B-Instruct
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Code generated by modern language models often reads naturally. Yet, it also often fails to implement what was asked. This should be no surprise, as research shows the models' own confidence signals are poorly calibrated with actual correctness. A promising way to assess correctness looks inside the model: by contrasting the hidden states of correct and incorrect programs, recent work captured an internal signal of code correctness that is able to judge candidate solutions better than the model's token-level or stated confidence, with no test execution. However, this signal was captured under one particular way, leaving open an important question: whether it reflects a robust property of the model or an artifact of that choice. We study this question systematically, varying how the signal is extracted from the model internals. Besides this, we also ask if the signal's quality is limited by the data used to extract it, by constructing program pairs that differ only in the fault that makes them incorrect. Our results show that no single configuration is best, and that isolating the fault does not help.
Tags
Links
- Source: https://arxiv.org/abs/2608.08266v1
- Canonical: https://arxiv.org/abs/2608.08266v1
Trouble viewing inline? Open PDF directly →
Full Text
87,793 characters extracted from source content.
Expand or collapse full text
On the Robustness of LLMs’ Internal Representation of Code Correctness Francisco Ribeiro, Sohaila Abdulsattar*, Renata Gonzalez*, Mahmoud Kassem*, Sarah Nadi *These authors contributed equally and are listed alphabetically. Abstract Code generated by modern language models often reads naturally. Yet, it also often fails to implement what was asked. This should be no surprise, as research shows the models’ own confidence signals are poorly calibrated with actual correctness. A promising way to assess correctness looks inside the model: by contrasting the hidden states of correct and incorrect programs, recent work captured an internal signal of code correctness that is able to judge candidate solutions better than the model’s token-level or stated confidence, with no test execution. However, this signal was captured under one particular way, leaving open an important question: whether it reflects a robust property of the model or an artifact of that choice. We study this question systematically, varying how the signal is extracted from the model internals. Besides this, we also ask if the signal’s quality is limited by the data used to extract it, by constructing program pairs that differ only in the fault that makes them incorrect. Our results show that no single configuration is best, and that isolating the fault does not help. I Introduction Writing source code is increasingly delegated to large language models (LLMs). They complete the next line in an editor [1], generate whole functions from a description [2], and implement entire features at the repository level [3]. As they grow more fluent, their output is increasingly accepted with little scrutiny [4], and a growing fraction of the code reaching real systems now originates from a model rather than a human [5]. However, fluency is not the same as correctness. An LLM can produce code that reads naturally yet does not implement the requested functionality [6, 7]: it may be syntactically correct and even pass some tests, yet miss the specification, with nothing apparent in it reliably indicating whether it is correct. A good test suite can check correctness, but tests are often incomplete, missing, or themselves left to the model [8], and running them is expensive when the LLM produces many candidates. Early signs of correctness would therefore help developers trust generated code and prioritise which candidates to review. While the model’s own confidence (i.e., the probability it assigns to the generated tokens) or its stated confidence when asked [9] are potential signals, research showed that they are not well calibrated with correctness [10, 11]. Instead of relying on the model’s outputs, another option is to look at what the LLM internally computes. A model forms intermediate numerical representations of the input as it processes it, known as hidden states. These states are readily available and have been shown to encode high-level properties such as truthfulness [12, 13] or latent knowledge [14]. The main idea is that contrasting the hidden states of inputs that have a property against those that lack it recovers a vector along which the concept varies [15, 14, 13, 12]. This vector, a representation of the concept, can then be used to score new inputs by how far they point along it, indicating whether the input has the property. We use the term linear probing for this general approach of extracting a concept from hidden states. Most linear probing work has targeted natural language (NL) concepts such as sentiment [15] or truthfulness [12, 13]. However, recent work showed that it can also capture code correctness [11] where contrasting an LLM’s hidden states for correct versus incorrect implementations of the same task isolates a code correctness representation. Figure˜1 illustrates this idea, showing a model-generated implementation and the benchmark’s canonical solution for one HumanEval task: returning the sum of the odd values that sit at even positions. The model’s solution steps through the odd positions instead of the even ones. The authors’ captured code correctness representation ranked the correct program above the incorrect one without needing test execution, while the model’s own output probability and stated confidence did not. However, the highest obtained accuracy ranged from 41–63% across models and benchmarks, suggesting that the method of capturing the representation may not generalize well. Furthermore, for a fixed model/benchmark combination, accuracy varied significantly by which data subset captured and validated the representation versus tested it. ⬇ 1def solution(lst): 2 sum_of_odd_elements = 0 3 for i in range(1, len(lst), 2): 4 if lst[i] % 2 != 0: 5 sum_of_odd_elements += lst[i] 6 return sum_of_odd_elements (a) Incorrect: LLM-generated attempt that iterates over odd positions. ⬇ 1def solution(lst): 2 return sum([x for idx, x in enumerate(lst) if idx%2==0 and x%2==1]) (b) Correct: canonical solution that iterates over even positions. Figure 1: Two implementations of HumanEval/121 — return the sum of the odd values at even positions. Accordingly, the current results in the literature are promising but leave open questions about the representation’s quality and its robustness to data variation. Our goal is to systematically investigate the factors that influence the quality and robustness of code correctness representations. We make two key observations that motivate our study design. First, there are multiple methods to construct a concept representation in the literature [15, 16]. We hypothesize that the choice of method may affect the quality of the captured representation, and that perhaps some methods may generalize better than others across models and benchmarks. Second, the contrast between correct and incorrect programs may carry incidental differences that are not relevant to correctness, such as variable names or implementation style. Such captured incidental differences may explain why the correctness representation becomes sensitive to data variation. For example, in the example in Figure 1, the main fault is on Line 4, where the model iterates over odd positions instead of even ones. However, the two programs also differ in other ways: the correct program uses a comprehension with sum while the incorrect one uses a loop with an accumulator, they use different variable names, and they check for parity differently (%2!=0 vs. %2==1). In this paper, we systematically investigate the design choices behind capturing a code correctness representation to assess their effect. We also investigate how data variation affects the quality of the captured correctness signal. More specifically, we answer the following research questions (RQs): RQ1 How do the key design choices involved in capturing a code correctness direction (the direction-construction method, prompt framing, and hidden-state location) affect its quality and robustness? RQ2 Does controlling for differences between correct/incorrect programs via mutations and refactorings improve the quality of the correctness direction? Our evaluation covers in-distribution settings, where the direction is fit and tested on disjoint subsets of the same benchmark (HumanEval [2] and BigCodeBench [17]), and out-of-distribution settings, where it is fit on MBPP+ [18, 19] and tested on either benchmark, across four instruction-tuned LLMs. Our results show that no single configuration recovers the direction best. Only the construction method generalises, while the best prompt framing, read-out location, and model change from one benchmark to the other. Controlling the fitting pairs to isolate the bug-causing change does not improve the direction either — on BigCodeBench a direction fit on such pairs separates them with high accuracy in isolation, yet does not transfer to ranking the benchmark’s own candidate implementations. Overall, the contributions of this paper are threefold: 1. a systematic study of how the method of constructing the direction, the framing of the prompt, and the hidden-state location read from the model affect the accuracy of the captured code correctness direction across four LLMs and two benchmarks. 2. a data generation pipeline that isolates bug-causing changes via controlled mutations and behavior-preserving refactorings to test if directions built from such data, rather than from model-generated failing attempts, carry a higher quality correctness signal. 3. a publicly available replication package containing the data and code to reproduce the study: https://figshare.com/s/8da5228fa8c8fc668f8 I Background This section presents foundational aspects to understand how LLMs represent data internally, how to extract a direction corresponding to a target concept, and how prior work applied this to code correctness. I-A Hidden states locations A decoder-only transformer language model maps a token sequence to hidden states through a stack of L layers [20]. For an input x, it produces a hidden state hi(l)(x)∈ℝdh^(l)_i(x) ^d at every layer l∈0,1,…,Ll∈\0,1,…,L\ and every token position i, where l=0l=0 is the embedding layer and d is the hidden size. These states encode high-level semantic and syntactic properties recoverable with simple probing methods [15]. As a hidden state exists for every token at every layer, it requires deciding which token to read the hidden state from. Two choices are common: reading the last token, a single hidden state that has attended to the entire preceding stimulus, or the response average, the mean of the hidden states over the response tokens [15]. I-B Construction methods Linear probing captures a direction in hidden-state space corresponding to a target concept by contrasting representations of inputs that differ in it [15]. Starting from paired positive and negative stimuli, it takes a hidden-state representation for each at a chosen location (Section˜I-A) and turns the differences into one concept direction v(l)v^(l) per layer. Truthfulness, sentiment, and other abstract concepts are recoverable in this linear form and can be used to monitor model behaviour [14, 21, 13, 12]. Two prominent methods turn contrasting pairs into a direction: (a) Principal component analysis (PCA):the per-pair representation differences at layer l are collected and mean-centered, and v(l)v^(l) is taken as their first principal component (i.e., the direction of largest variance among the contrasts) [22]. Its orientation is arbitrary, so the sign is resolved by a per-layer majority rule over labeled examples, so that higher projections correspond to inputs that exhibit the concept [15]. (b) Mean-difference (mean-diff):the direction is the difference between the positive and negative class means at layer l, v(l)=a¯+(l)−a¯−(l),v^(l)\;=\; a^(l)_+- a^(l)_-, (1) where a¯+(l) a^(l)_+ and a¯−(l) a^(l)_- are the class means. Its orientation is fixed, so no separate sign step is needed. Despite its simplicity, mean-diff has been reported to often recover directions better than PCA [16]. Regardless of how a direction is captured, a new input is scored by projecting its representation onto the direction: the further it points along it, the more it exhibits the concept. I-C Framings We use the term framing for how the input is wrapped into a prompt. Framing shapes which aspects of the model’s internal state the contrast picks Figure˜2 shows three common framings in this line of work: (a) Neutral:The model is shown only the input, with no reference to the concept [11], so any signal must arise from the model’s own unguided processing. This is the most conservative framing. (b) Concept:The stimulus adds a meta-instruction directing the model to consider how much of the concept is present, eliciting its declarative knowledge about that concept [15]. (c) Function:The stimulus instructs the model to produce behaviour that exhibits the concept or its opposite (e.g. to write a correct or an incorrect implementation), contrasting the instruction-conditioned states [15]. I-D Using linear probing to capture code correctness While most linear probing work targets abstract NL concepts, e.g. truthfulness [12, 13], Ribeiro et al. [11] adapted it to capture code correctness, the same concept our work studies. Their contrasting pairs join a task’s canonical solution with a plausible failing attempt: an LLM-generated implementation of the task that fails its test suite. Because such an attempt is generated independently of the canonical solution, it can differ from it in any way — algorithm, code structure, variable naming — and not only in what makes it fail. The authors reported two findings. First, a code correctness direction can be captured and used to distinguish correct from incorrect programs more accurately than the model’s own confidence, whether read intrinsically from token probabilities [23] or reflectively from a verbalised judgement [9]. Second, it is useful for ranking: ordering candidate implementations by their correctness score raises the chance a correct one is selected, matching or exceeding a specialized ranker [24]. However, their results came from a single choice on each axis: the direction was built with PCA, read from the last token, and fit under a neutral framing but evaluated under a concept one. Its accuracy also varied with the data split, so the signal may be sensitive to how it is captured, both in terms of method and data. I Experimental Setup This section describes our experimental setup. We first cover the aspects shared across both RQs (Sections I-A–I-D), and then settings specific to each RQ (Sections I-E and I-F). I-A Fitting, Validation, and Testing Protocol We split tasks into disjoint fitting, validation, and test partitions. The per-layer direction is captured on the fitting partition. Since the most informative layer is not known in advance, the validation partition selects a single layer l⋆l (the one whose direction best separates correct from incorrect programs under the validation framing (Section I-B)) and we report accuracy on the held-out test partition at l⋆l under the matching test framing. A program is scored by projecting its representation at the chosen read-out location (Section I-B) onto the layer’s direction, s(l)(x)=σ(l)⟨h(l)(x),v(l)⟩∥v(l)∥,s^(l)(x)\;=\;σ^(l)\, h^(l)(x),\,v^(l) v^(l) , (2) where σ(l)∈+1,−1σ^(l)∈\+1,-1\ is the per-layer sign: the majority-rule value for PCA (Section I-B), and +1+1 for mean-diff, whose orientation is already fixed. A higher absolute score is intended to indicate a more likely correct program. We use two metrics. Pairwise accuracy is the fraction of same-task correct/incorrect pairs in which the correct program scores higher (a 1-of-2 choice); during validation, we select l⋆l as the layer with the highest pairwise accuracy on the validation partition, breaking ties toward the deepest layer. Selection accuracy (AccValAcc_Val) is the test-time metric: among four candidate completions for a task, the task succeeds when the correct one is selected (a 1-of-4 choice). We report it at test time because it matches the intended use and the setting of prior work [11, 15]. We report selection accuracy under two layer choices: AccValAcc_Val is selection accuracy at l⋆l , the layer chosen on the validation partition without test labels, and is our primary reported number; best-layer accuracy is selection accuracy at the layer maximising accuracy on the test partition, an oracle upper bound isolating direction quality from layer-selection cost. Prior work established that the direction can outperform the model’s own confidence [11], so we do not repeat that comparison. Instead, we focus on how construction and data affect the direction itself. I-B Design Space A configuration pairs a construction method (PCA or mean-diff), a framing (neutral, concept, or function), and a hidden-state location (last token or response average). The construction method asks which notion of separation aligns with correctness, and each method embodies a different trade-off. PCA keeps only the dominant axis of variation among the pair differences: if correctness drives most of the variation between correct and incorrect programs, PCA isolates it and discards the rest as noise, but if off-target properties such as length or formatting dominate, the correctness signal lies along one of the discarded axes and is lost. Mean-diff discards nothing: the difference of the class means retains, in one mixed direction, every property that systematically differs between correct and incorrect programs — correctness along with any incidental difference that accompanies it. Thus, the trade-off is between losing the signal when it is not dominant (PCA) and diluting it with whatever else separates the correct and incorrect classes (mean-diff). Because neither risk can be ruled out in advance, we evaluate both. The framing asks how explicitly, if at all, the LLM is prompted for correctness. The read-out location asks whether a single fully-informed position suffices (last token) or pooling across the response helps (response average). A framing mode specifies two framings: one used when fitting the direction, and one used when validating and testing it (Section I-A); the latter two stages (validating and testing) always share the same framing, so the layer is selected under the framing the direction is scored under. Rather than crossing every fit framing with every evaluation framing, we use six modes, written fit→ : N→ , N→ , C→ , C→ , F→ , and F→ , where N, C, and F denote the neutral, concept, and function framings. The function framing is restricted to fitting, since it pairs a positive instruction with the correct program and a negative one with the incorrect program, so the instruction itself reveals the label and would leak it at validation or test time; it therefore never appears as an evaluation framing. RQ1 varies these three axes with the data fixed to the correct/incorrect pairs of prior work [11]. RQ2 fixes the configuration and varies the data, using pairs we construct instead (Sections I-E and I-F). Neutral Concept Function Task: <task> Code: ```python <code> ``` Consider the amount of correctness in the following code. Task: <task> Code: ```python <code> ``` The amount of correctness in the code is Write a correct/incorrect implementation for the following task. Task: <task> Code: ```python <code> ``` Figure 2: The three framings’ core is a task and candidate program (yellow). Neutral is the core only. Concept adds a meta-instruction (blue) and an answer cue (pink). Function prepends a persona instruction (blue). I-C Models and Benchmarks We use the same four instruction-tuned LLMs as prior work [11], with their short names in bold: Mistral-7B-Instruct-v0.3, Qwen-2.5-Coder-7B-Instruct, OpenCoder-8B-Instruct, and CodeLlama-7B-Instruct. All are open-weights (required to read hidden states) and lie in the 7–8B range, so scale does not confound cross-model comparison. Mistral is the general-purpose model from the original representation engineering work [15], and the other three are code-specialized. We evaluate on the same two benchmarks: HumanEval [2], with 164 self-contained problems over core Python and foundational algorithms, and BigCodeBench [17], with 1,140 tasks that call external libraries such as numpy and pandas. Each task provides a correct solution and an executable test suite, which we use as a proxy for correctness. As a methodological check, we reproduce the single configuration of prior work [11], a PCA direction read from the last-token hidden state fit under a neutral framing and evaluated under a concept one, and confirm reproduction of its published accuracies. I-D Stimulus Construction A stimulus is the prompt from which we collect hidden states: it presents the task and a candidate program to the LLM under one of the three framings of Section I-C; which framing is used is set by the configuration (Section I-B). Figure˜2 shows the three framings on the same task and program. The replication package of prior work [11] assembled the stimulus as a plain concatenated string. Throughout this paper we instead build it structurally, e.g. using chat_template for the neutral framing. I-E RQ1: Data Settings We borrow a significant amount of the data setup used by Ribeiro et al. [11] to isolate the effect of the design choices. Each fitting pair joins the task’s canonical solution with a plausible failing attempt (Section I-D). The data is split into fitting, validation, and test partitions in two ways: In-distribution: the direction is fit, validated, and tested on folds of the same dataset under ten-fold cross-validation. Out-of-distribution: RQ1 additionally fits on two out-of-distribution sources, MBPP+ [18, 19] and a fully LLM-generated naive task set, under nested cross-validation: fitting and validation on four inner folds and ten outer folds. Testing always uses ten outer folds of the target dataset (HumanEval or BigCodeBench). Therefore, the full RQ1’s configuration space is 2×2×3×2×3×2×4=5762× 2× 3× 2× 3× 2× 4=576 configurations, corresponding to method, read-out location, fit framing, validation/test framing, fit source, test dataset, and model, respectively. I-F RQ2: Data Settings RQ2 keeps the configuration fixed and changes the data the direction is fit and evaluated on. Starting from the HumanEval and BigCodeBench tasks, we construct correct/incorrect pairs in four steps: Step 1: Mutant Generation. We introduce a bug into a correct solution with a rule-based mutant generator that applies one of 20 operators, each a small and targeted edit (Table I). TABLE I: The 20 mutation operators used to build the controlled pairs. Code Operator Example (orig. → mut.) Arithmetic & Relational AOR Arithmetic Op. Replace a + b → a - b AOD Arithmetic Op. Delete a + b → a AOI Arithmetic Op. Insert a → a + 1 ROR Relational Op. Replace a == b → a != b BOR Bitwise Op. Replace a | b → a & b NEG Negation x → -x Variables & Constants CR Constant Replace x = 5 → x = 6 VCR Variable to Constant return x → return 0 CVR Constant to Variable return 0 → return x VVR Variable to Variable a = b → a = c CRN Constructor to None Node() → None Control Flow & Logic SD Statement Delete x = 1; y = 2 → y = 2 COR Conditional Op. Replace a and b → a or b COD Conditional Op. Delete a and b → a UOI Unary Op. Insert if x: → if not x: UOD Unary Op. Delete not x → x RC Remove Conditional if a: → if True: RVM Return Value Mutate return x → return None TR True Return return x → return True FR False Return return x → return False The generator parses the program into an Abstract Syntax Tree (AST) with type inference via astroid [25], keeping mutations syntactically valid and applied only to semantically compatible types. For example, it blocks arithmetic mutations (swapping + for -) on string or list operands, which would fail with a trivial TypeError rather than a plausible logical bug; since Step 2 keeps any mutant that fails the test suite, such trivially broken edits would otherwise pass that filter alongside genuine logical faults. This step mutated 1,135 BigCodeBench tasks (20 operators applied; statement deletion (SD) most abundant at ∼31% 31\%) and 143 HumanEval tasks (19 operators applied; constant replacement (CR) most abundant at ∼26.8% 26.8\%), dropping only tasks with no applicable mutant. Step 2: Mutant Validation. We execute every mutant against the benchmark’s native test suite and keep only those that explicitly fail — killed mutants, in mutation-testing terms [26] — discarding semantic equivalents that pass. This yielded 27,928 killed mutants for BigCodeBench and 4,566 for HumanEval. Step 3: Confounding. A model may exploit surface shortcuts, e.g. keying on variable naming or code length as the “bug” signal rather than the semantics. To counter this, we add confounds: structurally refactored versions of a mutant that fail the same way. We prompt Qwen2.5-Coder-32B-Instruct [27] to rewrite each killed mutant with behaviour-preserving edits, giving a distinct version of the same error. Step 4: Confound Validation. The rewrite may introduce a different error or accidentally fix the bug, so we re-run each confound and keep it only if it fails with the same failure fingerprint as its source mutant, discarding any that pass or fail differently. This leaves 9,585 validated confounds for BigCodeBench (593 tasks) and 1,262 for HumanEval (66 tasks). Data Splitting. Mirroring RQ1, we split tasks into 10/10/80 fitting/validation/test folds under ten-fold cross-validation. From the validated pairs, we form two variants of controlled pairs: M-Only, pairing each reference solution with its mutants, and MC, which also adds the confounds. Each variant is evaluated in isolation — fit, validated, and tested on held-out splits of the same pairs — and in transfer — fit and validated on the pairs but tested on the benchmark’s own 1-of-4 selection task from RQ1, the same test its in-distribution directions face. Since a task yields many mutants and confounds, we sample the fitting and validation pairs in two ways: weighted keeps one mutant per task (probability proportional to its operator’s frequency) and, for MC, one uniformly random confound; paired uses every mutant and confound, giving more but uneven pairs. Weighted is the default for the fitting and validation pairs, and the test split of controlled pairs is always sampled weighted; paired is a robustness check (Section˜V). IV RQ1: How do the key design choices involved in capturing a code correctness direction affect its quality and robustness? Tables I and I show the full sweep of results: every valid combination of construction method, read-out location, and framing (Section˜I-B) across four models. Each cell is AccValAcc_Val, the validation-selected accuracy (Section˜I-A); the first row of each table is the configuration used by prior work [11]. The tables show that no single configuration is best across both benchmarks or across LLMs. In-distribution, a single configuration is best across all four models on BigCodeBench (mean-diff, response average, neutral fitting and testing framing), but on HumanEval the best configuration differs by model. We therefore ask how much each choice, on its own or combined with others, changes AccValAcc_Val. We measure this with an analysis of variance (ANOVA), reported in Table˜IV. Each choice is a factor — construction method, read-out location, fitting framing, testing framing, benchmark, and model. ANOVA gives every factor, and every combination of factors, a share of the variance in AccValAcc_Val: its η2η^2. A single factor’s share is its main effect; a combination’s share is an interaction, meaning the factors act together, so neither can be set without regard to the other. Each factor and each interaction is one term of the decomposition; the six factors and all possible interactions give 6363 terms, whose η2η^2 sum to 100%100\%. Table˜IV lists the largest terms. TABLE I: RQ1 configuration sweep on BigCodeBench. Per-model AccValAcc_Val (mean and std-dev (subscript) over folds) for every construction method (pca/mean-diff (md)), read-out location (last token (last)/response average (avg)), fitting framing, and validation=testing framing (neut/conc/func). First row ≈ prior work [11]; directions fit in- or out-of-distribution (MBPP+/synthetic); per-column maxima in bold. All numbers are percentages. in-distribution OOD: MBPP+ OOD: synthetic method loc fit val/test Mistral Qwen CodeLlama OpenCoder Mistral Qwen CodeLlama OpenCoder Mistral Qwen CodeLlama OpenCoder Configuration of prior work [11] pca last neut conc 42.7± 4.5 40.8± 5.8 40.5± 8.5 39.6± 5.1 32.2± 3.6 20.5± 7.6 30.1± 6.8 28.4± 4.3 27.6± 12.2 10.3± 1.9 22.8± 4.1 36.0± 5.8 Full configuration sweep pca last neut neut 38.8± 4.5 34.4± 3.3 38.3± 3.6 39.5± 5.1 23.5± 1.9 22.7± 1.3 20.3± 1.4 19.1± 1.1 32.0± 1.8 22.7± 2.8 26.3± 3.6 24.1± 3.8 pca last conc neut 37.0± 4.1 47.2± 5.4 36.5± 3.3 47.7± 3.6 24.7± 7.3 43.0± 8.3 34.0± 12.7 32.4± 6.6 25.6± 2.1 27.7± 4.2 17.1± 2.3 26.4± 4.6 pca last conc conc 62.6± 6.1 60.1± 3.5 56.2± 3.9 62.6± 2.5 50.9± 8.6 52.4± 2.0 41.3± 7.2 49.1± 5.1 13.7± 1.3 14.3± 0.6 18.7± 2.7 32.9± 1.9 pca last func neut 38.3± 5.9 35.5± 3.7 38.1± 3.7 38.8± 5.9 25.2± 1.7 20.3± 1.2 17.5± 1.0 19.4± 1.2 26.8± 1.4 20.7± 2.3 30.5± 8.5 30.2± 3.9 pca last func conc 42.7± 5.5 39.7± 7.8 36.1± 9.0 36.7± 5.5 30.5± 2.6 26.4± 9.6 30.3± 7.8 32.3± 7.1 16.3± 4.3 9.6± 1.5 13.8± 3.8 17.0± 2.3 pca avg neut neut 64.5± 5.4 65.7± 11.5 63.4± 7.8 61.8± 6.3 34.6± 12.7 45.8± 13.8 32.9± 16.2 49.5± 10.4 25.1± 3.5 21.2± 5.6 22.3± 3.9 32.2± 8.9 pca avg neut conc 49.2± 6.8 40.9± 6.0 42.4± 4.8 48.8± 8.0 49.5± 2.3 41.2± 2.5 32.1± 6.6 29.4± 5.5 23.0± 7.3 24.2± 10.9 20.2± 4.7 25.7± 3.0 pca avg conc neut 41.3± 7.5 52.0± 4.4 41.3± 5.9 56.9± 4.4 44.5± 8.4 49.3± 10.4 44.9± 16.3 41.0± 18.3 26.4± 1.2 27.0± 3.5 28.0± 11.5 29.3± 6.7 pca avg conc conc 61.2± 5.1 59.9± 3.9 58.7± 6.7 63.1± 1.8 57.0± 7.1 54.2± 7.1 44.7± 5.4 39.7± 8.8 13.0± 0.9 12.9± 1.1 16.7± 6.0 23.6± 1.9 pca avg func neut 61.4± 5.3 66.0± 2.6 63.3± 5.9 65.2± 6.2 35.5± 14.0 38.3± 11.2 31.2± 11.6 53.8± 12.7 33.3± 3.7 24.2± 5.5 22.0± 2.9 29.5± 7.3 pca avg func conc 26.0± 5.3 41.8± 6.1 36.9± 6.5 48.2± 4.6 27.1± 10.1 38.9± 7.2 26.9± 8.6 27.1± 7.2 10.7± 2.2 13.7± 2.7 14.6± 4.1 17.2± 2.9 md last neut neut 48.5± 3.9 54.1± 10.0 48.6± 6.1 48.6± 7.2 23.1± 1.8 23.2± 1.4 20.4± 1.5 19.1± 1.2 31.5± 1.1 24.3± 3.1 25.5± 4.4 22.9± 2.2 md last neut conc 50.2± 3.6 58.4± 8.5 51.7± 8.2 49.6± 5.4 32.5± 2.8 19.9± 8.3 27.8± 6.9 28.6± 7.3 27.4± 7.5 11.0± 4.4 14.1± 3.9 28.9± 4.9 md last conc neut 37.3± 4.1 54.8± 6.1 48.0± 7.3 50.6± 3.8 22.0± 6.2 36.1± 10.7 38.0± 7.7 28.0± 8.2 27.5± 3.5 30.1± 4.5 20.2± 6.2 26.1± 5.1 md last conc conc 66.0± 6.3 68.7± 4.8 63.0± 3.1 65.1± 2.0 50.7± 12.3 52.1± 2.0 43.9± 2.3 41.2± 8.3 14.9± 2.0 14.1± 0.9 18.4± 3.2 32.8± 2.0 md last func neut 46.1± 4.9 49.0± 7.5 47.6± 4.3 47.6± 7.6 25.6± 1.8 20.7± 1.2 17.7± 0.9 19.7± 1.4 27.8± 2.2 19.4± 1.7 24.6± 4.3 27.6± 4.3 md last func conc 39.7± 8.2 46.1± 10.2 48.4± 6.9 54.3± 2.6 31.6± 3.2 28.6± 9.9 29.6± 9.4 31.1± 7.4 14.3± 3.4 9.5± 1.2 9.5± 0.9 17.3± 2.1 md avg neut neut 73.5± 4.9 77.4± 2.6 71.2± 4.2 74.8± 5.1 36.3± 2.8 52.2± 7.0 41.3± 7.7 41.1± 4.3 24.6± 4.2 16.3± 3.9 18.7± 2.3 28.4± 3.8 md avg neut conc 50.4± 6.7 49.8± 7.8 57.9± 8.3 50.6± 8.3 29.8± 5.3 45.6± 4.2 30.2± 3.1 31.0± 2.1 20.6± 9.4 15.8± 1.7 20.9± 10.8 28.3± 3.6 md avg conc neut 50.7± 7.7 54.0± 4.2 62.1± 7.7 56.5± 6.6 44.5± 10.9 42.3± 7.0 57.9± 6.9 47.0± 5.3 28.1± 3.8 29.2± 4.1 31.1± 9.6 28.9± 7.1 md avg conc conc 64.6± 4.8 66.8± 4.5 64.7± 3.8 67.0± 1.9 60.0± 4.8 51.0± 11.1 42.0± 3.9 34.2± 3.3 13.4± 1.2 13.1± 1.2 12.8± 3.6 22.7± 2.7 md avg func neut 68.9± 3.8 72.4± 4.1 69.6± 3.9 70.6± 4.5 29.0± 11.7 40.1± 4.0 35.6± 5.9 50.9± 13.8 30.8± 1.9 21.5± 6.1 21.7± 4.3 31.0± 5.8 md avg func conc 46.0± 4.4 46.7± 5.9 57.4± 7.0 55.9± 8.0 28.5± 4.6 39.0± 12.0 32.6± 6.3 34.6± 7.8 12.7± 2.3 13.8± 2.7 11.3± 1.1 16.0± 0.8 TABLE I: RQ1 configuration sweep on HumanEval; columns and conventions as in Table˜I. All numbers are percentages. in-distribution OOD: MBPP+ OOD: synthetic method loc fit val/test Mistral Qwen CodeLlama OpenCoder Mistral Qwen CodeLlama OpenCoder Mistral Qwen CodeLlama OpenCoder Configuration of prior work [11] pca last neut conc 32.3± 3.8 56.0± 14.3 34.5± 9.1 42.2± 8.8 30.7± 3.2 27.3± 7.9 33.3± 10.3 22.9± 4.3 34.2± 6.0 53.4± 4.9 36.6± 11.0 32.3± 17.3 Full configuration sweep pca last neut neut 64.0± 4.0 68.9± 8.0 66.5± 4.7 65.5± 6.8 54.7± 4.5 78.1± 3.0 67.6± 3.1 71.0± 2.7 64.4± 5.8 57.3± 6.9 64.5± 4.1 69.7± 3.8 pca last conc neut 43.6± 10.8 70.8± 7.8 39.9± 12.6 59.5± 12.9 25.3± 7.9 29.7± 8.4 29.7± 11.2 37.8± 6.2 34.3± 7.9 31.9± 17.5 52.7± 6.7 60.8± 15.5 pca last conc conc 33.5± 5.2 56.4± 9.3 42.7± 9.3 52.3± 6.6 34.5± 10.4 31.9± 15.8 30.1± 7.6 32.5± 14.5 33.0± 3.2 62.4± 1.9 35.8± 4.2 57.3± 2.4 pca last func neut 63.5± 3.3 69.0± 6.1 66.0± 3.7 66.0± 6.2 59.3± 5.5 79.0± 3.6 63.3± 4.2 71.3± 2.4 54.2± 10.6 68.8± 5.1 56.0± 17.0 26.6± 24.7 pca last func conc 30.5± 3.0 55.2± 13.9 33.0± 7.0 40.4± 9.2 32.0± 2.4 27.9± 7.8 32.2± 7.2 33.7± 8.4 30.7± 4.0 61.8± 3.6 31.0± 5.5 40.0± 8.4 pca avg neut neut 35.6± 5.5 42.1± 12.7 36.4± 6.7 51.6± 9.3 38.3± 11.9 46.5± 8.0 41.8± 6.8 53.7± 6.8 32.6± 8.9 30.1± 11.3 33.1± 9.8 29.3± 15.1 pca avg neut conc 34.5± 8.3 49.3± 9.9 30.0± 4.7 50.2± 11.1 28.2± 4.7 41.5± 11.9 33.3± 4.2 33.0± 8.7 31.6± 10.0 50.2± 11.9 32.3± 8.2 36.4± 16.7 pca avg conc neut 32.4± 9.7 49.5± 8.7 40.7± 9.0 49.4± 7.5 26.8± 16.0 40.5± 4.2 40.8± 4.3 51.8± 8.5 34.1± 3.5 29.6± 4.6 28.4± 3.4 35.2± 5.8 pca avg conc conc 34.4± 3.4 58.8± 8.3 35.5± 10.0 42.7± 4.7 30.5± 7.6 29.8± 19.6 33.2± 11.2 34.6± 16.6 33.2± 3.2 63.6± 2.1 30.7± 3.4 47.4± 3.4 pca avg func neut 44.3± 8.9 59.3± 14.4 44.7± 11.0 62.8± 6.7 41.8± 10.1 64.9± 6.5 52.5± 11.8 56.1± 7.2 35.1± 2.8 40.7± 9.0 36.7± 3.3 27.9± 9.8 pca avg func conc 31.8± 5.4 60.3± 8.5 36.7± 5.7 47.9± 14.1 34.2± 6.8 58.8± 4.7 30.7± 8.8 34.9± 10.7 31.2± 2.7 66.9± 3.1 25.3± 7.7 42.0± 7.6 md last neut neut 64.6± 3.0 74.5± 9.2 68.0± 3.3 65.4± 6.1 55.1± 3.6 79.1± 2.9 67.2± 3.2 71.0± 2.7 60.9± 8.3 59.5± 9.3 65.1± 3.6 70.5± 4.2 md last neut conc 34.1± 6.6 67.9± 5.8 36.4± 5.6 41.2± 10.2 31.2± 4.1 34.0± 9.6 31.9± 9.3 23.7± 4.5 35.7± 4.6 54.4± 5.8 28.5± 7.1 49.0± 3.9 md last conc neut 45.5± 12.7 79.4± 10.5 50.7± 12.5 58.5± 12.0 29.8± 9.1 47.4± 10.8 45.1± 12.5 45.5± 14.2 22.6± 8.9 23.0± 5.5 44.4± 19.3 60.6± 14.7 md last conc conc 39.4± 6.3 61.3± 8.2 49.4± 6.0 54.0± 4.5 44.9± 4.2 51.4± 3.8 40.8± 9.6 37.0± 16.1 33.1± 3.0 62.5± 2.0 35.5± 4.7 57.5± 2.5 md last func neut 64.7± 4.5 68.7± 8.3 69.8± 1.6 65.0± 5.2 59.9± 5.0 79.1± 3.2 63.0± 4.0 71.3± 2.4 53.6± 5.6 71.7± 3.1 63.8± 3.1 36.3± 25.7 md last func conc 32.4± 7.1 59.8± 10.6 35.4± 6.0 41.8± 7.6 32.6± 3.6 30.7± 6.7 38.9± 4.9 32.1± 8.5 31.3± 3.3 62.9± 2.7 24.5± 3.4 40.0± 5.9 md avg neut neut 49.8± 5.5 58.2± 9.7 51.6± 7.3 63.7± 8.8 32.3± 7.8 50.4± 4.3 49.5± 10.2 47.0± 3.3 35.1± 5.8 33.4± 11.4 33.3± 4.2 29.0± 13.9 md avg neut conc 29.9± 3.3 68.4± 13.4 32.1± 8.0 49.3± 10.0 26.9± 6.5 32.6± 12.6 37.9± 8.0 33.2± 5.8 34.8± 4.4 57.2± 6.4 32.6± 6.5 25.3± 14.5 md avg conc neut 34.5± 7.9 56.8± 5.1 40.9± 7.4 49.3± 10.8 36.4± 11.6 42.6± 3.5 41.9± 8.4 46.5± 15.5 33.2± 5.5 27.0± 4.0 25.3± 5.3 33.8± 6.3 md avg conc conc 45.0± 9.0 63.6± 11.4 47.8± 3.8 54.3± 8.5 43.6± 8.6 28.4± 12.0 47.5± 4.5 26.5± 4.7 32.7± 3.7 63.7± 2.3 30.9± 3.9 47.1± 3.3 md avg func neut 48.8± 5.7 64.0± 12.5 49.8± 6.0 66.8± 8.1 38.2± 9.0 71.5± 4.8 48.2± 10.6 58.5± 9.7 38.0± 5.4 45.3± 14.8 35.9± 4.0 36.4± 17.1 md avg func conc 30.7± 5.8 61.2± 8.6 35.0± 8.6 54.0± 10.1 29.8± 5.0 46.0± 11.6 35.7± 6.6 37.7± 11.2 32.1± 3.1 66.9± 3.0 24.1± 4.7 45.0± 3.8 TABLE IV: ANOVA for RQ1. η2η^2 = variance share in AccValAcc_Val from a factor (main effect) or an interaction. Panels (1)–(4) follow Sections IV-1–IV-4 (1) General View η2η^2 main effects 02. model identity 14% 06. testing framing (test) 07% 07. construction method 07% 22. benchmark <1%<1\% 24. read-out location (loc) <1%<1\% 28. fitting framing (fit) <1%<1\% interactions 01. fit × test framing 15% 03. loc × benchmark 12% 04. loc × test framing × benchmark 11% 05. benchmark × model 07% any term involving benchmark 47% BigCodeBench HumanEval η2η^2 best η2η^2 best (2) Within each benchmark read-out location 20% avg 06% last construction method 14% md 03% md fitting framing 05% conc 01% func testing framing <1%<1\% — 20% neut model identity 11% agree 51% Qwen fit × test framing 26% 07% loc × test framing 15% 08% (3) Out-of-distribution fitting mean acc. in-distribution 52% 50% MBPP+ 35% 43% synthetic 22% 42% (4) Construction, data, and model construction 16% 42% fitting data 75% 18% model 09% 40% IV-1 General View We take the broadest view first: we pool both benchmarks (BigCodeBench and HumanEval) and rank the choices by how much of the variance in AccValAcc_Val each one carries. This view is restricted to in-distribution fitting; the fitting source is examined on its own later (Table˜IV, panel 3). The restriction is needed because in-distribution does not name a single fitting source: it is BigCodeBench data when we test on BigCodeBench and HumanEval data when we test on HumanEval, whereas the out-of-distribution sources — MBPP+ and the synthetic set — are the same whichever benchmark we test on. That is, the benchmark and the in-distribution source change together and cannot be told apart. We find that the resulting decomposition (Table˜IV, panel 1) spreads the variance across many terms rather than concentrating it in one. The two largest shares, 15%15\% and 14%14\%, are (1) the combination of fitting and testing framing, and (2) the model. The benchmark on its own is negligible — under 1%1\% — but it frequently appears together with other interaction terms: with the read-out location (12%12\%), with the location and testing framing together (11%11\%), and with the model (7%7\%). Summed together, the terms involving the benchmark account for about 47%47\% of the variance (final row in Table˜IV, panel 1). So the benchmark alone does not set the accuracy level; it sets which other design choices matter. The read-out location is the clearest example: on its own it explains under 1%1\%, but paired with the benchmark it explains 12%12\%, because the location that performs best on one benchmark is worse on the other (in panel 2 its best level flips between the response average and the last token). This pattern sets up the next step of the analysis. If the benchmark decides which level of a choice works best, then a ranking computed over the pooled benchmarks averages away exactly that information: a choice can carry little variance in the pool not because it is unimportant, but because its opposite effects on the two benchmarks cancel, as they do for the read-out location. Therefore, the pooled view can say that the benchmark shapes the other choices, but not which setting to prefer on a given benchmark; for that, we next examine each benchmark on its own (Table˜IV, panel 2). IV-2 Within each benchmark Examined on its own, each benchmark ranks the choices differently (Table˜IV, panel 2). On BigCodeBench the largest share is not a single choice but the fitting and testing framing acting together (26%26\%), followed by the read-out location (20%20\%) and that same location combined with the testing framing (15%15\%). The location matters, but it cannot be set on its own: the framing it is read under changes its effect. Concept fitting illustrates this: on BigCodeBench, a mean-diff direction fit under the concept framing and read at the last token scores 6363–69%69\% across the four models when the testing framing is also concept, but 3737–55%55\% under a neutral one (Table˜I). Construction method is the exception, the one choice that behaves the same way whatever the rest is set to. It is a main effect with no large interaction beside it (14%14\% on BigCodeBench, 3%3\% on HumanEval), and its better level is mean-diff on both benchmarks; it is the only construction choice whose preferred setting never reverses. Every other choice depends on the benchmark, and the read-out location is the clearest case. On BigCodeBench the response average wins: a neutral mean-diff direction reaches 7171–77%77\% across the four models when averaged over the response, against 4848–54%54\% at the last token (Table˜I). On HumanEval the last token wins, 6565–75%75\% against 5050–64%64\% for the same direction (Table˜I). These two opposite preferences are what cancelled in the pooled view — averaging over the benchmarks left the location under 1%1\% in panel 1 — and they are why its best level flips between the two benchmarks in panel 2. The models follow the same benchmark-dependent pattern. On BigCodeBench they agree: model identity accounts for only 11%11\% of the variance, and the best configuration lands within a few points across the four (panel 2). On HumanEval they disagree sharply: model identity accounts for 51%51\%, the largest single share on either benchmark, and the best per-model configuration ranges from 42%42\% (Mistral) to 62%62\% (Qwen) (Table˜I). A further 20%20\% on HumanEval is the testing framing on its own, which favours the neutral prompt (panel 2). On HumanEval, a configuration that is best for one model need not be best for another. IV-3 Out-of-distribution fitting We now return to the factor held out of the general view (Section˜IV-1): the source of the fitting data. So far, every direction was fit on its own benchmark’s fitting data. Now, we fit it on data from MBPP+ or the synthetic set, while still testing on the same benchmark (the right two blocks of Table˜I and Table˜I). Panel 3 of Table˜IV reports the mean AccValAcc_Val for each source. In-distribution fitting is best on both benchmarks, but both decrease when fitting out-of-distribution. On HumanEval it is a small decrease: mean accuracy goes from 50%50\% to 43%43\% on MBPP+ and 42%42\% on the synthetic set, a decrease of 7 and 8 points, respectively. On BigCodeBench the decrease is larger: from 52%52\% to 35%35\% on MBPP+ and to 22%22\% on the synthetic set, a decrease of 17 and 30 points, respectively. The fitting source therefore matters on both benchmarks, but considerably more on BigCodeBench than on HumanEval. At 22%22\%, the synthetic-fit mean on BigCodeBench has dropped to the 25%25\% chance level of the 1-of-4 selection: a poorly matched fitting source does not merely weaken the correctness signal but can reduce it to chance. IV-4 Construction, data, and model The decomposition so far has more terms than can be compared across the two benchmarks at a glance. Producing a direction takes three different components, and every factor in our work can be attributed to one of them: (1) how the direction is constructed: the method, read-out location, and framing; (2) what data it is fit on: in-distribution and out-of-distribution; (3) which model it is read from: 4 LLMs which are neither a construction choice nor part of the data. These three groups comprise everything, and panel 4 of Table˜IV reports them per benchmark as before. On BigCodeBench the fitting data carries 75%75\% of the variance, construction 16%16\%, and the model 9%9\%. On HumanEval the order is different: construction carries 42%42\%, the model 40%40\%, and the fitting data 18%18\%. The kind of choice that carries the most variance is therefore not the same on the two benchmarks: on BigCodeBench it is the data the direction is fit on, and on HumanEval it is how the direction is built and which model it is read from. takeawaybox There is no single best configuration for capturing a code correctness direction. Only the construction method generalises: mean-diff beats PCA. Read-out location, framing, and model are not consistent across benchmarks, so which kind of choice matters most is benchmark-dependent: on BigCodeBench the fitting-data source accounts for most of the variance (75%75\%), while on HumanEval it splits between construction (42%42\%) and model (40%40\%). V RQ2: Does controlling for differences between correct/incorrect programs improve the quality of the correctness direction? Table˜V reports the accuracy of correctness directions fit on controlled pairs: pairs whose incorrect member is constructed from the correct one rather than drawn from a plausible failing attempt (Section˜I-D). It covers both variants on both benchmarks — M-Only, whose incorrect member is a single-fault mutation of the correct solution, and MC, which adds a behaviour-preserving rewrite on top of that fault (Section˜I-F). Its upper block is an aggregated view of RQ1’s results on the same test sets and differs from the lower blocks only in the fitting source, not the test set. Each lower block fits on one benchmark’s controlled pairs and its last column tests on a held-out split of that same source. Each cell is AccValAcc_Val with the best-layer accuracy in parentheses (Section˜I-A). By default, the layer is selected on a held-out split of the fitting pairs, while Section˜V-6 also reports selecting it on a held-out split of the test benchmark, as RQ1 does in-distribution. Recall that RQ1 found mean-diff to generally give the best directions across both benchmarks, with no single best read-out location, framing, or model (Section˜IV). Therefore, every direction in Table˜V is built with mean-diff and averaged over the other choices. As a check on how the direction is built, Table˜VI repeats the two same-benchmark fits with PCA and with paired sampling. We report M-Only in detail, then the MC variant to test how adding controlled rewrites affects the results (Section˜V-7). TABLE V: RQ2 transfer: mean-diff direction fit on a benchmark’s controlled pairs (M-Only/MC), test on BigCodeBench, HumanEval, and held-out split of those pairs. Cells are AccValAcc_Val (best layer in parentheses), averaged over read-out locations, framings, and models. Top block is RQ1’s mean-diff on the same test sets, differs only in fitting source. Dashes mark conditions not run; † fits on one benchmark, tests on the other. tested on fit source BigCodeBench HumanEval held-out RQ1 sources in-distribution 56.7 (61.6) 52.8 (61.7) — MBPP+ 35.2 (49.2) 44.4 (57.7) — synthetic 21.5 (40.5) 42.6 (53.3) — fit on BigCodeBench controlled pairs M-Only 19.6 (36.8) 29.8 (43.1)† 83.3 (86.4) MC 19.0 (36.7) 30.0 (43.0)† 81.7 (84.3) fit on HumanEval controlled pairs M-Only 22.2 (38.9)† 47.6 (57.3) 71.6 (78.9) MC 21.3 (37.1)† 48.5 (57.9) 71.1 (78.5) TABLE VI: RQ2 robustness (M-Only). AccValAcc_Val for a direction fit on a benchmark’s controlled pairs, tested in isolation (a held-out split of those pairs) and in transfer (the benchmark), across construction method and sampling. Isolation stays high and transfer low throughout, so neither accounts for the RQ1 gap; paired sampling separates held-out pairs at least as well yet transfers no better. MC behaves the same (Table˜V). BigCodeBench HumanEval method sampling isol. transf. isol. transf. mean-diff weighted 83.3 19.6 71.6 47.6 mean-diff paired 85.9 19.1 78.4 48.0 PCA weighted 81.4 20.0 65.1 46.1 PCA paired 83.2 19.7 73.0 44.7 V-1 M-Only pairs are separable in isolation Fit, validated, and tested on a held-out split of the same controlled pairs, the M-Only direction reaches 83.3%83.3\% on BigCodeBench and 71.6%71.6\% on HumanEval (86.4%86.4\% and 78.9%78.9\% at the best layer). Separation this high on unseen pairs means the pairs carry a consistent signal that is learnable: had the mutations produced malformed or degenerate programs, a direction fit on one split of the pairs could not separate another. For context, these values even sit above each benchmark’s own in-distribution fit (56.7%56.7\% and 52.8%52.8\%), although the two settings answer different questions — one separates a solution from its mutants, the other ranks the benchmark’s candidate implementations. Still, the held-out accuracy is lower on HumanEval than on BigCodeBench. This may reflect the smaller pool of HumanEval mutants (4,5664,566 against 27,92827,928 from BigCodeBench). Whether this in-isolation signal is the correctness direction, and whether it carries over in transfer to the benchmarks, is the core question for the rest of this section. V-2 Testing on BigCodeBench We now change only the test set: the direction is again fit and validated on BigCodeBench’s M-Only pairs, but instead of scoring held-out pairs of the same construction, it faces BigCodeBench’s own 1-of-4 selection task over candidate implementations, the same test RQ1’s directions face. There, the accuracy reaches 19.6%19.6\%, against 56.7%56.7\% for RQ1’s in-distribution fit on the same BigCodeBench tasks — a decrease of 37.137.1 points. The M-Only fit also sits below every RQ1 source, including MBPP+ (35.2%35.2\%) and the synthetic set (21.5%21.5\%), neither of which shares the BigCodeBench tasks that the controlled pairs keep. Since these pairs are highly separable in isolation (Section˜V-1), the gap to the in-distribution fit is a transfer failure: the signal that tells a solution from its mutation does not carry over to ranking BigCodeBench’s plausible failing attempts. V-3 Testing on HumanEval Fit and validated on HumanEval’s M-Only pairs and tested on HumanEval, the accuracy reaches 47.6%47.6\%, against 52.8%52.8\% for RQ1’s in-distribution fit on HumanEval — a decrease of 5.25.2 points, far smaller than the 37.137.1-point decrease on BigCodeBench. As such, on HumanEval, isolating the bug-causing change leaves the direction closer to the in-distribution fit, while on BigCodeBench the equivalent isolation lowers accuracy by more than half. This split by benchmark follows the pattern of RQ1, where the effect of each construction choice also depended on the benchmark (Section˜IV). V-4 Crossing benchmarks Fitting on one benchmark’s controlled pairs and testing on the other (the daggered cells) gives low accuracy in both directions, but these change the benchmark between fitting and testing and so do not isolate the fault’s effect. The two crossings are not symmetric: fitting on BigCodeBench and testing on HumanEval (29.8%29.8\%) does somewhat better than the reverse (22.2%22.2\%). Were the gap purely a format mismatch between benchmarks, we might expect the two crossings to be closer. The asymmetry may instead reflect differences in task complexity: the higher difficulty of BigCodeBench enables a higher-quality direction that then transfers better to HumanEval than the reverse. V-5 Direction quality On BigCodeBench, the M-Only fit’s validation-selected and best-layer accuracies differ widely (19.6%19.6\% and 36.8%36.8\%; a 17.217.2-point gap), far more than for the in-distribution fit (56.7%56.7\% and 61.6%61.6\%; a 4.94.9-point gap). The decrease is not merely a matter of poor layer selection: even at the best layer, the M-Only direction (36.8%36.8\%) is 24.824.8 points below the in-distribution fit (61.6%61.6\%), so the direction itself is worse, not merely read at a suboptimal layer. On HumanEval, no such gap appears: at the best layer the M-Only direction (57.3%57.3\%) is only 4.44.4 points below the in-distribution fit (61.7%61.7\%). The weaker direction is therefore specific to BigCodeBench. V-6 Selecting the layer on the benchmark The wide 17.217.2-point gap between the M-Only fit’s validation-selected and best-layer accuracies on BigCodeBench reflects a second cost, this time from layer selection itself: the layer that best separates the controlled pairs need not be the layer that best ranks the benchmark’s candidates. We quantify this cost by selecting the layer on a held-out split of the test benchmark — as RQ1’s in-distribution fits do — rather than on the controlled pairs. Doing so raises the BigCodeBench M-Only fit from 19.6%19.6\% to 32.9%32.9\%, most of the way to its 36.8%36.8\% oracle: about 1313 of the 17.217.2-point gap is a layer-selection mismatch between the controlled pairs and BigCodeBench, the rest a genuinely weaker direction. On HumanEval, the same swap barely moves the M-Only fit (47.6%47.6\% to 48.6%48.6\%): validating on HumanEval’s controlled pairs already selects essentially the same layer as validating on the benchmark itself, so there is no mismatch to recover, and the added cost is again specific to BigCodeBench. V-7 Adding controlled confounds The MC variant applies behaviour-preserving rewrites, e.g. variable renaming, so that the two implementations differ in surface form while the fault stays fixed (Section˜I-F). Across every measure, MC tracks M-Only. It is comparably separable in isolation (81.7%81.7\% on BigCodeBench and 71.1%71.1\% on HumanEval, against 83.3%83.3\% and 71.6%71.6\%), its transfer accuracy is just as low (19.0%19.0\% on BigCodeBench and 48.5%48.5\% on HumanEval, against 19.6%19.6\% and 47.6%47.6\%), and it benefits the same way from selecting the layer on the benchmark (19.0%19.0\% to 32.7%32.7\% on BigCodeBench). Therefore, adding controlled surface variation neither closes the BigCodeBench gap to the in-distribution fit nor disturbs the HumanEval result: the captured direction does not seem to depend on these surface features. V-8 Robustness to construction and sampling The gap to RQ1’s in-distribution fit is not an artefact of how the direction is built. Table˜VI repeats each same-benchmark fit with PCA in place of mean-diff and with paired in place of weighted sampling, reporting both isolation and transfer. In transfer the accuracy stays within a narrow band on each benchmark — roughly 1919–20%20\% on BigCodeBench and 4545–49%49\% on HumanEval across all four method–sampling combinations (M-Only shown; MC is comparable, Table˜V). In isolation every combination stays highly separable, and paired sampling, which fits on every available pair rather than one per task, separates the held-out pairs better than weighted sampling (M-Only 85.9%85.9\% against 83.3%83.3\% on BigCodeBench, 78.4%78.4\% against 71.6%71.6\% on HumanEval). That the larger, better-separated paired fitting set still transfers no better reinforces that the in-isolation signal does not lead to a more capable correctness direction (Section˜V-1). takeawaybox [frametitle=RQ2: Key takeaway] Fitting on program pairs that differ only by the bug-causing change yields a direction that separates such pairs well, yet ranks the benchmarks’ candidate implementations worse than RQ1’s in-distribution fit — slightly worse on HumanEval, substantially worse on BigCodeBench. On BigCodeBench, the M-Only fit reaches 19.6%19.6\%, against 56.7%56.7\% on the same tasks; on HumanEval it reaches 47.6%47.6\%, against 52.8%52.8\%, a much smaller decrease. MC barely changes results (19.0%19.0\% and 48.5%48.5\%), and construction method and sampling do not as well (Table˜VI). In isolation M-Only is separable (83.3%83.3\% and 71.6%71.6\%, MC comparable), so the decrease points to a property of the captured direction rather than malformed pairs. VI Discussion VI-A The nature of the captured direction The captured code correctness direction is not a single property of a model: its accuracy, and which configuration recovers it best, depend on how the direction is constructed and what it is contrasted against. RQ1 varies the construction: one choice generalises across both benchmarks — mean-diff beats PCA — but the rest do not, and which kind of choice matters most is itself decided by the benchmark (Section˜IV). RQ2 varies the contrast: a direction fit on a benchmark’s controlled pairs separates a held-out split of them well (83.3%83.3\% on BigCodeBench and 71.6%71.6\% on HumanEval, higher still under paired sampling), yet on BigCodeBench that separability does not carry over to ranking the benchmark’s own plausible failing attempts (19.6%19.6\%, against 56.7%56.7\% for the in-distribution fit). Telling a program from its own single-fault mutation and judging whether independent candidates are correct are thus not the same property. Paired sampling makes this clearer: fitting on every pair rather than one per task raises separability but leaves transfer unchanged. This qualifies the broad reading of internal “truth” or “correctness” directions [12, 13, 15]: their identity and strength are properties of the configuration and contrast set, not of the model alone. VI-B Controlling the fitting data We expected that removing the incidental differences between a correct program and a plausible failing attempt would sharpen the direction, leaving only the fault. Our results do not bear this out. Isolating the bug-causing change does not improve transfer on either benchmark, and on BigCodeBench it lowers it substantially: the M-Only fit reaches 19.6%19.6\% against 56.7%56.7\% for the in-distribution fit on the same tasks, below even the out-of-distribution sources that share none of those tasks (MBPP+ 35.2%35.2\%, synthetic 21.5%21.5\%). On HumanEval the same isolation costs only 5.25.2 points (47.6%47.6\% against 52.8%52.8\%); as in RQ1, the benchmark sets the size of the effect. Part of the BigCodeBench gap is a layer-selection mismatch — selecting the layer on the benchmark recovers about 1313 of the 17.217.2-point gap — but even at the oracle layer the mutation direction stays 24.824.8 points below it, so a genuinely weaker direction remains. We read the BigCodeBench result as a mismatch between the contrast the direction is fit on and the programs it later scores. Both controlled variants build the incorrect member by perturbing the correct solution — M-Only seeds a single fault, MC adds behaviour-preserving rewrites — whereas a benchmark’s plausible failing attempts are independent implementations, free to differ in algorithm and structure, not only at the fault. That MC leaves BigCodeBench transfer unchanged (19.0%19.0\%) indicates the missing ingredient is not surface variety but this difference in kind: a direction tuned to separate a solution from a perturbed copy of itself is not thereby tuned to judge an independent attempt. The high separability (83.3%83.3\%) rules out malformed mutations; whether the injected faults resemble the mistakes models make in practice is taken up in Section˜VII. VI-C Practical use of the technique The code correctness signal is usable, but should be tuned per setting rather than applied as a fixed recipe. First, construct the direction with mean-diff: it is the one choice whose better setting never reverses, generally beating PCA on both benchmarks (Section˜IV). Second, do not fix the read-out location or framing in advance; the best location reverses between HumanEval and BigCodeBench, so select it per model and benchmark on a validation split. The gap between validation-selected and best-layer accuracy is itself a cost to report, not hide: on BigCodeBench it is wide for the mutation fit, and quoting only the oracle layer overstates what the probe achieves. More generally, a single headline accuracy — including prior work’s 4141–63%63\% range [11] — reflects one configuration out of many, and our sweep shows that accuracy varies widely across them. That is, reporting the validation-selected accuracy of the whole sweep describes what the technique achieves without tying the claim to one configuration. The same variation explains the value of approaches that do not fix the read-out at all: AutoProbe [28] learns which hidden states to read per model instead of committing to a pre-selected layer and token position. Our results quantify the accuracy decrease when that choice is made poorly. VII Threats to Validity Construct Validity. Using unit tests as a proxy for correctness may be incomplete and does not capture non-functional aspects, e.g., performance. Moreover, high probing accuracy alone is weak evidence that the captured direction encodes correctness and not a correlated feature [29]: a sufficiently expressive probe can score well by memorising the labels rather than by reading them from the hidden states [30]; probes can score highly on a property the model does not use [31], and prove unreliable for concept removal and detection [32, 33]. To mitigate this, our probes are single linear directions, leaving them little capacity to memorise, and we do not rely on a single configuration: we vary the construction method, framing, and read-out location, select the layer on a validation split, and test on two benchmarks with cross-validation. RQ2 further controls the fitting data with mutations that isolate the fault and behaviour-preserving rewrites that vary only surface form, checking whether the direction tracks correctness and not incidental differences between programs. Internal Validity. RQ2 showed that a direction fit on mutations did not transfer to the benchmark’s plausible failing attempts, which could reflect the mutation process and not fault isolation alone. Our mutation pipeline only checks types, not whether an edit resembles a mistake a developer or a model would plausibly make, so some mutations may be unrealistic. Nonetheless, we use mutations because isolating the bug-causing change requires pairs that differ only in a single, localised fault, for which mutation is the standard way to construct [26]. More broadly, injected faults need not resemble real ones and detectors trained on them transfer poorly [34, 35, 36], and models complete code containing them less reliably [37]. The held-out mutant positive control reduces this concern: the same direction separates held-out mutations, so the transfer result is not an artefact of malformed or unlearnable mutations. Moreover, the confounds are generated by Qwen2.5-Coder-32B-Instruct, which shares a model family with one probed model (Qwen2.5-Coder-7B-Instruct), so rewrites in a familiar style could in principle favour that model. The MC variant adds these rewritten mutants to the M-Only fitting pairs while the test set stays fixed, so comparing the two shows how much the rewrites change the result. Averaged over models, every measure we report changes little when they are added (Section˜V-7); since an average could hide a model-specific effect, Table˜VII in the appendix repeats the comparison per model: no model’s accuracy moves by more than 3.43.4 points on any measure, and the probed Qwen model moves slightly against the rewrites on every such measure. Thus, any family-specific advantage is small. Incorrect programs also differ in origin, pre-generated in RQ1 and mutations of the canonical solution in RQ2; studying both exposes how this source shapes the direction. External Validity. We study four 7–8B-parameter LLMs on two Python benchmarks, covering in-distribution and out-of-distribution stimuli. The observed effects may not hold for larger or smaller models, other architectures, or other programming languages, and our single-function tasks do not cover repository-level settings such as SWE-bench [3]. To mitigate this, we include both general and code models, benchmarks of differing complexity, and out-of-distribution data. Whether a single correctness direction generalizes across data is debated: some report a near-universal truthfulness hyperplane [38], others find uneven generalization across logical transformations [39] or argue the property is graded and not a single boundary [40]. This is consistent with our finding that no single configuration is best across both benchmarks. VIII Related Work Prior work introduced the setting we build on: reading a model’s hidden states to judge the correctness of generated code without executing it [11]. Bui et al. [41] report that internal representations correlate strongly with whether a program passes its tests. Vu et al. [28] raise transferability by choosing the read-out layer and token per model rather than fixing them, while others read the same signal before generation to predict failure [42], as a risk score over internal states [43], or as span-localized calibrated uncertainty [44]. Mechanistic accounts ask where and how information about code correctness is represented inside the model, tracing it through sparse autoencoders [45] and attribution graphs [46], extending evidence that code models encode program semantics internally [47], while a parallel security line reads or steers a vulnerability direction in the same space [48, 49, 50, 51]. Each of these fixes one construction of the direction and inherits whatever correct and incorrect programs its benchmark supplies; we instead measure how much the read-out location, construction method, and prompt framing change the signal, and find that the best location reverses between HumanEval and BigCodeBench. The closest contrast, Vu et al.’s per-model selection [28], sidesteps this choice rather than quantifying its cost. The probing recipe itself originates outside code, where hidden states linearly separate true from false statements [12, 13] and representation engineering generalises it to reading and steering many concepts [15]. The same construction has since been applied to a model’s own outputs: probing reasoning traces for self-verification [52], predicting answer accuracy before any answer is produced [53], and reading correctness from class centroids in the spirit of mean-diff [54]. We bring this line to the correctness of generated code. Our second question needs correct and incorrect programs that differ only in the fault-causing change, which mutation testing supplies by seeding single localised faults into working code [26]. Behaviour-preserving rewrites such as renaming and reformatting are the standard control for surface form [55, 56, 57]. We combine both: mutations isolate the fault, behaviour-preserving rewrites vary surface form. Kassem et al. [58] prompt an LLM to inject one semantic error from a fixed taxonomy into HumanEval and BigCodeBench solutions, discard the variants that still pass the tests, and release 1,217 labelled pairs. We construct our own pairs for two reasons: (1) LLM injection leaves residual label noise, which they acknowledge, whereas our deterministic operators act on a typed AST and so keep every mutation localised and type-compatible by construction; (2) the MC variant needs a behaviour-preserving rewrite of each mutant (Section˜I-F), and no released dataset we know of pairs its faults with such rewrites. IX Conclusion We studied how the construction method, prompt framing, and hidden-state location shape a captured code correctness direction (RQ1), and whether representing the bug-causing change through controlled modifications beats plausible failing attempts (RQ2). Two findings stand out: no single configuration is best, with only mean-diff generally ahead of PCA; and isolating the fault does not help, as a direction that tells a program from a perturbed copy is not suited to judge an independent candidate. Several directions follow from these results. First, RQ2 indicates that telling a solution from a perturbed copy of itself is not the same as judging an independent attempt; fault synthesis that better imitates the mistakes models make, e.g. via semantics-aware or LLM-based mutation, could narrow that difference and make controlled pairs a viable fitting source. Second, our study characterises the captured direction only by its accuracy; a mechanistic account, e.g. through sparse autoencoders, could reveal whether the direction encodes a semantic notion of correctness or a bundle of correlated cues, and so explain why it shifts with the configuration. Third, correctness is only one property of generated code; the same probing methodology could target properties for which tests provide no executable proxy, such as efficiency or security. Overall, reading correctness from a model’s hidden states is possible, yet configuration-dependent. [Per-Model Effect of the Confound Rewrites] TABLE VII: Per-model view of the confound check: AccValAcc_Val for a mean-diff direction fit on a benchmark’s controlled pairs without the rewrites (M-Only) and with them (MC), followed by the change in percentage points (Δ= = MC −- M-Only). Settings follow Table˜V (weighted sampling, averaged over read-out locations and framings), and the All column reproduces its model-averaged cells. Two kinds of row support no conclusion and are marked accordingly: † scores each variant on its own held-out pairs, so the two accuracies come from different test sets; ‡ leaves every model near the 25%25\% chance level of the 1-of-4 selection, so neither variant transfers there. The four unmarked rows share a test set and reach 60.7%60.7\%, and carry the comparison. Mistral Qwen CodeLlama OpenCoder All tested on M-Only MC (Δ)( ) M-Only MC (Δ)( ) M-Only MC (Δ)( ) M-Only MC (Δ)( ) M-Only MC (Δ)( ) fit on BigCodeBench controlled pairs BigCodeBench‡ 17.517.5 17.417.4 (−0.2)(-0.2) 18.318.3 18.218.2 (−0.1)(-0.1) 20.120.1 21.421.4 (+1.3)(+1.3) 22.722.7 19.319.3 (−3.4)(-3.4) 19.619.6 19.019.0 (−0.6)(-0.6) layer on BigCodeBench 33.733.7 33.833.8 (+0.1)(+0.1) 32.432.4 31.831.8 (−0.7)(-0.7) 33.733.7 34.134.1 (+0.5)(+0.5) 31.731.7 31.231.2 (−0.5)(-0.5) 32.932.9 32.732.7 (−0.2)(-0.2) HumanEval 26.226.2 26.026.0 (−0.2)(-0.2) 38.638.6 37.237.2 (−1.4)(-1.4) 25.225.2 26.626.6 (+1.4)(+1.4) 29.329.3 30.430.4 (+1.1)(+1.1) 29.829.8 30.030.0 (+0.2)(+0.2) held-out pairs† 81.281.2 79.879.8 (−1.4)(-1.4) 89.489.4 87.987.9 (−1.5)(-1.5) 78.278.2 75.275.2 (−3.0)(-3.0) 84.484.4 84.184.1 (−0.3)(-0.3) 83.383.3 81.781.7 (−1.6)(-1.6) fit on HumanEval controlled pairs HumanEval 39.339.3 40.240.2 (+0.9)(+0.9) 60.760.7 60.360.3 (−0.4)(-0.4) 37.837.8 40.340.3 (+2.5)(+2.5) 52.552.5 53.053.0 (+0.5)(+0.5) 47.647.6 48.548.5 (+0.9)(+0.9) layer on HumanEval 42.342.3 43.043.0 (+0.7)(+0.7) 59.159.1 58.258.2 (−0.9)(-0.9) 41.141.1 40.940.9 (−0.2)(-0.2) 51.951.9 53.953.9 (+2.0)(+2.0) 48.648.6 49.049.0 (+0.4)(+0.4) BigCodeBench‡ 22.822.8 21.221.2 (−1.5)(-1.5) 20.620.6 19.119.1 (−1.6)(-1.6) 19.719.7 19.319.3 (−0.4)(-0.4) 25.825.8 25.825.8 (+0.0)(+0.0) 22.222.2 21.321.3 (−0.9)(-0.9) held-out pairs† 63.063.0 63.663.6 (+0.6)(+0.6) 84.284.2 84.684.6 (+0.4)(+0.4) 64.164.1 62.062.0 (−2.2)(-2.2) 75.075.0 74.374.3 (−0.7)(-0.7) 71.671.6 71.171.1 (−0.5)(-0.5) Recall that a confound is a behaviour-preserving rewrite of a mutant, so it is itself incorrect and fails in the same way as the mutant it comes from (Section˜I-F). Therefore, M-Only and MC are two fitting variants, the second adding the refactored mutants to the pairs of the first. Each variant is fitted, validated, and tested separately, so the M-Only and MC columns of Table˜VII hold the accuracies of two different directions, and Δ is the difference between those two accuracies. The M-Only/MC comparisons in Section˜V are averaged over the four models. The behaviour-preserving rewrites were generated by Qwen2.5-Coder-32B-Instruct, while the probed Qwen model in our experiments is Qwen2.5-Coder-7B-Instruct. In principle, an average could hide an effect specific to the probed model, so Table˜VII shows both variants per model, for every measure reported in Section˜V. Two things are visible in the absolute accuracies. First, every model individually reproduces the pattern that Section˜V reports on average: the controlled pairs are highly separable in isolation. Yet, fitting on controlled pairs but testing on plausible failing attempts transfers poorly. Second, Qwen2.5-Coder-7B-Instruct is the most separable model on five of the eight measures — the two rows marked † and the three rows tested on HumanEval — but it already leads on them under M-Only, which contains no rewrites at all. Therefore, its advantage is present before any Qwen-generated data enters the fitting set, and so cannot be an effect of the rewrites. The deltas tell the same story. Table˜VII marks the two kinds of row that support no conclusion, leaving four that do. The two rows marked ‡ , both labelled BigCodeBench, leave every model between 17.517.5 and 25.8%25.8\%, around the 25%25\% that guessing gives on the 1-of-4 selection. When two variants are that close to guessing, a small Δ only says that neither of them transfers; it does not show that the rewrites are harmless. The two rows marked † have a different limitation: M-Only is tested on held-out M-Only pairs and MC on held-out MC pairs, so their two accuracies come from different test sets and cannot be compared directly. We report both kinds so that the table covers every measure of Section˜V. The four unmarked rows carry the comparison: the two labelled HumanEval and the two labelled layer on. In each of the four, M-Only and MC are scored on the same test set, so the two differ only in the data used to build the direction. In the rows labelled HumanEval, that data is the variant’s own controlled pairs: the layer is selected on a held-out split of them, so M-Only and MC differ both in their fitting pairs and in their validation pairs. In the rows labelled layer on, the layer is instead selected on a held-out split drawn from the test benchmark itself, as RQ1 does for its in-distribution fits (Section˜V-6). That split is the same whichever variant is being fitted, so M-Only and MC are validated on identical data and their fitting pairs are the only difference between them. Accuracy across these four rows reaches 60.7%60.7\%, well clear of guessing, so there is a signal for the rewrites to disturb if they were going to. They do not: adding them moves no model by more than 2.52.5 points, and moves Qwen2.5-Coder-7B-Instruct by at most 1.41.4, always downwards. Including the marked rows does not change the picture. Across all six rows that test on a benchmark, no model gains or loses more than 3.43.4 points, and Qwen2.5-Coder-7B-Instruct is worse with the rewrites than without them in every one of them, by at most 1.61.6 points. Therefore, the per-model view agrees with the model-averaged result of Section˜V-7: the rewrites have little influence on any model’s results, including the model whose family produced them. References [1] A. Svyatkovskiy, S. K. Deng, S. Fu, and N. Sundaresan, “Intellicode compose: code generation using transformer,” in Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), 2020, p. 1433–1443. [2] M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. d. O. Pinto, J. Kaplan, H. Edwards, Y. Burda, N. Joseph, G. Brockman et al., “Evaluating large language models trained on code,” arXiv preprint arXiv:2107.03374, 2021. [3] C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan, “SWE-bench: Can language models resolve real-world GitHub issues?” in The Twelfth International Conference on Learning Representations, 2024. [4] S. Barke, M. B. James, and N. Polikarpova, “Grounded copilot: How programmers interact with code-generating models,” Proceedings of the ACM on Programming Languages, vol. 7, no. OOPSLA1, 2023. [5] Y. Fu, P. Liang, A. Tahir, Z. Li, M. Shahin, J. Yu, and J. Chen, “Security weaknesses of copilot-generated code in GitHub projects: An empirical study,” ACM Transactions on Software Engineering and Methodology, 2025. [6] Z. Wang, Z. Zhou, D. Song, Y. Huang, S. Chen, L. Ma, and T. Zhang, “Towards understanding the characteristics of code generation errors made by large language models,” in Proceedings of the IEEE/ACM 47th International Conference on Software Engineering (ICSE), 2025, p. 2587–2599. [7] A. Gu, W.-D. Li, N. Jain, T. X. Olausson, C. Lee, K. Sen, and A. Solar-Lezama, “The counterfeit conundrum: Can code language models grasp the nuances of their incorrect generations?” in Findings of the Association for Computational Linguistics: ACL 2024, 2024, p. 74–117. [8] E. T. Barr, M. Harman, P. McMinn, M. Shahbaz, and S. Yoo, “The oracle problem in software testing: A survey,” IEEE Transactions on Software Engineering, vol. 41, no. 5, p. 507–525, 2015. [9] K. Tian, E. Mitchell, A. Zhou, A. Sharma, R. Rafailov, H. Yao, C. Finn, and C. D. Manning, “Just ask for calibration: Strategies for eliciting calibrated confidence scores from language models fine-tuned with human feedback,” in Conference on Empirical Methods in Natural Language Processing (EMNLP), 2023, p. 5433–5442. [10] C. Spiess, D. Gros, K. S. Pai, M. Pradel, M. R. I. Rabin, A. Alipour, S. Jha, P. Devanbu, and T. Ahmed, “Calibration and correctness of language models for code,” in International Conference on Software Engineering (ICSE), 2025. [11] F. Ribeiro, C. Spiess, P. Devanbu, and S. Nadi, “On LLMs’ internal representation of code correctness,” in Proceedings of the IEEE/ACM 48th International Conference on Software Engineering (ICSE). Association for Computing Machinery, 2026. [12] A. Azaria and T. Mitchell, “The internal state of an LLM knows when it’s lying,” in Findings of the Association for Computational Linguistics: EMNLP, 2023. [13] S. Marks and M. Tegmark, “The geometry of truth: Emergent linear structure in large language model representations of true/false datasets,” arXiv preprint arXiv:2310.06824, 2023. [14] C. Burns, H. Ye, D. Klein, and J. Steinhardt, “Discovering latent knowledge in language models without supervision,” in International Conference on Learning Representations (ICLR), 2023. [15] A. Zou, L. Phan, S. Chen, J. Campbell, P. Guo, R. Ren, A. Pan, X. Yin, M. Mazeika, A.-K. Dombrowski et al., “Representation engineering: A top-down approach to AI transparency,” arXiv preprint arXiv:2310.01405, 2023. [16] S. Im and S. Li, “A unified understanding and evaluation of steering methods,” 2026. [Online]. Available: https://arxiv.org/abs/2502.02716 [17] T. Y. Zhuo, M. C. Vu, J. Chim, H. Hu, W. Yu, R. Widyasari, I. N. B. Yusuf, H. Zhan, J. He, I. Paul et al., “BigCodeBench: Benchmarking code generation with diverse function calls and complex instructions,” arXiv preprint arXiv:2406.15877, 2024. [18] J. Austin, A. Odena, M. Nye, M. Bosma, H. Michalewski, D. Dohan, E. Jiang, C. Cai, M. Terry, Q. Le, and C. Sutton, “Program synthesis with large language models,” arXiv preprint arXiv:2108.07732, 2021. [19] J. Liu, C. S. Xia, Y. Wang, and L. Zhang, “Is your code generated by ChatGPT really correct? rigorous evaluation of large language models for code generation,” in Advances in Neural Information Processing Systems (NeurIPS), 2023. [20] A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, Ł. Kaiser, and I. Polosukhin, “Attention is all you need,” in Advances in Neural Information Processing Systems (NeurIPS), 2017. [21] K. Li, O. Patel, F. Viégas, H. Pfister, and M. Wattenberg, “Inference-time intervention: Eliciting truthful answers from a language model,” in Advances in Neural Information Processing Systems (NeurIPS), 2023. [22] H. Abdi and L. J. Williams, “Principal component analysis,” WIREs Computational Statistics, vol. 2, no. 4, p. 433–459, 2010. [23] S. Kadavath, T. Conerly, A. Askell, T. Henighan, D. Drain, E. Perez, N. Schiefer, Z. Hatfield-Dodds, N. DasSarma, E. Tran-Johnson et al., “Language models (mostly) know what they know,” arXiv preprint arXiv:2207.05221, 2022. [24] Z. Sun, L. Li, Y. Liu, X. Du, B. Wang, J. Zhu, C. Wang, and Y. Liu, “Sifting through the chaff: On utilizing execution feedback for ranking the generated code candidates,” in Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering (ASE), 2024, p. 229–241. [25] Logilab and PyCQA, “astroid: A common base representation of python source code,” https://github.com/pylint-dev/astroid, 2024. [26] R. Just, D. Jalali, L. Inozemtseva, M. D. Ernst, R. Holmes, and G. Fraser, “Are mutants a valid substitute for real faults in software testing?” in Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE), 2014. [27] B. Hui, J. Yang, Z. Cui, J. Yang, D. Liu, L. Zhang, T. Liu, J. Zhang, B. Yu, K. Lu et al., “Qwen2.5-Coder technical report,” arXiv preprint arXiv:2409.12186, 2024. [28] T. T. Vu, T.-D. Bui, T.-T. Nguyen, S. Nguyen, and H. Vo, “Model-agnostic quality assessment for LLM-generated code via dynamic internal representation selection,” Journal of Systems and Software, vol. 237, p. 112852, 2026. [29] Y. Belinkov, “Probing classifiers: Promises, shortcomings, and advances,” Computational Linguistics, vol. 48, no. 1, p. 207–219, 2022. [30] J. Hewitt and P. Liang, “Designing and interpreting probes with control tasks,” in Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP), 2019. [31] A. Ravichander, Y. Belinkov, and E. Hovy, “Probing the probing paradigm: Does probing accuracy entail task relevance?” in Proceedings of the 16th Conference of the European Chapter of the Association for Computational Linguistics: Main Volume, 2021. [32] Y. Elazar, S. Ravfogel, A. Jacovi, and Y. Goldberg, “Amnesic probing: Behavioral explanation with amnesic counterfactuals,” Transactions of the Association for Computational Linguistics, vol. 9, p. 160–175, 2021. [33] A. Kumar, C. Tan, and A. Sharma, “Probing classifiers are unreliable for concept removal and detection,” Advances in Neural Information Processing Systems (NeurIPS), 2022. [34] J. Patra and M. Pradel, “Semantic bug seeding: A learning-based approach for creating realistic bugs,” in Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2021. [35] C. Richter and H. Wehrheim, “Learning realistic mutations: Bug creation for neural bug detectors,” in 2022, IEEE Conference on Software Testing, Verification and Validation (ICST), 2022. [36] J. He, L. Beurer-Kellner, and M. Vechev, “On distribution shift in learning-based bug detectors,” in International Conference on Machine Learning (ICML), 2022. [37] T. Dinh, J. Zhao, S. Tan, R. Negrinho, L. Lausen, S. Zha, and G. Karypis, “Large language models of code fail at completing code with potential bugs,” in Advances in Neural Information Processing Systems (NeurIPS), 2023. [38] J. Liu, S. Chen, Y. Cheng, and J. He, “On the universal truthfulness hyperplane inside LLMs,” in Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, 2024. [39] Y. Bao, X. Zhang, T. Du, X. Zhao, Z. Feng, H. Peng, and J. Yin, “Probing the geometry of truth: Consistency and generalization of truth directions in LLMs across logical transformations and question answering tasks,” in Findings of the Association for Computational Linguistics: ACL, 2025. [40] Z. Ying, S. Ravfogel, N. Kriegeskorte, and P. Hase, “The truthfulness spectrum hypothesis,” arXiv preprint arXiv:2602.20273, 2026. [41] T.-D. Bui, T. T. Vu, T.-T. Nguyen, S. Nguyen, and H. Vo, “Correctness assessment of code generated by large language models using internal representations,” Journal of Systems and Software, vol. 230, p. 112570, 2025. [42] W. Lugoloobi, T. Foster, W. Bankes, and C. Russell, “LLMs encode their failures: Predicting success from pre-generation activations,” arXiv preprint arXiv:2602.09924, 2026. [43] Y. Huang, L. Ma, K. Nishikino, and T. Akazaki, “Risk assessment framework for code LLMs via leveraging internal states,” in Proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering (FSE), 2025. [44] D. Gros and P. Devanbu, “Localized calibrated uncertainty in code language models,” arXiv preprint arXiv:2512.24560, 2025. [45] K. Tahimic and C. Cheng, “Mechanistic interpretability of code correctness in llms via sparse autoencoders,” 2025. [Online]. Available: https://arxiv.org/abs/2510.02917 [46] Y. He, Z. Zhao, K. Zhou, B. Dai, J. Fu, and Y. Yang, “CodeCircuit: Toward inferring LLM-generated code correctness via attribution graphs,” arXiv preprint arXiv:2602.07080, 2026. [47] C. Jin and M. Rinard, “Emergent representations of program semantics in language models trained on programs,” ser. ICML’24. JMLR.org, 2024. [48] J. He and M. Vechev, “Large language models for code: Security hardening and adversarial testing,” in Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (CCS), 2023. [49] W. Yu, R. Mangal, T. Zhuo, M. Fredrikson, and C. S. Pasareanu, “A mixture of linear corrections generates secure code,” 2025. [Online]. Available: https://arxiv.org/abs/2507.09508 [50] J. Li, L. Cui, J. Zhang, H. Fei, Y. Chen, and H. Zhu, “Steering large language models for vulnerability detection,” in IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP), 2025. [51] R. Melo, C. Mamede, A. Catarino, R. Abreu, and H. L. Cardoso, “Are sparse autoencoders useful for java function bug detection?” 2026. [Online]. Available: https://arxiv.org/abs/2505.10375 [52] A. Zhang, Y. Chen, J. Pan, C. Zhao, A. Panda, J. Li, and H. He, “Reasoning models know when they’re right: Probing hidden states for self-verification,” arXiv preprint arXiv:2504.05419, 2025. [53] I. V. M. Cencerrado, A. P. Masdemont, A. G. Hawthorne, D. D. Africa, and L. Pacchiardi, “No answer needed: Predicting llm answer accuracy from question-only linear probes,” 2026. [Online]. Available: https://arxiv.org/abs/2509.10625 [54] S. Cho, Z. Wu, K. D. Costa, and A. Koshiyama, “The confidence manifold: Geometric structure of correctness representations in language models,” 2026. [Online]. Available: https://arxiv.org/abs/2602.08159 [55] S. Wang, Z. Li, H. Qian, C. Yang, Z. Wang, M. Shang, V. Kumar, S. Tan, B. Ray, P. Bhatia, R. Nallapati, M. K. Ramanathan, D. Roth, and B. Xiang, “ReCode: Robustness evaluation of code generation models,” in Annual Meeting of the Association for Computational Linguistics (ACL), 2023. [56] J. Henkel, G. Ramakrishnan, Z. Wang, A. Albarghouthi, S. Jha, and T. Reps, “Semantic robustness of models of source code,” in 2022 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), 2022, p. 526–537. [57] P. Jain, A. Jain, T. Zhang, P. Abbeel, J. Gonzalez, and I. Stoica, “Contrastive code representation learning,” in Proceedings of the 2021 Conference on Empirical Methods in Natural Language Processing, M.-F. Moens, X. Huang, L. Specia, and S. W.-t. Yih, Eds. Online and Punta Cana, Dominican Republic: Association for Computational Linguistics, Nov. 2021, p. 5954–5971. [Online]. Available: https://aclanthology.org/2021.emnlp-main.482/ [58] M. Kassem, F. Ribeiro, and S. Nadi, “An automated methodology for generating labeled datasets of semantic errors in code,” in Proceedings of the 3rd International Workshop on Large Language Models for Code (LLM4Code), ser. LLM4Code ’26. New York, NY, USA: Association for Computing Machinery, 2026, p. 14–20.