Paper deep dive
LLM-Powered Workflow Optimization for Multidisciplinary Software Development: An Automotive Industry Case Study
Shuai Wang, Yinan Yu, Earl Barr, Dhasarathy Parthasarathy
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 94%
Last extracted: 3/26/2026, 2:28:27 AM
Summary
The paper presents a graph-based workflow optimization approach for Multidisciplinary Software Development (MSD) in the automotive industry. By modeling the development process as a dependency graph of artifacts and handoffs, the authors replace manual translation tasks with LLM-powered services. This approach was evaluated on the 'spapi' system at Volvo Group, achieving a 93.7% F1 score and significantly reducing development time per API from 5 hours to under 7 minutes.
Entities (4)
Relation Signals (2)
spapi → developedat → Volvo Group
confidence 100% · a production in-vehicle API system at Volvo Group
LLM-powered services → optimizes → Multidisciplinary Software Development
confidence 90% · LLM-Powered Workflow Optimization for Multidisciplinary Software Development
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Multidisciplinary Software Development (MSD) requires domain experts and developers to collaborate across incompatible formalisms and separate artifact sets. Today, even with AI coding assistants like GitHub Copilot, this process remains inefficient; individual coding tasks are semi-automated, but the workflow connecting domain knowledge to implementation is not. Developers and experts still lack a shared view, resulting in repeated coordination, clarification rounds, and error-prone handoffs. We address this gap through a graph-based workflow optimization approach that progressively replaces manual coordination with LLM-powered services, enabling incremental adoption without disrupting established practices. We evaluate our approach on \texttt{spapi}, a production in-vehicle API system at Volvo Group involving 192 endpoints, 420 properties, and 776 CAN signals across six functional domains. The automated workflow achieves 93.7\% F1 score while reducing per-API development time from approximately 5 hours to under 7 minutes, saving an estimated 979 engineering hours. In production, the system received high satisfaction from both domain experts and developers, with all participants reporting full satisfaction with communication efficiency.
Tags
Links
- Source: https://arxiv.org/abs/2603.21439v1
- Canonical: https://arxiv.org/abs/2603.21439v1
Trouble viewing inline? Open PDF directly →
Full Text
70,945 characters extracted from source content.
Expand or collapse full text
LLM-Powered Workflow Optimization for Multidisciplinary Software Development: An Automotive Industry Case Study Shuai Wang Chalmers University of Technology Gothenburg, Sweden shuaiwa@chalmers.se Yinan Yu Chalmers University of Technology Gothenburg, Sweden yinan@chalmers.se Earl Barr University College London London, United Kingdom e.barr@ucl.ac.uk Dhasarathy Parthasarathy Volvo Group Gothenburg, Sweden dhasarathy.parthasarathy@volvo.com Abstract Multidisciplinary Software Development (MSD) requires domain ex- perts and developers to collaborate across incompatible formalisms and separate artifact sets. Today, even with AI coding assistants like GitHub Copilot, this process remains inefficient; individual coding tasks are semi-automated, but the workflow connecting domain knowledge to implementation is not. Developers and experts still lack a shared view, resulting in repeated coordination, clarification rounds, and error-prone handoffs. We address this gap through a graph-based workflow optimization approach that progressively re- places manual coordination with LLM-powered services, enabling incremental adoption without disrupting established practices. We evaluate our approach onspapi, a production in-vehicle API sys- tem at Volvo Group involving 192 endpoints, 420 properties, and 776 CAN signals across six functional domains. The automated workflow achieves 93.7% F1 score while reducing per-API develop- ment time from approximately 5 hours to under 7 minutes, saving an estimated 979 engineering hours. In production, the system re- ceived high satisfaction from both domain experts and developers, with all participants reporting full satisfaction with communication efficiency. Keywords Multidisciplinary Software Development, Automation, Workflow Optimization, Large Language Model ACM Reference Format: Shuai Wang, Yinan Yu, Earl Barr, and Dhasarathy Parthasarathy. 2026. LLM-Powered Workflow Optimization for Multidisciplinary Software De- velopment: An Automotive Industry Case Study. In Companion Proceedings of the 34th ACM Symposium on the Foundations of Software Engineering (FSE ’26), June 5–9, 2026, Montreal, Canada. ACM, Montreal, Canada, 12 pages. https://doi.org/10.1145/n.n Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. FSE ’26, Montreal, Canada © 2026 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-x-x-x-x/Y/M https://doi.org/10.1145/n.n Deployment-Ready Code Control engineers API designer Vehicle state experts System engineers Std. Do c Deve lopers Coordi nation group Expert Team Deployment-Ready Code Ctrl. do c API Spec Signal Def. Sys. do c Server 2 Server 3 Server 1 Experts Domain knowledge co ntrol Spec Signals In tegratio n Output Communication Deve lopers review (a) Common MSD Workflow (b) OptimizedWorkflow Figure 1: Comparison of workflows in the Multidisciplinary Software Development (MSD) process: (a) a typical MSD work- flow and (b) optimized workflow through automated transla- tion via our graph-based approach. 1 Introduction In many industrial software projects, domain experts and software developers must collaborate across disciplinary boundaries, coordi- nating through heterogeneous artifacts that each party produces, maintains, and evolves independently. Experts contribute specifica- tions, signal definitions, and design documents grounded in their respective domains, while developers must reconcile these artifacts and translate them into a unified, executable codebase. This coordi- nation pattern is straightforward when artifacts are few and stable, but becomes a persistent bottleneck as systems grow in scope and the number of contributing disciplines increases. The automotive industry, with its deep regulatory requirements, safety-critical con- straints, and multidisciplinary teams, offers an instructive example of how document-to-code translation can dominate engineering effort [39]. This pattern is characteristic of Multidisciplinary Software De- velopment (MSD), which arises whenever software systems must encode specialized knowledge from non-software domains. In MSD settings, domain experts (engineers, scientists, regulators, or busi- ness analysts) produce specifications using discipline-specific for- malisms that software developers must interpret, align, and im- plement as coherent system behavior [24,27]. The collaboration arXiv:2603.21439v1 [cs.SE] 22 Mar 2026 FSE ’26, June 5–9, 2026, Montreal, CanadaShuai Wang, Yinan Yu, Earl Barr, and Dhasarathy Parthasarathy is inherently two-way: developers translate domain requirements into code, while domain experts must understand implementation constraints to refine their specifications [15,44]. This continuous dialogue creates value by embedding deep expertise into software, but it also introduces persistent operational challenges that scale poorly with system complexity. This paper presents a practical case study in automotive soft- ware development at Volvo Group. We usespapias a running example: an in-vehicle web server that exposes vehicle state and control-related properties through RESTful APIs to driver-facing mobile applications as well as backend services. Developingspapi requires a multidisciplinary team, including product owners, busi- ness translators, UI and app designers, Android engineers, software developers, control engineers working in MATLAB/Simulink, sys- tem engineers, and system architects. These roles rely on distinct technical vocabularies, toolchains, and artifact formats, and changes in one domain often propagate to others in ways that are difficult to anticipate or track. Using this case study, we highlight recurring operational problems in translating domain artifacts into code and show how LLM-based automation can substantially reduce manual overhead while maintaining delivery quality. Figure 1 illustrates a common pattern we observe in MSD: re- quirements are authored across heterogeneous documents by differ- ent stakeholders, then manually translated by developers into im- plemented endpoints, followed by repeated feedback cycles where feasibility and constraints are communicated back to domain ex- perts for refinement. Inspapi, this translation spans a patchwork of documents and a correspondingly tedious patchwork of imple- mentation tasks, which slows delivery and increases the risk of de- fects. Our goal, shown in Figure 1(b), is to automate the translation from domain artifacts tospapiendpoints. Achieving this requires transforming the MSD workflow itself: we reorganize the hand- offs and dependencies so that LLM-powered services can replace repeated manual coordination. We design this workflow transfor- mation using a graph-based representation of the artifacts and their dependencies. We make four contributions relevant to practitioners facing sim- ilar MSD challenges. •We showcase the operational reality of artifact-driven mul- tidisciplinary development at scale by characterizing the translation bottleneck inspapi, an in-vehicle API system at Volvo Group. The failure modes we identify generalize across industries where software must encode specialized domain knowledge, offering practitioners a vocabulary for diagnosing similar inefficiencies in their own workflows. •We show that automating translation requires transform- ing the MSD workflow itself, not just accelerating individ- ual coding tasks. We model the workflow as a graph of artifacts, dependencies, and handoffs, and use this repre- sentation to systematically restructure the process so that LLM-powered services can incrementally replace manual coordination while keeping domain experts in the loop and minimizing disruption to established practices. •We provide quantitative evidence from a deployed system that generates 192 real-world API endpoints across six in- dustrial domains. Compared to semi-automated implemen- tations (human developers assisted by GitHub Copilot), the automated workflow achieves a 93.7% F1 score and reduces per-API development time from approximately 5 hours to under 7 minutes, saving an estimated 979 engineering hours across the endpoint portfolio. • We report deployment experience and stakeholder feedback from production use at a major automotive manufacturer. Do- main experts and developers using the system daily reported high satisfaction (averaging 4.80 and 4.67, respectively, on a 5-point scale), indicating that the approach delivers practical value beyond offline metrics. The remainder of this paper is organized as follows. Section 2 de- scribes thespapisystem and the operational problems observed in its development workflow. Section 3 presents our workflow op- timization approach and its implementation. Section 4 reports ex- perimental results and stakeholder feedback. Section 5 discusses practical considerations. Section 6 surveys related work, and Sec- tion 7 concludes. 2 The spapi System spapiis an in-vehicle web server deployed at Volvo Group that provides a stable, authenticated API layer mapping vehicle signals and control state to well-typed RESTful endpoints. Driver-facing mobile applications and backend fleet services consume these end- points to display vehicle status, adjust climate and comfort settings, and monitor operational parameters across the vehicle’s functional domains. Developing and maintainingspapihas required 15 to 20 full- time engineers (FTEs) to deliver over 100 APIs spanning six func- tional domains: driver productivity, connected systems, energy management, vehicle systems, visibility, and dynamics. Three cat- egories of artifacts drive this workflow. OpenAPI specifications define endpoint behavior, data types, and interface contracts; these artifacts embody the essential complexity [20] of the system and serve as the authoritative source for mobile and cloud application integration. Signal definitions describe low-level CAN bus mes- sages encoding vehicle state, authored by control engineers and system architects who understand the physical systems. Mapping documents bind high-level API properties to their underlying sig- nals, specifying how abstractions like “climate mode” translate to specific CAN message fields. The typical workflow proceeds through a sequence. Domain experts produce requirements and signal descriptions based on ve- hicle capabilities and business needs. Developers manually convert those documents into endpoints, adapters, data models, and tests, consulting the various artifact types to understand how each API property should behave. A dedicated coordination group, supple- mented by direct contact with domain experts, resolves ambiguities that arise when specifications are incomplete or inconsistent. Under this workflow, defining a single API could take as long as 10 weeks from initial specification to deployment-ready code. LLM-Powered Workflow Optimization for Multidisciplinary Software Development: An Automotive Industry Case StudyFSE ’26, June 5–9, 2026, Montreal, Canada Observed Problems. Four problems characterize the workflow’s failure modes, each contributing to inefficiency that compounds as the system scales. Fragmented artifacts. Multiple overlapping documents, in- cluding API specifications, signal definitions, detailed descriptions, and coordination notes, describe related information in different formats and at different levels of abstraction. Developers must cross- reference and align these sources to produce correct implementa- tions. When artifacts fall out of sync, as they frequently do during requirements evolution, the reconciliation burden compounds and error opportunities multiply. Manual-translation overload. Developers spend substantial effort transcribing information from specifications and signal defini- tions into code, diverting time from higher-value activities such as design, testing, and verification. Even with assistance from coding agents like GitHub Copilot, developers must still manually locate relevant artifacts, interpret domain-specific formalisms, reconcile inconsistencies across documents, and repeatedly consult domain experts to resolve ambiguities. This coordination burden grows proportionally with API and signal count. With over 400 unique properties and 776 associated CAN signals across thespapisys- tem, translation work creates a persistent bottleneck that cannot be resolved by coding assistants alone; it requires automating the workflow itself. Ambiguity-driven churn. Underspecified items in domain doc- uments prompt clarification rounds between developers and ex- perts, each consuming time from both parties and potentially inval- idating prior implementation decisions. Signal definitions inspapi were often concise to the point of ambiguity, requiring developers to consult vehicle state experts, system engineers, and sometimes control engineers, whose discipline has deep technical foundations spanning decades [5]. A single ambiguous signal could cascade into multiple days of clarification before implementation could proceed. Coordination bottlenecks. The coordination group established to streamline information flow acrossspapidevelopment proved inadequate for managing hundreds of API properties and vehi- cle signals. Developers began bypassing the group to contact do- main experts directly, creating ad-hoc communication patterns that were difficult to track and prone to inconsistency. Once such workarounds begin delivering value, organizational inertia makes them resistant to change, even when their inefficiency is widely recognized. Industry Implications. These problems are not unique to auto- motive systems. Similar bottlenecks arise wherever software must encode specialized domain knowledge and development requires ongoing coordination across disciplinary boundaries. The consequences compound at scale. Manual transcription shifts engineering time away from architecture, testing, and verifica- tion, increasing both development costs and defect risk. Fragmented artifacts and frequent clarification cycles produce inconsistent im- plementations, with conflicts discovered late in integration when rework costs are highest. As product scope or regulatory require- ments grow, staffing and coordination overhead increase dispro- portionately, yet adding engineers provides only temporary relief without addressing underlying inefficiencies. Perhaps most criti- cally, domain understanding becomes concentrated in role-specific artifacts and individual expertise; when personnel change or speci- fications evolve, the implicit knowledge embedded in translation decisions can be lost, forcing costly rediscovery. These failure modes motivate automation strategies that reduce manual handoffs through tighter artifact-code integration and tar- geted tooling. The following sections describe our approach and its application to spapi. Our Approach. We address these challenges through an iterative workflow optimization approach that models the MSD process as a graph and progressively automates manual translation nodes. The workflow graph represents participants (domain experts, develop- ers, and automated services) as nodes, with artifact exchanges as edges. This representation makes explicit the communication struc- ture that drives development effort and highlights where manual translation creates bottlenecks. We apply a series of graph transformations that replace manual nodes with LLM-powered services, reducing complexity and com- munication overhead while preserving the information flows that domain experts rely upon. Each transformation targets a specific translation task: generating signal access code from definitions, aligning API properties with corresponding signals, and assem- bling complete endpoints from validated components. Rather than replacing the entire workflow at once, we incrementally automate individual tasks, validating each step with domain experts before proceeding to the next. This graph-based perspective enables systematic identification of automation opportunities and provides a framework for mea- suring improvement across iterations. The result is a production pipeline comprising three coordinated services that reduce per-API development time from approximately 5 hours to under 7 minutes while achieving quality comparable to manual implementation. 3 Methods and Implementation This section describes our approach to automating artifact-driven multidisciplinary workflows. We model the development process as a graph and apply iterative transformations that replace manual translation tasks with LLM-powered services. 3.1 Workflow Graph Representation To formalize the complex interactions in software development, we represent the workflow as a directed dependency graphG= (V,R). We define nodesVas concrete artifacts (e.g., specification documents, signal definitions, or constraint descriptions) and edges R as information dependencies. Formally, letV=푑 1 ,푑 2 , . . .,푑 푛 denote the set of documents generated during the workflow. A relation(푑 푖 ,푟 푖푗 ,푑 푗 ) ∈ Rexists if the production or validation of document푑 푗 depends on the information contained in푑 푖 . The workflowGis thus represented as a set of relational triples: G=(푑 푖 ,푟 푖푗 ,푑 푗 ) | 푑 푖 ,푑 푗 ∈V,푟 푖푗 ∈ R(1) This formulation shifts the problem of workflow automation from managing human coordination to a structured transformation of a document dependency graph into executable code. Figure 2 (Init) shows the initial workflow graph forspapi. Four expert roles participate: API designers responsible for OpenAPI FSE ’26, June 5–9, 2026, Montreal, CanadaShuai Wang, Yinan Yu, Earl Barr, and Dhasarathy Parthasarathy Code generation ... APIAutoBlowLvlStatus: Signal indicated the Auto Blower level mode Output: SPAPI Endpoint Code Control engineers API designer Vehicle state experts System engineers Ct rl. m odels API Spec Signal D ef.Signal D esc. Std. Do c Deve lopers Coordi nation group Control engineers API designer Vehicle state experts System engineers Ct rl. m odels Std. Do c Developers CoordinationGroup Signal R/W Synthesis Signal D esc.Signal D ef. API Spec Control engineers API designer Vehicle state experts System engineers Ctrl. m odels Std. Do c Developers API Spec Signal R/W Synthesis Signal-prop Synthesis Prop-endpoint Synthesis Control engineers API designer API Spec Signal R/W Synthesis Signal-prop Synthesis Output: SPAPI Endpoint Code Output: SPAPI Endpoint Code Output: SPAPI Endpoint Code Init Vehicle state experts System engineers Prop-endpoint Synthesis API Spec Signal R/W Synthesis Signal-prop Synthesis APIACModeStatus ACMode_Standard:1 ACMode_Economy:0 class APIACModeStatus(Enum): APIACModeStatus_Standard =1 APIACModeStatus_Economy = 0 LLM Code base Signal defin atio n Read/Write Signal Code ClimateObject: description: climate settings on the truck. properties: acMode: enum: ["STANDARD", "ECONOMY"] description: Air conditioning mode. example: "ECONOMY“ ...... APIACModeStatus: Signal used to control the AC Cos(v1, v2) LLM Code generation Fuzzy matching & Code generation from fastapiimport APIRouter from app.modelsimport ClimateObject from app.properties import get_acMode, get_autoFanLevel router = APIRouter(tags=['Climate']) @router.get('/climates', response_model=ClimateObject) defget_climates() -> ClimateObject: ac_mode = get_acMode() auto_fan_lv = get_autoFanLevel() climate_object = ClimateObject( type="Climate", acMode=ac_mode, autoFanLevel=auto_fan_lv ) returnclimate_object import APIAutoBlowLvlStatus def get_autoFanLevel(): import APIACModeStatus def get_acMode(): Standard= APIACModeStatus.APIACModeStat us_Standard Embed Signal descripti on API specification Embed Top-K simil arity Read/Write Property Code Output: SPAPI Endpoint Code LLM Signal R/W Synthesis Signal-prop Synthesis Prop-endpoint Synthesis Graph-Level Iteration Iter. 1Iter. 2 Iter. 3 Node-Level Transformation Output: SPAPI Endpoint Code Final Deployed Workflow Artifact Artifact Artifact Artifact Artifact Artifact Artifact Artifact Artifact Expert Team Developers Cpx: -1 Auto: +1 Comm : +2 Cpx: -2 Auto: +1 Comm : +2 Cpx: -2 Auto: +1 Comm: +2 Human-Machine Interface (HMI) Figure 2: Iterative workflow optimization framework for vehicle API generation. The upper part illustrates graph-level optimization, depicting how the initial manual workflow undergoes three iterative refinements to achieve a highly automated workflow. The lower-right part illustrates the final deployed workflow, which comprises three server nodes. The lower-left part illustrates the detailed structure of each node. specifications, vehicle state experts who define CAN signal seman- tics, system engineers who integrate signals across subsystems, and control engineers who establish vehicle behavior constraints. These experts produce artifacts that developers must translate into code, with a coordination group mediating communication. The graph is densely connected: all four expert roles interact with each other and with developers, resulting in significant coordination overhead. Without an explicit graph representation, such workflow transfor- mations tend to remain ad-hoc, making coordination bottlenecks difficult to reason about systematically or evaluate across iterations. This workflow graphGserves as the starting point for opti- mization. Our goal is to systematically replace manual translation nodes with automated services, reducing graph complexity and communication overhead while preserving the information flows that domain experts require. 3.2 Workflow Optimization Framework Our framework aims to optimize the workflow by operating at two distinct levels: node-level transformation, which automates individ- ual manual tasks, and graph-level restructuring, which streamlines the workflow by eliminating redundant coordination dependencies. Node-level Transformation. At the node level, we formalize the conversion of manual translation tasks into LLM-driven automated services. For each document node푑 푖 ∈V, we denote its associated input materials asM 푖 (e.g., domain specifications and signal def- initions) and human-provided refinement instructions asI 푖 . The transformation process is modeled as a function: 푓 LLM : (M 푖 ,I 푖 ) → 푐 푖 (2) where푐 푖 represents a modular, executable code artifact. To ensure reliability, each 푐 푖 must pass an automated validation checkΦ test : Φ test (푐 푖 ,M 푖 ) →pass, fail(3) whereΦ test relies on test cases synthesized fromM 푖 . Only artifacts that satisfyΦ test = passare accepted. Upon successful validation, the manual node푑 푖 is substituted by an automated service node푠 푖 , which encapsulates푐 푖 and exposes a programmatic interface. This substitution is denoted as 푑 푖 ⇒ 푠 푖 . Graph-level Restructuring. Following node-level transformations, the initial graphGevolves into an intermediate stateG ′ . We then refine the topology by identifying and removing redundant coor- dination edges. An edge(푣 푖 ,푟 푖푗 ,푣 푗 ) ∈ G ′ is defined as redundant if the information dependency푟 푖푗 can be resolved through direct LLM-Powered Workflow Optimization for Multidisciplinary Software Development: An Automotive Industry Case StudyFSE ’26, June 5–9, 2026, Montreal, Canada Table 1: Scoring scheme for transformation impact across three dimensions DimensionScore Description Complexity -1Task or exchange removed or com- bined 0No change +1Task or exchange added Automation -1Task becomes more manual 0No change +1Task becomes more automatic Communication -2Less explainable AND less exe- cutable -1 Less explainable OR less executable 0No change +1 More explainable OR more exe- cutable +2More explainable AND more exe- cutable programmatic invocation between their corresponding automated services. Formally, we define an edge asisRedundantif:∃푠 푖 ,푠 푗 such that 푑 푖 ⇒ 푠 푖 , 푑 푗 ⇒ 푠 푗 , and 푠 푗 can directly consume outputs of 푠 푖 . The optimized workflow graphG ∗ is reached through an iterative reduction process: G (푘+1) =푟 ∈ G (푘) | ¬isRedundant(푟)(4) The process converges at a fixed point whereG (푘+1) = G (푘) . Throughout this reduction, domain experts conduct reviews to ensure that no essential information flow is lost. 3.3 Measuring Transformation Impact To formalize the assessment, we model a transformation휏as a mapping from an original workflow푊to a transformed workflow 푊 ′ = 휏(푊). The overall impact of휏is evaluated along the three dimensions defined in Table 1. Let the scoring function for each dimension푑 ∈ complexity, automation, communication be푠 푑 (휏) ∈Z, where the range and semantics of푠 푑 are given directly by the discrete levels in Table 1. Each score reflects expert judgment on how the transformation changes the corresponding property when comparing푊and푊 ′ . The transformation impact vector is then defined as s(휏)= 푠 complexity (휏), 푠 automation (휏), 푠 communication (휏) . The first dimension measures graph complexity: whether a trans- formation adds or removes tasks and communication edges. The second measures automation level: whether work shifts from man- ual to automatic execution. The third measures communication quality through the lens of duality, i.e., the degree to which arti- facts are both explainable to humans and executable by machines. Source code with meaningful identifiers and comments exemplifies high duality [10]. Transformations that produce executable code with clear documentation score positively on this dimension. classCANSignalFunctionWriter(dspy.Signature): """Generate a Python function to read or write a CAN Signal. -Read/write the CAN value or its enumequivalent. -Enum class name = CAN Signal name (no changes). -Function names: start with 'read_' or 'write_'. -Check min/max if available. -Include docstrings.""" CAN_Signal: dict= dspy.InputField(desc="CAN signal metadata") code: str= dspy.OutputField(desc="Generated Python module") 1 2 3 4 5 6 7 8 9 10 11 Figure 3: A simplified DSPy signature for Signal R/W Syn- thesis. The LLM generates Python functions to read or write CAN signals based on signal metadata. 3.4 Node-Level Automation We implemented three automated services to replace manual trans- lation tasks in thespapiworkflow. Each service corresponds to a distinct translation step, and together they form the pipeline shown in the lower portion of Figure 2. 3.4.1 Signal R/W Synthesis. The first service generates Python code for reading and writing CAN signals. It takes signal definitions as input (signal names, data types, value ranges, and enumeration mappings) and produces functions that interface with the vehicle’s CAN bus. We use the DSPy framework [21] for structured prompting, as illustrated in Figure 3. LLMs can be adapted to diverse tasks through prompting [7,8] and excel at processing semi-structured inputs [19,28]. DSPy’sTypedPredictorensures that generated code conforms to expected types; if output violates constraints, the system automatically re-prompts the model. Recent work on constrained generation [6,29,35] enables LLM outputs to satisfy syntactic requirements, facilitating integration with traditional software tooling. For validation, we generate test cases using a separate LLM call and prompt the code-generating LLM to self-debug based on test failures. Once verified, signal R/W code is stored in a vector database indexed by structured signal descriptions, enabling retrieval for downstream synthesis steps. Our test-based validation approach aligns with recent work on LLM-driven test automation in automotive settings [39]. 3.4.2 Signal-Property Synthesis. The second service aligns API properties with their corresponding CAN signal handlers. A key challenge in synthesizing deployable API endpoints lies in correctly aligning API properties with underlying CAN signals. Given an API property defined at the application level, the system must identify one or more corresponding CAN signals and determine how their values should be interpreted, transformed, and composed to produce semantically correct API behavior. This alignment is challenging because API and CAN specifica- tions often diverge. Value domains may not match (e.g.,ON/OFFvs. 0/1), units may differ (e.g.,m/son CAN vs.km/hin the API), and some properties aggregate multiple CAN signals (e.g., a single time property derived from separate minute and second signals). As a result, naive matching based on names or types is unreliable and can introduce silent semantic errors. FSE ’26, June 5–9, 2026, Montreal, CanadaShuai Wang, Yinan Yu, Earl Barr, and Dhasarathy Parthasarathy Task: Align an API property with CAN signal(s). Let’s think step by step: 1)Identify the API property intent (name/values/unit). 2)Select semantically equivalent CAN signal(s). 3)Check value domains; if mismatched, write an explicit mapping (e.g., ON/OFF 0/1). 4)Check units; if different, annotate the required conversion (e.g., m/s km/h). 5)If the property composes multiple signals, specify the one-to-many composition. Return JSON as defined by: <DEFINED_JSON_SCHEMA> Figure 4: Representative prompt used in the Signal-Property matching task (simplified for clarity). from fastapi import APIRouter, Depends, HTTPException from pydantic import BaseModel from typing import Any router = APIRouter() # ======== Models (Generated from OpenAPI) ======== class SpeedResponse(BaseModel): speed: float unit: str # ======== Shared Dependencies ======== def get_auth_context() -> Any: # Authentication / authorization logic return "role": "user" # ======== Endpoint Template ======== @router.get("/vehicle/speed", response_model=Response) async def get_vehicle_speed( request: "SpeedRequest", auth_ctx: Any = Depends(get_auth_context)): try: speed = read_vehicle_speed() response =Response(speed=speed, unit="km/h",) return response except Exception: raiseHTTPException(status_code=500, detail="...") 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Figure 5: Example of a FastAPI endpoint boilerplate template. To make these assumptions explicit and verifiable, we use a JSON alignment template as an intermediate representation. The LLM must enumerate all contributing CAN signals and specify explicit value mappings, enum correspondences, and unit conversion anno- tations when needed. As shown in Figure 4, we further guide gen- eration with a chain-of-thought prompt that encourages stepwise reasoning over (i) property intent, (i) value and unit consistency, and (i) whether the mapping is direct, requires transformation, or involves multi-signal composition. Together, the template con- straint and structured reasoning reduce hallucinated assumptions and improve robustness across heterogeneous signal specifications. 3.4.3 Property-Endpoint Synthesis. The third service assembles property handlers into deployable API endpoints based on the OpenAPI specification. Given the API contract and generated prop- erty accessors as input, it produces complete FastAPI endpoint implementations, including routing, request validation, response serialization, and error handling. Synthesizing endpoints directly from specifications is error- prone in practice. Naively generated endpoints may violate the Task: Instantiate (not freely generate) a FastAPI endpoint from an API specification. Inputs: - <FastAPI_Endpoint_Boilerplate_Template> - <API_SPECIFICATION> Constraints: 1)Treat the OpenAPI specification as the single source of truth. 2)Do not modify routes, methodsor schemas. 3)Use the FastAPI template without modification. 4)Fill only endpoint-specific logic (property access and response composition). 5)Rely on FastAPI‘s schema-driven validation. Figure 6: A representative prompt used in the API Endpoint synthesis task (simplified for clarity). OpenAPI contract, for example by using inconsistent parameter names, omitting or introducing response fields, or mismatching route paths and HTTP methods. In addition, validation logic such as range checks or enum constraints may be partially implemented or entirely omitted, leading to subtle contract violations that are difficult to detect at runtime. To mitigate these risks, this service adopts a contract-first, template- based generation strategy. A FastAPI endpoint boilerplate template (Figure 5) fixes the endpoint structure, routing, schemas, and cross- cutting concerns such as authentication, logging, and error han- dling. The LLM is restricted to instantiating endpoint-specific logic within predefined slots, guided by the prompt shown in Figure 6. Validation is delegated to FastAPI’s schema-driven mechanisms, ensuring consistent enforcement of constraints specified in the OpenAPI document. 3.5 Graph-Level Optimization Following node-level synthesis, the initial workflow is modeled as a coordination graphG (0) , where nodes represent development activities or automated services, and edges denote information dependencies and human-mediated coordination. Graph-level opti- mization is an iterative process that restructuresG (푘) by introduc- ing executable services to absorb coordination overhead. Formally, each optimization step applies a transformation휏 푘 :G (푘) →G (푘+1) that replaces manual hand-offs with automated services, thereby eliminating edges resolved programmatically. As illustrated in Figure 2, the transformation of thespapiwork- flow proceeds through three successive iterations: Iteration 1: Signal R/W Synthesis. By generating executable signal access code directly from definitions, this service eliminates the re- quirement for developers to consult vehicle state experts, removing the associated coordination edge fromG (0) . Iteration 2: Signal-Property Synthesis. This stage automates the alignment between API properties and CAN signals. By generating mapping code, the service absorbs the complex interactions previ- ously required between API designers, vehicle state experts, and system engineers, eliminating two additional edges. Iteration 3: Property-Endpoint Synthesis. This transformation en- codes vehicle-specific constraints (e.g., access permissions and value ranges) directly into OpenAPI annotations. The LLM utilizes these LLM-Powered Workflow Optimization for Multidisciplinary Software Development: An Automotive Industry Case StudyFSE ’26, June 5–9, 2026, Montreal, Canada Table 2: Cumulative transformation impact across three iter- ations. IterationComp. Auto. Comm. 1: Signal R/W-1+1+2 2: Signal-Property-2+1+2 3: Property-Endpoint-2+1+2 Net change-5+3+6 constraints during generation to ensure architectural compliance, removing the need for manual review by control engineers. The cumulative impact of these transformations is quantified in Table 2. Each step휏 푘 consistently increments the automation level while enhancing communication quality by producing out- puts that are both explainable and executable. Collectively, these optimizations reduced the workflow complexity by 5 edges, im- proved communication quality by 6 units, and increased the overall automation index by 3 relative to the manual baseline. 3.6 Deployed System After iterative optimization, the final system replaces all manual translation steps with automated services and reaches a stable configuration validated by domain experts. The resulting workflow, shown in the lower-right of Figure 2, consists of three server nodes connected in a linear pipeline. Compared to the initial manual workflow, the deployed system achieves a net complexity reduction of 5, a communication quality improvement of 6, and an automation increase of 3. System overview. The system takes as input an initial workflow graphG (0) with dense manual coordination and a set of domain artifacts, including OpenAPI specifications, signal definitions, and constraint documents. It outputs an optimized workflow graphG ∗ in which manual translation nodes are replaced by service nodes and redundant coordination edges are removed, yielding a compact and executable end-to-end pipeline. Architecture and interaction. Each node inG ∗ is deployed as an independent server exposing a well-defined API and composed sequentially to mirror the optimized workflow graph. The architec- ture decouples workflow logic from the underlying language model implementation, enabling flexible substitution of open-source or proprietary LLMs under different cost, latency, and privacy con- straints. A unified human–machine interface allows domain experts to inspect API-to-signal mappings, review generated code, and re- quest regeneration with additional constraints, preserving human oversight without manual translation. Execution and adaptability. The system supports both fully auto- mated and human-in-the-loop execution. For well-specified tasks, the pipeline operates end-to-end without intervention; ambiguous mappings or specification inconsistencies are flagged for expert review. By replacing input artifacts or domain-specific instructions, the same framework can be readily adapted to new APIs, vehicle platforms, or other translation-heavy workflows. 4 Evaluation RQ1: [Overall performance]Does the automated workflow achieve code quality comparable to AI-assisted human development (with Copilot) across different automotive domains? RQ2: [ Reliability]Do the specific techniques employed (boiler- plate templates, code composition, and automated debug- ging) each contribute measurably to system reliability? RQ3: [Efficiency]Does the automated workflow reduce develop- ment time compared to AI-assisted processes while main- taining acceptable quality? RQ4: [Human factors]Do domain experts and developers report satisfaction with the deployed system sufficient to support continued production use? 4.1 Experimental Setup We conducted experiments on 192 real-world automotive API end- points collected from six distinct industrial domains at Volvo Group, as summarized in Table 3. These APIs collectively span 420 unique properties and 776 associated CAN signals, representing the full scope of the spapi system. We use the original production implementations developed by engineers (assisted by GitHub Copilot) as ground truth, referred to as the baseline. Precision (P) measures the correctness of gen- erated property-level code, computed as푃= |Correct| |Generated| . Recall (R) measures coverage of the original API specification, computed as 푅= |Correct| |Baseline| . F1 is the harmonic mean of precision and recall, computed as 퐹1= 2푃푅 푃+푅 . The baseline implementations have been reviewed and deployed in production and therefore reflect accepted system behavior. In this domain, semantic errors typically manifest as concrete issues such as enum mismatches, value range violations, or missing signal bindings, all of which are explicitly targeted by our validation and automated debugging mechanisms. We deliberately adopt a conservative matching strategy, preferring to flag ambiguous cases for human review rather than generating potentially incorrect code, in order to avoid silent semantic errors. To address RQ4, we invited all practitioners with direct experi- ence of both workflows to provide structured feedback: four domain experts and two developers. This complete census of qualified eval- uators rated the system on role-specific criteria using a 5-point scale. Experts assessed communication effort, functional coverage, and implementation accuracy; developers assessed communication efficiency, debugging effort, and code maintainability. Baseline workflow. Since no existing automated solutions target API development in industrial automotive scenarios, we compare our system with APIs developed by human engineers assisted by proprietary AI coding coding agents. In this baseline, engineers were permitted to use GitHub Copilot, a state-of-the-art AI-assisted coding tool, to support implementation. We assess both API quality and development time. LLM usage and time cost. The system distinguishes between of- fline processing and deployment-time execution to manage LLM FSE ’26, June 5–9, 2026, Montreal, CanadaShuai Wang, Yinan Yu, Earl Barr, and Dhasarathy Parthasarathy Table 3: Performance and satisfaction scores across six automotive domains. DomainDomain ExpertsNum PerformanceSatisfaction PRF1 Expert Developer Driver productivityHMI/UX, business translators, regulators341.0000.9570.9784.934.86 Connected systemsBusiness translators, dealers, sales staff530.9480.9070.9274.764.69 EnergyControl/mechanical/electrical engineers, emissions181.0000.9130.9554.864.71 Vehicle systemSystem architects, embedded software engineers340.9740.8860.9284.774.62 VisibilityMechanical engineers, designers, HMI/UX141.0000.9250.9614.884.75 DynamicsControl engineers390.9830.8650.9204.754.55 Total-1920.9760.9020.9374.804.67 usage efficiently. All compute-intensive LLM operations occur dur- ing the offline stage and do not affect runtime performance. In our experiments, we use the proprietary LLM GPT-4o (2024-05-13). During offline processing, the LLM is used to scan and filter the entire CAN database and derive read/write equations for relevant signals. In a full experimental run involving 192 APIs and 776 CAN signals, the system made approximately 15,000 LLM calls over 20.6 hours. This corresponds to an average cost of 396 seconds and 80 LLM calls per API. During deployment, the previously generated read/write equa- tions are reused and do not require regeneration. The LLM is only invoked for lightweight tasks such as matching API properties to signals and synthesizing the final API endpoint. On average, each API requires about 5 LLM calls, resulting in approximately 10 sec- onds per API. This overhead is low and acceptable for practical use in engineering workflows. 4.2 RQ1: Code Quality Across Domains Table 3 summarizes code quality results across all six automotive domains. The automated workflow achieves strong performance consistently: four domains (Driver productivity, Energy, Visibility, and Dynamics) reach perfect precision of 100%, indicating that all generated property-level code was correct. The remaining two domains (Connected systems and Vehicle system) achieve precision above 94%. Recall scores are slightly lower, ranging from 86.5% to 95.7% across domains. This reflects our conservative matching strategy during property-to-signal alignment, where we apply strict filtering to retain only high-confidence matches. Properties with ambigu- ous signal mappings are flagged for human review rather than generating potentially incorrect code. Despite this conservative approach, average recall exceeds 90%, indicating strong coverage of the original specifications. The overall F1 score of 93.7% demonstrates that the automated workflow produces code quality comparable to baseline develop- ment across diverse automotive domains. Importantly, performance remains consistent regardless of which expert roles are involved– the system handles APIs requiring input from control engineers (Dynamics, Energy) as effectively as those involving HMI/UX de- signers or business translators. Stakeholder satisfaction scores (detailed in Section 4.5) provide additional validation, with both experts and developers reporting Table 4: Ablation study: impact of individual techniques on code quality and satisfaction. Configuration PerformanceSatisfaction PRF1 Expert Developer Full automated workflow0.9760.9020.9374.804.67 without boilerplate templates0.9680.8950.9304.744.45 without code composition0.9560.8830.9184.694.43 without automated debugging0.9110.8410.8754.334.15 Table 5: Signal code accuracy before and after automated debugging, by signal type. Stage Signal TypeEnum Bool Numerical Object Total Count634903319776 Initial LLM output96.50%96.70%90.90%89.50%93.40% After automated debugging100%100%100%100%100% high satisfaction and noting that the system facilitates transparent monitoring through well-defined interfaces. Answer to RQ1: Yes. The optimized workflow achieves 93.7% F1 with consistent performance across six diverse domains, meeting production quality standards. 4.3 RQ2: Reliability of Code Generation Techniques We conducted an ablation study to quantify the contribution of each technique to overall system reliability. Table 4 shows performance when individual components are removed. Removing boilerplate templates reduces F1 from 93.7% to 93.0% and decreases developer satisfaction from 4.67 to 4.45. Without templates, generated code exhibits inconsistent structure and style, requiring additional manual cleanup. Removing code composition (assembling endpoints from reusable, validated fragments) reduces F1 to 91.8% and satisfaction scores to 4.69 and 4.43 for experts and developers respectively. The most significant impact comes from removing automated debugging. Without test-based validation and self-correction, F1 drops to 87.5%, and satisfaction scores fall to 4.33 and 4.15. This rep- resents a substantial degradation that would likely be unacceptable for production use. Table 5 provides detailed analysis of the debugging component. We categorized the 776 CAN signals into five functional types and LLM-Powered Workflow Optimization for Multidisciplinary Software Development: An Automotive Industry Case StudyFSE ’26, June 5–9, 2026, Montreal, Canada Table 6: Property-to-signal matching performance by embed- ding strategy. Embedding InputPRF1 Raw signal code0.7630.2770.406 Original descriptions0.8610.4510.592 Rewritten descriptions0.9800.9250.952 Table 7: Detection performance for common specification errors. Error TypePRF1 Out-of-range value0.9791.0000.989 Invalid enum value0.9891.0000.994 measured accuracy before and after the debugging phase. Initial LLM outputs achieve high accuracy for most categories (96.5% for Enum, 96.7% for Bool) but lower accuracy for more complex types (90.9% for Numerical, 89.5% for Object). Common errors include sub- tle syntax mismatches, such as usingLowSupplyPress(Enum_Value) instead of the correctLowSupplyPress[Enum_Value]. After auto- mated debugging, all signal types reach 100% accuracy, validating our two-stage strategy of generating an initial draft followed by test-based refinement. Effect of Embedding Strategies on Property-Signal Matching. We also evaluated the impact of embedding strategy on property-to- signal matching, a critical step in the pipeline. Table 6 compares three approaches: embedding raw signal code, embedding original textual descriptions from documentation, and embedding rewritten descriptions enriched with clarified semantics. All configurations maintain high precision due to strict simi- larity thresholds, but recall varies substantially. Raw signal code performs poorly (F1 = 0.406) because code lacks semantic context. Original textual descriptions improve performance (F1 = 0.592), but brevity and ambiguity limit accuracy. Rewritten descriptions, where LLMs expand and clarify signal semantics, achieve F1 of 0.952, demonstrating that investment in description quality yields substantial returns. 4.3.1 Robustness to Specification Errors. To assess robustness in real-world conditions, we evaluated the system’s ability to detect errors in user-provided specifications. We manually injected two common error types into YAML specification files: numerical val- ues exceeding defined ranges and enum values not present in the allowed set. As shown in Table 7, the system detects these errors with high precision, achieving F1 scores of 0.989 and 0.994 respectively. Be- yond ensuring correctness under ideal inputs, the pipeline serves as a validation layer that provides early feedback to help users identify and correct specification errors before they propagate to generated code. Answer to RQ2: Yes, each technique contributes measurably to system reliability. Automated debugging has the largest impact, Table 8: Quality and time comparison: automated vs. baseline development. Configuration PerformanceTime PRF1Per APISystem Total Full automated workflow0.9760.9020.937396s20.6h without Signal R/W Synthesis0.9650.9130.939+1.5h+288.0h without Signal-Property Synthesis0.9920.9530.972+2.5h+480.0h without Property-Endpoint Synthesis0.9800.9070.942+1.1h+211.2h Baseline workflow (Copilot)0.9590.9060.932+5.1h+979.2h improving F1 by 6.2 percentage points and enabling 100% accuracy on signal code after refinement. Boilerplate templates and code composition each contribute smaller but meaningful improvements. The embedding strategy for property-signal matching also signifi- cantly affects performance, with enriched descriptions improving F1 from 0.592 to 0.952. 4.4 RQ3: Development Time Comparison We compared our automated workflow against baseline develop- ment by systematically replacing each automated service with human engineers and measuring both quality and time. Table 8 presents the results. The fully automated workflow completes API generation in 396 seconds per endpoint (approximately 6.6 minutes), while the base- line workflow requires approximately 5.1 additional hours per end- point, a reduction of over 97% in development time. Across the full portfolio of 192 APIs, automation saved approximately 979 hours of engineering effort compared to the baseline workflow. Baseline development achieves higher recall in some configu- rations, revealing a quality-efficiency tradeoff. When humans per- form Signal-Property Synthesis with the help from Github Copilot, F1 increases from 93.7% to 97.2% because engineers can resolve ambiguous mappings that the automated system conservatively flags for review. However, this 3.5 percentage point improvement requires 2.5 additional hours per API (480 hours total across the portfolio), a tradeoff that is difficult to justify at scale. Each automated service contributes meaningful time savings. Signal R/W Synthesis saves 1.5 hours per API by automating the translation of signal definitions into access code. Signal-Property Synthesis saves 2.5 hours per API – the largest contribution – by automating the cognitively demanding task of mapping API prop- erties to signals. Property-Endpoint Synthesis saves 1.1 hours per API by automating endpoint assembly from validated components. Answer to RQ3: Yes. Per-API development time decreases from 5.1 hours to under 7 minutes (97% reduction), saving approximately 979 engineering hours across 192 APIs. 4.5 RQ4: Stakeholder Satisfaction We invited four domain experts and two developers who work with thespapisystem to evaluate the deployed workflow. Each participant rated the system on three criteria using a 5-point scale. Table 9 presents the detailed results. Both groups report high overall satisfaction, with experts av- eraging 4.80 and developers averaging 4.67. Most notably, all six participants gave perfect scores of 5.0 for communication efficiency, indicating unanimous recognition that the automated workflow FSE ’26, June 5–9, 2026, Montreal, CanadaShuai Wang, Yinan Yu, Earl Barr, and Dhasarathy Parthasarathy Table 9: Detailed satisfaction ratings from domain experts and developers. RoleEvaluation CriterionScore Average Expert (n=4) Communication efficiency5.00 4.80Accuracy of implementation4.89 Coverage of functional requirements4.51 Developer (n=2) Communication efficiency5.00 4.67Debugging effort4.37 Code style and maintainability4.64 effectively reduces coordination overhead–the primary pain point identified in the baseline process. Experts rated accuracy of implementation at 4.89, reflecting con- fidence in the correctness of generated code. The slightly lower score for coverage of functional requirements (4.51) aligns with our quantitative finding that recall is somewhat lower than precision; some edge cases require manual handling. Developers rated code style and maintainability at 4.64, indicating that generated code meets their quality standards, though debugging effort received a slightly lower score of 4.37, suggesting room for improvement in error diagnostics. The system is deployed in production at Volvo Group and con- tinues to serve as the primary mechanism for API development. Practitioners reported improved transparency and reproducibility compared to the baseline workflow, particularly due to the ability to trace API-to-signal mappings and consistently regenerate code as specifications evolve. Answer to RQ4: Yes. Despite the small sample size, which rep- resents the complete population of practitioners directly involved in both workflows, all participants reported satisfaction levels sup- porting continued production use. The unanimous improvement in communication efficiency and sustained production deployment provide converging evidence that the approach effectively addresses the coordination bottleneck motivating this work. 4.6 Threats to Validity Internal validity. The ground truth may itself contain errors. We mitigate this by using production code that has undergone review and testing. External validity. Our evaluation focuses on a single API system at one automotive manufacturer. While the 192 endpoints span six functional domains involving diverse expert roles (control en- gineers, HMI designers, system architects, business translators), generalization to other organizations or industries requires further validation. Construct validity. Property-level F1 may not capture all aspects of code quality. We supplement quantitative metrics with stake- holder satisfaction ratings to address this limitation. 5 Discussion On choosing workflows to automate. Although Section 3 pro- vides technical criteria for workflow automation, selecting suitable workflows ultimately requires informed judgment. Beyond techni- cal feasibility, successful adoption depends on organizational readi- ness and openness to change, which are often difficult to assess in advance. In the case ofspapi, the workflow was both well-scoped and supported by a team willing to experiment, which proved criti- cal to achieving tangible benefits. On the use of LLMs in workflow automation. Our results show that LLMs can support multiple stages of workflow automa- tion, including parsing, translation, generation, and evaluation. However, effective use of LLMs still requires experience, partic- ularly in deciding when hybrid solutions combining scripts and LLMs are more appropriate. The iterative nature of our approach allows LLM usage to evolve alongside the workflow as teams refine these decisions over time. On multidisciplinary collaboration. Multidisciplinary soft- ware development often suffers from unclear ownership between developers and domain experts. By representing workflows explic- itly and enabling LLM-driven translations into domain-accessible forms, our graph-based approach improves transparency and partic- ipation. This makes workflows more iterable and shareable, helping move teams closer to practical joint ownership. From a software engineering perspective, our findings suggest that translation-heavy MSD workflows constitute a distinct class of coordination-intensive processes. In such workflows, development effort is dominated not by algorithmic complexity, but by repeated artifact translation, handoffs, and clarification cycles across roles. Our results indicate that effective automation in these settings lies primarily in restructuring artifact flows and coordination structures, rather than optimizing individual coding tasks. We believe this perspective can inform the design of future LLM-assisted tools that operate at the workflow level rather than the function or file level. 6 Related work Improving MSD:. Although software is increasingly being adopted across diverse fields, research on improving MSD remains rela- tively limited [38,40,41]. Previous research includes a survey of non-software engineers [24] to understand their perspectives on ef- fective collaboration with software engineers, as well as a study [14] that uses activity theory to interpret sources of friction in MSD. Other studies have investigated specific types of multidisciplinary collaboration, such as those involving data scientists [9,23] and machine learning engineers [25,26,32], emphasizing the nature of these collaborations and the sociotechnical challenges that arise. Ad- ditionally, some research has addressed sector-specific challenges in MSD, such as in healthcare [42] and automotive domains [18,30], identifying collaboration issues and their associated costs. AI in MSD:. As AI becomes more prevalent in software engineer- ing, recent research has explored how AI can help address collabora- tion challenges in MSD. One interview study [31] used the concept of shared mental models to analyze communication gaps between AI developers and domain experts. Other studies [33,36,37,43] explored the use of prompting as a means for rapid prototyping among participants with varied workflows. Research in Human- Computer Interaction (HCI) has also examined multi-participant interactions with AI systems [16], including the development of guidelines [3] and taxonomies [12] for human-AI collaboration. Additional works have focused on designing improved interactions [1, 17] to enhance the agency of domain experts. LLM-Powered Workflow Optimization for Multidisciplinary Software Development: An Automotive Industry Case StudyFSE ’26, June 5–9, 2026, Montreal, Canada LLMs for REST APIs: In connection with the case study, an ex- panding body of research leverages LLMs for various aspects of REST API engineering. This includes generating API logic from specifications [11], creating API documentation from source code [13], producing tests for APIs [22,39], and enabling APIs as tools for LLM applications [2, 4, 34]. In contrast to prior work that improves isolated tasks, we tar- get the workflow that connects heterogeneous domain artifacts to implemented APIs. We model this MSD workflow as a graph and transform it so LLM-powered services can incrementally replace manual translation and coordination while preserving domain- expert involvement, demonstrated in production on spapi. 7 Conclusion In this paper, we show that LLM-powered workflow automation works in production MSD settings. By modeling workflows as graphs and selectively automating translation steps, we substan- tially reduce coordination overhead while preserving human over- sight. Thespapideployment at Volvo Group validates this ap- proach at scale. The pattern we address is not automotive-specific; it applies wherever software encodes specialized domain knowl- edge. Acknowledgment This work was partially funded by the Autonomous Systems and Software Program (WASP), supported by the Knut and Alice Wallen- berg Foundation, and the Chalmers Artificial Intelligence Research Centre (CHAIR). References [1]Mateen Ahmed Abbasi, Petri Ihantola, Tommi Mikkonen, and Niko Mäkitalo. 2025. Towards Human-AI Synergy in Requirements Engineering: A Framework and Preliminary Study. 2025 Sixth International Conference on Intelligent Data Science Technologies and Applications (IDSTA) (2025). doi:10.1109/IDSTA66210. 2025.11202850 [2] Adam Alami and Neil A. Ernst. 2025. Human and Machine: How Software Engineers Perceive and Engage with AI-Assisted Code Reviews Compared to Their Peers. arXiv preprint (2025). https://arxiv.org/abs/2501.02092 [3]Saleema Amershi, Dan Weld, Mihaela Vorvoreanu, Adam Fourney, Besmira Nushi, Penny Collisson, Jina Suh, Shamsi Iqbal, Paul N Bennett, Kori Inkpen, et al.2019. Guidelines for human-AI interaction. In Proceedings of the 2019 chi conference on human factors in computing systems. 1–13. [4] Jayachandu Bandlamudi, Ritwik Chaudhuri, Neelamadhav Gantayat, Kushal Mukherjee, Prerna Agarwal, Renuka Sindhgatta, and Sameep Mehta. 2025. A framework for testing and adapting rest apis as llm tools. arXiv preprint arXiv:2504.15546 (2025). [5]Stuart Bennett. 1993. A History of Control Engineering 1930-1955 (1st ed.). Peter Peregrinus, GBR. [6]Luca Beurer-Kellner, Marc Fischer, and Martin T. Vechev. 2024. Guiding LLMs The Right Way: Fast, Non-Invasive Constrained Generation. In Forty-first International Conference on Machine Learning, ICML 2024, Vienna, Austria, July 21-27, 2024. OpenReview.net. https://openreview.net/forum?id=pXaEYzrFae [7]Tom B. Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, Sandhini Agarwal, Ariel Herbert-Voss, Gretchen Krueger, Tom Henighan, Rewon Child, Aditya Ramesh, Daniel M. Ziegler, Jeffrey Wu, Clemens Winter, Christopher Hesse, Mark Chen, Eric Sigler, Mateusz Litwin, Scott Gray, Benjamin Chess, Jack Clark, Christopher Berner, Sam McCandlish, Alec Radford, Ilya Sutskever, and Dario Amodei. 2020. Language Models are Few-Shot Learners. arXiv:2005.14165 [cs.CL] https://arxiv.org/abs/2005.14165 [8] Sébastien Bubeck, Varun Chandrasekaran, Ronen Eldan, Johannes Gehrke, Eric Horvitz, Ece Kamar, Peter Lee, Yin Tat Lee, Yuanzhi Li, Scott Lundberg, Harsha Nori, Hamid Palangi, Marco Tulio Ribeiro, and Yi Zhang. 2023. Sparks of Artificial General Intelligence: Early experiments with GPT-4. arXiv:2303.12712 [cs.CL] https://arxiv.org/abs/2303.12712 [9]Gabriel Busquim, Allysson Allex Araújo, Maria Julia Lima, and Marcos Kali- nowski. 2024. Towards Effective Collaboration between Software Engineers and Data Scientists developing Machine Learning-Enabled Systems. In Brazilian Symposium on Software Engineering (SBES). Curitiba, Brazil. [10]Casey Casalnuovo, Earl T. Barr, Santanu Kumar Dash, Prem Devanbu, and Emily Morgan. 2020. A theory of dual channel constraints (ICSE-NIER ’20). Association for Computing Machinery, New York, NY, USA, 25–28. doi:10.1145/3377816. 3381720 [11] Saurabh Chauhan, Zeeshan Rasheed, Abdul Malik Sami, Zheying Zhang, Jussi Rasku, Kai-Kristian Kemell, and Pekka Abrahamsson. 2025. Llm-generated microservice implementations from restful api definitions. arXiv preprint arXiv:2502.09766 (2025). [12] Dominik Dellermann, Adrian Calma, Nikolaus Lipusch, Thorsten Weber, Sascha Weigel, and Philipp Ebel. 2021. The future of human-AI collaboration: a tax- onomy of design knowledge for hybrid intelligence systems. arXiv preprint arXiv:2105.03354 (2021). [13]Sida Deng, Rubing Huang, Man Zhang, Chenhui Cui, Dave Towey, and Rongcun Wang. 2025. LRASGen: LLM-based RESTful API Specification Generation. arXiv preprint arXiv:2504.16833 (2025). [14]Zixuan Feng, Thomas Zimmermann, Lorenzo Pisani, Christopher Gooley, Jeremiah Wander, and Anita Sarma. 2025. When Domains Collide: An Ac- tivity Theory Exploration of Cross-Disciplinary Collaboration. arXiv preprint arXiv:2506.20063 (2025). [15]Benjamin Guerineau, Chen Zheng, Matthieu Bricogne, Alexandre Durupt, Louis Rivest, Harvey Rowson, and Benoît Eynard. 2017. Management of Heterogeneous Information for Integrated Design of Multidisciplinary Systems. Procedia CIRP 60 (2017), 320–325. doi:10.1016/j.procir.2017.02.020 Complex Systems Engineering and Development Proceedings of the 27th CIRP Design Conference Cranfield University, UK 10th – 12th May 2017. [16] Muhammad Hamza, Dominik Siemon, Muhammad Azeem Akbar, and Tahsinur Rahman. 2024. Human-AI Collaboration in Software Engineering: Lessons Learned from a Hands-On Workshop. In Proceedings of the ACM/IEEE International Workshop on Software-intensive Business (IWSiB ’24). doi:10.1145/3643690.3648236 [17]Jeffrey Heer. 2019. Agency plus automation: Designing artificial intelligence into interactive systems. Proceedings of the National Academy of Sciences 116, 6 (2019), 1844–1850. arXiv:https://w.pnas.org/doi/pdf/10.1073/pnas.1807184115 doi:10.1073/pnas.1807184115 [18]Hans-Martin Heyn, Khan Mohammad Habibullah, Eric Knauss, Jennifer Horkoff, Markus Borg, Alessia Knauss, and Polly Jing Li. 2023. Automotive perception software development: An empirical investigation into data, annotation, and ecosystem challenges. arXiv preprint arXiv:2303.05947 (2023). [19]Gonzalo Jaimovitch-López, Cèsar Ferri, José Hernández-Orallo, Fernando Martínez-Plumed, and María José Ramírez-Quintana. 2023. Can language models automate data wrangling? Machine Learning 112, 6 (2023), 2053–2082. [20]Frederick P. Brooks Jr. 1987. No Silver Bullet - Essence and Accidents of Software Engineering. Computer 20, 4 (1987), 10–19. doi:10.1109/MC.1987.1663532 [21]Omar Khattab, Arnav Singhvi, Paridhi Maheshwari, Zhiyuan Zhang, Keshav Santhanam, Sri Vardhamanan, Saiful Haq, Ashutosh Sharma, Thomas T Joshi, Hanna Moazam, et al.2023. Dspy: Compiling declarative language model calls into self-improving pipelines. arXiv preprint arXiv:2310.03714 (2023). [22] Myeongsoo Kim, Tyler Stennett, Dhruv Shah, Saurabh Sinha, and Alessandro Orso. 2024. Leveraging large language models to improve rest api testing. In Proceedings of the 2024 ACM/IEEE 44th International Conference on Software Engi- neering: New Ideas and Emerging Results. 37–41. [23]Miryung Kim, Thomas Zimmermann, Robert DeLine, and Andrew Begel. 2016. Characterizing the Roles of Data Scientists in a Large Software Company. In ICSE’16: Proceedings of the 38th International Conference on Software Engineering. Austin, TX, USA. [24]Paul Luo Li, Amy J Ko, and Andrew Begel. 2017. Cross-disciplinary perspectives on collaborations with software engineers. In 2017 IEEE/ACM 10th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE). IEEE, 2–8. [25]Hanjun Luo, Chiming Ni, Jiaheng Wen, Zhimu Huang, Yiran Wang, Bingduo Liao, Sylvia Chung, Yingbin Jin, Xinfeng Li, Wenyuan Xu, XiaoFeng Wang, and Hanan Salam. 2025. HAI-Eval: Measuring Human-AI Synergy in Collaborative Coding. arXiv preprint (2025). https://arxiv.org/abs/2512.04111 [26]Lucy Ellen Lwakatare, Aiswarya Raj, Jan Bosch, Helena Holmström Olsson, and Ivica Crnkovic. 2019. A Taxonomy of Software Engineering Challenges for Machine Learning Systems: An Empirical Investigation. In Agile Processes in Software Engineering and Extreme Programming, Philippe Kruchten, Steven Fraser, and François Coallier (Eds.). Springer International Publishing, Cham, 227–243. [27] Jonathan Mougin, Jean-françois Boujut, Franck Pourroy, and Grégory Poussier. 2015. Modelling knowledge transfer: A knowledge dynamics perspective. Con- current engineering 23, 4 (2015), 308–319. [28]Avanika Narayan, Ines Chami, Laurel Orr, Simran Arora, and Christopher Ré. 2022. Can foundation models wrangle your data? arXiv preprint arXiv:2205.09911 (2022). FSE ’26, June 5–9, 2026, Montreal, CanadaShuai Wang, Yinan Yu, Earl Barr, and Dhasarathy Parthasarathy [29]Kanghee Park, Jiayu Wang, Taylor Berg-Kirkpatrick, Nadia Polikarpova, and Loris D’Antoni. 2024. Grammar-Aligned Decoding. arXiv:2405.21047 [cs.AI] https://arxiv.org/abs/2405.21047 [30] Joakim Pernstål, R. Feldt, T. Gorschek, and D. Florén. 2019. Communication Problems in Software Development — A Model and Its Industrial Application. International Journal of Software Engineering and Knowledge Engineering 29, 10 (2019), 1497–1538. arXiv:https://doi.org/10.1142/S0218194019500475 doi:10.1142/ S0218194019500475 [31] David Piorkowski, Soya Park, April Yi Wang, Dakuo Wang, Michael Muller, and Felix Portnoy. 2021. How ai developers overcome communication challenges in a multidisciplinary team: A case study. Proceedings of the ACM on human-computer interaction 5, CSCW1 (2021), 1–25. [32] David Sculley, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips, Diet- mar Ebner, Vinay Chaudhary, Michael Young, Jean-Francois Crespo, and Dan Dennison. 2015. Hidden technical debt in machine learning systems. Advances in neural information processing systems 28 (2015). [33]Hari Subramonyam, Divy Thakkar, Andrew Ku, Juergen Dieber, and Anoop K Sinha. 2025. Prototyping with prompts: Emerging approaches and challenges in generative ai design for collaborative software teams. In Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems. 1–22. [34]Chunliang Tao, Xiaojing Fan, and Yahe Yang. 2024. Harnessing llms for api interactions: A framework for classification and synthetic data generation. In 2024 5th International Conference on Computers and Artificial Intelligence Technology (CAIT). IEEE, 628–634. [35]Shubham Ugare, Tarun Suresh, Hangoo Kang, Sasa Misailovic, and Gagan- deep Singh. 2024. SynCode: LLM Generation with Grammar Augmentation. arXiv:2403.01632 [cs.LG] https://arxiv.org/abs/2403.01632 [36] Shuai Wang, Wenji Mao, Penghui Wei, and Daniel D Zeng. 2022. Knowledge structure driven prototype learning and verification for fact checking. Knowledge- Based Systems 238 (2022), 107910. [37]Shuai Wang, Penghui Wei, Qingchao Kong, and Wenji Mao. 2024. A knowledge enhanced learning and semantic composition model for multi-claim fact checking. Knowledge-Based Systems 304 (2024), 112439. [38] Shuai Wang and Yinan Yu. 2025. iQUEST: An Iterative Question-Guided Frame- work for Knowledge Base Question Answering. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 15616–15628. doi:10.18653/v1/2025.acl-long.760 [39]Shuai Wang, Yinan Yu, Robert Feldt, and Dhasarathy Parthasarathy. 2025. Au- tomating a Complete Software Test Process Using LLMs: An Automotive Case Study. arXiv:2502.04008 [cs.SE] https://arxiv.org/abs/2502.04008 [40]Xixi Wang, Miguel Costa, Jordanka Kovaceva, Shuai Wang, and Francisco C Pereira. 2025. Plugging Schema Graph into Multi-Table QA: A Human-Guided Framework for Reducing LLM Reliance. arXiv preprint arXiv:2506.04427 (2025). [41]Xixi Wang, Jordanka Kovaceva, Miguel Costa, Shuai Wang, Francisco Camara Pereira, and Robert Thomson. 2025. Domain-Adapted Pre-trained Language Models for Implicit Information Extraction in Crash Narratives. arXiv preprint arXiv:2510.09434 (2025). [42] Jens H. Weber-Jahnke, Morgan Price, and James Williams. 2013.Software engineering in health care: Is it really different? And how to gain impact . In 2013 5th International Workshop on Software Engineering in Health Care (SEHC). IEEE Computer Society, Los Alamitos, CA, USA, 1–4. doi:10.1109/SEHC.2013.6602469 [43]Zhixiong Zeng, Shuai Wang, Nan Xu, and Wenji Mao. 2021. Pan: Prototype-based adaptive network for robust cross-modal retrieval. In Proceedings of the 44th international ACM SIGIR conference on research and development in information retrieval. 1125–1134. [44] Chen Zheng, Matthieu Bricogne, Julien Le Duigou, Peter Hehenberger, and Benoit Eynard. 2018. Knowledge-based engineering for multidisciplinary systems: Integrated design based on interface model. Concurrent Engineering 26, 2 (2018), 157–170. doi:10.1177/1063293X17734591