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.
Alex: Welcome to another episode of ResearchPod. Sam, I've been reading about software development in places like car manufacturing—what's this paper we're discussing today?
Sam: This paper looks at a real-world project at Volvo Group called spapi—it's an in-vehicle web server that lets apps and services read and control things like vehicle speed or climate settings through simple web connections. The main idea is that building this kind of software involves teams from different fields who create separate documents and specs, and developers spend most of their time manually piecing those together into working code. They call this kind of teamwork across fields 'multidisciplinary software development,' or MSD for short.
Alex: So the core problem is all that back-and-forth translating documents into code, right? Like developers chasing experts for clarifications instead of just building?
Sam: Exactly. In spapi, which handles 192 endpoints across areas like energy management and vehicle dynamics, developers faced fragmented docs—OpenAPI specs for what the APIs should do, signal definitions for low-level car data on the CAN bus, and mapping notes linking them. This meant cross-referencing everything by hand, plus rounds of coordination with experts, turning each API from a quick task into about five hours of work. The paper shows this manual translation is the hidden drag, eating up engineering time as the system grows.
Alex: And they say even tools like GitHub Copilot don't fix the whole workflow?
Sam: That's right—it speeds up coding bits, but not the handoffs between experts and developers. The study models the entire process as a graph, like a map of connected steps and documents, to spot where automation could replace those manual links. This sets up their approach to cut that time while keeping quality high.
Alex: So they model the whole process as a graph to find where to automate. What does that graph actually look like?
Sam: Imagine the development steps as a map of connected dots and lines—each dot is a document or person involved, like a signal definition from an expert or an API spec from a designer, and each line shows how one feeds into the next, like "this signal info is needed to build that code." By drawing it this way, they can see exactly where manual handoffs create traffic jams, such as developers waiting on experts. Researchers call this a directed dependency graph. Their plan is to swap those manual dots one by one with automated services powered by large language models—AI systems trained on vast text data that can read descriptions and spit out working code snippets, much like a smart assistant turning a recipe into step-by-step instructions.
Alex: Okay, so they replace the handoffs with AI services step by step. But how do those services actually work—what do they do with the documents?
Sam: They start with three main services, added one iteration at a time. First, signal read-write synthesis takes raw signal definitions—like what a CAN bus signal means for vehicle data—and generates Python code to read or write it, tested automatically against examples from the docs. Next, signal-property synthesis matches API properties, say an air conditioning mode, to the right signals using word similarities, creating mappings with units and values. Finally, property-endpoint synthesis uses templates to assemble full web endpoints from those pieces, like FastAPI routes that handle requests safely. Each service outputs reliable code fragments that connect directly, cutting out expert back-and-forth.
Alex: So it's like untangling a messy phone tree into a straight line of auto-calls between services. Does the graph itself get simplified too?
Sam: Yes—after swapping nodes, they prune unnecessary lines, or edges, where services can now talk directly without human coordination. This happens iteratively, with experts checking each change to avoid losing key info. The paper reports the final pipeline for spapi's 192 endpoints took per-API time from about five hours down to seven minutes, with quality matching manual work.
Alex: Meaningful improvement without sacrificing accuracy. But to get that kind of reliability from AI services, they must have ways to check the generated code doesn't go wrong. How did they make sure each replacement in the graph actually improved things?
Sam: They set up a scoring system to judge each change to the workflow map. For every swap of a manual step with an AI service, experts rated it on three things: first, does it simplify the map by removing steps or links; second, does it make more work automatic instead of human; third, does the new output stay clear for people to read and ready for computers to run, like code with good names and notes that both humans and machines understand easily. Scores ranged from minus points for worsening a category to plus points for improving it—think of it as a balanced scorecard for workflow health. Positive overall scores confirmed the transformations were worthwhile.
Alex: So experts reviewed each step with that scorecard. But inside the services, what keeps the AI from messing up tricky matches, like when car data units don't line up?
Sam: For reliability, they used a tool called DSPy—it's a way to guide AI language models with structured instructions and automatic fixes, like giving a recipe that checks itself if the cake doesn't rise and tries again. In signal read-write generation, the AI creates Python functions from signal details, then makes its own test cases, runs them, and self-corrects any failures before storing the code in a searchable collection based on signal meanings—imagine a smart filing cabinet that finds similar items by how alike their descriptions are. For matching API properties to signals, the system reasons step-by-step: it spots the property's purpose from name, values, and units; picks matching signals; handles mismatches like converting speeds from meters per second to kilometers per hour or mapping on-off switches to zero-one numbers; and notes if one property needs several signals combined. This careful prompting and checking ensured the code worked as well as hand-written versions.
Alex: That explains the high match to manual quality. You've covered the services well. But in that final property-endpoint step, how do they avoid the AI just guessing wrong on things like route names or validation rules?
Sam: They use a fixed starting template for the code—like a fill-in-the-blank form with the basic structure already set: routes, error handling, and data checks are locked in place. The AI only fills the specific spots for reading signals and building responses, guided by a strict list of rules: stick exactly to the API description, don't change paths or add fields. This template-based approach, combined with step-by-step thinking prompts, keeps the output matching the original specs without common slip-ups like wrong parameter names. It's deployed as part of three connected servers forming a straight-line pipeline.
Alex: So the servers chain together directly. Did they test on real endpoints?
Sam: They did, across 192 production APIs from six car areas, using the original human-coded versions as the target. The automated code matched closely in correctness and coverage, performing about as well overall. Developers and experts rated it high enough for ongoing use, noting less back-and-forth.
Alex: You've mentioned those techniques like debugging and templates boosting reliability. But how do we know which one matters most—did they test removing them one by one?
Sam: They did what's called an ablation study—it's like taking apart a machine piece by piece to see how each part affects the whole, by measuring performance without one component at a time. Without automated debugging, where the AI generates tests and fixes its own code errors, accuracy dropped sharply. Removing templates that provide fixed code structures also hurt results, showing they prevent sloppy outputs. This proved debugging is key for production quality.
Alex: Beyond accuracy, how does it handle messy real-world inputs, like wrong values in specs?
Sam: The system spots common errors, such as numbers outside allowed ranges or invalid option choices, with near-perfect detection. It acts as an early checker, preventing bad data from creating faulty code.
Alex: Meaningful gains across the board. And experts—did they actually like using it?
Sam: Six practitioners rated it highly: perfect scores for cutting communication needs, averaging high marks overall from experts and developers on accuracy, style, and less debugging hassle. Though a small group, it matched production use at Volvo. The paper suggests this workflow sets a reliable path for scaling similar tasks, but cautions it's from one case at a single company, so applying it elsewhere needs more tests.
Alex: Fair point—strong for coordination-heavy tasks like this. Beyond cars, where else might it fit?
Sam: Anywhere software turns domain knowledge into code—like healthcare records or finance rules—facing similar handoffs. It shifts focus from single tools to workflow graphs, letting teams automate translations while keeping experts in loop. The spapi success shows sustained cuts in coordination, a meaningful pattern for multidisciplinary work.
Alex: That's a grounded takeaway—restructuring workflows with AI services tackles a real bottleneck without overpromising. Thanks for breaking it down, Sam.
Sam: My pleasure. Thanks for listening to ResearchPod.