Pith. sign in

REVIEW 3 major objections 5 minor 58 references

On the Robustness of LLMs' Internal Representation of Code Correctness

T0 review · 3 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read No single configuration captures the internal code-correctness signal, and isolating the injected fault makes transfer worse.

desk verdict A carefully executed configuration sweep of linear probes for code correctness; the RQ2 negative result is real for this mutation pipeline but should not be overgeneralized. read the letter →

arxiv 2608.08266 v1 pith:6AMXAHIO submitted 2026-08-08 cs.SE cs.AIcs.LG

Francisco Ribeiro , Sohaila Abdulsattar , Renata Gonzalez , Mahmoud Kassem , Sarah Nadi This is my paper · ORCID
classification cs.SEcs.AIcs.LG
keywords linearprobingcodecorrectnesshiddenstatesLLMinternalrepresentationsmutationtestingrepresentationrobustnessHumanEvalBigBench
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper asks whether the internal code correctness signal that prior work extracted from LLM hidden states is a robust property of the model or an artifact of how it was captured. By sweeping construction method, prompt framing, hidden-state location, fitting data, and model across two benchmarks, it finds that no single configuration is best: only the construction method (mean-diff over PCA) generalizes, while the best framing, read-out location, and model change with the benchmark. In a second experiment, it builds correct/incorrect pairs that differ only in the injected fault using rule-based mutations, and shows that a direction fit on these pairs separates them well in isolation (83.3% on BigCodeBench) yet ranks the benchmark's own plausible failing attempts far worse (19.6%) than an in-distribution fit (56.7%). The implication is that the captured direction is a property of the configuration and the contrast set, so correctness probes must be tuned per setting and reported with their configuration.

What carries the argument

The central object is the code correctness direction, a vector in hidden-state space extracted by linear probing from contrasting correct and incorrect program pairs at each layer of a transformer LLM. The paper compares two constructions: PCA, which takes the first principal component of the per-pair representation differences, and mean-diff, the difference of the two class means; it also varies the prompt framing (neutral, concept, function) and the read-out location (last token vs. response average). Candidate programs are scored by projecting the hidden state at the chosen location onto the direction. For RQ2, the machinery is a controlled-pair pipeline: 20 rule-based AST mutation operators seed a single fault into a correct solution, mutants are kept only if they fail the benchmark's test suite, and behavior-preserving rewrites are added as confounds; the resulting directions are tested both in isolation on held-out pairs and in transfer on the benchmark's 1-of-4 selection task. This pipeline is what demonstrates the separation-versus-transfer gap that grounds the paper's main conclusion.

What would settle it

Fit a direction on mutants generated by an LLM-based fault injector that mimics the mistakes models plausibly make, then test it on BigCodeBench's candidate-ranking task: accuracy at the 56.7% in-distribution level would refute the claim that isolating the fault does not help.

Watch

Extended reading notes

Core claim

On its own terms, the paper claims that the quality of a captured code correctness direction depends on how it is built, what data it is fit on, and which model it is read from, rather than being a fixed internal property of the model. It establishes this by sweeping 576 configurations and reporting that the fit-by-test framing interaction and the model dominate the variance, while the benchmark decides which choices matter. It additionally claims that isolating the bug-causing change does not improve the direction: directions fit on mutant-controlled pairs separate those pairs at 71.6–83.3%, but transferring to the benchmark's own candidate rankings yields 19.6% on BigCodeBench versus 56.7% for an in-distribution fit, with the gap only partly recovered by selecting the read-out layer on the benchmark itself. The conclusion is that telling a solution from a perturbed copy of itself is not the same as judging an independent candidate, so the correctness direction is configuration-dependent.

Load-bearing premise

The conclusion that isolating the fault does not help assumes that rule-based AST mutations failing the benchmark's test suite are a reasonable proxy for the mistakes LLMs actually make in code generation.

Editorial extensions

If this is right

  • Practitioners should tune the read-out location and framing per model and benchmark on a validation split rather than reuse a fixed recipe.
  • Reported accuracies for internal correctness directions should include the configuration sweep's validation-selected accuracy, since a single headline number can overstate the technique.
  • Directions fit on mutation-controlled pairs cannot be assumed to judge independent candidate implementations; high in-isolation separability does not imply transfer.
  • Mean-diff is the safer default construction method, since it is the only choice whose preferred setting never reverses across the studied conditions.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If correctness directions are configuration-dependent, comparisons between correctness probes and other internal signals such as truthfulness or sentiment must control for construction and data, or the differences may be artifacts.
  • The same isolation-versus-transfer protocol could be applied to other probed properties such as security or efficiency; the paper's logic predicts that high in-isolation separability will not by itself yield transfer to real candidate judgments.
  • The BigCodeBench-specific failure may scale with task diversity and candidate independence; a testable extension would vary mutation count and task difficulty within one benchmark to map where the transfer gap appears.
  • Since selecting the layer on the benchmark recovered most of the BigCodeBench gap, future work should report validation-selected and oracle-layer accuracies separately to distinguish direction quality from layer-selection cost.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper investigates whether internal linear "correctness directions" in LLMs are robust properties of the model or artifacts of how they are constructed. RQ1 sweeps a design space of two construction methods (PCA, mean-diff), three prompt framings, two read-out locations, two fitting-data sources, four models, and two benchmarks, reporting that no single configuration is best and that only the construction method (mean-diff over PCA) generalizes across benchmarks. RQ2 builds controlled correct/incorrect pairs by injecting single faults into canonical solutions via typed AST mutations, with optional behavior-preserving rewrites, and finds that directions fit on such pairs separate held-out mutants with high accuracy (83.3% on BigCodeBench) but transfer poorly to ranking the benchmarks' own candidate implementations (19.6% on BigCodeBench vs. 56.7% for the in-distribution fit; 47.6% vs. 52.8% on HumanEval). The paper concludes that no single configuration is best and that isolating the fault does not help, and it provides a public replication package.

Significance. If the results hold, the paper contributes a useful negative result to the literature on internal code-correctness representations: the captured direction is configuration-dependent and contrast-dependent, rather than a stable model property. The study is disciplined in several ways: disjoint fitting/validation/test partitions, tenfold cross-validation, reproduction of the prior work's single configuration, explicit layer-selection protocol, and a per-model confound analysis in the appendix. The replication package is a concrete strength. However, the central quantitative claims lack significance tests and confidence intervals, and the RQ2 conclusion rests on a mutation distribution whose representativeness the authors themselves concede is unverified. The conclusions are therefore plausible but not yet established at the strength stated in the abstract.

major comments (3)
  1. [Section V, Table V] The central RQ2 comparison is reported as point estimates without uncertainty: 56.7 vs. 19.6 on BigCodeBench and 52.8 vs. 47.6 on HumanEval. The HumanEval gap is only 5.2 percentage points, and without fold-level paired tests, bootstrap intervals, or effect-size statistics it is not possible to tell whether this drop is distinguishable from noise. The paper's conclusion that "isolating the fault does not help" is stated unconditionally, but the evidence is strong only for BigCodeBench and weak for HumanEval. Please report variance estimates and paired significance tests for these comparisons, and state which conclusions are supported on each benchmark separately.
  2. [Section VII, Internal Validity] The paper's own limitation statement says: "our mutation pipeline only checks types, not whether an edit resembles a mistake a developer or a model would plausibly make." This is load-bearing for RQ2's transfer failure: if the AST mutations are unrepresentative of real model errors, the drop from 56.7% to 19.6% could reflect the unnaturalness of the injected faults rather than the claim that fault isolation does not help. The held-out mutant separability result (Section V-1) verifies learnability within the mutation distribution, but it is not a positive control for representativeness. To support the abstract's second conclusion, the paper needs either a transfer experiment with more realistic single-fault pairs (e.g., LLM-generated semantic errors such as those of [58], or semantic bug seeding as in [34]) or a carefully weakened claim that the result holds for rule-based mutations but is untested for realistic faults.
  3. [Section IV, Table IV] The ANOVA decomposition is presented with variance shares such as "fit x test framing 15%" and "benchmark x model 7%", but no significance tests or confidence intervals are reported for these shares, and the "best level flips" conclusions in panel 2 are inferred from means without quantifying uncertainty. Since RQ1's headline conclusion is that "no single configuration is best," the claim should be supported by pairwise comparisons or interactions tests with appropriate multiple-comparison correction, not only by inspection of the largest point estimates. This is especially important because HumanEval shows large model-dependent variation (model identity 51% of variance), and some of the best-configuration differences in Tables II and III may be within fold-to-fold noise.
minor comments (5)
  1. [Section III-A] The name "AccVal" for a test-time selection accuracy is confusing because the metric is reported at test time; consider renaming it to something like "selection accuracy at the validation-selected layer" to avoid the implication that it is a validation-set number.
  2. [Tables II and III] The first row is labeled "Configuration of prior work" and the text says reproduction was confirmed, but the prior published accuracies are not listed; including them in the table or text would let the reader verify the reproduction claim directly.
  3. [Section III-F] The distinction between weighted and paired sampling is described briefly; clarifying how many fitting pairs remain after sampling (e.g., average number of mutants per task) would help the reader interpret the M-Only and MC results.
  4. [Figure 2] The Function panel's text "Write a correct/incorrect implementation" may be a template rather than an actual stimulus; please clarify whether the actual stimulus contains both variants or is shown for both conditions.
  5. [Appendix, Table VII] The appendix's handling of rows marked dagger and double-dagger is transparent and commendable, but the phrase "support no conclusion" should be read alongside the main-text claim that MC tracks M-Only; consider moving the caveat into Section V-7 so the limitation is visible in the main body.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's claims are measured outcomes of held-out empirical evaluations, and the reproduced prior-work baseline is not load-bearing for the new conclusions.

full rationale

This is an empirical study rather than a derivation, so there is no chain in which a predicted quantity reduces to a fitted parameter by construction. RQ1 systematically varies construction method, framing, and read-out location, fitting directions on training splits, selecting layers on validation splits, and reporting accuracy on held-out test folds; the claim that no single configuration is best is a summary of measured accuracies across 576 configurations, not an artifact of how the study was set up. RQ2's controlled mutation pairs are the object of study: the paper fits directions on M-Only and MC pairs and measures both in-isolation separability (83.3% on BigCodeBench) and transfer to benchmark candidate ranking (19.6% versus 56.7% for the in-distribution fit). The low transfer accuracy is a measured outcome, and the in-isolation separability is explicitly used only as a positive control to rule out malformed or unlearnable mutations, not as evidence that injected mutations resemble real model mistakes. The acknowledged limitation in Section VII ('our mutation pipeline only checks types, not whether an edit resembles a mistake a developer or a model would plausibly make') is a construct-validity threat, not a circular step, because the conclusion 'isolating the fault does not help' is an empirical generalization that could have come out differently and is not definitionally entailed by the operationalization. Self-citation to prior work [11] appears as a reproduced baseline: the paper confirms reproduction of the published accuracies and then varies the configuration, so the new claims about configuration dependence do not rest on [11]'s conclusions. No load-bearing argument reduces to a self-citation or to the fitting data itself. Overall circularity score is 0.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central claims rest on the probing methodology's background assumptions (hidden states linearly encode concepts, tests define correctness, mutations proxy real bugs). There are no fitted constants or invented entities; the directions are empirical objects fit by the methods being compared.

assumptions (4)
  • domain assumption Linear directions in hidden states can represent abstract properties such as correctness.
    Invoked throughout (Section II-B, IV) and in Section VII construct validity; this is the premise of the probing methodology, established by prior work [12,13,15] but not proven here.
  • domain assumption Test suite pass/fail is a valid oracle for code correctness.
    Section III-C uses native test suites as correctness proxy; Section VII acknowledges incompleteness and non-functional aspects.
  • domain assumption Rule-based mutants that fail the test suite approximate real incorrect programs.
    Section III-F and VII: the mutation pipeline is the basis of RQ2; the authors explicitly flag that injected faults need not resemble real mistakes [34-36].
  • standard math ANOVA eta-squared decompositions and PCA assume standard linear/statistical modeling assumptions.
    Used in Section IV for variance decomposition without diagnostics or significance testing.

how reviews work

0 comments
Cite this review

Pith. "Pith review of On the Robustness of LLMs' Internal Representation of Code Correctness." pith.science (2026). https://pith.science/paper/6AMXAHIO

@misc{pith2026260808266,
  author       = {Pith},
  title        = {Pith review of: On the Robustness of LLMs' Internal Representation of Code Correctness},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6AMXAHIO}},
  note         = {Machine review of arXiv:2608.08266}
}
read the original 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.

Figures

Figures reproduced from arXiv: 2608.08266 by the authors.

Figure 1
Figure 1. Two implementations of HumanEval/121 — return the sum of the odd values at even positions. sentations. We make two key observations that motivate our study design. First, there are multiple methods to con￾struct 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… view at source ↗
Figure 2
Figure 2. The three framings’ core is a task and candidate program (yellow). [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

58 extracted references · 39 canonical work pages

  1. [58]

    An automated methodol- ogy for generating labeled datasets of semantic errors in code,

    M. Kassem, F. Ribeiro, and S. Nadi, “An automated methodol- ogy for generating labeled datasets of semantic errors in code,” inProceedings of the 3rd International Workshop on Large Language Models for Code (LLM4Code), ser. LLM4Code ’26. New York, NY, USA: Association for Computing Machinery, 2026, pp. 14–20

    work page 2026

  2. [34]

    Semantic bug seeding: A learning- based approach for creating realistic bugs,

    J. Patra and M. Pradel, “Semantic bug seeding: A learning- based approach for creating realistic bugs,” inProceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2021

    work page 2021

  3. [1]

    In- tellicode compose: code generation using transformer,

    A. Svyatkovskiy, S. K. Deng, S. Fu, and N. Sundaresan, “In- tellicode compose: code generation using transformer,” inPro- ceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), 2020, pp. 1433–1443

    work page 2020

  4. [2]

    Evaluating large language models trained on code,

    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

    arXiv 2021

  5. [3]

    SWE-bench: Can language models resolve real-world GitHub issues?

    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?” inThe Twelfth International Con- ference on Learning Representations, 2024

    work page 2024

  6. [4]

    Grounded copi- lot: How programmers interact with code-generating models,

    S. Barke, M. B. James, and N. Polikarpova, “Grounded copi- lot: How programmers interact with code-generating models,” Proceedings of the ACM on Programming Languages, vol. 7, no. OOPSLA1, 2023

    work page 2023

  7. [5]

    Security weaknesses of copilot-generated code in GitHub projects: An empirical study,

    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

    work page 2025

  8. [6]

    Towards understanding the characteristics of code generation errors made by large language models,

    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,” inPro- ceedings of the IEEE/ACM 47th International Conference on Software Engineering (ICSE), 2025, pp. 2587–2599

    work page 2025

Show all 58 references
  1. [7]

    The counterfeit conundrum: Can code lan- guage models grasp the nuances of their incorrect generations?

    A. Gu, W.-D. Li, N. Jain, T. X. Olausson, C. Lee, K. Sen, and A. Solar-Lezama, “The counterfeit conundrum: Can code lan- guage models grasp the nuances of their incorrect generations?” inFindings of the Association for Computational Linguistics: ACL 2024, 2024, pp. 74–117

    2024

  2. [8]

    Theoracleprobleminsoftwaretesting:Asurvey,

    E. T. Barr, M. Harman, P. McMinn, M. Shahbaz, and S. Yoo, “Theoracleprobleminsoftwaretesting:Asurvey,”IEEETrans- actions on Software Engineering, vol. 41, no. 5, pp. 507–525, 2015. TABLE VII: Per-model view of the confound check: AccV alfor a mean-diff direction fit on a bench...

    2015

  3. [9]

    Justaskforcalibration:Strategies for eliciting calibrated confidence scores from language models fine-tuned with human feedback,

    K. Tian, E. Mitchell, A. Zhou, A. Sharma, R. Rafailov, H. Yao, C.Finn,andC.D.Manning,“Justaskforcalibration:Strategies for eliciting calibrated confidence scores from language models fine-tuned with human feedback,” inConference on Empirical Methods in Natural Language Process...

    2023

  4. [10]

    Calibration and correctness of language models for code,

    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,” inInternational Conference on Software Engineering (ICSE), 2025

    2025

  5. [11]

    On LLMs’ internal representation of code correctness,

    F. Ribeiro, C. Spiess, P. Devanbu, and S. Nadi, “On LLMs’ internal representation of code correctness,” inProceedings of the IEEE/ACM 48th International Conference on Software Engineering (ICSE). Association for Computing Machinery, 2026

    2026

  6. [12]

    The internal state of an LLM knows when it’s lying,

    A. Azaria and T. Mitchell, “The internal state of an LLM knows when it’s lying,” inFindings of the Association for Computational Linguistics: EMNLP, 2023

    2023

  7. [13]

    The geometry of truth: Emer- gent linear structure in large language model representations of true/false datasets,

    S. Marks and M. Tegmark, “The geometry of truth: Emer- gent linear structure in large language model representations of true/false datasets,”arXiv preprint arXiv:2310.06824, 2023

    2023 arXiv

  8. [14]

    Discovering latent knowledge in language models without supervision,

    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

    2023

  9. [15]

    Representation engineering: A top-down approach to AI transparency,

    A. Zou, L. Phan, S. Chen, J. Campbell, P. Guo, R. Ren, A. Pan, X. Yin, M. Mazeika, A.-K. Dombrowskiet al., “Representation engineering: A top-down approach to AI transparency,”arXiv preprint arXiv:2310.01405, 2023

    2023 arXiv

  10. [16]

    A unified understanding and evaluation of steering methods,

    S. Im and S. Li, “A unified understanding and evaluation of steering methods,” 2026. [Online]. Available: https://arxiv.org/ abs/2502.02716

    2026

  11. [17]

    BigCodeBench: Benchmarking code generation with diverse function calls and complex instructions,

    T. Y. Zhuo, M. C. Vu, J. Chim, H. Hu, W. Yu, R. Widyasari, I. N. B. Yusuf, H. Zhan, J. He, I. Paulet al., “BigCodeBench: Benchmarking code generation with diverse function calls and complex instructions,”arXiv preprint arXiv:2406.15877, 2024

    2024 arXiv

  12. [18]

    Program synthesis with large language models,

    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,”arXivpreprint arXiv:2108.07732, 2021

    2021 arXiv

  13. [19]

    Is your code generated by ChatGPT really correct? rigorous evaluation of large language models for code generation,

    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,” inAdvances in Neural Information Processing Systems (NeurIPS), 2023

    2023

  14. [20]

    Attention is all you need,

    A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, Ł. Kaiser, and I. Polosukhin, “Attention is all you need,” inAdvances in Neural Information Processing Systems (NeurIPS), 2017

    2017

  15. [21]

    Inference-time intervention: Eliciting truthful answers from a language model,

    K. Li, O. Patel, F. Viégas, H. Pfister, and M. Wattenberg, “Inference-time intervention: Eliciting truthful answers from a language model,” inAdvances in Neural Information Processing Systems (NeurIPS), 2023

    2023

  16. [22]

    Principal component analysis,

    H. Abdi and L. J. Williams, “Principal component analysis,” WIREs Computational Statistics, vol. 2, no. 4, pp. 433–459, 2010

    2010

  17. [23]

    Language models (mostly) know what they know,

    S. Kadavath, T. Conerly, A. Askell, T. Henighan, D. Drain, E. Perez, N. Schiefer, Z. Hatfield-Dodds, N. DasSarma, E. Tran- Johnsonet al., “Language models (mostly) know what they know,”arXiv preprint arXiv:2207.05221, 2022

    2022 arXiv

  18. [24]

    Sifting through the chaff: On utilizing execution feed- back for ranking the generated code candidates,

    Z. Sun, L. Li, Y. Liu, X. Du, B. Wang, J. Zhu, C. Wang, and Y. Liu, “Sifting through the chaff: On utilizing execution feed- back for ranking the generated code candidates,” inProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering (ASE), 20...

    2024

  19. [25]

    astroid: A common base representation of python source code,

    Logilab and PyCQA, “astroid: A common base representation of python source code,” https://github.com/pylint-dev/astroid, 2024

    2024

  20. [26]

    Are mutants a valid substitute for real faults in software testing?

    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?” inProceedings of the 22nd ACM SIGSOFT InternationalSymposiumonFoundationsofSoftwareEngineer- ing (FSE), 2014

    2014

  21. [27]

    Qwen2.5-Codertechnicalreport,

    B. Hui, J. Yang, Z. Cui, J. Yang, D. Liu, L. Zhang, T. Liu, J.Zhang,B.Yu,K.Luetal.,“Qwen2.5-Codertechnicalreport,” arXiv preprint arXiv:2409.12186, 2024

    2024 arXiv

  22. [28]

    Model-agnostic quality assessment for LLM-generated code via dynamic internal representation selection,

    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

    2026

  23. [29]

    Probing classifiers: Promises, shortcomings, and advances,

    Y. Belinkov, “Probing classifiers: Promises, shortcomings, and advances,”Computational Linguistics, vol. 48, no. 1, pp. 207– 219, 2022

    2022

  24. [30]

    Designing and interpreting probes with control tasks,

    J. Hewitt and P. Liang, “Designing and interpreting probes with control tasks,” inProceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP), 2019

    2019

  25. [31]

    Probingtheprobing paradigm: Does probing accuracy entail task relevance?

    A.Ravichander,Y.Belinkov,andE.Hovy,“Probingtheprobing 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

    2021

  26. [32]

    Amnesic probing: Behavioral explanation with amnesic counterfactuals,

    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, pp. 160–175, 2021

    2021

  27. [33]

    Probing classifiers are unreliable for concept removal and detection,

    A. Kumar, C. Tan, and A. Sharma, “Probing classifiers are unreliable for concept removal and detection,”Advances in Neural Information Processing Systems (NeurIPS), 2022

    2022

  28. [35]

    Learningrealisticmutations:Bug creation for neural bug detectors,

    C.RichterandH.Wehrheim,“Learningrealisticmutations:Bug creation for neural bug detectors,” in2022,IEEEConferenceon Software Testing, Verification and Validation (ICST), 2022

    2022

  29. [36]

    On distribution shift in learning-based bug detectors,

    J. He, L. Beurer-Kellner, and M. Vechev, “On distribution shift in learning-based bug detectors,” inInternational Conference on Machine Learning (ICML), 2022

    2022

  30. [37]

    Large language models of code fail at completing code with potential bugs,

    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,” inAdvances in Neural Information Processing Systems (NeurIPS), 2023

    2023

  31. [38]

    On the universal truthfulness hyperplane inside LLMs,

    J. Liu, S. Chen, Y. Cheng, and J. He, “On the universal truthfulness hyperplane inside LLMs,” inProceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, 2024

    2024

  32. [39]

    Probing the geometry of truth: Consistency and generalization of truth directions in LLMs across logical transformations and question answering tasks,

    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,” inFindings of the Association for Computational Linguistics:...

    2025

  33. [40]

    The truth- fulness spectrum hypothesis,

    Z. Ying, S. Ravfogel, N. Kriegeskorte, and P. Hase, “The truth- fulness spectrum hypothesis,”arXivpreprintarXiv:2602.20273, 2026

    2026

  34. [41]

    Correctness assessment of code generated by large language models using internal representations,

    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

    2025

  35. [42]

    LLMs encode their failures: Predicting success from pre-generation activations,

    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

    2026 arXiv

  36. [43]

    Risk assess- ment framework for code LLMs via leveraging internal states,

    Y. Huang, L. Ma, K. Nishikino, and T. Akazaki, “Risk assess- ment framework for code LLMs via leveraging internal states,” inProceedings ofthe33rd ACMInternationalConferenceonthe Foundations of Software Engineering (FSE), 2025

    2025

  37. [44]

    Localized calibrated uncertainty in code language models,

    D. Gros and P. Devanbu, “Localized calibrated uncertainty in code language models,”arXiv preprint arXiv:2512.24560, 2025

    2025

  38. [45]

    Mechanistic interpretability of code correctness in llms via sparse autoencoders,

    K. Tahimic and C. Cheng, “Mechanistic interpretability of code correctness in llms via sparse autoencoders,” 2025. [Online]. Available: https://arxiv.org/abs/2510.02917

    2025

  39. [46]

    Code- Circuit: Toward inferring LLM-generated code correctness via attribution graphs,

    Y. He, Z. Zhao, K. Zhou, B. Dai, J. Fu, and Y. Yang, “Code- Circuit: Toward inferring LLM-generated code correctness via attribution graphs,”arXiv preprint arXiv:2602.07080, 2026

    2026

  40. [47]

    Emergentrepresentationsofprogramse- manticsinlanguagemodelstrainedonprograms,

    C.JinandM. Rinard,“Emergentrepresentationsofprogramse- manticsinlanguagemodelstrainedonprograms,”ser.ICML’24. JMLR.org, 2024

    2024

  41. [48]

    Large language models for code: Security hardening and adversarial testing,

    J. He and M. Vechev, “Large language models for code: Security hardening and adversarial testing,” inProceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (CCS), 2023

    2023

  42. [49]

    A mixture of linear corrections generates secure code,

    W.Yu,R.Mangal,T.Zhuo,M.Fredrikson,andC.S.Pasareanu, “A mixture of linear corrections generates secure code,” 2025. [Online]. Available: https://arxiv.org/abs/2507.09508

    2025 arXiv

  43. [50]

    Steering large language models for vulnerability detection,

    J. Li, L. Cui, J. Zhang, H. Fei, Y. Chen, and H. Zhu, “Steering large language models for vulnerability detection,” inIEEE International Conference on Acoustics, Speech and Signal Pro- cessing (ICASSP), 2025

    2025

  44. [51]

    Are sparse autoencoders useful for java function bug detection?

    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

    2026 arXiv

  45. [52]

    Reasoning models know when they’re right: Probing hidden states for self-verification,

    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

    2025 arXiv

  46. [53]

    No answer needed: Predicting llm answer accuracy from question-only linear probes,

    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

    2026

  47. [54]

    The confidence manifold: Geometric structure of correctness representations in language models,

    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

    2026 arXiv

  48. [55]

    ReCode: Robustness evaluation of code generation models,

    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,” inAnnual Meeting of the Association for Computational Linguistics (ACL), 2023

    2023

  49. [56]

    Semantic robustness of models of source code,

    J. Henkel, G. Ramakrishnan, Z. Wang, A. Albarghouthi, S. Jha, and T. Reps, “Semantic robustness of models of source code,” in2022 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), 2022, pp. 526–537

    2022

  50. [57]

    Contrastive code representation learning,

    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 C...

    2021

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.