Shuai Wang, Yinan Yu, Earl Barr, Dhasarathy Parthasarathy
9 min
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.
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.