GenAI for Automotive Software Development: From Requirements to Wheels

Alois Knoll; Andre Schamschurko; Fengjunjie Pan; Krzysztof Lebioda; Nenad Petrovic; Vahid Zolfaghari

REVIEW 4 major objections 6 minor 2 cited by

GenAI for Automotive Software Development: From Requirements to Wheels

T0 review · 4 major / 6 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 The authors claim that an LLM-driven, model-checked pipeline can generate, validate, and deploy automotive ADAS software end to end, cutting typical development cycles from days and hours to about a minute.

desk verdict A coherent end-to-end LLM/MDE workflow paper that overclaims its only quantitative result — the 'minutes' claim has no data behind it. read the letter →

arxiv 2507.18223 v1 pith:KWW7YTMD submitted 2025-07-24 cs.SE cs.AI

Nenad Petrovic , Fengjunjie Pan , Vahid Zolfaghari , Krzysztof Lebioda , Andre Schamschurko , Alois Knoll This is my paper

classification cs.SEcs.AI

keywords GenerativeAILargeLanguageModelsModel-DrivenEngineeringRetrievalAugmentedGenerationAutomotivesoftwaredevelopmentAdvancedDriverAssistanceSystemsAutomatedemergencybrakingTestscenario

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 sets out to establish that automotive advanced driver-assistance software can be generated end to end from requirements, with LLMs doing the writing and model-driven engineering doing the checking. The workflow starts from requirement and regulation documents, uses retrieval-augmented generation to extract test scenarios, has LLMs build a formal model (an Ecore metamodel, an XMI instance, and OCL constraints), and then generates both Python simulation code and C++ vehicle-controller code. The working case is automated emergency braking under UN Regulation No. 152. The payoff the authors aim for is shortening compliance, testing, and re-engineering cycles from days and hours to the order of a minute.

What carries the argument

The machinery is a staged pipeline whose hinge is a formal model stack: LLMs turn requirements into a simple UML-like sketch notation (PlantUML), which is transformed into an Ecore metamodel, an XMI instance model, and Object Constraint Language (OCL) rules; those artifacts are checked for consistency before code generation. Around that hinge, a two-stage retrieval-augmented generation system with smart chunking and reranking extracts regulation-compliant scenarios from documents such as UN R152, LLM pipelines generate simulation configuration code, and a C++ generator maps Vehicle Signal Specification signals to controller API calls for the testbench. The role of these pieces is to make generated artifacts verifiable in principle, which is the paper's answer to LLM hallucination risk.

What would settle it

Run the full pipeline on a second, unseen ADAS requirement set, measure the fraction of generated XMI/OCL artifacts that pass the model checker without human edits and the fraction of generated Python/C++ code that compiles and executes a valid braking event, and record total wall-clock time including all human corrections. If the pass rates are low enough that human rewriting dominates, or total time stays in the hours range, the central time-saving claim fails.

Watch

Extended reading notes

Core claim

The paper's central claim is that a single generative workflow can take automotive requirements and regulation documents and produce the formal models, test scenarios, simulation code, and target-platform control code for an ADAS function without hand-coding. Concretely, for automated emergency braking under UN Regulation No. 152, the workflow generates an Ecore metamodel with an XMI instance and Object Constraint Language (OCL) constraints as a consistency-checked formal representation, then uses that representation to emit Python configuration code for a simulation environment and C++ controller code for a vehicle on a testbench. The authors report that early results suggest cycle times for innovation and testing falling from days and hours to the order of a minute, a claim framed as potential rather than measured throughput.

Load-bearing premise

The load-bearing premise is that LLM-generated models, constraints, test scenarios, and code are correct enough for automated model-driven checks to replace most human review, yet the paper gives no data on how often those artifacts need correction; if they often fail, the promised minute-scale cycle collapses.

Editorial extensions

If this is right

If the claim holds, a changed ADAS requirement re-triggers model, test, and code generation, turning a re-engineering cycle from days of manual work into a single automated pass.
If the claim holds, generated test scenarios are traceable to regulatory documents such as UN R152, because RAG retrieval grounds each scenario in source text.
If the claim holds, OCL consistency checks catch a class of LLM hallucinations before code generation, providing a concrete trust layer for AI-written automotive artifacts.
If the claim holds, local deployment of the model and OCL generation steps lets carmakers keep proprietary requirements off external servers.

Reading between the lines

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

The paper does not test it, but the same requirements-to-model-to-code pattern should transfer to other ADAS functions such as lane keeping or pedestrian detection; a next experiment is measuring pass rates on a second regulation.
The minute-scale cycle is an aspiration from one initial result, not a measured throughput; the human reviewer still in the loop is not charged to the clock.
The reported ability of a small fine-tuned local model to match a frontier model on OCL generation, if it holds, strengthens the case for small specialized models where data sovereignty matters.
The architecture implies that final controller-code quality is capped by formal-model quality, so quantifying how often OCL checks catch real requirement errors would measure how much trust the check layer can carry.

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.

Desk Editor's Note

read the letter

Colleague,

Here's my read of 2507.18223. The genuinely new thing is the integration: the authors wire their previously reported components (OCL generation, XMI model generation, RAG over UN R152, CARLA scenario config, C++ testbench code) into one n8n pipeline and present the architecture. That's useful — it shows how MDE checks can sit between LLM outputs and code generation, and it's honest about residual human review.

What it does not do is present any new measurement. The conclusion's 'days and hours to order of a minute' claim is the entire quantitative payoff, and it's backed only by 'initial results' that are never reported. No wall-clock latency, no success rate, no end-to-end run, no compilation or simulation outcome. The stress-test note is right: even if a minute is possible for some stage, the human-in-loop steps in §2 and §3.1 — where the reviewer approves the metamodel before model-to-model transformation — are mandatory in the described flow, and the timing claim ignores or hides them. The model-level OCL checks also don't verify that the generated C++ is safe on the testbench; that's a gap between validation scope and conclusion.

That said, the components are grounded in prior work, and the self-citations are legitimate: they're pointing to their own earlier papers that presumably contain the actual evaluations. The current submission just doesn't translate that into evidence here. I also don't see a circularity problem — the workflow builds on their prior results, not the other way around.

So my verdict: as a research result, this fails the central claim — the timing statement is unsupported and the safety gap is load-bearing. But as a system/position paper, it's a coherent architecture description with honest limitations. If the authors had presented even one end-to-end run with numbers, it would be a reasonable tool paper.

For peer review: I'd send it to a workshop or tool track, not a main track, in its current form. But it's not incoherent, and the integration problem is real; a serious referee could extract value by demanding the missing evaluation. So I'd lean accept-to-review with the expectation of major revision, rather than desk reject — though a desk reject is defensible given the unfilled central claim.

Referee Report

4 major / 6 minor

Summary. The manuscript proposes a GenAI-empowered workflow for automotive ADAS software development. The workflow chains RAG-based extraction from regulations and requirements, LLM-based generation of an Ecore metamodel, XMI model instances, OCL constraints, CARLA simulation configuration code, and C++ target testbench code, with MDE consistency checks interleaved as a mitigation for LLM hallucination. The paper describes the architecture of each component (Sections 2–3) and concludes in Section 4 that, based on 'initial results' for automated emergency braking, the approach reduces development and testing time from days/hours to the order of a minute. No measurements, quantitative results, or end-to-end evaluation are reported.

Significance. If placed on a solid empirical footing, the proposed pipeline would be a meaningful contribution to automotive software engineering practice: it is one of the few end-to-end proposals that combine MDE-based validation with LLM generation for the complete chain from regulatory text to executable testbench code. The emphasis on locally deployable models and RAG for standards is also timely, and the individual components are grounded in a series of prior works by the authors, several of which are available as preprints. However, the paper's significance cannot be assessed from the manuscript alone, because the central claim of drastic time reduction is stated without presenting the underlying 'initial results' or any reproducibility artifact. The paper is therefore best viewed as a high-level architecture description rather than a validated approach.

major comments (4)

[Section 4, Conclusion] The sentence "Based on the initial results for automated emergency braking, the proposed approach ... exhibits strong potential for reducing the time needed for innovation and testing - from days and hours to order of magnitude of a minute" makes a quantitative claim that is never backed by data anywhere in the manuscript; no wall-clock times, artifacts, or comparisons appear in Sections 2 or 3. Without a reported end-to-end run (or at least precisely described and cited measurements), this claim is unverifiable and should be removed or replaced with a testable hypothesis.
[Sections 3.1 and 3.4] The workflow relies on the assumptions that LLM-generated XMI/OCL artifacts and the subsequently generated Python/C++ code are correct enough that MDE checks alone constitute sufficient validation; the paper provides no evidence on the error rates of these generated artifacts, no compilation or execution logs, and no statement about which generated outputs were actually used on the testbench. Because the stated time savings depend on reducing human review, the absence of evidence on generated-code quality is load-bearing.
[Sections 2 and 3.1] The workflow includes mandatory or recommended human review steps ("it is still recommended to include human reviewer in a loop" in Section 2; "Once human reviewer is satisfied, model-to-model transformation will be executed ..." in Section 3.1). The paper does not clarify whether the time estimate in Section 4 includes this human effort; if it does not, the estimate is misleading, and if it does, the 'order of a minute' claim is implausible. The workflow description should specify which steps are automatic versus human-gated and how the time claim treats those steps.
[Section 3.1] Claims about the performance of specific components (e.g., "Llama 3.1-70B based solution that achieves a comparable semantic score to GPT-4o," citing [8], and the fine-tuned OCL model, citing [7]) are made by reference to the authors' own prior works; because those references are preprints or workshop papers that are not summarized in this manuscript, the reviewer cannot assess whether the components satisfy the accuracy requirements of the end-to-end workflow. Please at least state the relevant metrics and conditions (dataset, baseline, evaluation protocol) for each cited result, or mark them explicitly as unpublished.

minor comments (6)

[Section 3.1] The phrase "set of Object Constraint Language Rule (OCL)" should be "set of Object Constraint Language (OCL) rules."
[Figures 1 and 4] Figures 1 and 4 have identical captions ("GenAI-empowered automotive software development workflow"), but Figure 4 appears to illustrate the RAG pipeline for regulation-compliant scenario generation; please correct the caption.
[Section 3.1] The cross-reference "as shown in Fig. 6" for the model-to-model transformation (Ecore from PlantUML) points to a figure that in the manuscript shows target platform code generation (Section 3.4); the figure numbering or reference is likely wrong.
[Section 2] The phrase "potential constrains" should be "potential constraints."
[Section 3.3] The section heading "Simulation T est Scenario Generation" contains a spurious space.
[References] The reference list is inconsistently formatted: some entries include DOI, arXiv identifiers, or access dates with different conventions; please unify (e.g., [3], [7], [13] vs. [15]).

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper presents a workflow composition, not a derivation, and its self-citations are supporting evidence rather than forced conclusions.

full rationale

The manuscript is a workflow proposal rather than a formal derivation: the claimed outcome is not obtained by equations or by inference from the same data it purports to predict. The only quantitative claim, the 'order of magnitude of a minute' reduction in Section 4, is attributed to 'initial results for automated emergency braking' that are not reported or cited with data; this is an evidence gap, not circularity. The self-citations (Section 3.1 references [7] and [8], Section 3.3 reference [3], Section 3.4 reference [9], and Section 2 references [10] and [11]) point to prior component implementations and evaluations. None is invoked as a uniqueness theorem, none forbids alternative designs, and none is used to define the target result in terms of itself. The MDE consistency check in Section 3.1 checks generated OCL constraints against a generated XMI instance, but the paper does not claim this check alone proves safety; it is presented as a design-time consistency step. No fitted parameter is later renamed as a prediction, and no result is defined by the very quantity it claims to derive. Under the rule that self-citation is not circularity when it functions as supporting evidence, no specific reduction can be exhibited, so the score is 0. Concerns about missing experimental support belong to correctness risk, not circularity.

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

The workflow rests on several unvalidated domain assumptions about the reliability of LLM-generated artifacts and the adequacy of automated checks. No free parameters are fit because the paper contains no quantitative experiments.

assumptions (4)

domain assumption LLMs can generate syntactically and semantically correct XMI model instances, OCL constraints, test scenario configurations, and C++ target code.
The entire pipeline depends on LLM output quality; no error rates are given. Invoked throughout Section 3.
domain assumption RAG with SmartChunking retrieves all relevant regulatory information and produces accurate test scenarios from UN Regulation No. 152.
Reliance on RAG for regulation compliance, Section 3.2.
domain assumption MDE consistency checking can detect hallucinations and ensure the correctness of generated models.
Uses OCL constraints and XMI instance checking to verify outputs, Section 3.1.
domain assumption The simulation environment (CARLA) and target testbench are accurate representations of real vehicle behavior.
The generated code is only as good as the simulation and testbench models, Sections 3.3 and 3.4.

how reviews work

0 comments

Cite this review

Pith. "Pith review of GenAI for Automotive Software Development: From Requirements to Wheels." pith.science (2026). https://pith.science/paper/KWW7YTMD

@misc{pith2026250718223,
  author       = {Pith},
  title        = {Pith review of: GenAI for Automotive Software Development: From Requirements to Wheels},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KWW7YTMD}},
  note         = {Machine review of arXiv:2507.18223}
}

read the original abstract

This paper introduces a GenAI-empowered approach to automated development of automotive software, with emphasis on autonomous and Advanced Driver Assistance Systems (ADAS) capabilities. The process starts with requirements as input, while the main generated outputs are test scenario code for simulation environment, together with implementation of desired ADAS capabilities targeting hardware platform of the vehicle connected to testbench. Moreover, we introduce additional steps for requirements consistency checking leveraging Model-Driven Engineering (MDE). In the proposed workflow, Large Language Models (LLMs) are used for model-based summarization of requirements (Ecore metamodel, XMI model instance and OCL constraint creation), test scenario generation, simulation code (Python) and target platform code generation (C++). Additionally, Retrieval Augmented Generation (RAG) is adopted to enhance test scenario generation from autonomous driving regulations-related documents. Our approach aims shorter compliance and re-engineering cycles, as well as reduced development and testing time when it comes to ADAS-related capabilities.

Figures

Figures reproduced from arXiv: 2507.18223 by the authors.

**Figure 2.** Model instance and OCL rule generation for consistency checking. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** LLM-based iterative metamodeling. 3.2 Regulation-Compliant Scenario Generation In automotive software development, especially for ADAS and Autonomous Driving Systems (ADS), producing precise, regulation-compliant test scenarios is essential [16]. Conventional manual methods for interpreting and verifying compliance with standards such as UN Regulation No. 152 are often inefficient, error-prone, and expensive. While… view at source ↗

Figures from the paper (3 more)

**Figure 4.** Figure 4: GenAI-empowered automotive software development workflow. [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]

**Figure 5.** Figure 5: Simulation scenario generation [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]

**Figure 6.** Figure 6: Target platform code generation. 4 Conclusion Based on the initial results for automated emergency braking, the proposed approach leveraging GenAI for automotive engineering and re-engineering processes automation in order to tackle the cognitive load and increasing S…

Discussion (0). Sign in to comment.

Forward citations

Cited by 2 Pith papers

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

LLM-Driven Approach to Modeling Tool Interoperability in Automotive Domain
cs.SE 2026-07 conditional novelty 4.0 of 10

An LLM workflow with automated validation maps and merges Ecore and SysML v2 models, hitting 100% semantic matching on four small automotive cases while struggling with SysML syntax.
A Unified Perception-Language-Action Framework for Adaptive Autonomous Driving
cs.RO 2025-07 reject novelty 3.0 of 10

A GPT-4.1-powered perception-language-action framework for autonomous driving is evaluated on a single intersection scenario without baselines or public artifacts.

Reference graph

Works this paper leans on

16 extracted references · 14 canonical work pages · cited by 2 Pith papers

[8]

LLM-enabled Instance Model Generation

Pan, F., Petrovic, N., Zolfaghari, V., Wen, L., Knoll, A.: Llm-enabled instance model generation. arXiv preprint arXiv:2503.22587 (Mar 2025), accessed: 2025-07- 09

work page Pith review arXiv 2025
[7]

In: 2024 IEEE International Symposium on Systems Engineering (ISSE)

Pan, F., Zolfaghari, V., Wen, L., Petrovic, N., Lin, J., Knoll, A.: Generative ai for ocl constraint generation: Dataset collection and llm fine-tuning. In: 2024 IEEE International Symposium on Systems Engineering (ISSE). pp. 1–8. Perugia, Italy (2024). https://doi.org/10.1109/ISSE63315.2024.10741141

work page arXiv 2024
[1]

COVESA website (2025), https://covesa.global/vehicle-signal-specification/, accessed: 2025-07-10

COVESA: Vehicle signal specification (vss). COVESA website (2025), https://covesa.global/vehicle-signal-specification/, accessed: 2025-07-10

work page 2025
[2]

Hugging Face model reposi- tory (2024), https://huggingface.co/deepseek-ai/deepseek-llm-7b-chat, accessed: 2025-07-11

DeepSeek: deepseek-ai/deepseek-llm-7b-chat. Hugging Face model reposi- tory (2024), https://huggingface.co/deepseek-ai/deepseek-llm-7b-chat, accessed: 2025-07-11

work page 2024
[3]

Are requirements really all you need? A case study of LLM-driven configuration code generation for automotive simulations

Lebioda, K., Petrovic, N., Pan, F., Zolfaghari, V., Schamschurko, A., Knoll, A.: Are requirements really all you need? a case study of llm-driven configuration code generation for automotive simulations. arXiv preprint arXiv:2505.13263 (May 2025), submitted May 19, 2025; DOI: 10.48550/arXiv.2505.13263

work page Pith review arXiv doi:10.48550/arxiv.2505.13263 2025
[4]

Optimizing Retrieval Augmented Generation for Object Constraint Language

Li, K.C., Zolfaghari, V., Petrovic, N., Pan, F., Knoll, A.: Optimizing re- trieval augmented generation for object constraint language. arXiv preprint arXiv:2505.13129 (May 2025). https://doi.org/10.48550/arXiv.2505.13129, https://arxiv.org/abs/2505.13129, presented at the First Large Language Models for Software Engineering Workshop (LLM4SE 2025), part o...

work page Pith review arXiv doi:10.48550/arxiv.2505.13129 2025
[5]

McKinsey & Company Insight (Jan 2020), https://www.mckinsey.com/industries/automotive-and-assembly/our- insights/the-case-for-an-end-to-end-automotive-software-platform

McKinsey & Company: The case for an end-to-end automotive- software platform. McKinsey & Company Insight (Jan 2020), https://www.mckinsey.com/industries/automotive-and-assembly/our- insights/the-case-for-an-end-to-end-automotive-software-platform

work page 2020
[6]

n8n.io (2025), https://n8n.io/, accessed: 2025-07-09

n8n: Powerful workflow automation software & tools – n8n. n8n.io (2025), https://n8n.io/, accessed: 2025-07-09

work page 2025

Show all 16 references

[9]

arXiv preprint arXiv:2505.02500 (May 2025), submitted May 2025

Pan, F., Song, Y., Wen, L., Petrovic, N., Lebioda, K., Knoll, A.: Automating automotive software development: A synergy of generative ai and formal methods. arXiv preprint arXiv:2505.02500 (May 2025), submitted May 2025

2025
[10]

Technical report, Technical University of Munich (2024), https://mediatum.ub.tum.de/doc/1738462/1738462.pdf

Petrovic, N., et al.: Synergy of large language model and model driven engineering for automated development of centralized vehicu- lar systems. Technical report, Technical University of Munich (2024), https://mediatum.ub.tum.de/doc/1738462/1738462.pdf

2024
[11]

arXiv preprint arXiv:2503.04506 (Mar 2025), https://arxiv.org/abs/2503.04506, accepted for IntelliSys2025

Petrovic, N., Zhang, Y., Maaroufi, M., Chao, K.Y., Mazur, L., Pan, F., Zolfaghari, V., Knoll, A.: Multi-modal summarization in model-based engineering: Automotive software development case study. arXiv preprint arXiv:2503.04506 (Mar 2025), https://arxiv.org/abs/2503.04506, acc...

2025 arXiv
[12]

In: Journal of Artificial Intelligence & Cloud Computing, vol

Phatale, A., Kaushik, A.: Generative ai adoption in automotive vehicle technology: Case study of custom gpt. In: Journal of Artificial Intelligence & Cloud Computing, vol. 3, pp. 1–5 (November 2024). https://doi.org/10.47363/JAICC/2024(3)400

2024 doi
[13]

https://doi.org/10.48550/arXiv.2503.12108, https://arxiv.org/abs/2503.12108, conference paper accepted for IntelliSys2025

Schamschurko, A., Petrovic, N., Knoll, A.C.: RECSIP: RE- peated Clustering of Scores Improving the Precision (2025). https://doi.org/10.48550/arXiv.2503.12108, https://arxiv.org/abs/2503.12108, conference paper accepted for IntelliSys2025

2025 doi arXiv
[14]

In: IEEE Software, vol

Staron, M., Abrahão, S.: Exploring generative ai in automated soft- ware engineering. In: IEEE Software, vol. 42, pp. 142–145 (2025). https://doi.org/10.1109/MS.2025.3533754 8 N. Petrovic et al

2025
[15]

Publications Office of the European Union (Oct 2020), uN-ECE Reg

United Nations Economic Commission for Europe: Un regulation no 152 – uniform provisions concerning the approval of motor vehicles with regard to the advanced emergency braking system (aebs) for m1 and n1 vehicles. Publications Office of the European Union (Oct 2020), uN-ECE R...

2020
[16]

In: 2024 2nd International Conference on Foundation and Large Language Models (FLLM)

Zolfaghari, V., Petrovic, N., Pan, F., Lebioda, K., Knoll, A.: Adopting rag for llm- aided future vehicle design. In: 2024 2nd International Conference on Foundation and Large Language Models (FLLM). pp. 437–442. Dubai, United Arab Emirates (2024). https://doi.org/10.1109/FLLM...

2024

Pith tools

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

[1] [8]

LLM-enabled Instance Model Generation

Pan, F., Petrovic, N., Zolfaghari, V., Wen, L., Knoll, A.: Llm-enabled instance model generation. arXiv preprint arXiv:2503.22587 (Mar 2025), accessed: 2025-07- 09

work page Pith review arXiv 2025

[2] [7]

In: 2024 IEEE International Symposium on Systems Engineering (ISSE)

Pan, F., Zolfaghari, V., Wen, L., Petrovic, N., Lin, J., Knoll, A.: Generative ai for ocl constraint generation: Dataset collection and llm fine-tuning. In: 2024 IEEE International Symposium on Systems Engineering (ISSE). pp. 1–8. Perugia, Italy (2024). https://doi.org/10.1109/ISSE63315.2024.10741141

work page arXiv 2024

[3] [1]

COVESA website (2025), https://covesa.global/vehicle-signal-specification/, accessed: 2025-07-10

COVESA: Vehicle signal specification (vss). COVESA website (2025), https://covesa.global/vehicle-signal-specification/, accessed: 2025-07-10

work page 2025

[4] [2]

Hugging Face model reposi- tory (2024), https://huggingface.co/deepseek-ai/deepseek-llm-7b-chat, accessed: 2025-07-11

DeepSeek: deepseek-ai/deepseek-llm-7b-chat. Hugging Face model reposi- tory (2024), https://huggingface.co/deepseek-ai/deepseek-llm-7b-chat, accessed: 2025-07-11

work page 2024

[5] [3]

Are requirements really all you need? A case study of LLM-driven configuration code generation for automotive simulations

Lebioda, K., Petrovic, N., Pan, F., Zolfaghari, V., Schamschurko, A., Knoll, A.: Are requirements really all you need? a case study of llm-driven configuration code generation for automotive simulations. arXiv preprint arXiv:2505.13263 (May 2025), submitted May 19, 2025; DOI: 10.48550/arXiv.2505.13263

work page Pith review arXiv doi:10.48550/arxiv.2505.13263 2025

[6] [4]

Optimizing Retrieval Augmented Generation for Object Constraint Language

Li, K.C., Zolfaghari, V., Petrovic, N., Pan, F., Knoll, A.: Optimizing re- trieval augmented generation for object constraint language. arXiv preprint arXiv:2505.13129 (May 2025). https://doi.org/10.48550/arXiv.2505.13129, https://arxiv.org/abs/2505.13129, presented at the First Large Language Models for Software Engineering Workshop (LLM4SE 2025), part o...

work page Pith review arXiv doi:10.48550/arxiv.2505.13129 2025

[7] [5]

McKinsey & Company Insight (Jan 2020), https://www.mckinsey.com/industries/automotive-and-assembly/our- insights/the-case-for-an-end-to-end-automotive-software-platform

McKinsey & Company: The case for an end-to-end automotive- software platform. McKinsey & Company Insight (Jan 2020), https://www.mckinsey.com/industries/automotive-and-assembly/our- insights/the-case-for-an-end-to-end-automotive-software-platform

work page 2020

[8] [6]

n8n.io (2025), https://n8n.io/, accessed: 2025-07-09

n8n: Powerful workflow automation software & tools – n8n. n8n.io (2025), https://n8n.io/, accessed: 2025-07-09

work page 2025