Pith. sign in

REVIEW 4 major objections 5 minor 1 cited by

Generating Automotive Code: Large Language Models for Software Development and Verification in Safety-Critical Systems

T0 review · 4 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read The paper claims that a locally deployed 7-billion-parameter LLM, steered by static checks and simulation feedback, can generate an adaptive cruise control function that respects the distance and acceleration constraints derived from ISO…

desk verdict Competent systems paper with a coherent framework and a plausible case study; the safety-compliance claim outruns the evidence, and the speed-dependent clearance requirement is not checkable from the reported data. read the letter →

arxiv 2506.04038 v1 pith:ZW3NIIVS submitted 2025-06-04 cs.SE cs.AI

Sven Kirchner , Alois C. Knoll This is my paper
classification cs.SEcs.AI
keywords largelanguagemodelssafety-criticalsoftwareadaptivecruisecontroltest-drivendevelopmentstaticanalysissimulationintegrationautomotivecodegeneration
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 a large language model can serve as an active participant in the automotive software development cycle, generating safety-relevant C++ code rather than only suggesting snippets. The proposed approach wraps the LLM in a feedback loop of static validation (structure, compilation, cppcheck/MISRA, unit tests) and integration monitoring in the CARLA simulator, with error feedback driving iterative regeneration. The authors validate this pipeline by generating an Adaptive Cruise Control function with Qwen2.5-Coder-7B-Instruct and report that all three independent generation runs maintain a following distance near the nominal 10 meters and keep acceleration within $|a| < 5$ m/s$^2$, including emergency braking. If those results hold, the framework is a template for using locally deployable LLMs in safety-critical automotive software while keeping classical quality gates in place.

What carries the argument

The load-bearing mechanism is a three-state safety state machine over software versions — static states, verified states, and safe states. The LLM handler regenerates code from error feedback each iteration; the Static Validation Module applies structure check, compilation check, cppcheck/MISRA style and semantic analysis, and Google Test unit tests; the Integration Monitoring Module then runs the code in CARLA through defined system APIs while a monitoring agent compares behavior against user-supplied system behaviour specifications. A "safe state" is defined as meeting all static criteria plus all integration criteria, and reaching that state is what the paper treats as compliance with the safety requirements.

What would settle it

Run the same three generations with the CARLA integration test extended to include a lead vehicle that brakes harder than the tested emergency scenario; if any generated function violates the minimum clearance condition or exceeds the $5\,\mathrm{m/s^2}$ braking threshold, the claim to ensure compliance would be contradicted.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central discovery is that a small, locally deployable LLM — Qwen2.5-Coder-7B-Instruct — can generate a safety-compliant ACC module when generation is embedded in an iterative lifecycle rather than used as a one-shot code writer. Across three independent generation runs, the code required on average 16.3 static iterations to pass all static checks, with unit testing the most demanding check at about 8 iterations and cppcheck/MISRA analysis about 4.3. The claim then moves to the integration state: with randomized lead-vehicle behavior in CARLA, the generated functions keep the following distance near 10 meters, respect the minimum clearance condition $\max(c_{\min}, \tau\cdot v)$, and never let $|a|$ exceed $5$ m/s$^2$, even under emergency braking.

Load-bearing premise

The safety conclusion rests on the assumption that passing the framework's static and integration checks is sufficient evidence of safety compliance, an assumption the paper itself does not formally prove.

Editorial extensions

If this is right

  • Safety gates remain in force: no generated version reaches integration until it compiles, passes cppcheck/MISRA analysis, and passes unit tests, so the LLM accelerates authoring without removing verification.
  • The same three-stage structure can be reapplied to other automotive functions whose requirements can be written as mathematical conditions, such as minimum clearance or acceleration bounds.
  • A 7B-parameter locally deployed model proved sufficient, so the approach does not require sending proprietary automotive data to external APIs.
  • Refinement cost concentrates in unit testing, which took roughly twice as many iterations as MISRA checks; improving test-suite construction would have the largest effect on time-to-safe-state.

Reading between the lines

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

  • Extension: the paper's "safe state" is an empirical check, not a proof; connecting the CARLA monitoring agent to formal runtime verification or reachability analysis would convert the same pipeline claim into a guarantee.
  • Extension: the randomized lead-vehicle scenario's coverage is not quantified, so a sensitivity study across braking profiles, cut-ins, and sensor noise would show how much of the requirement space the integration test actually exercises.
  • Extension: because the framework encodes requirements as mathematical expressions in JSON/YAML, the same machinery could be adapted to other standards, turning standards text into machine-checkable behavioural specifications.
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 / 5 minor

Summary. The paper proposes a framework that inserts LLM-generated code into a software development lifecycle for safety-critical automotive systems, combining static checks (structure, compilation, cppcheck/MISRA, unit tests) with CARLA-based integration monitoring and iterative refinement. The case study generates an Adaptive Cruise Control (ACC) function using Qwen2.5-Coder-7B-Instruct and reports iteration counts, following-distance traces, and acceleration traces for three independent runs, claiming compliance with ISO 15622-inspired minimum-clearance and acceleration requirements.

Significance. If the compliance claim were properly supported, the framework would be a useful template for LLM-assisted automotive software development. The paper's strengths are the explicit pipeline, the randomized lead-vehicle behavior in integration testing, and the use of benchmark-based LLM selection. However, the evaluation is too thin to support the general claim of 'ensuring compliance'; the current contribution is best read as a demonstration of an iterative generation-and-validation workflow rather than a verified safety process. The paper does not provide machine-checked proofs, code, or data, and the central quantitative requirement cannot be checked from the reported figures.

major comments (4)
  1. [IV.B, IV.C, Eq. (1)] The central quantitative requirement, Eq. (1), cannot be evaluated from the reported data because the paper never states c_min, tau_min, or the ego-vehicle speed profile v(t). Figure 7 shows following distances between roughly 8 m and 12 m; for any standard parameterization such as tau_min = 1 s and c_min = 2 m, a speed of 12 m/s requires 12 m clearance, so the displayed distances would violate Eq. (1). Without the parameter values and speed data, the claim in Section IV.C that the functions show 'consistent compliance with the defined requirements' is unsupported and not reproducible.
  2. [IV.C, Figures 7-8] The evaluation rests on three independent runs with no confidence intervals, no baseline controller comparison, and no sensitivity analysis. The 12-second randomized scenarios cover only a small slice of the speed and headway space over which Eq. (1) must hold, so the visual similarity of the three traces does not substantiate the general 'ensuring compliance' claim in the abstract or the closing sentence of Section IV.C.
  3. [III.A and V] The paper defines a 'Safe State' as any state that passes the framework's static and integration criteria (Section III.A), and Section V explicitly defers mathematical correctness guarantees to future work. Consequently, the abstract's statement that the framework 'ensuring compliance with safety-critical requirements' is an overclaim; the paper can honestly claim that the generated code passed a specified set of checks, not that it is safety-compliant in the normative, standard-certification sense.
  4. [IV.B, IV.C, Eq. (2)] Equation (2) applies only when no emergency brake is applied, but Section IV.C says the deceleration remains within the threshold even under emergency conditions. The paper should clarify whether emergency braking occurred in the logged runs and whether the 5 m/s^2 limit is supposed to apply at those times; Figure 8 shows the y-axis extended to -6 m/s^2, and it is not clear from the figure whether any samples violate the stated threshold.
minor comments (5)
  1. [II.B and III.B] There are several typographical issues, including 'because of to its balance' in Section II.B and 'Y AML', 'LLMS', and 'The framework integrates zero-shot' in Section III.B; a proofreading pass is needed.
  2. [IV.C, Figure 6] The caption of Figure 6 states averages (e.g., 'an average of 16.3 iterations'), but the figure appears to show bar heights without error bars or per-run values, so the reported averages cannot be checked from the figure alone.
  3. [Table I] The benchmark scores in Table I are reported as single percentages without variance, number of samples, or sampling temperature; these details matter for Pass@1 comparisons and should be included, at least in a footnote.
  4. [Contributions and Section III.C] The contributions list mentions 'formal verification', but the described pipeline contains only static analysis and simulation-based integration monitoring; either replace the term with 'static analysis and integration validation' or add an actual formal-verification component such as model checking or deductive verification.
  5. [References] Some references are incomplete for a journal submission: the ISO 15622 entry [36] lacks the publication year and edition, and the Aider benchmark [30] is cited only by a GitHub URL; full bibliographic details should be added.

Circularity Check

1 steps flagged · score 1.0 of 10

No significant circularity: the ACC 'compliance' result is an empirical validation against externally stated ISO 15622 criteria, not a fitted or self-cited derivation.

  1. self definitional [Section III.A, Figure 3 caption]
    "The ”Verified State” is achieved upon successful completion of static testing. ”Safe States” are achieved after meeting static and integration test criteria."

    This labels the validation outcome: a 'Safe State' is by definition the state that passes the framework's own static and integration tests. Consequently, statements such as 'ensuring compliance with safety-critical requirements' in the abstract and Section V depend in part on this definition rather than on an independent safety proof. The circularity is limited because the tests themselves are anchored to externally specified ISO 15622 criteria (Eq. 1, Eq. 2, and the 10 m nominal gap) and to randomized lead-vehicle simulation, so the reported distance and acceleration plots are not tautological.

full rationale

The paper's derivation chain is an empirical generation-and-validation loop, not a mathematical derivation with fitted parameters. The safety requirements (Eq. 1: minimum clearance at least MAX(cmin, tau_min * v); Eq. 2: |a| < 5 m/s^2; nominal 10 m following distance) are stated as inputs from ISO 15622. The framework generates ACC code with Qwen2.5-Coder-7B-Instruct, then evaluates the code against those same externally defined criteria through static checks and a CARLA integration test with randomized lead-vehicle behavior. There are no fitted parameters disguised as predictions: the LLM benchmark selection in Table I uses published benchmarks (Aider, McEval, HumanEval) and does not fit anything to the ACC outcome. There are also no load-bearing self-citations; the reference list contains no works by the authors. The only mildly self-referential element is the Section III.A definition of a 'Safe State' as the state that passes the framework's own checks, which makes the phrase 'safe' partly a labeling choice. However, the checks are not vacuous by construction: they are concrete ISO-derived quantitative conditions, and the integration evaluation uses randomized lead-vehicle scenarios rather than the exact training/fitting cases. The acknowledged lack of formal proofs in Section V ('mathematical guarantees to prove software correctness' as future work) is a completeness and correctness risk, not circularity. Therefore the central claim retains independent empirical content and the paper does not reduce to its own inputs.

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

The central claim rests on domain assumptions about what counts as verification and about simulator validity, plus hand-set validation thresholds, rather than on a mathematical derivation. No new physical or formal entities are postulated.

free parameters (4)
  • Nominal following distance = 10 m
    Set by the authors as an optimal balance between safety and comfort (Section IV.B); used as a validation target in integration monitoring.
  • Maximum acceleration magnitude = 5 m/s^2
    Chosen as the comfort and safety limit for non-emergency braking (Section IV.B, Eq. 2); the paper uses it as the pass/fail threshold in Figure 8.
  • Integration test duration = 12 s
    The reported trajectories run from 0 to 12 s (Figures 7 and 8); the choice is not justified and affects how much behavior is seen.
  • Evaluation sample size = 3 generations
    Three independent generations are used to estimate iteration counts and behavior (Section IV.C); no power analysis or statistical significance is reported.
assumptions (3)
  • domain assumption Passing the framework's static checks and integration test defines a 'Safe State' and is treated as safety compliance.
    Section III.A says a safe state is achieved when static and integration criteria are conclusively met; the abstract converts this into 'ensuring compliance with safety-critical requirements'.
  • domain assumption CARLA with synthetic sensor data and ground-truth monitoring is a valid proxy for real-world ACC behavior.
    Section III.D uses CARLA as the simulation environment; no real-vehicle or closed-track validation is provided.
  • domain assumption Withholding specific unit-test failure details still gives the LLM enough feedback to converge without overfitting.
    Section III.C states failure details are withheld to prevent overfitting, but convergence and generalization are not separately measured.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Generating Automotive Code: Large Language Models for Software Development and Verification in Safety-Critical Systems." pith.science (2026). https://pith.science/paper/ZW3NIIVS

@misc{pith2026250604038,
  author       = {Pith},
  title        = {Pith review of: Generating Automotive Code: Large Language Models for Software Development and Verification in Safety-Critical Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ZW3NIIVS}},
  note         = {Machine review of arXiv:2506.04038}
}
read the original abstract

Developing safety-critical automotive software presents significant challenges due to increasing system complexity and strict regulatory demands. This paper proposes a novel framework integrating Generative Artificial Intelligence (GenAI) into the Software Development Lifecycle (SDLC). The framework uses Large Language Models (LLMs) to automate code generation in languages such as C++, incorporating safety-focused practices such as static verification, test-driven development and iterative refinement. A feedback-driven pipeline ensures the integration of test, simulation and verification for compliance with safety standards. The framework is validated through the development of an Adaptive Cruise Control (ACC) system. Comparative benchmarking of LLMs ensures optimal model selection for accuracy and reliability. Results demonstrate that the framework enables automatic code generation while ensuring compliance with safety-critical requirements, systematically integrating GenAI into automotive software engineering. This work advances the use of AI in safety-critical domains, bridging the gap between state-of-the-art generative models and real-world safety requirements.

Figures

Figures reproduced from arXiv: 2506.04038 by the authors.

Figure 1
Figure 1. Introduction of Attention Mechanism and Transformer Architecture in Large Language Models for Code Generation. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. The code generation architecture consists of three components: the LLM handler (light blue), the static validation [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Software versions are categorized by safety clas [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: The integration monitoring framework consists of [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: ISO 15622 (Intelligent Transport Systems: Adaptive [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: Across three independent code generation runs using [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 8
Figure 8. Figure 8: The acceleration profiles over time show the typical [PITH_FULL_IMAGE:figures/full_fig_p007_8.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. Survey of GenAI for Automotive Software Development: From Requirements to Executable Code

    cs.SE 2025-07 conditional novelty 3.0 of 10

    A review of roughly 60 papers and 9 industry respondents finds GPT-family models dominate automotive code generation while requirements handling lags due to confidentiality constraints.

Reference graph

Works this paper leans on

38 extracted references · 26 canonical work pages · cited by 1 Pith paper

  1. [1]

    Software Engineering: A Practitioner’s Approach

    Roger Pressman. Software Engineering: A Practitioner’s Approach. 7th ed. USA: McGraw-Hill, Inc., 2009. ISBN : 0073375977

    work page 2009

  2. [2]

    A Standard Driven Software Architecture for Fully Autonomous Vehicles

    Alexandru Constantin Serban et al. “A Standard Driven Software Architecture for Fully Autonomous Vehicles”. In: 2018 IEEE International Conference on Software Architec- ture Companion (ICSA-C) . 2018, pp. 120–127. DOI: 10 . 1109/ICSA-C.2018.00040

    arXiv 2018

  3. [3]

    Brown et al

    Tom B. Brown et al. Language Models are Few-Shot Learn- ers. 2020. arXiv: 2005.14165 [cs.CL] . URL: https: //arxiv.org/abs/2005.14165

    arXiv 2020

  4. [4]

    CARLA: An Open Urban Driving Simulator

    Alexey Dosovitskiy et al. CARLA: An Open Urban Driving Simulator. 2017. arXiv: 1711 . 03938 [cs.LG] . URL: https://arxiv.org/abs/1711.03938

    arXiv 2017

  5. [5]

    Software Engineering

    Ian Sommerville. Software Engineering. 9th. Boston, MA, USA: Addison-Wesley, 2011

    work page 2011

  6. [6]

    Pressman

    Roger S. Pressman. Software Engineering: A Practitioner’s Approach. 8th. New York, NY , USA: McGraw-Hill, 2014

    work page 2014

  7. [7]

    Database System Concepts

    Abraham Silberschatz et al. Database System Concepts. 7th. New York, NY , USA: McGraw-Hill, 2020

    work page 2020

  8. [8]

    Software Architecture in Practice

    Len Bass et al. Software Architecture in Practice . 3rd. Boston, MA, USA: Addison-Wesley, 2012

    work page 2012

Show all 38 references
  1. [9]

    Test-Driven Development by Example

    Kent Beck. Test-Driven Development by Example . Boston, MA, USA: Addison-Wesley, 2003

    2003

  2. [10]

    Nicholas J. Higham. Accuracy and Stability of Numerical Algorithms. 2nd. Philadelphia, PA, USA: Society for Indus- trial and Applied Mathematics (SIAM), 2002

    2002

  3. [11]

    Patterns of Enterprise Application Architec- ture

    Martin Fowler. Patterns of Enterprise Application Architec- ture. Boston, MA, USA: Addison-Wesley, 2004

    2004

  4. [12]

    Building Secure Software: How to Avoid Security Problems the Right Way

    John Viega and Gary McGraw. Building Secure Software: How to Avoid Security Problems the Right Way . Boston, MA, USA: Addison-Wesley, 2001

    2001

  5. [13]

    The Art of Multiprocessor Programming

    Nir Shavit and Maurice Herlihy. The Art of Multiprocessor Programming. San Francisco, CA, USA: Morgan Kauf- mann, 2012

    2012

  6. [14]

    A Discipline of Programming

    Edsger Wybe Dijkstra. A Discipline of Programming . 1st. USA: Prentice Hall PTR, 1997. ISBN : 013215871X

    1997

  7. [15]

    The C++ Programming Language

    Bjarne Stroustrup. The C++ Programming Language . 4th. Addison-Wesley Professional, 2013. ISBN : 0321563840

    2013

  8. [16]

    Cppcheck: A static analysis tool for C++

    Daniel Marjam ¨aki. Cppcheck: A static analysis tool for C++ . 2024. URL: https : / / cppcheck . sourceforge.io/

    2024

  9. [17]

    Google Test: C++ Testing Framework

    Google. Google Test: C++ Testing Framework . Accessed: 2023-12-10. 2023. URL: https : / / github . com / google/googletest

    2023

  10. [18]

    ISO 26262: Road vehicles – Functional safety

    International Organization for Standardization. ISO 26262: Road vehicles – Functional safety . Geneva, Switzerland: ISO, 2018

    2018

  11. [19]

    Automotive SPICE Process Assessment Model

    VDA QMC Working Group 13. Automotive SPICE Process Assessment Model . Berlin, Germany: German Association of the Automotive Industry (VDA), 2022

    2022

  12. [20]

    MISRA C: Guidelines for the use of the C language in critical systems

    Motor Industry Software Reliability Association. MISRA C: Guidelines for the use of the C language in critical systems . 3rd. UK: MISRA, 2012

    2012

  13. [21]

    Ashish Vaswani et al.Attention Is All You Need. 2023. arXiv: 1706.03762 [cs.CL] . URL: https://arxiv.org/ abs/1706.03762

    2023 arXiv

  14. [22]

    The Llama 3 Herd of Models

    Aaron Grattafiori et al. The Llama 3 Herd of Models . 2024. arXiv: 2407.21783 [cs.AI]. URL: https://arxiv. org/abs/2407.21783

    2024 arXiv

  15. [23]

    Qwen2. 5-Coder Technical Report

    Binyuan Hui et al. “Qwen2. 5-Coder Technical Report”. In: arXiv preprint arXiv:2409.12186 (2024)

    2024 arXiv

  16. [24]

    Zero-Shot Prompting and Few- Shot Fine-Tuning: Revisiting Document Image Classifica- tion Using Large Language Models

    Anna Scius-Bertrand et al. “Zero-Shot Prompting and Few- Shot Fine-Tuning: Revisiting Document Image Classifica- tion Using Large Language Models”. In: Pattern Recogni- tion. Springer Nature Switzerland, Dec. 2024, pp. 152–166. ISBN : 9783031784958. DOI: 10 . 1007 / 978 - 3 - ...

    2024

  17. [25]

    Multimodal Chain-of-Thought Rea- soning in Language Models

    Zhuosheng Zhang et al. Multimodal Chain-of-Thought Rea- soning in Language Models . 2024. arXiv: 2302 . 00923 [cs.CL]

    2024

  18. [26]

    Better Zero-Shot Reasoning with Role- Play Prompting

    Aobo Kong et al. Better Zero-Shot Reasoning with Role- Play Prompting . 2024. arXiv: 2308 . 07702 [cs.CL] . URL: https://arxiv.org/abs/2308.07702

    2024 arXiv

  19. [27]

    VeCoGen: Automating Genera- tion of Formally Verified C Code with Large Language Mod- els

    Merlijn Sevenhuijsen et al. VeCoGen: Automating Genera- tion of Formally Verified C Code with Large Language Mod- els. 2025. arXiv: 2411.19275 [cs.SE] . URL: https: //arxiv.org/abs/2411.19275

    2025 arXiv

  20. [28]

    Comparison between JSON and Y AML for Data Serialization

    Malin Eriksson and Victor Hallberg. “Comparison between JSON and Y AML for Data Serialization.” PhD thesis. 2011. URL: https : / / urn . kb . se / resolve ? urn = urn : nbn:se:kth:diva-130815

    2011

  21. [29]

    McEval: Massively Multilingual Code Evaluation

    Linzheng Chai et al. McEval: Massively Multilingual Code Evaluation. 2024. arXiv: 2406.07436 [cs.PL]

    2024 arXiv

  22. [30]

    Aider Code Editing Benchmark

    Aider-AI. Aider Code Editing Benchmark . https : / / github . com / Aider - AI / aider / blob / main / benchmark/README.md. Accessed: 2025-01-22. 2024

    2025

  23. [31]

    Evaluating Large Language Models Trained on Code

    Mark Chen et al. Evaluating Large Language Models Trained on Code . 2021. arXiv: 2107.03374 [cs.LG]

    2021 arXiv

  24. [32]

    DeepSeek-Coder-V2: Breaking the Bar- rier of Closed-Source Models in Code Intelligence

    DeepSeek-AI et al. DeepSeek-Coder-V2: Breaking the Bar- rier of Closed-Source Models in Code Intelligence . 2024. arXiv: 2406.11931 [cs.SE]

    2024 arXiv

  25. [33]

    DeepSeek-Coder: When the Large Language Model Meets Programming – The Rise of Code Intelligence

    Daya Guo et al. DeepSeek-Coder: When the Large Language Model Meets Programming – The Rise of Code Intelligence

  26. [34]

    Codestral: Hello, World! Accessed: January 27,

    Mistral AI. Codestral: Hello, World! Accessed: January 27,

  27. [35]

    YOLOP: You Only Look Once for Panoptic Driving Perception

    Dong Wu et al. “YOLOP: You Only Look Once for Panoptic Driving Perception”. In: Machine Intelligence Research 19.6 (Nov. 2022), pp. 550–562. ISSN : 2731-5398. DOI: 10 . 1007 / s11633 - 022 - 1339 - y. URL: http : / / dx . doi.org/10.1007/s11633-022-1339-y

    2022 doi

  28. [36]

    Intelligent transport systems — Adaptive Cruise Control systems — Performance requirements and test procedures

    International Organization for Standardization. Intelligent transport systems — Adaptive Cruise Control systems — Performance requirements and test procedures . 2018. URL: https://www.iso.org/standard/71515.html

    2018

  29. [2024]

    arXiv: 2401.14196 [cs.SE]

    arXiv

  30. [2025]

    URL: https : / / mistral

    2024. URL: https : / / mistral . ai / news / codestral/

    2024

Pith tools

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