This article asiginally published on LinkedIn on June 23, 2026
Every time a major vehicle recall hits the news, the story tends to follow a familiar pattern: the company has a software problem.
The industry response is also familiar. OEMs hire more software developers, bring in software leaders from the broader technology industry, invest heavily in software-defined vehicle initiatives, and reorganize their development organizations. Suppliers often do the same.
This is understandable. Software now defines much of the vehicle experience: propulsion, chassis, body & comfort, infotainment, connectivity, ADAS, personalization, and the interaction between these systems. Software quality matters.
I think the conversation and diagnosis often focuses on late development stages.
The software may be where the problem appears. It is not always where the problem started.
In many cases, what looks like a software quality problem is actually a requirements, architecture, and verification problem compounded by an institutional knowledge problem. The code may be the visible layer. The deeper issue often sits upstream in the engineering phases and system that produced it.
When a recall is investigated, it may trace to a software behavior. It may be a diagnostic threshold, a state transition, a timing condition, a calibration interaction, a sequence that was not handled correctly, or even a single line of code.
But that is usually the immediate cause.
When you keep asking the deeper questions (e.g., using the 5 Whys) you often end up somewhere else. You find a requirement that was incomplete, ambiguous, or interpreted differently by two teams. You find a behavior that was never fully specified. You find a change made years earlier without enough design rationale. You find a verification gap. You find a variant condition nobody fully understood. You find a supplier interaction that was documented at the interface level, but not understood at the behavioral level.
That distinction matters. A software defect can be fixed in code. A systemic engineering defect requires a different response. It requires looking at how requirements were captured, how architecture decisions were made, how dependencies were traced, how verification coverage was defined, and how knowledge was preserved.
I have spent much of my career developing complex mechatronic and connected systems. One pattern has shown up: the hardest problems are rarely just about whether someone wrote good code. They are about whether the organization understands what the system is supposed to do, why it was designed that way, and how to prove a change is safe.
Modern vehicle systems are often not clean-sheet software products. Many of them are based on long-lived engineering assets. They contain model-based software, hand code, supplier software, calibration, diagnostics, safety logic, feature variants, and years of carryover content developed by many teams across organizations.
Often, these systems work well. That is part of the challenge. Stable legacy systems create confidence until something needs to change.
A new regulation appears. A field issue needs to be addressed. A diagnostic has to be modified. A feature needs to be added. A supplier module changes. A vehicle program reuses the software in a slightly different configuration. An over-the-air update requires revalidation. Suddenly, an engineer is asked to modify a system shaped by decisions made years earlier.
The hesitation is often real: "I am afraid to touch it. I do not know what will break."
That is not usually a statement about the engineer's capability. It is a statement about the engineering system around the engineer. The code may be stable. The model may still run. The vehicle may have passed validation. But the context has become fragile. The original rationale is incomplete. The assumptions are not obvious. The tests do not fully describe the intended behavior. The requirements may not be connected to the implementation. The person who knew the answer may have retired or moved on.
In most systems, the code is not the only asset. The real asset is the accumulated understanding of why the system behaves the way it does. When that understanding is not captured, every future change becomes harder and riskier than it should be.
When you look beyond one specific system or one specific defect, the same patterns tend to appear across many vehicle domains and many suppliers.
In theory, the specification should explain what the system is supposed to do and how success will be verified. In practice, the real specification is often spread across formal tools, old documents, change requests, models, calibrations, interface definitions, supplier documentation, and test procedures. Some requirements were never written down because the people involved at the time understood the context.
Carryover software is especially difficult. If a function has worked for years, there may be little incentive to reconstruct requirements around it. The behavior becomes accepted because it is already in production. But once a change is needed, the missing requirements matter again.
Another common issue is that requirements are written too close to the implementation. They describe how something was built rather than what the system needs to achieve. That makes reuse, impact analysis, and verification harder over time. The result is that an engineer may trace a code change back to a ticket, but still not understand the broader reason behind the behavior.
Without that context, the organization is not really maintaining a specification. It is maintaining a history of changes. Those are not the same thing.
Many engineering organizations still depend heavily on long-tenured experts. These are the people who know why a function behaves differently on one platform, which test result mattered, and why an interface was accepted even though the documentation was not ideal.
That kind of knowledge is valuable. It is also fragile. When an engineer who has owned an area for fifteen years retires, changes roles, or leaves the company, the organization keeps the artifacts but may lose the interpretation.
This has become more important as organizations go through restructuring, outsourcing, insourcing, electrification shifts, SDV reorganizations, and supplier strategy changes. Teams are not static. Tools are not static. Over time, the organization may retain the "what" but lose the "why." That is a serious engineering risk.
Automated testing has improved significantly in many areas. Unit testing, component testing, simulation, and software-in-the-loop environments are far better than they were years ago. But the biggest gaps often remain at the system level.
Vehicle behavior is increasingly distributed. A feature may depend on multiple ECUs, supplier modules, cloud interactions, calibration states, diagnostic states, and variant configurations. Correct behavior may depend not only on current inputs, but on what happened before.
Many organizations still rely heavily on expert judgment, vehicle-level testing, and manual interpretation. These methods are necessary, but insufficient if not connected to clear requirements and repeatable test coverage. The issue is not that engineers do not test. They test a lot. The issue is whether the coverage is tied to the intended behavior, including edge cases, variants, and historical failure modes.
A statement like "we ran it on the rig and it looked fine" may be useful in context. It is not the same as having a maintained regression suite at component, subsystem and system-level showing which requirements were covered, which variants were exercised, and which risks remain.
You cannot test your way out of unclear requirements. But unclear requirements also make it very difficult to know whether your testing is complete.
Automotive software is not developed by one organization. OEMs, Tier 1 suppliers, semiconductor providers, tool vendors, software vendors, and integration partners all contribute pieces of the system. In many cases, the OEM or next-level integrator receives object code, interface documents, diagnostic specifications, and expected behaviors, but not the full internal design logic.
This does not mean suppliers are doing poor work. The challenge is that system behavior emerges from interactions.
An interface document may describe signals, ranges, timing expectations, and error handling. But it may not fully explain the internal sequence of conditions that leads to a behavior in the field. OEMs and integrators are often good at identifying which module or supplier domain is involved. What is harder is reconstructing the behavioral chain across organizational boundaries.
Vehicle systems carry significant variant and configuration complexity. Different markets, platforms, powertrains, optional features, supplier choices, and over-the-air update levels all create different valid combinations.
Most of the software may be common. But a smaller percentage of variant logic can create a large share of the risk. A change that looks local may not be local. It may be safe for one market and not another, one powertrain and not another, or one supplier configuration and not another.
This is where weak requirements, weak traceability, and weak system-level regression coverage become expensive. The complexity is not just in the code. It is in the number of valid product configurations the code has to support over time.
Modern software tools matter. Better IDEs, static analysis, automated code review, CI/CD pipelines, model checking, test generation, and AI-assisted development all have value. Many organizations need more of this capability, not less.
But those tools operate mostly downstream. They can help an engineer write code faster. They can identify certain defects. They can improve consistency. They can generate tests. They can improve productivity. What they cannot do is answer the most important upstream questions:
When an engineer is hesitant to modify a critical function because the design intent is unclear, no amount of code completion will solve the real issue. Faster coding may actually make the problem worse if the organization does not first understand what should be changed and why.
This is the uncomfortable truth:
You cannot code your way out of missing requirements.
You cannot review your way out of missing design intent.
You cannot test your way out of a system no one fully understands.
There is a lot of discussion today about AI in engineering, agentic development, software-defined vehicles, and automated code generation. Some of it is useful. Some of it is hype.
From my perspective, the more important shift is simpler and more fundamental: the industry is being forced back to the left side of the V.
Systems engineers have always known that requirements, architecture, interfaces, verification strategy, and traceability are where product quality is either created or compromised. That is not new.
What is changing is the economics. For years, maintaining this level of rigor across complex legacy systems was slow, expensive, and difficult to sustain. Engineering teams made practical tradeoffs. Documentation fell behind. Requirements tools were not always connected to implementation. Test evidence was captured inconsistently. Decisions were made in meetings and emails. Experts filled the gaps because they knew the system.
That model works until it does not. It starts to break when complexity increases, when experienced people leave, when systems must be updated longer, when software spans more domains, and when changes have to happen faster.
AI does not make requirements discipline obsolete. If applied correctly, it may finally make requirements discipline scalable again. That is the opportunity.
The most valuable use of AI in this context is not simply writing the next line of code. It is helping organizations recover, connect, and maintain engineering knowledge.
Many companies already have much of the information they need, but it is fragmented. It exists across legacy code, Simulink models, calibration data, interface documents, supplier PDFs, change histories, old tickets, validation reports, HIL logs, field issue data, and expert input.
The challenge is that no human team can manually connect all of that information at the speed and scale now required. This is where AI can be useful. In many ways, this becomes engineering knowledge archaeology: recovering the design intent, requirements rationale, test evidence, and system behavior buried across code, models, tickets, documents, supplier interfaces, and expert memory.
AI can help mine the artifacts that already exist. It can identify relationships between requirements, design elements, code, tests, variants, and field issues. It can help reconstruct intent where documentation is incomplete, generate candidate test cases, support impact analysis, and show engineers where the system is understood and where it is not.
This does not replace engineering judgment. It gives engineering judgment a better foundation.
A practical example is a legacy control algorithm that works well but was never fully documented. An AI-assisted approach can examine the model or code structure, historical changes, tests, calibration data, and expert input to reconstruct what the function does and why. In field issue triage, an agent can search across interface documents, supplier documentation, diagnostic history, test logs, and related software artifacts to narrow the investigation.
In a complex engineering environment, the value is often not that AI produces a perfect answer. The value is that it helps the engineer get to the better upfront question faster.
The future is not that AI writes all the code and engineers disappear. That may be attractive in some software environments, but it is not how I see safety-critical and highly integrated product development evolving.
In vehicle engineering, responsibility does not go away. Compliance does not go away. Safety, security, and liability do not go away. System interactions do not go away. Supplier accountability does not go away. The need for experienced judgment does not go away.
What changes is the work engineers spend their time on. The best engineers will spend less time manually searching through documents, recreating context, and rebuilding tests from scratch. They will spend more time defining the problem, setting requirements, understanding tradeoffs, reviewing evidence, steering automation, and validating that the system remains safe and correct.
That is healthier for engineers. It also changes what engineering leaders need to value. The question is not only, "How many developers do we have?" It is also:
· Do we have clear requirements?
· Do we understand our architecture?
· Can we trace behavior from requirement to implementation to test evidence?
· Do we know where our institutional knowledge lives?
· Can our engineers safely change systems without depending on one expert who has carried the context for fifteen years?
· Are we using AI to generate more code, or are we using it to rebuild the knowledge base that makes change safe?
Those are very different questions.
For automotive leaders, and frankly for leaders in any industry with long-lived, safety-critical, or highly integrated systems, I would start with a few practical questions:
· Which systems depend on one or two people's memory?
· Where does the actual specification live?
· How much of the original design rationale is still recoverable?
· Can a capable mid-level engineer safely make a change to a critical function?
· Can you trace your most important requirements to implementation and verification evidence?
· How long does it take to onboard a new engineer into a critical legacy system?
These are not academic questions. They are business questions. They affect recall risk, warranty cost, field service actions, engineering efficiency, software update confidence, supplier management, and the ability to keep older vehicles compliant in the field.
They also affect morale. Engineers do not want to work in systems they are afraid to touch. They want clarity, context, and the ability to make changes with confidence.
The automotive software challenge is real. Software recalls have gone up every year for the past six consecutive years and are costing some automakers over $700 per vehicle sold. But calling every issue a software quality problem is too simple.
In many cases, software is the visible layer of a deeper engineering-system problem. The industry does not only need better coders or better tools. It needs a stronger connection between requirements, architecture, implementation, verification, and institutional knowledge.
That is where the next level of quality will come from. The organizations that get ahead will be the ones that stop treating legacy knowledge as something that lives in people's heads and start treating it as an engineering asset that must be captured, connected, maintained, and made usable.
AI can help. New tools can help. Better processes can help. But the starting point is the willingness to look upstream.
The next recall may appear in the code. The opportunity to prevent it usually starts much earlier.
I work with Envorso, where we help organizations in automotive and beyond address these kinds of engineering-system challenges. These views are my own.