Pith. sign in

REVIEW 4 major objections 8 minor 1 cited by

HLSDebugger: Identification and Correction of Logic Bugs in HLS Code with LLM Solutions

T0 review · 4 major / 8 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read HLSDebugger, a specialized encoder-decoder LLM trained on 300K synthetic HLS bugs, identifies and corrects logic bugs without test cases, outperforming GPT-4 by more than 3x in correction.

desk verdict Useful dataset and a sensible multitask model, but the headline 3x correction gain is partly an artifact of a substring-match metric that favors the fine-tuned model. read the letter →

arxiv 2507.21485 v1 pith:FGMN45BB submitted 2025-07-29 cs.SE cs.AI

Jing Wang , Shang Liu , Yao Lu , Zhiyao Xie This is my paper
classification cs.SEcs.AI
keywords high-levelsynthesislogicbugdebuggingencoder-decoderLLMlocalizationcorrectionHLSdatasetmulti-tasktraininglargelanguagemodels
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

HLSDebugger claims that HLS logic-bug debugging can be automated by a single fine-tuned encoder-decoder LLM that does not need golden test cases. The paper builds a large synthetic dataset of about 300K buggy HLS code samples, each labeled with the buggy snippet, the bug type, and the correction. The model jointly predicts the bug location and type with the encoder and generates the corrected snippet with the decoder, trained by a combined loss that balances identification and correction. On the eight-type benchmark, it reports 37.6% correction accuracy versus 10.5% for GPT-4, plus substantially higher precision and recall at every localization granularity. If the claim holds, it would mean a purpose-built open-source model can outperform a much larger commercial LLM on this specific debugging task.

What carries the argument

The load-bearing object is the encoder-decoder transformer with a combined training loss. The encoder processes the tokenized buggy code prefixed with a special [CLS] token; one MLP head reads the [CLS] embedding to predict the bug type, and another head assigns a bug/non-bug probability to every token. The decoder is a second transformer stack whose cross-attention layers take the encoder's embeddings as keys and values, letting the correction step attend to a soft representation of the buggy region rather than to an explicit, possibly wrong, localization string. The training objective sums a type cross-entropy loss, a token-level binary cross-entropy loss with class-imbalance scaling, and a maximum-likelihood generation loss, with the decoder loss weighted highest; this joint loss is what couples identification and correction in one model.

What would settle it

Run HLSDebugger on a held-out set of real HLS bug fixes drawn from version-control commit histories, comparing correction accuracy against GPT-4; if the gap narrows sharply or accuracy falls below 20%, the claim is confined to the synthetic training distribution.

Watch

Extended reading notes

Core claim

On its own terms, the paper's central claim is that HLS logic-bug debugging can be decomposed into bug type prediction, token-level bug location, and bug correction, and solved jointly by one encoder-decoder model fine-tuned on a large synthetic dataset. The encoder reads the buggy code and outputs both a bug-type classification and a per-token bug probability; the decoder generates the corrected snippet while attending to the encoder's context embeddings. The authors report that HLSDebugger corrects 37.6% of benchmark samples without being told where the bug is, versus 10.5% for GPT-4, and identifies the buggy line at 79.5% top-1 code-level accuracy. They also report that the same dataset improves a fine-tuned Gemma-7B from 7.5% to 15.1% correction accuracy, and that giving the ground-truth bug location raises HLSDebugger's correction accuracy to 49.1%.

Load-bearing premise

The model is trained and evaluated on bugs artificially inserted by GPT-3.5 from a fixed list of eight bug types, so the reported gains may not transfer to naturally occurring HLS bugs outside that list.

Editorial extensions

If this is right

  • Applying the same encoder-decoder recipe to other code domains without test cases should let bug localization be treated as a supervised token-classification task, avoiding the error accumulation of separate locate-then-correct prompts.
  • The released 300K-sample dataset is sufficient to lift an open-source 7B model's correction accuracy from 7.5% to 15.1% by supervised fine-tuning alone, so teams without access to large commercial models can still improve.
  • Because correction accuracy rises to 49.1% when the true buggy location is given, pairing HLSDebugger with an external locator (static analysis or another model) should push fix rates above the no-hint 37.6%.
  • The model's 87.6% code-wise top-5 line accuracy means a designer who checks up to five candidate lines will find the bug in most samples, which is a practical interaction pattern for a debugging assistant.

Reading between the lines

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

  • Our inference: the real test of the approach is out-of-distribution generalization, since the benchmark spans only the same eight synthetic bug types used for training; a version of the dataset built from real commit-based bug fixes would show whether the gain survives.
  • Our inference: the combined-loss idea should transfer to RTL and SystemVerilog debugging, where the same error-accumulation pathology appears when LLMs localize then fix; no HLS-specific mechanism is needed for the core argument.
  • Our inference: a cheap, testable extension is to vary the loss weighting alpha_decoder and measure the trade-off between identification and correction accuracy, which would reveal how tightly the two tasks are coupled.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 8 minor

Summary. The paper presents HLSDebugger, an encoder-decoder LLM (based on CodeT5-Large) fine-tuned for three HLS logic-debugging subtasks: bug type prediction, bug location identification, and bug correction. The authors construct and release a synthetic supervised dataset of about 300K samples by having GPT-3.5 insert one of eight logic-bug types into correct HLS code, then train a multi-task model with a combined loss. On a 2K-sample subset of the benchmark from [1], HLSDebugger achieves substantially higher bug-identification precision/recall than GPT-4, and 37.6% vs 10.5% strict-substring bug-correction accuracy, which the paper claims as a more than 3x improvement. They also show that providing the bug location improves correction for all models and that HLSDebugger remains best.

Significance. If the reported evaluation is taken at face value, the paper makes a useful contribution: a large open dataset, an open-source fine-tuned model, and a multi-task formulation are potentially valuable for the HLS community. The identification gains are large and internally consistent. However, the central quantitative claim about bug correction rests on an evaluation metric that is biased toward the fine-tuned model, and the training distribution closely mirrors the test benchmark. The actual advance is therefore currently uncertain and requires additional evaluation to be established.

major comments (4)
  1. [V-C, Table III] The bug-correction accuracy is measured by 'strict substring match' between the processed generated text and the canonical correct-snippet label. Since the HLSDebugger decoder is trained with MLE (Eq. 5) on exactly these canonical snippets, the model is directly optimized to reproduce the evaluation signal, whereas the GPT-4 baseline is zero-shot and likely to produce semantically correct fixes that differ lexically. A substring match also does not verify that the repaired HLS code compiles or preserves intended behavior. The reported 37.6% vs 10.5% (3.6x) is therefore not yet evidence of a 3.6x functional improvement. Please add an execution-based or semantic-equivalence evaluation (e.g., compile and run the repaired code on test benches, or use a metric tolerant to variable renaming and statement reordering), and report the results for all models.
  2. [IV-A and V-A] The synthetic training data are generated by inserting exactly the same eight bug types that appear in the test benchmark, and the label format (buggy snippet, correct snippet) is identical. This means the reported performance reflects the model's ability to reproduce the distribution used to create the benchmark, not necessarily its ability to find and fix naturally occurring HLS logic bugs. The paper should report performance on held-out naturally occurring buggy HLS code, or explicitly frame the benchmark as an in-distribution stress test. Also, Section IV-A states the bug list contains '18 types of logic bugs,' but Section V-A lists only 8; please reconcile this discrepancy.
  3. [V-B and References] The test benchmark from reference [1] lists J. Wang as a co-author, who is also the first author of the current paper. The paper does not disclose this overlap. The ROUGE-L filtering (Section V-B) removes code samples with high similarity to the test benchmark, but it does not address potential overlap in the bug-type and label-generation pipelines. Because both training and test sets use GPT-3.5-style generated snippets, the strict-match evaluation may be influenced by label-generation artifacts. Please disclose the overlap and provide a quantitative analysis of how the bug snippets in the test benchmark differ from those in the training distribution (e.g., lexical overlap, snippet length, edit distance).
  4. [VI] The headline differences (e.g., 37.6% vs 10.5% in Table III, and Table II identification metrics) are reported without confidence intervals or significance tests. The authors state that accuracies converge after 500 samples, but this is not a substitute for uncertainty quantification. Please provide bootstrap confidence intervals or a paired significance test over the 2K benchmark samples, especially for the comparison with GPT-4.
minor comments (8)
  1. [Algorithm 1] Line 12 uses 'E<start/>', which is not defined in the notation; it should be the start-token embedding or the start-token sequence, and the decoder input is not clearly specified.
  2. [Eq. (5)] The notation 'log Decoder(<start/>||{c<k i })' omits the conditioning on the encoder context; please make the probability explicit, e.g., log p(c_k | c_<k, E_1, ..., E_N).
  3. [Section IV-A] GPT-3.5 is cited to the GPT-4 technical report [19]; please provide the correct reference for GPT-3.5.
  4. [Section V-C] The definition of 'strict substring match' is vague: what exactly is 'processed' and how is a match determined? Please provide a concrete example of an accepted and a rejected output.
  5. [Section V-A] The test set is described as 'randomly selected 2K samples from the benchmark in [1]'; please report the exact split seed and the per-bug-type composition to allow reproducibility.
  6. [Abstract] The abstract contains a broken sentence: 'The absence of reliable test cases requires multi-tasking solutions, performing both bug identification and correction. complicates the multi-tasking required for effective HLS debugging.' This needs rewriting.
  7. [Section IV-A] The text says the dataset samples start with 'module' and end with 'end module', but the HLS code examples in Figure 1 are C++ functions; please clarify this mismatch between HLS code and Verilog-style keywords.
  8. [Section VIII] The conclusion says 'HLSDebugger first generates a large-scale labeled dataset'; this should be 'the authors generate', since the model does not generate the dataset.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the central comparison is against an external benchmark, and the metric, while lexical, is not a constructed alias of the training labels.

full rationale

The paper's claims are empirical rather than derivational. The 300K-sample training set is generated by the authors from crawled GitHub code and GPT-3.5-augmented RTLCoder conversions (Section IV-A), while the evaluation benchmark is taken from Wan et al. [1] (Section V-A), a distinct source. The authors additionally filter training samples with Rouge-L similarity above 0.5 against the benchmark to reduce leakage (Section V-B). The bug-correction metric is a strict substring match against the canonical correct-snippet label (Section V-C), and the decoder is trained with the MLE loss of exactly such snippets (Eq. 5). This alignment can inflate the measured advantage over zero-shot GPT-4, since HLSDebugger is optimized for the label format, but it does not constitute circularity: the test labels are not used in training and the model is not fitted to the evaluation subset. The use of the same eight bug types in synthetic training as in the benchmark reflects a shared taxonomy from [1], not an equation-level reduction. Self-citations, e.g., to RTLCoder [11] for data augmentation, are present but not load-bearing: the encoder-decoder architecture, combined loss (Eq. 6), and evaluation protocol stand independently. No step in the claimed derivation chain reduces by definition to its own input.

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

The central results depend on a set of manually tuned hyperparameters (loss weights, filtering threshold) and on the domain-specific assumption that a fixed eight-type bug taxonomy and synthetic bug insertion capture the structure of real HLS bugs. No new physical or mathematical entities are introduced.

free parameters (3)
  • Loss scaling factors alpha_type, alpha_bug, alpha_generated = 0.2, 2, 10
    The paper sets these hyperparameters manually to balance bug type, bug location, and correction generation losses; the values are not learned and different values could alter the reported performance.
  • Token loss weighting alpha_t and alpha_f = 0.05 and 1
    These weights adjust the imbalance between buggy and non-buggy tokens in the location classification loss; they are chosen by hand and are central to the reported precision-recall trade-off.
  • Rouge-L similarity threshold for training-test overlap filtering = 0.5
    Code samples with Rouge-L similarity greater than 0.5 to the test benchmark are removed; this threshold is a design choice that affects the training set composition.
assumptions (3)
  • domain assumption HLS logic bugs can be categorized into the eight types from the benchmark [1].
    The dataset generation and evaluation both rely on this fixed taxonomy; if real-world HLS bugs are more diverse, the model's relevance is limited.
  • domain assumption Bugs inserted by GPT-3.5 into correct code are representative of natural HLS logic bugs.
    The synthetic dataset is the sole training signal, and no human validation or real-world bug corpus is used to confirm that the inserted bugs resemble those that designers actually make.
  • standard math The encoder-decoder transformer architecture is suitable for token-level classification and sequence generation on code.
    The method inherits the standard statistical learning and transformer assumptions; no new mathematical foundation is required.

how reviews work

0 comments
Cite this review

Pith. "Pith review of HLSDebugger: Identification and Correction of Logic Bugs in HLS Code with LLM Solutions." pith.science (2026). https://pith.science/paper/FGMN45BB

@misc{pith2026250721485,
  author       = {Pith},
  title        = {Pith review of: HLSDebugger: Identification and Correction of Logic Bugs in HLS Code with LLM Solutions},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FGMN45BB}},
  note         = {Machine review of arXiv:2507.21485}
}
read the original abstract

High-level synthesis (HLS) accelerates hardware design by enabling the automatic translation of high-level descriptions into efficient hardware implementations. However, debugging HLS code is a challenging and labor-intensive task, especially for novice circuit designers or software engineers without sufficient hardware domain knowledge. The recent emergence of Large Language Models (LLMs) is promising in automating the HLS debugging process. Despite the great potential, three key challenges persist when applying LLMs to HLS logic debugging: 1) High-quality circuit data for training LLMs is scarce, posing a significant challenge. 2) Debugging logic bugs in hardware is inherently more complex than identifying software bugs with existing golden test cases. 3) The absence of reliable test cases requires multi-tasking solutions, performing both bug identification and correction. complicates the multi-tasking required for effective HLS debugging. In this work, we propose a customized solution named HLSDebugger to address the challenges. HLSDebugger first generates and releases a large labeled dataset with 300K data samples, targeting HLS logic bugs. The HLSDebugger model adopts an encoder-decoder structure, performing bug location identification, bug type prediction, and bug correction with the same model. HLSDebugger significantly outperforms advanced LLMs like GPT-4 in bug identification and by more than 3x in bug correction. It makes a substantial advancement in the exploration of automated debugging of HLS code.

Figures

Figures reproduced from arXiv: 2507.21485 by the authors.

Figure 1
Figure 1. Comparison between traditional LLM solutions on debugging [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Our proposed dataset generation flow in HLSDebugger. It consists of two parts: 1) unsupervised dataset collection and 2) supervised [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 4
Figure 4. The inference and training schematic for HLS Encoder. Given [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figures from the paper (4 more)
Figure 3
Figure 3. Figure 3: Our supervised dataset creation process involves three steps: [PITH_FULL_IMAGE:figures/full_fig_p004_3.png]
Figure 6
Figure 6. Figure 6: Combination of encoder objective and decoder objective for the encoder-decoder training scheme. ck, which can be denoted as {c {i<k} i }. ck = Decoder(<start/>||{c i<k i }, {Ecls, E1, ..., EN }) (3) ck represents the kth token of the correct code snippet sequence sgen.…
Figure 8
Figure 8. Figure 8: Bug correction accuracy of three models on different bug [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]
Figure 7
Figure 7. Figure 7: Bug identification performance of different LLM solutions on [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]

Discussion (0). Sign in 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. ChipVerilog: A Large-Scale OpenCores-Derived Benchmark for LLM-Based Verilog RTL Generation

    cs.AR 2026-07 conditional novelty 5.0 of 10

    On 64 large OpenCores-derived Verilog tasks, top LLMs reach 23.6% functional pass@1, 37.5% pass@5, and 0% on designs with two or more submodules, showing hierarchical RTL generation remains unsolved.

Reference graph

Works this paper leans on

27 extracted references · 15 canonical work pages · cited by 1 Pith paper

  1. [1]

    Invited paper: Software/hardware co-design for llm and its application for design verification,

    L. J. Wan, Y . Huang, Y . Li, H. Ye, J. Wang, X. Zhang, and D. Chen, “Invited paper: Software/hardware co-design for llm and its application for design verification,” in In ASP-DAC, 2024, pp. 435–441

    work page 2024

  2. [2]

    CREF: An LLM-based Conversational Software Repair Framework for Programming Tutors

    B. Yang, H. Tian, W. Pian, H. Yu, H. Wang, J. Klein, T. F. Bissyand´e, and S. Jin, “Cref: An llm-based conversational software repair framework for programming tutors,” arXiv preprint arXiv:2406.13972 , 2024

    work page Pith review arXiv 2024

  3. [3]

    Agentfl: Scaling llm-based fault localization to project-level context,

    Y . Qin, S. Wang, Y . Lou, J. Dong, K. Wang, X. Li, and X. Mao, “Agentfl: Scaling llm-based fault localization to project-level context,” arXiv preprint arXiv:2403.16362 , 2024

    arXiv 2024

  4. [4]

    A unified debugging approach via llm-based multi-agent synergy,

    C. Lee, C. S. Xia, J.-t. Huang, Z. Zhu, L. Zhang, and M. R. Lyu, “A unified debugging approach via llm-based multi-agent synergy,” 2024

    work page 2024

  5. [5]

    Aligning llms for fl-free program repair,

    J. Xu, Y . Fu, S. H. Tan, and P. He, “Aligning llms for fl-free program repair,” arXiv preprint arXiv:2404.08877 , 2024

    arXiv 2024

  6. [6]

    ChatDBG: Augmenting Debugging with Large Language Models

    K. Levin, N. van Kempen, E. D. Berger, and S. N. Freund, “Chatdbg: An ai-powered debugging assistant,” arXiv preprint arXiv:2403.16354 , 2024

    work page Pith review arXiv 2024

  7. [7]

    Ldb: A large language model debugger via verifying runtime execution step-by-step,

    L. Zhong, Z. Wang, and J. Shang, “Ldb: A large language model debugger via verifying runtime execution step-by-step,” arXiv preprint arXiv:2402.16906, 2024

    arXiv 2024

  8. [8]

    Rtlfixer: Automatically fixing rtl syntax errors with large language models,

    Y . Tsai, M. Liu, and H. Ren, “Rtlfixer: Automatically fixing rtl syntax errors with large language models,” 2023

    work page 2023

Show all 27 references
  1. [9]

    Hdldebugger: Streamlining hdl debugging with large language models,

    X. Yao, H. Li, T. H. Chan, W. Xiao, M. Yuan, Y . Huang, L. Chen, and B. Yu, “Hdldebugger: Streamlining hdl debugging with large language models,” arXiv preprint arXiv:2403.11671 , 2024

    2024 arXiv

  2. [10]

    Llm4sechw: Leveraging domain-specific large language model for hardware debug- ging,

    W. Fu, K. Yang, R. G. Dutta, X. Guo, and G. Qu, “Llm4sechw: Leveraging domain-specific large language model for hardware debug- ging,” in 2023 Asian Hardware Oriented Security and Trust Symposium (AsianHOST). IEEE, 2023, pp. 1–6

    2023

  3. [11]

    Rtlcoder: Outperforming gpt-3.5 in design rtl generation with our open-source dataset and lightweight solution,

    S. Liu, W. Fang, Y . Lu, Q. Zhang, H. Zhang, and Z. Xie, “Rtlcoder: Outperforming gpt-3.5 in design rtl generation with our open-source dataset and lightweight solution,” 2023

    2023

  4. [12]

    Mg-verilog: Multi-grained dataset to- wards enhanced llm-assisted verilog generation,

    Y . Zhang, Z. Yu et al. , “Mg-verilog: Multi-grained dataset to- wards enhanced llm-assisted verilog generation,” arXiv preprint arXiv:2407.01910, 2024

    2024 arXiv

  5. [13]

    Quixbugs: a multi- lingual program repair benchmark set based on the quixey challenge,

    D. Lin, J. Koppel, A. Chen, and A. Solar-Lezama, “Quixbugs: a multi- lingual program repair benchmark set based on the quixey challenge,” in Proceedings Companion of the 2017 ACM SIGPLAN International Conference on Systems, Programming, Languages, and Applications: Software fo...

    2017

  6. [14]

    Codeflow: Improving the code review process at microsoft: A discussion with jacek czerwonka, michaela greiler, christian bird, lucas panjer, and terry coatta,

    J. Czerwonka, M. Greiler, C. Bird, L. Panjer, and T. Coatta, “Codeflow: Improving the code review process at microsoft: A discussion with jacek czerwonka, michaela greiler, christian bird, lucas panjer, and terry coatta,” Queue, vol. 16, no. 5, oct 2018

    2018

  7. [15]

    Verilogreader: Llm-aided hardware test generation,

    R. Ma, Y . Yang, Z. Liu, J. Zhang, M. Li, J. Huang, and G. Luo, “Verilogreader: Llm-aided hardware test generation,” 2024

    2024

  8. [16]

    Explaining eda synthesis errors with llms,

    S. Qiu, B. Tan, and H. Pearce, “Explaining eda synthesis errors with llms,” arXiv preprint arXiv:2404.07235 , 2024

    2024 arXiv

  9. [17]

    C2hlsc: Can llms bridge the software- to-hardware design gap?

    L. Collini, S. Garg, and R. Karri, “C2hlsc: Can llms bridge the software- to-hardware design gap?” arXiv preprint arXiv:2406.09233 , 2024

    2024 arXiv

  10. [18]

    Hlspilot: Llm-based high-level synthesis,

    C. Xiong, C. Liu, H. Li, and X. Li, “Hlspilot: Llm-based high-level synthesis,” 2024

    2024

  11. [19]

    Gpt-4 technical report,

    J. Achiam, S. Adler, S. Agarwal, L. Ahmad, I. Akkaya, F. L. Aleman, D. Almeida, J. Altenschmidt, S. Altman, S. Anadkat et al. , “Gpt-4 technical report,” arXiv preprint arXiv:2303.08774 , 2023

    2023 arXiv

  12. [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,” Advances in neural information processing systems , vol. 30, 2017

    2017

  13. [21]

    Gemma: Open models based on gemini research and technology,

    G. Team, T. Mesnard, C. Hardin, R. Dadashi, S. Bhupatiraju, S. Pathak, L. Sifre, M. Rivi `ere, M. S. Kale, J. Love et al. , “Gemma: Open models based on gemini research and technology,” arXiv preprint arXiv:2403.08295, 2024

    2024 arXiv

  14. [22]

    Codet5: Identifier- aware unified pre-trained encoder-decoder models for code understand- ing and generation,

    Y . Wang, W. Wang, S. R. Joty, and S. C. H. Hoi, “Codet5: Identifier- aware unified pre-trained encoder-decoder models for code understand- ing and generation,” ArXiv, 2021

    2021

  15. [23]

    ROUGE: A package for automatic evaluation of summaries,

    C.-Y . Lin, “ROUGE: A package for automatic evaluation of summaries,” in Text Summarization Branches Out . Barcelona, Spain: Association for Computational Linguistics, Jul. 2004

    2004

  16. [24]

    The use of the area under the roc curve in the evaluation of machine learning algorithms,

    A. P. Bradley, “The use of the area under the roc curve in the evaluation of machine learning algorithms,” Pattern recognition, vol. 30, no. 7, pp. 1145–1159, 1997

    1997

  17. [25]

    Mistral 7b,

    A. Q. Jiang, A. Sablayrolles, A. Mensch, C. Bamford, D. S. Chaplot, D. d. l. Casas, F. Bressand, G. Lengyel, G. Lample, L. Saulnier et al., “Mistral 7b,” arXiv preprint arXiv:2310.06825 , 2023

    2023 arXiv

  18. [26]

    Deepseek-coder: When the large language model meets programming–the rise of code intelligence,

    D. Guo, Q. Zhu, D. Yang, Z. Xie, K. Dong, W. Zhang, G. Chen, X. Bi, Y . Wu, Y . Liet al. , “Deepseek-coder: When the large language model meets programming–the rise of code intelligence,” 2024

    2024

  19. [27]

    Code llama: Open foundation models for code,

    B. Roziere, J. Gehring, F. Gloeckle, S. Sootla, I. Gat, X. E. Tan, Y . Adi, J. Liu, T. Remez, J. Rapin et al., “Code llama: Open foundation models for code,” 2023

    2023

Pith tools

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