Pith. sign in

REVIEW 4 major objections 6 minor 1 cited by

Optimizing Token Consumption in LLMs: A Nano Surge Approach for Code Reasoning Efficiency

T0 review · 4 major / 6 minor · reviewed 2026-08-16 · deepseek-v4-flash

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

Pith's one-line read Code smells inflate token consumption in Chain-of-Thought code reasoning, and refactoring or prompt annotation reduces it by roughly 50% and 24.5% respectively.

desk verdict Useful exploratory evidence that code smells inflate CoT token use, but the headline refactoring saving ignores the refactoring step's own tokens and internal inconsistencies undercut the claims. read the letter →

arxiv 2504.15989 v2 pith:PE5DZ2XU submitted 2025-04-22 cs.SE

Junwei Hu , Weicheng Zheng , Yihan Liu , Yan Liu This is my paper · ORCID
classification cs.SE
keywords chain-of-thoughtreasoningtokenconsumptionoptimizationcodesmellsrefactoringpromptengineeringLLMinferencecostrepaircost-sensitiveprompting
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 tries to establish that token consumption in Chain-of-Thought (CoT) code reasoning is substantially driven by the quality of the code fed to the model, not just by the model's internal reasoning. Using code smells—recurring structural problems such as long methods and duplicated logic—as a measurable proxy for code quality, it compares 'smelly' and 'clean' Java samples and finds that smelly code consumes noticeably more tokens during inference. It then shows two external interventions: automated refactoring to remove smells cuts token use by roughly 50%, and adding an explicit smell annotation to the prompt cuts it by about 24.5%, both while preserving functional equivalence as measured by CodeBLEU and similarity scores. A third set of prompt-level strategies—context awareness, role assignment, and cost limits—adds further reductions of 15–30%. If true, the paper's contribution is that code hygiene and prompt design are economically meaningful levers for LLM inference cost, available without modifying model weights.

What carries the argument

The load-bearing mechanism is the use of code smells as an externally measurable proxy for reasoning difficulty, combined with a preprocessing layer the paper calls the 'Token-Aware Coding Flow.' Code smells (long methods, duplicated logic, complicated boolean or regex expressions, and similar patterns) are detectable before inference; the paper shows they predict extra token expenditure because the model must re-verify structure and intent. On top of that, three prompt-level controls—Context Awareness (injecting file path, function names, and surrounding code), Responsibility Tuning (assigning a role such as software engineer or QA engineer), and Cost Sensitive (limiting output or token budget)—steer the same model toward shorter reasoning traces. The comparison metrics that carry the quantitative claims are tokens normalized by time or by code complexity, rather than raw token counts, so that samples of different size can be compared.

What would settle it

Run the same 300 smelly-code samples through the full pipeline, counting refactoring tokens plus inference tokens on the refactored code, and compare that total with inference tokens on the original code. If the end-to-end total is not clearly lower, the headline savings figure is an accounting artifact rather than a real efficiency gain.

Watch

Extended reading notes

Core claim

The central discovery is that the token cost of CoT reasoning over code is not fixed: it reacts strongly to how the input code is written and how the prompt frames it. On smelly code the model enters repeated verification loops—the paper illustrates this with a mask-reshaping example in which the model re-derives C versus Fortran memory layout several times—whereas clean code lets it converge faster. Refactoring away smells lowers complexity-normalized token consumption from 0.1015 to 0.0576 tokens per unit complexity (about 50%), and explicit smell hints lower mean total tokens from 5,876 to 4,431 (about 24.5%). Prompt strategies deliver further savings: context awareness 15–20%, responsibility tuning 10–15%, and cost limits 20–30%, though overly tight cost limits can truncate output. The paper reads these results as evidence that external, model-agnostic interventions—refactoring and prompt engineering—can make CoT-based code repair substantially cheaper without sacrificing repair quality.

Load-bearing premise

The load-bearing premise is that the token cost of the refactoring step itself can be ignored in the comparison; if that cost is comparable to the roughly 50 percent saving, the net efficiency gain shrinks or disappears.

Editorial extensions

If this is right

  • If refactoring really halves token use, engineering teams can treat code-smell removal as a direct inference-cost optimization, not just a maintainability practice.
  • Explicit smell annotations in prompts are nearly free and cut tokens by about 24.5%, suggesting that cheap annotations can substitute for costly refactoring when refactoring is impractical.
  • Because different smell types carry different token burdens, with expression-related and structural smells costing the most, prioritizing removal of those categories yields the largest efficiency gain.
  • Prompt-level steering (context, role, and cost limits) offers 10–30% savings and can be combined, indicating that prompt design is a reusable efficiency knob that does not require retraining.
  • If these results generalize beyond the tested Java and reasoning-model setup, API cost forecasting for LLM-based coding assistants should include input code quality as a variable.

Reading between the lines

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

  • A testable extension the authors do not run: count the tokens spent by the refactoring pass itself and compare end-to-end totals; only then does the roughly 50% saving represent net cost reduction rather than a shift of cost to a preprocessing step.
  • The same mechanism suggests a broader principle: any input property that reduces the model's need to re-verify assumptions—clear naming, explicit type information, or stated invariants—should reduce token spend, and this could be tested by perturbing clean code with injected ambiguities and measuring token deltas.
  • The cost-sensitive results hint at a trade-off frontier: token budgets can be tuned to sit just above the point where output truncation starts, yielding maximum savings per unit of quality loss; mapping that frontier per task would be a practical follow-up.
  • Because the interventions are external to the model, they are likely portable to other models and languages; comparing savings across model families would reveal whether external code hygiene matters more for weaker or stronger reasoners.
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

4 major / 6 minor

Summary. The paper proposes a 'Token-Aware Coding Flow' to reduce Chain-of-Thought (CoT) token consumption during LLM-based code repair. Using the CodeXGLUE Java dataset, DeepSeek-R1 as the inference engine, and Tree-Sitter-based code-smell annotation, the authors compare token usage between clean and smelly code, before and after refactoring, across different smell types, with and without explicit smell annotations in prompts, and under three prompt-engineering strategies (Context Awareness, Responsibility Tuning, Cost Sensitive). The headline results are that smelly code consumes more tokens than clean code, refactoring reduces token consumption by about 50%, explicit smell annotations reduce it by about 24.5%, and prompt strategies yield further reductions, all while 'without compromising repair quality.' The paper frames this as a preliminary, exploratory study rather than a definitive solution.

Significance. If the empirical claims were properly supported, the paper would offer practically relevant evidence that external code hygiene and prompt design can materially reduce CoT inference cost, and it would be a useful contribution to a growing literature on token-efficient LLM use in software engineering. Strengths include the use of an external model (DeepSeek-R1) and an external dataset (CodeXGLUE), which avoids the circularity of fitting parameters to the reported claims, and the fact that the headline comparisons are, in principle, reproducible and falsifiable. However, the current evidence is largely descriptive and several load-bearing details are missing or internally inconsistent, so the significance is currently conditional on a substantive revision.

major comments (4)
  1. [Section IV-B and Section III-C] The RQ2 headline saving of roughly 50% excludes the token cost of producing the refactored code. Section IV-B states that baseline token usage was measured, 'we applied automated refactoring to the smelly code,' and then token usage was measured on the refactored code; if the refactoring step itself is performed by DeepSeek-R1 API calls, as Section III-C says token consumption was recorded 'during both code repair and refactoring tasks,' then the refactoring tokens are part of the end-to-end pipeline cost and must be reported. If Tree-Sitter performed the refactoring at zero marginal token cost, the paper must state this explicitly and reconcile it with the Section III-C description. Without this information, the central practical claim that refactoring reduces computational overhead is not established.
  2. [Tables I, II, VI, and Section IV-A/IV-B/IV-D] The claims that smelly code 'significantly' increases token consumption, that refactoring yields a 'substantial reduction,' and that explicit smell annotations reduce consumption by 24.5% are based only on descriptive statistics (means, standard deviations, quartiles) with no significance tests, confidence intervals, or effect-size measures. Because RQ2 and RQ4 use paired designs (same samples under two conditions), the authors should report paired tests such as Wilcoxon signed-rank tests, and RQ1 should use an appropriate two-sample test or bootstrap intervals. The word 'significant' appears throughout the analysis but is not supported statistically anywhere.
  3. [Section IV-C, Table IV, and Section III-B-3] The prose in the RQ3 analysis and Findings inverts the rankings in Table IV. The text says 'complicated regex expression, parameter list too long, and complicated boolean expression' incur the highest token costs and that 'binary operator in name and func name' are lower, but Table IV lists binary operator in name (0.3424) as highest, followed by complicated boolean expression (0.3361), mutation too much (0.3321), cyclomatic complexity (0.3285), and complicated regex expression (0.3221), while too long parameter list (0.1942) and func name (0.1592) are near the bottom. Additionally, Section III-B-3 says 50 samples per smell type (500 total), but Section IV-C says 30 snippets per category (300 total). These inconsistencies directly undermine the RQ3 conclusions and must be corrected.
  4. [Section IV-B, Tables III/V, Section IV-E, and the abstract] The abstract and conclusion claim savings are achieved 'without compromising repair quality,' but the evidence for functional preservation is weak and partly contradictory. In RQ2, functional consistency is assessed via CodeBLEU, but the reported mean CodeBLEU between original and refactored code is only 0.5224, and the '70% code functionality similarity threshold' mentioned in the RQ3/RQ4 analysis is not defined or justified as a functional-equivalence criterion. Moreover, Section IV-E explicitly states that Cost Sensitivity 'sometimes led to the truncation of essential code elements, resulting in reduced functional correctness and lower accuracy,' which is a direct quality compromise. The paper must either qualify the 'without compromising' claim to exclude cost-sensitive truncation or provide a valid functional-equivalence measure that supports it.
minor comments (6)
  1. [Section III-B-3 vs. Section IV-C] The sample-size inconsistency between 50 samples per smell type and 30 samples per smell type should be resolved, and the naming of smell types should be made consistent across the text and Table IV (e.g., 'parameter list too long' vs. 'too long parameter list').
  2. [Section IV-A and Table I] The 'Time-Scaled Token Consumption' metric is never formally defined; the text says 'tokens per unit time,' but it is unclear whether this is tokens divided by inference time, tokens per second, or another normalization. A precise definition is needed because this metric is the basis of RQ1 and RQ3 comparisons.
  3. [Section III-C and reproducibility] The paper states that all API interactions were automated via Python scripts 'to guarantee reproducibility and efficiency,' but no code, data, or artifact link is provided. At least a public repository with the scripts and the smelly/clean/refactored datasets should be supplied.
  4. [References] Reference [20] is unrelated to software engineering or LLMs (it concerns molecular dynamics), and reference [31] is cited as 'Tufano et al. (2017)' but the listed paper is by Mastropaolo et al. (2021). Both citations should be corrected or replaced.
  5. [Figures and section headings] Several presentation issues should be fixed: the heading 'I. I NTRODUCTION' contains a spacing artifact, Figure 2 mentions 'GPT-o3' while the text says 'GPT-o1,' and headings such as 'C RAFTING THE FUTURE HOUSE' and 'T RIGGERING THE NANO SURGE' are unclear and should be renamed to reflect their content.
  6. [Tables V and VII] Tables V and VII are referenced only loosely in the analysis, and their relationship to the '70% functionality similarity threshold' is not explained. Each table should be interpreted in the text or removed if not essential.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: all reported token-saving results are direct measurements made with an external model on an external benchmark, so the central claims are not equivalent to their inputs by construction.

full rationale

This paper is an empirical measurement study rather than a derivation. RQ1 and RQ3 compare logged token counts on smelly versus clean CodeXGLUE snippets; RQ2 and RQ4 compare token counts across code versions and prompt variants; RQ5 compares different prompt strategies. The model (DeepSeek-R1), dataset (CodeXGLUE), and smell annotation tool (Tree-Sitter) are all external, and no fitted parameter is later relabeled as a prediction. The main caveat is that RQ2's approximate 50% refactoring saving does not include the tokens consumed by the DeepSeek-R1 calls that perform the refactoring; that is a cost-accounting and scope limitation, not a circularity, because the compared quantities (inference tokens on smelly versus refactored code) are not defined in terms of one another. Accordingly, no circular step can be exhibited and the circularity score is 0.

Assumptions & free parameters 3 free parameters · 5 assumptions · 0 invented entities

No invented entities. 'Nano Surge' and 'Token-Aware Coding Flow' are rhetorical labels for measured effects and known prompt patterns, not new physical or architectural objects with independent falsifiable handles.

free parameters (3)
  • Functionality similarity threshold = 0.70
    The paper applies a 70% code functionality similarity threshold (Sections IV-C and IV-D) to decide which outputs count, with no justification or sensitivity analysis; the RQ4 comparison and RQ3 grouping depend on it.
  • Time-scaled token consumption normalization = tokens per unit time
    Hand-chosen normalization used in RQ1 and RQ2 to compare clean versus smelly code; no rationale is given for why tokens per unit time, rather than total tokens, is the correct efficiency measure.
  • Sample sizes = 300 clean, 300 smelly, 30 per smell type
    Arbitrary sample sizes with no power analysis; random sampling without seeds means the exact subsets are not reproducible.
assumptions (5)
  • domain assumption Tree-Sitter reliably detects the ten code smell categories in the CodeXGLUE Java samples.
    The smelly/clean dataset split in Section III-C depends on this annotation; no precision or recall validation is reported.
  • domain assumption CodeBLEU and text/code similarity at a 70% threshold measure functional consistency.
    The 'without compromising repair quality' claim is supported only by these proxies (Tables III, V, VII, IX), not by executing repaired code.
  • ad hoc to paper The token cost of the refactoring API calls is excluded from the reported savings.
    RQ2 counts only inference tokens on the refactored code; the refactoring calls in Section IV-B are not accounted for, so net savings may be lower.
  • domain assumption DeepSeek-R1 API runs are reproducible without controlling temperature or seeds.
    No sampling or decoding parameters are reported (Section III-C), yet all tables treat single runs as measurements.
  • domain assumption The ten selected smell types and the token-per-unit-time normalization are appropriate proxies for code complexity and efficiency.
    Sections III-B and IV-A introduce this normalization and smell categorization without justification or sensitivity analysis.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Optimizing Token Consumption in LLMs: A Nano Surge Approach for Code Reasoning Efficiency." pith.science (2026). https://pith.science/paper/PE5DZ2XU

@misc{pith2026250415989,
  author       = {Pith},
  title        = {Pith review of: Optimizing Token Consumption in LLMs: A Nano Surge Approach for Code Reasoning Efficiency},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PE5DZ2XU}},
  note         = {Machine review of arXiv:2504.15989}
}
read the original abstract

With the increasing adoption of large language models (LLMs) in software engineering, the Chain of Thought (CoT) reasoning paradigm has become an essential approach for automated code repair. However, the explicit multi-step reasoning in CoT leads to substantial increases in token consumption, reducing inference efficiency and raising computational costs, especially for complex code repair tasks. Most prior research has focused on improving the correctness of code repair while largely overlooking the resource efficiency of the reasoning process itself. To address this challenge, this paper proposes three targeted optimization strategies: Context Awareness, Responsibility Tuning, and Cost Sensitive. Context Awareness guides the model to focus on key contextual information, Responsibility Tuning refines the structure of the reasoning process through clearer role and responsibility assignment, and Cost Sensitive incorporates resource-awareness to suppress unnecessary token generation during inference. Experiments across diverse code repair scenarios demonstrate that these methods can significantly reduce token consumption in CoT-based reasoning without compromising repair quality. This work provides novel insights and methodological guidance for enhancing the efficiency of LLM-driven code repair tasks in software engineering.

Figures

Figures reproduced from arXiv: 2504.15989 by the authors.

Figure 1
Figure 1. An example of redundant reasoning caused by confusion between [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. The Ladder of Programming and AI. (1) Traditional coding paradigm: [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Illustration of the LLM-driven code generation workflow in real [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Experiment Design Process. The diagram shows the steps involved [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 6
Figure 6. Figure 6: Comparison of time-scaled token consumption between clean code [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]
Figure 7
Figure 7. Figure 7: Comparison of complexity-normalized token consumption before and [PITH_FULL_IMAGE:figures/full_fig_p006_7.png]
Figure 8
Figure 8. Figure 8: Average token growth rate per code smell type. [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]
Figure 9
Figure 9. Figure 9: Average token growth rate by code smell category. [PITH_FULL_IMAGE:figures/full_fig_p007_9.png]
Figure 10
Figure 10. Figure 10: Comparison of total token consumption for smelly code with and [PITH_FULL_IMAGE:figures/full_fig_p008_10.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. CodeAgents: A Token-Efficient Framework for Codified Multi-Agent Reasoning in LLMs

    cs.AI 2025-07 conditional novelty 5.0 of 10

    Rewriting multi-agent LLM prompts as pseudocode with assertions, replanning, and comments yields moderate accuracy gains and large token savings in the tests reported here, though some headline numbers are overstated.

Reference graph

Works this paper leans on

36 extracted references · 11 canonical work pages · cited by 1 Pith paper

  1. [6]

    When to Stop? Towards Efficient Code Generation in LLMs with Excess Token Prevention

    L. Guo, Y . Wang, E. Shi, W. Zhong, H. Zhang, J. Chen, R. Zhang, Y . Ma, and Z. Zheng, “When to stop? towards efficient code generation in llms with excess token prevention,” 2024. [Online]. Available: https://arxiv.org/abs/2407.20042

    work page Pith review arXiv 2024

  2. [8]

    Autol2s: Auto long-short reasoning for efficient large language models,

    F. Luo, Y .-N. Chuang, G. Wang, H. A. D. Le, S. Zhong, H. Liu, J. Yuan, Y . Sui, V . Braverman, V . Chaudhary, and X. Hu, “Autol2s: Auto long-short reasoning for efficient large language models,” 2025. [Online]. Available: https://arxiv.org/abs/2505.22662

    arXiv 2025

  3. [10]

    Demystifying long chain-of-thought reasoning in llms,

    E. Yeo, Y . Tong, M. Niu, G. Neubig, and X. Yue, “Demystifying long chain-of-thought reasoning in llms,” 2025. [Online]. Available: https://arxiv.org/abs/2502.03373

    arXiv 2025

  4. [26]

    Cothink: Token-efficient reasoning via instruct models guiding reasoning models,

    S. Fan, P. Han, S. Shang, Y . Wang, and A. Sun, “Cothink: Token-efficient reasoning via instruct models guiding reasoning models,” 2025. [Online]. Available: https://arxiv.org/abs/2505.22017

    arXiv 2025

  5. [1]

    Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning,

    DeepSeek-AI, D. Guo, D. Yang, H. Zhang, J. Song, R. Zhang, R. Xu, Q. Zhu, S. Ma, P. Wang, X. Bi, X. Zhang, X. Yu, Y . Wu, Z. F. Wu, Z. Gou, Z. Shao, Z. Li, Z. Gao, A. Liu, B. Xue, B. Wang, B. Wu, B. Feng, C. Lu, C. Zhao, C. Deng, C. Zhang, C. Ruan, D. Dai, D. Chen, D. Ji, E. Li, F. Lin, F. Dai, F. Luo, G. Hao, G. Chen, G. Li, H. Zhang, H. Bao, H. Xu, H. W...

    arXiv 2025

  6. [2]

    A study on prompt design, advantages and limitations of chatgpt for deep learning program repair,

    J. Cao, M. Li, M. Wen, and S. chi Cheung, “A study on prompt design, advantages and limitations of chatgpt for deep learning program repair,”

    work page

  7. [3]

    The code barrier: What llms actually understand?

    S. L. Nikiema, J. Samhi, A. K. Kabor ´e, J. Klein, and T. F. Bissyand ´e, “The code barrier: What llms actually understand?” arXiv preprint arXiv:2504.10557, 2025

    arXiv 2025

  8. [4]

    Large language models for software engineering: A systematic literature review,

    X. Hou, Y . Zhao, Y . Liu, Z. Yang, K. Wang, L. Li, X. Luo, D. Lo, J. Grundy, and H. Wang, “Large language models for software engineering: A systematic literature review,” 2024. [Online]. Available: https://arxiv.org/abs/2308.10620

    arXiv 2024

Show all 36 references
  1. [5]

    Distilling llm agent into small models with retrieval and code tools,

    M. Kang, J. Jeong, S. Lee, J. Cho, and S. J. Hwang, “Distilling llm agent into small models with retrieval and code tools,” 2025. [Online]. Available: https://arxiv.org/abs/2505.17612

    2025

  2. [7]

    Development in times of hype: How freelancers explore generative ai?

    M. Dolata, N. Lange, and G. Schwabe, “Development in times of hype: How freelancers explore generative ai?” in Proceedings of the IEEE/ACM 46th International Conference on Software Engineering , ser. ICSE ’24. ACM, Apr. 2024, p. 1–13. [Online]. Available: http://dx.doi.org/10....

    2024

  3. [9]

    Optimizing token usage on large language model conversations using the design structure matrix,

    R. M. G. Alarcia, “Optimizing token usage on large language model conversations using the design structure matrix,” in Proceedings of the 26th International DSM Conference (DSM 2024), Stuttgart, Germany , ser. DSM 2024. The Design Society, 2024, p. 069–078. [Online]. Available...

    2024 doi

  4. [11]

    Polymetric views - a lightweight visual approach to reverse engineering,

    M. Lanza and S. Ducasse, “Polymetric views - a lightweight visual approach to reverse engineering,” IEEE Transactions on Software Engineering, vol. 29, no. 9, pp. 782–795, 2003

    2003

  5. [12]

    USA: Addison- Wesley Longman Publishing Co., Inc., 1999

    Refactoring: improving the design of existing code . USA: Addison- Wesley Longman Publishing Co., Inc., 1999

    1999

  6. [13]

    Bad smells - humans as code critics,

    M. Mantyla, J. Vanhanen, and C. Lassenius, “Bad smells - humans as code critics,” in 20th IEEE International Conference on Software Maintenance, 2004. Proceedings. , 2004, pp. 399–408

    2004

  7. [14]

    A comprehensive evaluation of parameter-efficient fine-tuning on method-level code smell detection,

    B. Zhang, P. Liang, X. Zhou, X. Zhou, D. Lo, Q. Feng, Z. Li, and L. Li, “A comprehensive evaluation of parameter-efficient fine-tuning on method-level code smell detection,” 2024. [Online]. Available: https://arxiv.org/abs/2412.13801

    2024

  8. [15]

    Ai in software engineering: Perceived roles and their impact on adoption,

    I. Zakharov, E. Koshchenko, and A. Sergeyuk, “Ai in software engineering: Perceived roles and their impact on adoption,” 2025. [Online]. Available: https://arxiv.org/abs/2504.20329

    2025 arXiv

  9. [16]

    Envisioning the next-generation ai coding assistants: Insights & proposals,

    K. Nghiem, A. M. Nguyen, and N. D. Q. Bui, “Envisioning the next-generation ai coding assistants: Insights & proposals,” 2024. [Online]. Available: https://arxiv.org/abs/2403.14592

    2024 arXiv

  10. [17]

    A survey of neural code intelligence: Paradigms, advances and beyond,

    Q. Sun, Z. Chen, F. Xu, K. Cheng, C. Ma, Z. Yin, J. Wang, C. Han, R. Zhu, S. Yuan, Q. Guo, X. Qiu, P. Yin, X. Li, F. Yuan, L. Kong, X. Li, and Z. Wu, “A survey of neural code intelligence: Paradigms, advances and beyond,” 2025. [Online]. Available: https://arxiv.org/abs/2403.14734

    2025 arXiv

  11. [18]

    Data preparation for deep learning based code smell detection: A systematic literature review,

    F. Zhang, Z. Zhang, J. W. Keung, X. Tang, Z. Yang, X. Yu, and W. Hu, “Data preparation for deep learning based code smell detection: A systematic literature review,” 2024. [Online]. Available: https://arxiv.org/abs/2406.19240

    2024 arXiv

  12. [19]

    An empirical study on the code refactoring capability of large language models,

    J. Cordeiro, S. Noei, and Y . Zou, “An empirical study on the code refactoring capability of large language models,” 2024. [Online]. Available: https://arxiv.org/abs/2411.02320

    2024 arXiv

  13. [20]

    Uncertainty-aware molecular dynamics from bayesian active learning for phase transformations and thermal transport in sic,

    Y . Xie, J. Vandermause, S. Ramakers, N. H. Protik, A. Johansson, and B. Kozinsky, “Uncertainty-aware molecular dynamics from bayesian active learning for phase transformations and thermal transport in sic,”

  14. [21]

    Open-source ai-powered optimization in scalene: Advancing python performance profiling with deepseek-r1 and llama 3.2,

    S. Hasan and S. Basak, “Open-source ai-powered optimization in scalene: Advancing python performance profiling with deepseek-r1 and llama 3.2,” 2025. [Online]. Available: https://arxiv.org/abs/2502.10299

    2025 arXiv

  15. [22]

    Available: https://arxiv.org/abs/2203.03824

    [Online]. Available: https://arxiv.org/abs/2203.03824

    arXiv

  16. [23]

    Prompt learning for multi-label code smell detection: A promising approach,

    H. Liu, Y . Zhang, V . Saikrishna, Q. Tian, and K. Zheng, “Prompt learning for multi-label code smell detection: A promising approach,”

  17. [24]

    The impact of prompt programming on function-level code generation,

    R. Khojah, F. G. de Oliveira Neto, M. Mohamad, and P. Leitner, “The impact of prompt programming on function-level code generation,” 2024. [Online]. Available: https://arxiv.org/abs/2412.20545

    2024 arXiv

  18. [25]

    Research on compressed input sequences based on compiler tokenization,

    Z. Li and X. Lu, “Research on compressed input sequences based on compiler tokenization,” Information, vol. 16, no. 2, 2025. [Online]. Available: https://www.mdpi.com/2078-2489/16/2/73

    2025

  19. [27]

    Chain-of-thought tokens are computer program variables,

    F. Zhu, P. Wang, and Z. Sui, “Chain-of-thought tokens are computer program variables,” 2025. [Online]. Available: https: //arxiv.org/abs/2505.04955

    2025 arXiv

  20. [28]

    An empirical study on usage and perceptions of llms in a software engineering project,

    S. Rasnayaka, G. Wang, R. Shariffdeen, and G. N. Iyer, “An empirical study on usage and perceptions of llms in a software engineering project,” 2024. [Online]. Available: https://arxiv.org/abs/2401.16186

    2024 arXiv

  21. [29]

    Chain- of-thought in neural code generation: From and for lightweight language models,

    G. Yang, Y . Zhou, X. Chen, X. Zhang, T. Y . Zhuo, and T. Chen, “Chain- of-thought in neural code generation: From and for lightweight language models,” 2024. [Online]. Available: https://arxiv.org/abs/2312.05562

    2024 arXiv

  22. [30]

    How propense are large language models at producing code smells? a benchmarking study,

    A. Velasco, D. Rodriguez-Cardenas, L. R. Alif, D. N. Palacio, and D. Poshyvanyk, “How propense are large language models at producing code smells? a benchmarking study,” 2025. [Online]. Available: https://arxiv.org/abs/2412.18989

    2025 arXiv

  23. [31]

    Studying the usage of text-to-text transfer transformer to support code-related tasks,

    A. Mastropaolo, S. Scalabrino, N. Cooper, D. N. Palacio, D. Poshyvanyk, R. Oliveto, and G. Bavota, “Studying the usage of text-to-text transfer transformer to support code-related tasks,” 2021. [Online]. Available: https://arxiv.org/abs/2102.02017

    2021 arXiv

  24. [32]

    Codexglue: A machine learning benchmark dataset for code understanding and generation,

    S. Lu, D. Guo, S. Ren, J. Huang, A. Svyatkovskiy, A. Blanco, C. Clement, D. Drain, D. Jiang, D. Tang, G. Li, L. Zhou, L. Shou, L. Zhou, M. Tufano, M. Gong, M. Zhou, N. Duan, N. Sundaresan, S. K. Deng, S. Fu, and S. Liu, “Codexglue: A machine learning benchmark dataset for code...

    2021 arXiv

  25. [33]

    Code smells for machine learning applications,

    H. Zhang, L. Cruz, and A. van Deursen, “Code smells for machine learning applications,” 2022. [Online]. Available: https: //arxiv.org/abs/2203.13746

    2022 arXiv

  26. [36]

    From system 1 to system 2: A survey of reasoning large language models,

    Z.-Z. Li, D. Zhang, M.-L. Zhang, J. Zhang, Z. Liu, Y . Yao, H. Xu, J. Zheng, P.-J. Wang, X. Chen, Y . Zhang, F. Yin, J. Dong, Z. Guo, L. Song, and C.-L. Liu, “From system 1 to system 2: A survey of reasoning large language models,” 2025. [Online]. Available: https://arxiv.org/...

    2025 arXiv

  27. [2023]

    Available: https://arxiv.org/abs/2304.08191

    [Online]. Available: https://arxiv.org/abs/2304.08191

    arXiv

  28. [2024]

    Available: https://arxiv.org/abs/2402.10398

    [Online]. Available: https://arxiv.org/abs/2402.10398

    arXiv

Pith tools

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