Yu Fang is Co-Founder & CTO at Sonatus, specializing in distributed systems and AI-enabled vehicle architectures.
Every stage of a vehicle’s life runs on different software. Development teams use simulation platforms. Test teams use data loggers and validation suites. Manufacturing teams run end-of-line testing on their own dedicated systems. After-sales service teams use yet another set of diagnostic tools. Each team picks what works for its specific domain in isolation.
The problem is what happens between and across the stages, not within them. Think of the traditional vehicle life cycle as a relay race. Development hands off to testing. Testing hands off to production. Production hands off to service. At each exchange, knowledge has to be repackaged or rebuilt. Often, it’s worse than that; the tools at each stage don’t share any knowledge or learnings with each other. That creates three costs that worsen with each transfer:
1. The overhead of system maintenance multiplies because every additional tool in the chain is one more system to license, integrate, patch and support.
2. Training overhead grows since new hires and cross-functional teams have to learn a different tool for each stage they touch.
3. Most significantly, continuity of knowledge breaks down. The context an engineer had while building a feature doesn’t travel cleanly to the person troubleshooting it in the field six months later.
None of this is a failure of any single team. It’s a structural cost of treating design, development, testing, production and support as five workflows instead of one continuous process. For OEMs, that cost shows up as extra time added at every stage: slower development, slower testing, slower fault investigations—plus duplicated effort and institutional knowledge that’s lost from one team to the next.
What Made Unification Unrealistic Before
For most of software history, unifying these tools wasn’t realistic. Software is purpose-built. A testing tool is designed to verify that a system behaves as expected under a defined set of conditions, and a diagnostic tool is made to pinpoint the root cause of a fault once something has gone wrong. Adapting one to do the job of the other means rewriting substantial portions of the code. If an engineer wants a button moved or a workflow changed, that’s a development cycle.
AI is beginning to change that equation because agentic AI solutions across these stages increasingly share the same foundation. The large language model (LLM) underneath a testing tool is, fundamentally, the same model underneath a field diagnostics tool. Whether the task is analyzing a validation test case before launch or troubleshooting a customer issue after sale, the AI doing the reasoning is the same. Only the surrounding context changes.
Rather than building a separate system for every domain, organizations can extend the same underlying intelligence across development, testing and service, adapting to each team’s context without starting from zero each time. That’s a meaningfully different starting point than the industry has had before, even if most organizations are still early in acting on it.
The Harder Work Is Organizational
Early signs of this are visible across the industry, even where organizations might only be doing one or two of these things today:
• Routing field failures more directly into over-the-air update cycles.
• Feeding service desk knowledge back into design and test criteria for the next model year.
• Using factory floor anomaly data to compare part quality across suppliers.
• Exploring whether validation data from development can travel with the vehicle to speed day-one service diagnoses.
None of this is fully solved anywhere yet, but it points to where the industry is headed once tools stop resetting at every handoff.
This isn’t simply a matter of swapping software, either. Unifying tools across life cycle stages usually means unifying ownership, budget and process across teams that have operated independently for years. This creates a change management challenge as much as a technical one. Organizations that treat this as simply a tooling decision are likely to find the harder work is organizational.
Building The Unification Strategy
In my experience, this type of organizational transformation tends to follow a few core principles:
• Adopt unification as a company-wide strategy. Data, knowledge and AI unification has to be a mandate from leadership, not a project owned by a single team.
• Designate champions within each phase of the process. The effort needs to have advocates embedded across development, test, manufacturing and service.
• Identify what belongs in the shared context. Not every piece of data, knowledge or artifact needs to travel between stages, but the right signals do.
• Implement AI solutions for one or two use cases first. Ones that specifically leverage the two-way knowledge flow throughout the life cycle rather than a full rollout at once.
• Treat early implementations as a starting point. Learn from them, iterate and expand.
Why This Can’t Wait
The pressure to address these tools is mounting. As vehicles become more software-defined and the pace of iteration accelerates, the cost of siloed tools grows. Every additional stage-specific tool is another point where institutional knowledge gets trapped, another integration point to maintain and another delay between when a problem is discovered and when a fix is implemented.
What closes that gap is running the same tools—or at least the same underlying intelligence—across every stage. Companies that manage to treat design, development, testing, production and support as one continuous system rather than five separate functions stand to gain structural competitive advantages:
• Catching issues earlier because insight from one stage reaches the next faster.
• Reducing the number of physical test vehicles and duplicated validation efforts needed because data and context carry forward.
• Shortening the distance between a real-world signal and an implemented solution.
The technical excuse for staying siloed is largely gone. What’s left is a leadership choice: keep optimizing each stage of the vehicle life cycle or start treating the life cycle as one connected system running on a unified toolchain. In an industry where time-to-SOP and speed of issue resolution are becoming the real competitive differentiators, that choice won’t stay optional for long. The organizations that make it early will set the pace everyone else is forced to follow.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
