When BYD ships a new platform faster than its legacy competitors can complete a single ECU change request, the legacy OEMs struggle to explain why. The excuses are manifold, including cheaper labor, government subsidies, and lower safety standards.

The “China speed” advantage is not about just working harder. It is about working within a single, productive organizational environment. BYD produces around 75% of its vehicle components in-house. Tesla has pulled integration tasks back from its Tier-1s and runs them centrally. The engineers working on the battery, the motor controller, the e-drive software, and the vehicle architecture report into a single chain of command. There is no friction between OEM and supplier because there actually is no supplier.

Legacy OEMs cannot replicate this. They will not buy out Bosch, Continental, ZF, Magna, or Aptiv—and even if they wanted to, antitrust regulators and market caps would stop them. The vertical-integration option is structurally limited.

In this article, I introduce a concept to address this problem. I call it CORE SPICE Vertical Integration: an operating model that delivers the capital-efficiency and speed benefits of vertical integration without the ownership—by constructing a neutral development zone where individual experts, drawn from OEM and supplier organizations, work as one team on one program under a shared productive environment.

In the Embedded World Conference 2024, I presented this cooperation principle with Thomas Ziller and Franco Baiocchi under the name “Fusion”. We cemented it in our book “CAR IT Reloaded” in 2024/2025 (German/English editions). The principle was  now re-branded as “CORE SPICE Vertical Integration.”

The argument consists of two parts. This part 1 article explains why the conventional OEM-supplier construct is the real bottleneck and what happens when you stop trying to manage this natural friction and instead suspend it within a defined DMZ (demilitarized zone). Part 2 will discuss challenging questions of IP boundaries, commercial models, career risk for embedded engineers, project infrastructure, and security considerations.

The interface problem

Anyone who has lived through a distressed MtO (Make-to-Order, the conventional ECU car part development) project knows the challenges of cooperation with multiple suppliers and the OEM. It is a well-documented problem within the industry (e.g., see CAR IT Reloaded, chapter 1). The friction lies neither within the supplier nor within the OEM organization; rather, it is at the interface between them.

At those interfaces, OEM and supplier teams independently model the same vehicle subsystem, compete for resources, and live in constant commercial tension because neither can fully trust the other’s outcomes. It manifests as change requests, escalations, back-and-forth negotiations, etc., rather than constructive conversations, because the people who could resolve a clarification in five minutes do not sit in the same room and instead route it through contractual amendments. The fallout includes late defects, escalations, and failures at end-of-line integration, because integration testing occurs at the end of a contractual cycle rather than continuously across the system boundary. Incompatible development processes and tools that cannot interact with each other, except via e-mails and spreadsheets sent back and forth between the development parties, lead to a nightmare of inconsistency.

None of this friction exists at companies like BYD or Tesla. It cannot, because there are no boundaries that could create such friction.

Such friction is the regular situation at all OEM-supplier interfaces. Managing dozens of MtO projects within a single vehicle platform development easily explains why 4 or 5 years are needed to manage the entire car platform and deliver an SOP.

A legacy OEM does not lose to a Chinese OEM by being slower per engineer. It loses because it pays a coordination tax on every interface, while its Chinese competitor gets it “for free.”

Why the obvious answers do not work

The industry has been trying to close this gap for decades. The attempts fall into recognizable patterns.

The first pattern is mandating co-location through contracts. Some OEM-supplier contracts now require resident engineers, on-site presence at integration milestones, or co-located workshops at critical phases. These produce moments of collaboration but do not change the underlying program structure. Each side still reports to its own management, runs its own internal processes (sometimes contradictory), and tracks its own set of metrics.

The second is “preferred partner” or strategic-supplier programs. That includes long-term framework agreements, shared roadmaps, and sometimes joint innovation budgets. These measures help improve the OEM-supplier relationship, but they do not accelerate the design and implementation process. The procurement organizations on both sides maintain a separate commercial framework, regardless of their strategic intentions.

The third is the Toyota resident-engineer model—gesuto enjinia (see here)—which embeds supplier engineers in Toyota’s development offices for one- to three-year stays. It is the closest historical precedent for what I am proposing, and it has worked at Toyota for decades. It has not transferred to legacy automotive OEMs, and the reason is contractual. The Toyota model assumes a keiretsu-grade trust relationship with cross-shareholdings and decades of shared history. A German OEM and a Tier-1 with whom it competes for next-year RFQs cannot replicate that model.

The fourth is joint ventures and equity investments in critical suppliers. These solve specific bottlenecks—chip supply, battery cells, etc.—but they do not address the day-to-day engineering friction across the dozens of other interfaces in a program.

Those four patterns have the same fallout: each preserves the redundant program structure, where the OEM and supplier each run their own program in parallel and pretend the result is a single program. Such a conventional setup can never result in the much-envied “China speed.”

What CORE SPICE Vertical Integration changes

The shift is fundamental and conceptual. Instead of trying to manage the friction between two programs, you suspend it completely, structure the development venture within a well-defined systems development “zone,” and run it as a single program.

A useful metaphor is a commercial DMZ—a demilitarized zone in the original sense, where the normal rules of organizational territory are suspended in service of a larger purpose. In this DMZ, individual experts from the OEM and the relevant supplier or suppliers work as a team on a single program. Not “in close coordination” or “with regular alignment,” but as one team. That results in a single feature list, a shared backlog, a consistent development process, the same cadence, and a consistent body of test evidence. In such an environment, clearly defining the program’s purpose is paramount. One TCC (Team Capability Coach) is holding the team together. They retain their respective employers. However, within the zone, the dual-program coordination has no unproductive overhead that consumes most of their time today.

This is what I mean by CORE SPICE Vertical Integration. The supplier ecosystem remains intact; the commercial relationships continue to exist outside the zone. The “zone” integration removes the friction, scoped to the program where speed matters most.

It is not the same as resident engineers, because resident engineers participate in someone else’s program; they do not become an integrated part of the project. It is also not the same as co-location, because co-location is only a workspace decision, but the processes remain separate. It is also not the same as a joint venture, because there is no new legal entity.

Instead, a “Vertical Integration” program is a substitute for the integration most Chinese companies achieve through ownership. Legacy OEMs cannot just buy their Tier-1s, but they can build a zone where, for the duration of the program, the question of who owns whom becomes effectively irrelevant.

Why does this only work with a vertically integrated program

Simply putting people from three companies in one room does not yet make them a team. Anyone who has run a cross-company integration workshop knows what happens: tooling differences, divergent process languages, conflicting chains of command—that’s a natural outcome that results in two parallel worlds with extra meetings.

CORE SPICE Vertical Integration only works because CORE SPICE provides the operating system underneath it. There is one QA Triage team lead (not two). The Validation and Verification Testing Lead (VVT Lead) oversees product quality across the entire program. Feature-based tracking provides everyone with a common language for progress. The TCC role holds the team across a boundary. Integrated, central roles are indispensable. Without these, virtual integration collapses back into coordination overhead.

The CORE SPICE values—shared accountability, transparency on status, ownership of outcomes rather than deliverables—are what make the zone possible.

This is also why the model cannot be adopted and executed by an OEM and a supplier on their own. It needs a third actor, organizationally neutral to both sides, to run the operating system and hold the team-coaching role across companies. The CORE SPICE model helps remove friction and continues insisting on eliminating redundant requirements and ensuring a consistent sense of urgency.

What comes next

CORE SPICE Vertical Integration is a program/project consistent approach. It is not a product or a consultant framework. It is a strategy to achieve the much-envied “China speed.”

Several hard questions need to be worked out before any program can run on this model.

• Which categories of work belong inside the DMZ, and which stay behind the supplier’s IP firewall?
• What commercial frame replaces fixed-price MtO contracting, which is structurally incompatible with this model?
• How do embedded experts protect their careers inside their home organizations during eighteen-to-twenty-four-month assignments outside the normal reporting line?
• How does the zone handle export control and OEM-internal classification rules when access is granted at the artifact level rather than the company level?

I will address each of these in Part 2, including the commercial-model question.

The point is simple: legacy automotive OEMs cannot outwork Chinese vertical integration. They can, however, construct a synthetic version of it. The “Vertical Integration” program’s scope is to “reduce to the max” to the point where speed matters most, while preserving the safety and security of OEM platforms, the supplier ecosystem that took decades to build, and closing the speed gap exactly where it hurts most: at the commercial boundary, inside the program, between the companies.

That is what CORE SPICE Vertical Integration is.

Part 2 will go into how to make it work.

References:

• Car IT Reloaded, The “fusion” principle
• https://www.youtube.com/watch?v=CHGPejLA1bI: The proxy-presentation on Embedded World

W. Edwards Deming once stated: “In God we trust. All others must bring data.” In most distressed projects I have worked with, the problem is not that the team lacks data. The problem is that the data they do have cannot be relied upon. Tickets exist, reports are produced, charts are displayed—but the underlying system is often inconsistent, and the numbers, at best, describe a rough mood rather than a reality. However, without trustworthy insights, risk minimization (CORE SPICE Principle #7 and arguably the single most important principle when a project is under stress) will fail.

The underlying data, once it is tied together across the data sources, can deliver quality on the project progress and risks. Unique identifiers, clean taxonomy, clear ownership, consistent closure—those aspects are boring accounting work. But when they are missing, the dashboards above them report numbers that nobody can actually trust.

The good news is that the fix is not particularly sophisticated. It is mostly discipline, applied early and kept consistent. This article walks through what that discipline looks like.

Familiar Symptoms

Most projects under pressure I have encountered share a small catalog of symptoms.

• The same (or at least semantically equivalent) defect is logged several times by four engineers, each with a slightly different label, and nobody notices until the reopen rate starts climbing.
• A feature is declared done, but nobody can point to the specification it was built against.
• A change request gets processed through the defect workflow because that was easier at the time, and three weeks later, the scope has grown without anyone deciding so.
• A system “release” means one thing to engineering, another to testing, and a third to the customer’s purchasing team.
• A supplier tracks its contribution in its own spreadsheet, and the integrator’s project tool has no idea what state the supplier’s deliverables are in.
• The testing team tests based on personal experience because there are no documented specifications traced back to the design or requirements. The “completeness” presumption is a mere intention, not a quantifiable, measurable assessment.

These are some of the symptoms of project distress. More daily syncs, more risk registers, or more “write-only” documents cannot compensate for them. A project can have all of those and still be unable to answer, at any given moment, what exactly a feature is in this project, what counts as a defect, what is in the upcoming release, and who is accountable for each open issue right now.

Four Issue Types

Every trackable thing in an MtO project is an “issue” (or use an equivalent term that encompasses all of the below object types). It is practical to limit the taxonomy to four issue types:

Features are customer-visible functionality or essential quality aspects. They originate from specifications (requirements, design). Each feature has exactly one owner: the Feature Owner (see also the CORE SPICE Accelerator #3: end-to-end responsibility, see here). A Feature Owner is accountable for the definition and delivery of a feature from inception through verification.

Defects (or bugs): Deviations from an approved specification. This is not a philosophical definition; it is a practical one. Without a specification, there is no objective basis for calling something a defect. That is a frequent contractual and organizational problem.

Change Requests: agreed deviations from the approved (“baselined”) scope or specification. They are neither features nor defects, and treating them as either creates predictable trouble. When change requests are handled as defects, the scope expands silently while the quality metrics appear to worsen. When they are treated as features, the burndown inflates, making the project look slower than it really is. Change Request, as a distinct, separate type, avoids both distortions.

Work Items: General tasks. They are everything the team needs to do in order to implement one of the three above. They must always be linked to a feature, a defect, or a change request. An orphan work item with no parent is almost always a sign of either duplication or something that no longer needs to be done.

Often, those “tickets” have different prefixes, so that the nature of a unique object is immediately recognizable. Everything trackable fits into one of them.

The same system needs to serve all contributors, including suppliers. A supplier that maintains its defects in a separate tool with its own classification scheme creates a parallel universe. In such cases, the defect curve often spans only half the project. I prefer to be explicit about this in the Supplier Agreement: suppliers use the project’s issue management tool, with the project’s taxonomy and ID scheme.

Unique Identifiers

Every issue carries a unique identifier with a meaningful prefix, such as FEAT-0142 for features, DEF-1203 for defects, CR-0087 for change requests, or WRK-4561 for work items. The prefix makes the type obvious at a glance, and the number is unique across the project’s full lifecycle. This is one of those basic hygiene items that is easy to underestimate until it is missing, at which point cross-referencing becomes guesswork, and any automated traceability reporting becomes unreliable.

The same principle extends to specifications, test cases, and other artifacts. When a defect references REQ-0033 and TEST-INT-0891, the related trace is unambiguous.

The Small V: A Definition of Done for Every Issue

Every issue—feature, defect, change request, or work item—needs an explicit “Definition of Done.” One pattern that works well across all four types is what I think of as a small V, embedded in the issue itself.

On the left side of the V, the issue is defined: What must be delivered, fixed, changed, or done. On the right side, each item on the left has a corresponding verification.

_{(Remark: this is a simplified model that does not distinguish between system and software levels. However, I recommend NOT expanding it into system levels (e.g., system requirements, system design, etc.) for practical reasons.)}

For a feature, the small V traces from the linked specification down through implementation and back up through integration, system test, and customer acceptance. For a defect, it runs from the specification the defect violates, through the fix, to the verification that the fix holds in the target release. Change Requests follow the same pattern as the features. Work items are negotiable, but the expectation and its verification should be explicitly defined.

That is how the team operationalizes No Task Left Behind (CORE SPICE Accelerator #1). The detailed mechanics—lifecycles, states, review rules—belong in either the Project Approach or the Configuration Management Approach, whichever the team prefers as the home for issue governance.

Release Scope

Every release has a clearly defined scope: which features are included, which defects are resolved, and which change requests are incorporated. In the configuration management literature, this is called a baseline, which is accurate but sometimes sounds a bit ceremonial to engineers. In practice, I find “release scope” a good day-to-day term, while “baseline” remains appropriate in the Configuration Management Approach itself.

Whatever it is called, its absence is costly. Without it, “defect DEF-1203 is fixed” does not actually mean anything unless one can specify which release it is fixed in. The same applies to features. Release scope is what the customer is comparing against at delivery.

The discipline is not complicated: each release has a named, frozen scope. Every known defect carries an estimate and a target release, or it is unplanned work dressed up as planned work. Changes to the scope after freeze are themselves change requests and flow through the normal change request workflow. The Project Lead, supported by the Configuration Manager and the TCC, maintains scope consistency.

Effort Estimation

Effort estimation has a reputation for being annoying. It is, but it is also one of the most useful disciplines a project team can adopt—not because the numbers are precise, but because the act of estimating forces the team to think thoroughly about each new/modified issue before it enters a release scope. In a way, “the plan is nothing—the planning is everything.” The real value of the planning activity is gaining a thorough understanding of the complexity and risks of each new issue.

A simple three-bucket scale works well for most MtO projects I have seen:

• S: about 4 hours (a working morning)
• M: about 2 days
• L: larger than M

“S” issue is something that one engineer can complete in a focused half-day.

“M” is a two-day commitment, often with a small handoff.

“L” is everything beyond that.

More detailed estimates are usually not meaningful because of the uncertainty inherent in each set of issues.

Also, “L” comes with a specific rule. Whenever an “L” issue appears, the team’s first response should be to break it down into smaller “S” or “M” issues, each with its own Definition of Done, owner, and traceability. Most “L” issues, on closer inspection, decompose naturally. But not all of them do. Some tasks—a complex system integration, a regulatory submission, a particular safety-critical algorithm—are genuinely atomic. Forcing artificial decomposition produces a fake structure that hides the real risk rather than reveals it.

When an “L” issue cannot be meaningfully broken down, the team should treat its size as the actual problem to manage. Such treatment achieves two things: a) it helps prioritize at or near the top of the release backlog, and b) it is assigned to one of the most highly skilled available owners. Usually, junior engineers cannot effectively handle that level of uncertainty inside a fixed-budget MtO contract; senior engineers can. This is Risk Minimization (CORE SPICE Principle #7) made operational at the issue level.

A Note on Units

Estimates in CORE SPICE projects are expressed in real, calendar-aligned units—hours and days, not “story points” or other abstractions. Story points have their defenders, and there is a legitimate argument that they decouple estimation from individual capacity, so a junior and a senior engineer can agree on a relative size without arguing about who is faster. That argument is acceptable in open-ended R&D projects, but it does not survive contact with MtO reality. The customer’s contract is usually in working days or weeks. The Project Lead needs to know whether the release will land on time, in days, not in abstract points. In reality, story points must almost always be translated back to days anyway, which makes them an extra layer of abstraction with no added value to the team’s effectiveness.

Estimation applies to every issue type, not just features. Defects, change requests, and work items all carry estimates and target releases—or they are unplanned work masquerading as planned.

Traceability: The Minimum That Matters

Traceability is one of those topics that tends to get overblown in strongly regulated projects, where the tendency is to trace everything to everything and discover six months later that nobody is actually reading the traceability matrix. A smaller, deliberate set of traces is more useful and much easier to maintain:

• From specification (requirement, design) to feature.
• From specification (requirement, design) to test case.
• From test case to one or more test runs.
• From each test run to its result data.
• From any defect back to the test run, the test case, and the specification it violates (and, consequently, the associated feature).

These traces are sufficient to make the small V auditable for every issue, and to make the defect curve meaningful at release boundaries. The details of what is traced, how, and by whom belong in the Traceability Approach.

Living Documents and Baselined Documents (a.k.a. “Artifacts”)

Not every project artifact is “frozen.” Specifications—requirements, design, interface definitions—are baselined. They are fixed at a version, associated with a specific release, and changed only through a deliberate revision. In contrast, the CORE SPICE Approach documents—the Issue Management Approach, the Configuration Management Approach, the Project Approach, and others—are, by design, living documents. They evolve as the team learns what works and what does not. All artifacts must have clearly named owners and visible status, but the mechanics differ: a living document is versioned without being frozen; a baselined document is frozen by design.

Artifacts in distressed projects usually have at least one of the following flaws: Either the Approaches are frozen into bureaucratic immutability and become useless (“write-only”), or the specifications are never frozen at all, leaving them unreferenceable. Both failures are avoidable once the distinction is explicit and articulated in one of the corresponding Approaches.

Two Views, One System

A recurring question from customers is whether to display features and defects on a single combined burndown chart or on two separate ones. This is essentially a presentation choice, and I recommend treating it as such.

Keeping features and defects on separate charts makes sense. Feature closure is a steady, human-paced activity; defect closure arrives in waves, peaking around integration and release. Mixing them on a single chart obscures the dynamics of both. Externally, if the customer’s key stakeholder prefers a combined view, it is straightforward to derive one from the same underlying data. The two views are not in conflict. One serves operational needs, the other communication, and both are automated from the same issue management system.

A Simple KPI Set

Once the foundation is in place, a small set of KPIs is enough to give the Project Lead and the key stakeholders a clear read on progress, risk, and where to intervene:

• Feature closure rate and projected release completion can be visualized in the feature burndown.
• Critical defect backlog and its trend can be visualized as a defect curve.
• Open change requests and their scope impact can be visualized similarly to the features.
• Reopen rate. This metric is typically used for defects.
• Release scope readiness shows the next release has a frozen, deliverable scope. That can be integrated into the overall release plan (from inception to SOP).

Those metrics should be automatically generated daily. This is what the Project Lead reads to see progress and risk. It is also what the customer sees, and what builds or erodes trust over time. Further KPIs are optional. When a project starts tracking dozens of KPIs, it is usually because the underlying data cannot quite be trusted. So be careful when adding KPIs.

Radical Transparency

A unified issue system, properly used, produces something that distressed projects almost never have: an honest, shared view of reality. Every issue is visible. Every status is current. Every estimate is in real units. Every release scope is named. Every defect can be traced back to its specification. The Project Lead, the team, the suppliers, and the customer are looking at the same data, in the same system, at the same time. There is no parallel universe. There is no “internal” version of the truth and an “external” version for the steering committee. There must be a single source of truth for everyone.

This may appear uncomfortable at first, especially for teams accustomed to managing the customer’s perception by curating what they see. But it is also liberating. The team stops spending energy on impression management and starts spending it on the actual work. The customer stops asking suspicious questions because nothing is being hidden from them. The relationship shifts from adversarial to collaborative—not because everyone became more reasonable, but because the data made obfuscation impossible.

Radical transparency is also, in my experience, the single strongest predictor of whether a distressed project will recover. Teams that hide their problems cannot fix them.

Automation and the Project Tool Engineer

KPIs should not be maintained by hand. It should be automated, and the role responsible for that automation is the Project Tool Engineer. This project role should be introduced early (in line with CORE SPICE Accelerator #5 “Automate Everything” and Principle #12 (Automated Traceability)). This role designs and maintains the automations that generate the burndown, defect curve, KPI set, traceability reports, and release scope view.

When the role is missing or underresourced, engineers end up spending valuable time on manual reporting—or even worse, not at all. In such cases, teams work in expensive, wasteful silos, which is an anti-pattern that is expensive, error-prone, and demoralizing. In 2026, there is, in most cases, no good reason for manual reporting. The Project Tool Engineer role enables the rest of the foundation to pay for itself.

Discipline, Not Bureaucracy

A well-structured project management system may appear bureaucratic: more prefixes, more closure criteria, more fields to fill in, more structure around what engineers would prefer to simply get stuff done. Senior engineers have seen enough process-heavy initiatives fail to recognize the pattern, and their skepticism is a healthy reaction to their past experience.

The difference is that the strategy described in this article is both uncompromising and super simple. The “plumbing” described above is not compliance theater; it is the mechanism that replaces compliance theater. With honest data in place, the team stops being judged by numbers nobody trusts and starts showing—to management, to the customer, to each other—what is actually true. That is the opposite of bureaucracy. It is Merit Over Bureaucracy (CORE SPICE Principle #11) made operational.

Skepticism can, in my view, only be resolved by demonstrating the practical value of such an integrated project management system. In my experience, adoption rarely comes from the initial explanation. You cannot “convince” professionals by merely postulating a quality framework. It comes from the first honest burndown or defect curve that the team recognizes as the truth they already knew anecdotally. Once that moment arrives, the system becomes a Formula 1 car rather than a mule carriage.

Conclusion

Deming’s observation applies universally: no data, no insights; no insights, no real risk minimization.

The three articles of this series describe a complete recovery dashboard:

• The feature burndown tells the team whether delivery is on track.
• The defect curve indicates whether quality is on track.
• The unified issue system ensures that the data feeding both charts is honest.

With the simple taxonomy—four issue types, unique identifiers, one system including suppliers, a Definition of Done for every issue, a clearly defined release scope, living and baselined documents properly separated, and a handful of KPIs automated—the project team can see what is actually happening in their project.

That is the precondition for minimizing risk, for the radical Transparency that distinguishes recovering projects from sinking ones, for a trusting customer relationship, and ultimately for a successful SOP.

Where to Start

For a team starting a new project, the first Approach to draft is the Issue Management Approach. Note that the Project Approach is also created at the same time. Still, the Project Approach remains a working, living document for a long time—actually, until all other Approaches have been fully established. Nevertheless, the Issue Management Approach is the foundation on which everything else depends, and the one that repays the investment the fastest—often within a single release cycle. The Configuration Management Approach and the Traceability Approach follow naturally once the taxonomy and identifiers are agreed upon.

For a team already “in flight,” the honest answer is less tidy, but the same three Approaches remain the right starting point. Retrofitting costs more than a greenfield setup, but continuing without a foundation costs even more.

References

• Feature-Based Project Tracking — projectcrunch.com/feature-based-project-tracking-how-to-regain-control-in-distressed-mto-projects/
• The Defect Curve — projectcrunch.com/the-defect-curve-a-key-factor-in-turning-around-distressed-mto-projects/
• CORE SPICE Coaching Concept — projectcrunch.com/core-spice-coaching-concept/

An important visual metric to assess the trend in the MtO project is the defect curve—the quality counterpart to the feature burndown. Together, they form a complete picture of project health: one tracks what gets delivered, the other tracks how well it was built.

No Specification, No Defect

As a crucial precondition for managing defects effectively, identifying the failed requirement is essential. A defect can only be defined against a specification. This is not a technicality—it is the legal and technical foundation of defect management that sometimes gets overlooked in the hectic pace of an MtO delivery.

A defect is a deviation from specified, agreed, or contractually mandated behavior—a “requirements baseline.” Without a specification—a document that stipulates what the system is supposed to do—there is no objective basis for calling anything a defect. An engineer who believes something is broken and an engineer who believes it is working as intended will frequently argue indefinitely, because neither has a reference point.

Some projects don’t actually see the value in understanding this crucial distinction. That’s why proper coaching is so decisive in project management. This is why specification quality is a prerequisite for meaningful defect tracking. In MtO projects, the specification spans the entire V-model: from system-level behavioral specs, through architecture and design decisions, down to software-level interface and module specifications. The granularity and formality of traceability between V-stages vary by project complexity and customer requirements, but at every level, the specification serves as the baseline—no specification—no defect.

The practical implication is that, in a turnaround project, one of the first diagnostic questions is whether specifications actually exist at the level of granularity needed to drive defect assessment. If they do not, defect tracking is noise—and the first fix is not in the defect tracker; it is in the specification.

Minimum Viable Traceability

Traceability is one of the most over-engineered topics in MtO project management. Teams frequently spend months building elaborate trace matrices across hundreds of artifacts (sometimes driven by assessors or redundant quality representatives)—only to produce something nobody reads or maintains. That is not traceability. That is compliance theater.

The goal of traceability, in practice, is not completeness for its own sake. It is the ability to answer one question when a defect surfaces: what was specified, how was it tested, and what did the test reveal? Everything beyond that is fundamentally optional.

For defect management specifically, the minimum viable traceability chain has four links:

1. Specification → Test Case. Every test case must trace back to the specification element it is verifying. This is the foundational link. Without it, there is no way to determine whether a failing test reflects a real deviation from a requirement or an error in the test itself. It also answers the question that arises in every Quality Triage: “Is this a defect against the spec, or did the test case misinterpret the spec?” The trace makes the distinction possible.
2. Test Case → Test Run(s). A test case, as an isolated document, says little about the product quality. A test run is an instance of that test case executed at a specific point in time, against a specific build, with a specific result. One test case typically produces multiple test runs across builds, releases, and configurations. The trace from test case to test run enables the team to distinguish between a defect that appeared in build 1.3.2 and was resolved in 1.4.0 versus one that has been consistently failing for six builds.
3. Test Run → Test Run Data. Each test run must record its inputs, configuration, build identifier, execution environment, and result (pass, fail, or blocked). That helps ensure that the issue is not a random—perhaps test-environment-induced—aberration. Without a cleanly recorded test trace, finding the root cause can prove impossible. The data must be captured at the moment of execution, automatically where possible.
4. Defect → Test Case → Specification. When a defect is logged, it must trace back to the test case that revealed it, and through that test case, back to the specification element that defines the expected behavior. This chain makes the Quality Triage efficient.

This four-link chain is not optional in a non-trivial MtO project.

The Distinction between Feature, Defect, and Change Request

Once specifications exist, the team must agree on what a defect actually is—and what it is not. Often, the issue categories are confused, and the confusion is expensive.

A feature is a defined unit of customer-relevant scope. It exists because the customer or an applicable standard demands it. It is planned, owned, sized, and sequenced into a release. A feature is a delivery commitment.

A defect is a deviation from the specification, which, in turn, defines the project scope. The expected behavior or a product quality aspect, such as timing or data transfer rate, does not match the implementation. A defect is not a missing feature. It is a broken promise on something that was already agreed upon.

A change request is a request to modify the specification—to add, modify, or remove a scope-relevant product attribute. It comes from the customer, from a regulatory update, or from a technical decision that invalidates a prior agreement (requirements baseline). A change request is not a defect. It is a new or modified scope that must be assessed, negotiated, and planned like any other feature.

Misclassifying a change request as a defect inflates the defect backlog and obscures real scope changes.

The rule is simple: defects go in the defect tracker. Change requests go through the scope change process. These are different workflows, different owners, different planning implications. It can still all be tracked using one tool, as long as the issue types are clearly defined; it only implies different workflows and responsibilities.

Frequent Symptoms in Troubled Projects

Most distressed projects log bugs in Jira, a spreadsheet, or a makeshift team-specific board. The data is not systematically used to improve product quality.

The symptoms are familiar:

Defect inflation. A single issue spawns multiple duplicates logged by different engineers across disciplines. The backlog balloons, but nobody can tell how many real problems exist.

Defect hiding. Critical issues are quietly downgraded before milestone reviews or quickly fixed without logging them at all.

No closure discipline. Defects are opened enthusiastically and closed reluctantly—or not at all. Nobody feels responsible for driving issues to resolution, because nobody owns them.

No trend analysis. Management asks: “How many open bugs do we have?” The answer is a number. That number, in isolation, is meaningless. What matters is the trend—and that requires a tool capable of generating it.

A Word on Tooling: Spreadsheets Are Not an Option

In a non-trivial MtO project—anything with more than a handful of engineers, multiple suppliers, and a formal release cycle—managing defects in a spreadsheet or a makeshift Kanban board is a path to disaster. It is not a question of preference; it is a structural problem.

Spreadsheets do not enforce ownership. They do not generate trends automatically. They cannot link defects to features, to specifications, or to release plans. They break under concurrent edits. They have no audit trail. And they require manual effort to produce any report, which means reports are produced infrequently, and always too late.

The defect curve requires daily data. Daily data requires a proper issue management system. The tool must support automated status tracking, configurable severity schemas, traceability to features and specifications, and report generation without human intervention.

The investment is not large. The cost of not having it—in lost data, opaque status, and undetected trends—is enormous.

What Is the Defect Curve?

The defect curve is not a single data point; rather, it is a set of three tracked metrics, plotted over time—typically daily or weekly (“time unit”), aligned to release cycles:

1. New defects discovered (inflow) — how many new issues are found per time unit?
2. Defects closed (outflow) — how many are resolved and verified per time unit?
3. Open defect backlog (net) — how many valid, unresolved defects exist right now?

These three metrics tell a story that no status meeting can replicate. In a healthy release cycle, the curve follows a predictable shape: discovery peaks early in integration, closure accelerates behind it, and the open backlog rises briefly, then falls as the release stabilizes. In a distressed project, the story is different: discovery keeps rising, closure is flat, and the backlog compounds week over week. The wave never breaks. Sometimes, no defects are discovered at all, and then—often just at the time of customer delivery—the product falls apart, and everyone acts surprised.

That discrepancy is the earliest warning signal of a quality crisis. If you are watching the curve, you see it in time to act. If you are not, you discover it at system integration, when it is too late.

Interactive defect curve — click Healthy, Plateau warning, or Widening gap crisis buttons to switch between release quality patterns across a 12-week cycle

Figure 1: Insert defect curve chart here — three-line chart showing New defects/week (coral), Closed/week (teal dashed), and Open backlog (blue) across a 12-week release cycle with phase bands for Construction, Integration, Stabilization, and Release/SOP. Red dashed line = SOP acceptance threshold.

Why Trends Matter

The defect count at any given moment is a snapshot that says nothing about the health of the product release. Trends, on the other hand, provide a context for assessing the direction the project release is taking. Trends matter for three reasons:

Visibility. The customer often expects to see the defect curve—not as a courtesy, but as a control mechanism. In the final phase before SOP (Start of Production), most customers will insist on it. A team that can produce a credible, data-backed defect trend curve earns trust.

Risk management. A widening gap between discovery and closure is a risk indicator. It tells you, weeks in advance, that the release timeline is at risk. That is early enough to act: add resources, cut scope, adjust the release date. Detected at the milestone review, the same information arrives too late for anything other than damage control.

Resource demand. A rising defect backlog indicates insufficient team velocity. The closure rate is not keeping pace with the discovery rate. This is a concrete, measurable signal that either more people are needed, or the scope of “done” needs to be restructured.

Severity Classification

The defect curve only works if defects are classified honestly and consistently. A minimum severity model for MtO projects has four levels:

• Critical (Blocker): Safety, security, or compliance-relevant function fails. Release is blocked until resolved or explicitly accepted with documented rationale and customer agreement.
• Major: Significant functional degradation. Customer-visible and reproducible. Must be resolved or formally accepted before release.
• Minor: Limited impact. Accepted with rationale and logged in the release notes. Planned for a future release.
• Cosmetic / Observation: No functional impact. Tracked but not included in the release curve.

Severity is assigned by the VVT engineer (Verification, Validation, and Test) who discovers the defect during testing. That initial rating is then reviewed—and, if necessary, overruled—in the Quality Triage. Developer self-classification is a conflict of interest. The person who wrote the code is not the right person to assess its severity.

Every non-trivial defect must go through a structured assessment before it is acted upon. This process is sometimes called a Change Control Board (CCB) in process-heavy organizations. The name is unfortunate—it implies slow bureaucracy, committees, and multi-day cycles. In a turnaround environment, slow is not an option.

I suggest using a more constructive term, such as Quality Triage, instead. The name reflects what it actually is: a fast, focused daily or near-daily review, attended by relevant feature owners and the Project Lead when needed.

The Quality Triage answers three questions for each defect:

1. Severity confirmed? Does the initial VVT engineer rating hold under technical scrutiny?
2. Impact assessed? Which feature and specification are affected? Which release? Which customer-visible behavior?
3. Owner assigned and release planned? Who owns the fix, and in which release does it land?

That third question is where the Triage connects directly to release planning. A defect that cannot be fixed in the current release gets planned into the next one. It becomes a work item in the future release scope, with an owner and a target date.

Defects without a planned release are a wasteful dead end — deferred until no one remembers the original context of the defect.

Preventing Duplicate Defects

Duplicate defects are one of the most persistent sources of waste in any large defect backlog. Two engineers encounter the same failure in different test contexts, log it separately, and the triage team spends time debating two entries that describe the same root cause. In a project with hundreds of open defects and multiple suppliers logging independently, duplicate rates of 20–30% are not unusual.

This is a problem LLMs are well-suited to solve—and in 2026, there is no good reason not to use them for it.

Before it reaches the Quality Triage, a new defect is automatically screened against the existing open backlog using an LLM-assisted deduplication step. The model compares the new defect’s description, affected component, failure mode, and reproduction steps against the open issues and returns a ranked list of likely duplicates, with a confidence score. The VVT engineer reviews the candidates in seconds. If a true duplicate is found, the new entry is linked and closed immediately.

Beyond deduplication, LLMs can also assist the triage process itself: pre-assessing likely severity based on the failure description and specification context, suggesting a probable owner based on component and historical patterns, and flagging whether the defect description is sufficient. This does not replace the Quality Triage, but it significantly compresses preparation time.

Every Defect Has an Owner

Ownerless defects are backlog theater — they exist in the tracker, surface in meetings, and never get resolved.

Ownership is assigned in the Quality Triage, no later than 24 hours after the defect is logged. The owner is responsible for the defect from that point until closure. The owner drives the resolution (not necessarily personally).

The daily Sync applies the same ownership logic to defects as to features: “This critical defect has not moved in three days. What is the actual blocker?”

Releasing Features with Defects

A feature can be declared done while carrying open defects. This is not a contradiction—it is a deliberate and documented quality decision.

The rule is: a feature is done when all open defects against it are rated Minor or Cosmetic, and those defects are formally logged, owned, and planned for a future release. A feature with open Critical or Major defects is not “done.”

The end state of a well-managed MtO release is not “zero defects.” It is a known quality state: all Critical defects are resolved or explicitly accepted, with a documented rationale and customer sign-off.

The VVT Lead, together with the Project Lead, makes the release recommendation on this basis, not on a zero count. The test report and release notes are the formal record: every unresolved defect that ships with the release is listed, classified, and owned.

Escalations

Serious customer complaints, by definition, are escalations. Escalations must be treated with urgency and transparency. Routing a customer escalation through standard backlog processes is a trust-destroying mistake. The customer who escalates is already frustrated. Making them wait for the next triage cycle makes it worse.

The practical response is structural: plan a buffer of resources for escalations. In every release cycle, reserve a fixed percentage of available engineering bandwidth—held back from planned feature work—for escalation response.

The Anatomy of a Release Quality Cycle

Every MtO release has a natural quality lifecycle. Understanding it prevents the most common misreadings of the defect curve.

Phase 1 — Construction: Features are being implemented. Unit tests run. Defect discovery is low, not because quality is high, but because systematic integration testing has not yet begun. A suspiciously flat discovery curve in this phase is not reassuring; it signals that testing is not aggressive enough.

Phase 2 — Integration: Subsystems connect. Integration tests run. Discovery accelerates sharply. This is expected. A rising defect count during integration is the system doing its job. The critical question is whether the closure rate is keeping pace.

Phase 3 — Stabilization: New discovery slows. Closure dominates. The open backlog falls. The Quality Triage shifts from assessment-heavy to closure-heavy. Remaining defects are classified and owned, and either resolved in this release or explicitly planned for the next.

Phase 4 — Release: Open Critical defects: resolved or formally accepted. Open Major defects: resolved or planned. All defects documented in the test report and release notes. The product ships with a known quality state — not a hoped-for one.

The defect curve makes each phase visible and the transitions legible. If Phase 3 never starts — if discovery keeps rising with no closure acceleration — that is data. It tells you the product is not ready, regardless of the schedule.

Predicting the Defect Curve

One of the most important things to understand about the defect curve is that it looks very different depending on where you are in the product’s release lifecycle — and that the shape is predictable.

Early releases tend to be quiet. The scope is limited. Test coverage is growing but not yet comprehensive. Defect counts are low. This is normal. A low count in early releases is a function of coverage, not quality.

Middle releases are where defect volumes ramp up. Features are delivered in larger batches. Integration testing reveals cross-feature interactions that unit tests missed. The discovery curve steepens.

The final release before SOP is where the curve peaks. Every feature that has been deferred, every integration edge case that was “noted for later,” every customer complaint from field testing, etc., all converge. This is the defect “storm,” and it must be planned for. It is not a surprise. It is a structural feature of the MtO project lifecycles, and teams that are unprepared for it get destroyed by it.

There are several approaches to planning the “storm” phase. I will mention two of the most frequently used in my practice.

Tiger teams. A dedicated group of the project’s most experienced engineers. They are absolute insiders who know the product in depth. This team is assembled to attack the Critical and Major backlog head-on. This approach works best for systemic or deeply rooted defect clusters that require expert knowledge to resolve quickly.

Feature owner-driven resolution. For feature-specific, well-understood defects, the feature owner drives resolution directly with their development team. This is the default path. The feature owner who delivered the feature is responsible for its defect closure, with the same urgency and ownership logic as the original delivery.

Both approaches require deliberate capacity planning — without it, the customer may pressure the team into relying on weakly qualified “best-cost” resources.

The Customer Is Watching

In the late project phase, most customers will not ask for a defect count. They will ask for the defect curve. They will often impose, as part of the contract, a limit on the number of open defects. The product cannot proceed to SOP unless the open defect count for each severity class is below a defined threshold.

That may be perceived as annoying, but it is a healthy expectation. A customer who tracks the defect curve is engaged in quality. Limiting the number of high-severity defects helps assess the project risk early.

This is also why the defect curve must be established early in the project. The customer needs history. A curve that only covers the last month of a two-year project proves nothing.

The CORE SPICE Connection

The five project turnaround measures are also reflected in the article’s measures (Feature-Based Project Tracking: How to Regain Control in Distressed MtO Projects).

No task left behind. Every defect is an owned task. Unowned defects do not exist. Every open issue has a name and a planned release.

Maintain the sense of urgency. The Critical backlog is reviewed daily. A Critical defect that has not moved in 48 hours is a Sync conversation, not a footnote.

End-to-end responsibility. Feature owners own their feature’s defect state, even after implementation is complete. Defects against their feature are their problem until they are closed.

Radical transparency. The defect curve, the Quality Triage outcomes, and the release notes are visible to everyone. That includes the core team, suppliers, and customers. This is especially important in the SOP phase, when the customer is actively tracking the curve.

Automate everything. The defect curve must be generated automatically from the issue management system. That must happen daily, without manual effort. In a non-trivial project, any other approach is not just inefficient—it is a data integrity risk.

Putting It All Together

The feature burndown and the defect curve are the two instruments of a distressed project’s recovery dashboard.

• Feature burndown converging: delivery is on track.
• The defect curve converging indicates that quality is on track.
• Defect backlog planned into future releases ensures that nothing is lost and everything is actively managed.
• The escalation buffer in place ensures that the customer relationship is protected.
• The defect curve is shared with the customer. That helps build trust and team confidence.

The lifecycle of defect volume is predictable: quiet in early releases, rising through integration, peaking before SOP. Plan for that peak. Staff the tiger team. Protect the feature owner’s bandwidth. Set the customer’s expectations with data, not assurances.

In a distressed project, provided the sponsor actively supports the aforementioned measures, a turnaround is always possible.

If the Critical backlog is not falling—or not falling fast enough to meet the customer’s SOP threshold—there is no quality. But if it is falling with a known, documented, owned residual state, the product is under control. And everyone can see it.

References

• Feature-Based Project Tracking — The companion burndown article: projectcrunch.com/feature-based-project-tracking-how-to-regain-control-in-distressed-mto-projects/
• CORE SPICE Coaching Concept — The 12 CORE SPICE principles: projectcrunch.com/core-spice-coaching-concept/
• Car IT Reloaded — Disruption in the Car Industry. Springer Verlag, 2025. ISBN 3658476907.

This expectation applies to automotive, but equally to aviation, medical devices, railway systems, and any domain where complex, safety-relevant systems are built to customer specification.

When MtO projects get into trouble, the symptoms are remarkably consistent:

• Work-item explosion. A single customer requirement spawns dozens of sub-tasks across disciplines—system requirements, architecture, software requirements, software design, implementation, integration, and verification. Responsibilities are often scattered across different engineers and tools. A project that started with 50 customer requirements now has 1,200 work items, and nobody can tell which customer feature is actually “done.”
• Silo thinking. System engineers don’t talk to software engineers. Software managers don’t talk to project leads. Line managers are randomly involved in the project work. The test team discovers what was built only when integration starts. Suppliers deliver their subsystems in isolation and claim everything is “on track.” The customer is kept at arm’s length. Each group optimizes for its own deliverables, not for the product as a whole. “I am not responsible for that” is often a popular attitude.
• Lack of sense of urgency. Once established, time buffers are consumed by other activities. The planning fallacy—well documented by Kahneman and Tversky—leads to optimistic schedules that drift, leaving deadlines impossible to meet.
• The “trust me” illusion. Management asks: “Are we on track?” The team answers: “Yes, we’ve got this.” That is a pointless ritual. No team or supplier will ever volunteer “No, we are failing.” Status must be measured, not asked for. Verbal assurances are not data. If control cannot be demonstrated with hard data, it does not exist.

The consequence: project status becomes opaque, customer escalations multiply, and team morale collapses. The project is “in trouble,” and nobody noticed until it was too late.

The Feature-Based Approach: What Is a Feature?

The definition of project scope can be structured in numerous ways (see WBS structures defined by the Project Management Institute, PMI). In recent years, many customers in the automotive industry have adopted the concept of a “feature” to define project scope.

While there are countless ways to define what a “feature” is, for our purposes, a feature is a well-defined chunk of customer-relevant scope. It is a deliverable slice of value that the customer or a standard demands, and whose completion can be objectively verified.

Features can be functional or non-functional:

• Functional: for example, “Active Steering Safety Manager,” “Bootloader Update Mechanism,” “CAN Communication Stack.”
• Non-functional: for example: “Startup Time < 200ms,” “ASIL-D Coverage,” “OBD Compliance,” “Cybersecurity Compliance Certification.”

The key criterion: a feature represents a meaningful unit of delivery. It aggregates all related work across the V-model—requirements, architecture, implementation, integration, and verification—regardless of whether the underlying work is system-level, software-level, or cross-disciplinary.

One Feature, One Owner

Feature ownership is a proven way to structure a project around technical expectations. Each feature has exactly one feature owner — a person responsible from inception to final verification. The feature owner is not “just software” or “just systems.” Feature owners own the outcome across disciplines—from left to right in the V. That directly implements the CORE SPICE principle of end-to-end responsibility: one person, one feature, from start to finish. It does not mean the feature owner must do all the work. Rather, the feature approach creates a matrix of responsibilities, and the feature owner must work with other feature owners to prevent redundancies. The advantage is that this approach is strictly merit-based: the feature management team follows the ideal path to delivery rather than requiring a more generalist mindset, since a feature owner usually does not know all the details across the V. Nevertheless, this approach offers a clear end-to-end view and closes the responsibility gap.

This is fundamentally different from tracking at the work-item level, where a requirement passes through five or six different hands, each responsible for only their discipline’s slice. In the feature-based model, the handover points—where things typically get stuck or lost—are eliminated.

Advantages of the Feature-Driven Approach

The feature-driven approach helps structure MtO projects systematically.

• It makes status measurable. Stakeholders see “Feature X: done” or “Feature X: blocked on integration test.” Not “247 work items, 63% closed.” The burndown speaks for itself — no more “trust me.”
• It forces prioritization. Features can be ranked, sequenced into releases, and traded off against deadlines. You cannot meaningfully prioritize 1,200 low-level work items, but you can prioritize 80 features.

The practical setup: The feature list is derived from customer requirements and applicable standards. In a typical complex MtO project, this results in 50-250 features. Each feature is mapped to a release. Status is tracked daily at the feature level—not at the sub-task level.

Radical Transparency: No Silos

Feature-based tracking only works if the entire operation is 100% transparent to everyone on the project team. This is not optional—It is a precondition.

“Everyone” means that:

• The core team: system engineers, software engineers, test engineers, integration leads — everyone sees every feature, every status, every blocker.
• Suppliers: If a supplier delivers custom-built systems or software components, they are part of the team. They participate in the daily Sync. They see the burndown. They report on the same features, in the same tool, with the same status definitions, and a clear “definition of done.” A supplier that delivers features in isolation and shows up at integration with “surprises” is a risk.
• The customer: The customer should see the feature status and the burndown. Hiding problems from the customer does not make them disappear—it makes the escalation worse when they inevitably surface.

No Information Asymmetry

In distressed projects, information asymmetry is a root cause of failure. When the supplier knows something the project lead does not, when the test team sees a problem that the customer has not been told about, when a feature owner is stuck but does not want to admit it—these are the moments where projects silently slide into crisis.

The feature chart, the burndown chart, and the daily Sync must be the single source of truth. If it is not easy to see for everybody, it effectively does not exist. If a supplier’s feature is red, everyone knows it is red—the supplier, the project lead, and the customer.

Risk Minimization Through Tight Tracking

Traditional risk management tends to be bureaucratic and reactive: risk registers, probability/impact matrices, and quarterly reviews are often boring activities that are increasingly pointless and wasteful. The risks sit in a spreadsheet. Nobody reads it until the steering committee.

Risk minimization, on the other hand, is the opposite: the goal is to make risks irrelevant by delivering early, testing often, and closing gaps daily. It is proactive and embedded in the daily workflow. This essential aspect is articulated as CORE SPICE Principle #7.

The Burndown Baseline

Using a burndown (or, alternatively, burn-up) chart is a well-proven risk-reduction, stakeholder-reporting, and project-tracking strategy. When properly set up, it offers near-real-time visibility into release progress, detects delays, and builds trust in the project delivery timeline.

At the start of a release (or a turnaround), the team establishes a baseline: the total number of items that must be completed for the release to ship. This includes features and critical bugs. During the release planning session, critical defects are prioritized alongside features — because a release is not “done” when all features are implemented. It is done when all features are verified and all critical defects are resolved.

The baseline is not a straight line. Real projects follow an S-curve: slow at the start (ramp-up, architecture, design), steep in the middle (implementation at peak velocity), and tapering at the end (integration, verification, final fixes). A straight-line baseline is a textbook fiction that misleads the team into thinking they are behind when they are still ramping up. The S-curve reflects how value is actually delivered.

From that point, the team tracks daily how many items remain versus how many should remain based on the baseline. The burndown chart makes the answer to “are we on track?” visible to everyone, every day, without anyone having to ask.

Figure 1: Feature + critical bug burndown. The baseline (dashed S-curve) shows the plan; the actual line (solid) shows reality. Both start at the same point. The actual line falls behind the planned S-curve through W1–W5. After corrective measures at W5, velocity increases, and the team converges back to the planned end state.

The chart illustrates a typical pattern: the first weeks show sluggish progress (the team is still reorganizing, silos are being broken down), followed by acceleration once the feature-based approach takes hold. The gap between baseline and actual at any point is the conversation starter: not “are we on track?” but “what do we need to close this gap by next week?”

Advantages of Feature Burndown Charts

Burndown charts offer many advantages:

• They offer daily visibility, which means a daily opportunity to intervene—detect, assess, and plan specific corrective actions.
• They help detect small deviations before they compound.
• They prevent “surprises” at milestone reviews.
• They help maintain the “sense of urgency.” If the line is flat, the team sees it. If the line is steep, the team sees that too.

The Daily Sync: The Heartbeat of the Turnaround

Purpose

A “sync” (also known as “standup”) is a 15-minute daily check-in. Syncs are not status meetings, no reporting ceremonies, etc. They are coordination sessions focused on feature flow and blockers.

Format

• Which features have moved since yesterday?
• Which features are blocked?
• What is needed to unblock the stuck features or bugs

What matters is whether the feature or bug is closer to “done.” Attended by feature owners, the project lead, leading architects, verification leads, and the Team Capability Coach (TCC). Suppliers participate on equal terms.

What Makes This Different from a Scrum Sync

The unfortunate experience with “real life Scrum” is that Scrum tends to be—ironically enough—a heavyweight, cadence-driven, inflexible instrument facilitated by a “scrum master” who often has insufficient power to ensure flawless execution of feature implementation.

As opposed to Scrum, the CORE SPICE approach proposes a release-based, incremental strategy:

No sprints. MtO projects plan releases, not sprints. This is Kanban-style, release-based cadence.

No theater. No “what I did yesterday / what I’ll do today” rituals. The burndown chart is the visual anchor: everyone sees the same picture, every day.

Suppliers in the room. A supplier that delivers features for this release participates in the Sync like any other team member. No separate “supplier sync” behind closed doors.

The TCC role can be summarized as follows:

Challenge the delay: “This feature hasn’t moved in three days. What is the real blocker?”

Facilitate organizational positive attitude: Help the team resolve cross-functional dependencies on the spot.

Sense of urgency: Maintain urgency without creating panic. The TCC ensures the team stays focused without burning out.

Anti-Patterns

The “daily sync” must be crisp, data-driven, and purposeful. The following fallacies should be prevented:

• Turning the Sync into a 45-minute problem-solving session. Whenever needed, dedicated ad hoc working groups must be spun off after the meeting. A good practice is to set aside a “blocked” time for this action right after the meeting, when current open questions can be worked out during the Sync in a small expert group.
• Reporting up instead of coordinating. All features and bugs should already be updated by the feature owners before the Sync.
• Skipping days because “nothing changed”—the cadence is the discipline.

The Psychology of “Closing Features:” the Dopamine Effect

Feature-based tracking is not just a mechanism for visibility and progress control. It is a motivation mechanism.

Every closed feature is a visible, undeniable achievement. The feature owner and the entire team can see it on the burndown chart: one more item moved to “Done.” It triggers a psychological reward—a dopamine response that reinforces the behavior that elicited it.

Feature and bug closure is fundamentally different from closing low-level sub-tasks. Nobody celebrates completing one of twelve software design reviews. But when “OBD Compliance” moves to “Done,” the team knows that a real, customer-visible chunk of work is finished. The effect compounds: each closed feature raises confidence and energy for the next one.

Figure 2: The positive feedback loop. Delivering a feature leads to recognition, triggering a psychological reward that fuels motivation, which drives the next delivery.

Recognition Without Ceremony

Feature closures should be acknowledged in the daily Sync—briefly, factually, but visibly. It is paying respect to the feature owner, who often had to invest a lot of “blood, sweat, and tears” to deliver the feature on time. The team that delivers should be recognized. Not with extensive celebrations, but with a simple acknowledgment—something along the lines of “Feature X is done. Well done, [name].”

That creates a culture where finishing things is valued—not just starting them. Over time, the burndown chart itself becomes a source of team pride: a visual record of what has been accomplished.

Why Celebrating Feature Closure Matters

Distressed teams are often frustrated or even demoralized. They have been in “crisis mode” for a long time, sometimes for months, working long hours with no visible sense of progress. The open-item count goes up. The backlog grows. Nobody feels like they are winning.

Feature-based tracking breaks the monolith into achievable milestones. Each closed feature is proof that progress is real. The positive psychological feedback loop—deliver, recognition, dopamine, motivation, deliver more—is the antidote to the vicious cycle of despair that distressed projects often fall into.

CORE SPICE Measures

The feature-based tracking approach does not work in isolation. It requires a foundation of five CORE SPICE measures already in place. For detailed descriptions, see “CORE SPICE Coaching Concept”.

• No task left behind. Every identified risk or gap becomes an owned task. If you create an issue, you will eventually deal with its outcome—this negative feedback loop prevents backlog mushrooming.
• Maintain the sense of urgency. Every MtO turnaround project is a task force. The TCC ensures high urgency is upheld as long as substantial risks remain unmitigated.
• End-to-end responsibility. The feature owner concept directly implements this: one person responsible from inception to final verification, cross-functional, not discipline-bound.
• Constantly assess the team. Project Lead and TCC monitor whether everyone contributes. Ineffective team members must be swiftly replaced—keeping them demotivates the rest.
• Automate everything. Feature tracking itself should be automated: status pulled from the issue management system, burndown charts generated without manual effort. With LLMs gaining traction, it should be a no-brainer.

Putting It All Together

The elements described in this article are not independent techniques to be adopted piecemeal. They form a system. When all are in place, it creates a self-reinforcing cycle:

• Feature-based tracking provides visibility.
• Radical transparency provides trust.
• The burndown baseline (features + critical bugs) provides accountability.
• The daily Sync provides cadence.
• Feature closures provide motivation.
• CORE SPICE measures provide the cultural foundation.

The cycle: Visibility → Urgency → Action → Progress → Recognition → Motivation → More progress

Feature-based tracking is not a methodology. It is a pragmatic tool that makes existing methodologies work in distressed MtO environments. The key insight is that tracking what the customer or the standard demands—features, both functional and non-functional—not what the process generates. Include critical bugs to reflect reality, not just the plan. Make everything transparent to everyone—the core team, the suppliers, and the customer.

The “trust me, I have this under control” era is over. The burndown is the answer. If the line is flat, there is no control. If the line is steep, the team is winning—and everyone can see it.

References

• Unlock Efficiency with CORE SPICE — The 12 CORE SPICE principles: projectcrunch.com/unlock-efficiency-with-core-spice/

• The Right Genes for Your Project — MtO vs. R&D project typology: projectcrunch.com/the-right-genes-for-your-project/

Last week, Anthropic CEO Dario Amodei said we might be “6–12 months away from models doing all of what software engineers do end-to-end.”

Think about it: If that’s true—if agentic AI can really do everything a software engineer does—then replicating Anthropic itself is just a prompt away. Anyone could build Cowork in their basement. Why would you pay a $60 billion company for something you can bootleg with their own tools?

Here is the thing: That’s the paradox that should keep every AI investor up at night.

Either agentic AI is as powerful as the pitch decks claim—in which case the companies selling it are commoditizing themselves. Or it’s not—in which case the trillion-dollar valuations are built on fantasy.

You cannot have it both ways.

The Yahoo Parallel Nobody Wants to Hear

In 1999, Yahoo was the internet. Yahoo’s market cap reached $125 billion. Every investor, analyst, and journalist agreed: Yahoo was the future. It had the users, the brand, the traffic, and the portal. The world literally ran on Yahoo.

Then the infrastructure underneath it—search, email, hosting—got commoditized. Cheaper. Better. Open. Google ate search. Gmail ate Yahoo Mail. WordPress ate Yahoo GeoCities. The “platform” everyone thought was an essential game-changer turned out to be a thin wrapper over generic technology.

By 2016, Verizon picked up Yahoo’s remains for $4.8 billion—a 96% discount from its peak.

Now replace “Yahoo” with “OpenAI.” Replace “portal” with “agentic AI platform.” Replace “search getting commoditized” with “LLMs getting commoditized.”

It is not the same pattern—but it rhymes.

Similar to Yahoo decades ago, OpenAI had a massive head start. ChatGPT was the fastest-growing consumer app in history. Sam Altman was on every magazine cover. The moat looked enormous.

Then DeepSeek showed you can train a frontier model for a fraction of the cost. Llama went open-source. NVIDIA stock collapsed by 17% in a single day. Claude matched GPT on most benchmarks. Gemini caught up. Mistral emerged. Dozens of open-weight models flooded the market. Every quarter, the performance gap between models shrinks while the cost per token collapses.

LLMs are converging toward a commodity faster than anyone predicted. The model layer—the very thing these companies are built on—is approaching marginal cost, just as search did in the early 2000s.

The Commoditization Paradox of Agentic AI

Here’s the part that truly breaks the god-like AI narrative.

The current scare story goes like this: Agentic AI will eat all software. Jira is dead. Salesforce is dead. Every SaaS tool will be replaced by an AI agent that just does the work.

Sounds terrifying—until you ask one simple question:

Agentic AI is software, too.

Every “agent” is fundamentally the same thing: an LLM connected to tools via APIs, wrapped in orchestration logic, with a user interface on top. That’s it. There is no deep, proprietary magic. There is no secret sauce. The MCP (Model Context Protocol) and similar standards are enabling tool integration to be plug-and-play. The models themselves are interchangeable.

If Anthropic’s Cowork can automate software development, then by definition, someone can use that exact same capability to build a Cowork competitor over a long weekend. The tools to displace the disruptor are the disruptor itself.

And no:  it is not an abstract, theoretical argument. We’ve already seen it happen. OpenClaw—a solo developer project—replicated most of what the big AI labs were pitching as their next billion-dollar product. OpenAI didn’t acquire the technology. They didn’t buy the company. They hired the guy. Because the technology was trivially replicable. The human judgment behind it was not.

The One Person Who Already Figured This Out

While Sam Altman is chasing a $500 billion IPO for a company that sells commodity software, and Dario Amodei is telling the world his agents will replace all engineers (thereby making his own product worthless—see above), one person has quietly made the move that reveals he understands everything in this article.

Elon Musk.

On February 2, 2026, SpaceX acquired xAI in a $1.25 trillion all-stock merger—the largest in history. SpaceX is valued at $1 trillion. xAI at $250 billion. On paper, this looks like another Musk ego trip. In reality, it’s the most strategically coherent move in the entire AI industry.

Here’s why: Musk is the only AI player who understood that AI alone is worth nothing.

But think about what SpaceX actually owns. Reusable rockets that no competitor has replicated at scale. Starlink—9,000+ satellites in orbit, 9 million subscribers, and billions in defense contracts with NASA and the Department of Defense. A literal company town in Texas. $15 billion in revenue and $8 billion in profit. These are physical, hard-to-replicate assets that took over two decades of engineering, explosions, and near-bankruptcies to build.

xAI’s Grok, on the other hand? A chatbot. A good one, sure — but fundamentally the same commodity as GPT, Claude, Gemini, and the rest. By itself, Grok is heading toward the same zero-margin future as every other LLM.

But Grok bolted onto SpaceX’s rocket infrastructure, Starlink’s global network, and planned orbital data centers? That’s a vertically integrated stack that no pure-play AI company can touch. OpenAI can’t launch satellites. Anthropic doesn’t have rockets. Perplexity doesn’t own a communications network.

Musk is not betting on AI. He’s betting on the things AI cannot replace—and then using AI as an add-on, not the foundation of his tech empire. That’s the opposite of what OpenAI and Anthropic are doing.

The irony is thick. The man the tech press loves to mock may be the only AI CEO who has actually internalized the logic of LLM commoditization. Everyone else is building castles on sand—premium-priced software layers that are racing to zero. Musk is building on physical infrastructure: rockets, satellites, and a distribution network that can’t be “prompted into existence.”

Many of Musk’s ideas are still science fiction, like the orbital data center. Radiation, cooling, launch costs, the sheer audacity of it. But the strategic direction is unmistakably correct. Even if the space data centers never materialize, SpaceX + Starlink + defense contracts is a $1 trillion hardware business. xAI is just a meager add-on.

Burry Is Early — But He’s Not Wrong (And Not Entirely Right, Either)

Michael Burry—the “Big Short” investor who famously predicted the 2008 housing collapse — has put roughly $1.1 billion in notional put options against Nvidia and Palantir. He’s also been shorting Oracle and publishing detailed analyses of how hyperscalers are inflating their earnings by stretching GPU depreciation from 3 years to 6 years, potentially overstating earnings by $176 billion between 2026 and 2028.

The market laughed at him initially—just like in 2007. As of February 2026, his Palantir puts are up 35%. Oracle has fallen 51% from its Q3 2025 peak. The broader S&P Software & Services Index has dropped 19% in a single month. Burry’s thesis is starting to print.

However, his Nvidia bet hasn’t paid off yet: the chips are still selling, demand is still real, and at ~24x forward earnings, NVDA isn’t priced like a bubble. Burry himself admitted his NVDA bet is “the most concentrated way to express a bearish view on the AI trade” — a sector bet, not a company bet.

I think Burry sees the disease correctly, but is aiming at the wrong organ.

Where Burry is right: The AI investment cycle is overheated. Trillion-dollar capex commitments for data centers look eerily similar to the fiber-optic boom of 2000, where less than 5% of US telecoms capacity was ever used. Depreciation accounting is masking real costs. Many pure-play AI companies will implode. Palantir at 200x earnings was never going to hold. Oracle’s AI pivot was always more PowerPoint than product.

Where Burry is potentially wrong: He’s shorting infrastructure (Nvidia, the picks-and-shovels provider) when history suggests the infrastructure layer is often the last to fall — and sometimes doesn’t fall at all. During the Gold Rush, Levi Strauss got rich. During the dot-com crash, Cisco got hammered but survived to become a $200+ billion company today. The server farms that powered the “useless” dot-com companies became the backbone of cloud computing.

Here’s the deeper irony: Musk just showed the market exactly where the real value is — physical infrastructure, vertical integration, things that can’t be cloned with a prompt. Burry is betting against the AI bubble, and he’s right about the bubble. But the optimal short isn’t Nvidia (which sells real hardware to real customers). The optimal short is the pure-software layer—the OpenAIs, the Anthropics, the Palantirs—whose valuations depend on maintaining pricing power in a market heading toward commodity.

Burry may be losing money on his Nvidia puts while being philosophically correct.

The Three Layers of AI Value—And Where It Goes to Zero

To understand who survives, think of the AI stack in three layers:

Layer 1: The Model (LLMs): This is heading to a commodity. GPT, Claude, Gemini, Llama, DeepSeek, Mistral—the performance gaps are narrowing every quarter. Open-weight models are closing the gap with proprietary ones. The cost per token is in free fall. Within 2–3 years, the model itself will be like electricity: essential, ubiquitous, and worth pennies on the original dollar.

Companies at risk: OpenAI (targeting a $500B+ IPO), Anthropic ($350B valuation for… a chatbot and some agents), Cohere, AI21, and anyone whose primary value proposition is “we have a good model.” Musk understood this, which is exactly why he bolted xAI onto SpaceX instead of trying to IPO Grok as a standalone company.

Layer 2: The Agent Wrapper. This is already a commodity. Cowork, Operator, Devin, and their dozen clones—these are LLM + API + orchestration + UI. There is no defensible moat in wiring a model to a set of tools. Any competent engineering team can (and will) build equivalents. The OpenClaw story is proof: one developer matched what the big labs were pitching as their next billion-dollar product in a few weeks.

Companies at risk: Any startup whose pitch is “we built an agent that does XYZ.” Venture capital in this space is in peak euphoria.

Layer 3: Data, Distribution, and Infrastructure. This is where durable value lives. It splits into three sub-categories:

• Irreplaceable data: Atlassian’s Teamwork Graph (100+ billion objects of institutional knowledge across 350,000 companies), Salesforce’s customer data, and Bloomberg’s financial data. The agent is replaceable; the data it operates on is not. This is the real moat.
• Infrastructure (picks and shovels): Nvidia (GPUs), Broadcom (custom ASICs/XPUs), TSMC (fabrication), the hyperscalers (AWS, Azure, GCP)—and, yes, SpaceX with its rockets, Starlink network, and orbital ambitions. Every AI company, regardless of which one wins, needs chips, power, connectivity, and cloud. This is the Levi Strauss play. It’s also the Musk play — and it’s why SpaceX at $1 trillion makes more strategic sense than OpenAI at $500 billion, even though OpenAI gets all the headlines.
• Distribution at enterprise scale: Companies embedded in mission-critical workflows with brutal switching costs—80% of the Fortune 500 runs on Atlassian; virtually every enterprise runs on Microsoft. Ripping Jira out of a 10,000-seat deployment isn’t a weekend project. It’s a multi-year, multi-million-dollar nightmare.

Where Should the Smart Money Go?

If you believe—as I do — that the model and agent layers are heading toward commodity, the investment implications are clear:

Avoid companies whose entire value proposition is “we have a good model” or “we built a cool agent.” That means extreme caution on OpenAI (if it IPOs), Anthropic, and the dozens of AI agent startups currently raising at absurd valuations. These are the Yahoo and Excite of this cycle.

Be selective with infrastructure. NVIDIA is still printing money, but at some point, custom silicon from Google (TPUs), Amazon (Trainium/Inferentia), and Broadcom’s XPUs will erode margins. The question is timing, not direction. Short-term bull, long-term cautious.

Favor the data and distribution moats. Companies like Atlassian—currently down 57% from its highs and trading at roughly 8x forward revenue—own something no agent can replicate: the institutional memory of hundreds of thousands of organizations. Their Teamwork Graph is not a feature. It’s a key that gets more valuable as more agents connect to it (via MCP). Paradoxically, the rise of agentic AI may make Atlassian more valuable, not less, because the agents need the data layer to function.

Don’t forget physical scarcity. One of the most underappreciated implications of AI commoditization is that software value compresses while hardware and energy value do not. Defense companies, energy infrastructure, semiconductor fabrication—these cannot be “prompted into existence.” Claude is not disrupting a Rheinmetall tank or a Siemens Energy turbine.

The Endgame

Here’s what I think happens:

1. 2026–2027: The AI hype peaks. More money pours into model companies and agent startups. Valuations get even more absurd. OpenAI targets a $500B+ IPO. Anthropic raises at $350B+. SpaceX/xAI goes public at $1.5 trillion — but unlike the others, it has $15 billion in revenue and $8 billion in profit from real hardware. Everyone believes this time is different.
2. 2027–2028: Reality bites. Model commoditization becomes undeniable. Open-weight models match proprietary ones on virtually every benchmark. Price-per-token approaches zero. Agent wrappers proliferate — there are 500 Cowork clones. Enterprise customers realize they don’t need to pay premium prices for what is essentially a commodity utility.
3. 2028–2029: The shakeout. Pure-play AI companies that couldn’t build real moats get acquired at massive discounts or shut down. The pattern of the dot-com bust repeats: the technology and the revolution were real, but 90% of the companies built on them were not.
4. What survives: The infrastructure layer (Nvidia/Broadcom, though with compressed margins), the data moats (Atlassian, Salesforce), the hyperscalers (who will provide AI like they provide cloud today — as a utility), the vertically integrated hardware-AI plays (SpaceX/xAI, if the execution holds), and the physical-world companies that AI simply cannot commoditize.

Michael Burry is betting on the crash. I think he’s right about the what, but potentially wrong about the where. The model layer will implode. The agent layer will commoditize. But the picks-and-shovels layer and the data-moat layer will survive—and in some cases, thrive.

The winners of the AI revolution won’t be the companies building AI. They’ll be the companies that own what AI cannot replicate: data, trust, physical infrastructure, and the human judgment to use it all wisely. Musk seems to get it. Burry half-gets it. The rest of the market? Still chasing the Yahoo dream.

As I wrote in my earlier piece on the AI Abundance Trap: LLMs don’t eliminate work; they give us 10× speed to develop everything else. The competitive edge in the coming decade belongs to those who refuse to let fast AI make them dumber.

So: cultivate your critical thinking. Invest in what can’t be prompted into existence. And prepare for the implosion that even Sam Altman’s pitch deck can’t prevent.

The dot-com crash didn’t kill the internet. It killed the pretenders.

The AI implosion won’t kill artificial intelligence. It will kill the Yahoos.

And if you want to know who survives? Look for the rockets, not the chatbots.

Where Should the Smart Money Go?

If you believe—as I do—that the model and agent layers are heading toward commodity, the investment implications are clear:

Avoid companies whose entire value proposition is “we have a good model” or “we built a cool agent.” That means extreme caution on OpenAI (if it IPOs), Anthropic, and the dozens of AI agent startups currently raising at absurd valuations. These are the Yahoo and Excite of this cycle.

Be selective with infrastructure. NVIDIA is still printing money, but at some point, custom silicon from Google (TPUs), Amazon (Trainium/Inferentia), and Broadcom’s XPUs will erode margins. The question is timing, not direction. Short-term bull, long-term cautious.

Favor the data and distribution moats. Companies like Atlassian—currently down 57% from its highs and trading at roughly 8x forward revenue—own something no agent can replicate: the institutional memory of hundreds of thousands of organizations. Their Teamwork Graph is not a feature. It’s a flywheel that gets more valuable as more agents connect to it (via MCP). Paradoxically, the rise of agentic AI may make Atlassian more valuable, not less, because the agents need the data layer to function.

Don’t forget physical scarcity. One of the most underappreciated implications of AI commoditization is that software value compresses while hardware and energy value do not. Defense companies, energy infrastructure, semiconductor fabrication—these cannot be “prompted into existence.” Claude is not disrupting a Rheinmetall tank or a Siemens Energy turbine.

The Endgame

Here’s what I think happens:

1. 2026–2027: The AI hype peaks. More money pours into model companies and agent startups. Valuations get even more absurd. OpenAI targets a $500B+ IPO. Anthropic raises at $350B+. SpaceX/xAI goes public at $1.5 trillion — but unlike the others, it has $15 billion in revenue and $8 billion in profit from real hardware. Everyone believes this time is different.
2. 2027–2028: Reality bites. Model commoditization becomes undeniable. Open-weight models match proprietary ones on virtually every benchmark. Price-per-token approaches zero. Agent wrappers proliferate — there are 500 Cowork clones. Enterprise customers realize they don’t need to pay premium prices for what is essentially a commodity utility.
3. 2028–2029: The shakeout. Pure-play AI companies that couldn’t build real moats get acquired at massive discounts or shut down. The pattern of the dot-com bust repeats: the technology was real, the revolution was real, but 90% of the companies built on it were not.
4. What survives: The infrastructure layer (Nvidia/Broadcom, though with compressed margins), the data moats (Atlassian, Salesforce), the hyperscalers (who will provide AI like they provide cloud today — as a utility), the vertically integrated hardware-AI plays (SpaceX/xAI, if the execution holds), and the physical-world companies that AI simply cannot commoditize.

Michael Burry is betting on the crash. I think he’s right about the what, but potentially wrong about the where. The model layer will implode. The agent layer will commoditize. But the picks-and-shovels layer and the data-moat layer will survive—and in some cases, thrive.

The winners of the AI revolution won’t be the companies building AI. They’ll be the companies that own what AI cannot replicate: data, trust, physical infrastructure, and the human judgment to use it all wisely. Musk seems to get it. Burry half-gets it. The rest of the market? Still chasing the Yahoo dream.

As I wrote in my earlier piece on the AI Abundance Trap: LLMs don’t eliminate work; they give us 10× speed to develop everything else. The competitive edge in the coming decade belongs to those who refuse to let fast AI make them dumber.

So: cultivate your critical thinking. Invest in what can’t be prompted into existence. And prepare for the implosion that even Sam Altman’s pitch deck can’t prevent.

The dot-com crash didn’t kill the internet. It killed the pretenders.

The AI implosion won’t kill artificial intelligence. It will kill the Yahoos.

And if you want to know who survives? Look for the rockets, not the chatbots.

Last year, as music is my hobby, I spent an evening creating professional-sounding songs with Suno. They sounded great, and I felt really good about myself—until I realized that tens of thousands of people are doing the exact same thing every day, and their Suno-creations sound brilliant. Suddenly, a product that used to take months, real talent, and real money is now worth next to nothing.

I’ve been thinking about this a lot lately: if someone using AI can deliver the exact same quality of work in just a few days that used to take months, how should that work be valued? Do we still pay the old rate, or is the entire pricing model broken?

That simple question exposes a quiet, open flaw in the entire AI narrative: what happens when intelligence itself becomes abundant and cheap?

Are LLMs Good Enough?

LLMs are continuously improving, but they remain fundamentally fast-thinking pattern matchers — exactly as Daniel Kahneman describes in his book Thinking, Fast and Slow. In it, he distinguishes two modes of human thinking: System 1 (“fast thinking”—quick, intuitive, pattern-matching) and System 2 (“slow thinking”—deliberate, logical reasoning required for complex, high-stakes work).

Current LLMs are pure System 1 machines. They simply predict the next token based on the previous ones. That’s why they still hallucinate at 10-20% across many real-world tasks. In that sense, they are not “intelligent” in the human meaning of the word.

For many routine tasks that do not require a predetermined outcome quality, this is often sufficient. But for anything that truly matters—tax advice, legal contracts, or safety- and security-critical automotive development—the risk is simply too high. You can outsource the first draft to an LLM, but thorough human verification and validation (true System 2 thinking) remain indispensable.

“Free”—at a Price

In that sense, for many tasks, current LLMs are already “good enough.” The real question is: what is such cheap content actually worth?

When output becomes infinite and near-free, the old pricing model collapses. “Agentic” AI like Claude Cowork can now develop complete software for pennies. Yet here is the bizarre paradox: pure software companies like Anthropic have valuations in the tens of billions, even though they are selling the very tools that will commoditize the software layer itself.

As a lateral example, SaaS (Software-as-a-Service) is being commoditized as we speak—the easy, promptable layers are turning into near-zero-cost commodities. If anyone can recreate something like OpenClaw in their basement, why would companies continue paying premium prices for what is quickly becoming a utility?

The trillion-dollar pitch decks assumed AI would capture huge rents from automated labor. Instead, raw intelligence itself is heading toward full commoditization.

But the problem runs deeper than just economics. Our heavy reliance on these fast-thinking systems is already creating a more subtle but serious issue: cognitive offloading. Recent studies, including a 2025 MIT Media Lab EEG experiment, show that users who lean heavily on LLMs exhibit significantly reduced brain engagement, lower critical thinking, and measurable “cognitive debt” over time.

In other words, while we happily offload more and more work to LLMs—even as they still hallucinate left and right—the users themselves are beginning to lose the ability to spot those hallucinations. That is not a good sign for the future of an LLM-driven AI industry.

Surviving the LLM Implosion

Despite all the shortcomings of current LLMs, not everything will be devoured by agentic AI. Many LLM-powered tasks already appear “good enough” in the sense that they can be completely automated, but we must focus on what survives commoditization: proprietary data, customer relationships, distribution, personal brand, and—most importantly—the irreplaceable human inspiration.

However, the ability to make educated decisions will become even more important as automation progresses rapidly. The decisive competitive factor for the next decade will be Effective Critical Systems Thinking (ECST). This slow, deliberate, System-2-level reasoning turns cheap AI from a crutch into a 10× multiplier. Companies and indie builders who deliberately cultivate ECST will pull ahead, while those who just prompt-and-pray fall behind.

In addition, some software tools are unlikely to become commoditized anytime soon. Certain infrastructure layers will remain extremely valuable. For instance, the Atlassian platforms (e.g., JIRA) that guarantee data persistence, compliance, auditability, and deep integration cannot be easily replicated with a prompt. Software that protects the high-trust environment— the rule of law, honest integration, open inquiry, and long-term value creation—will remain in every company’s war chest.

Otherwise, software becomes, in general, a “commodity”: relatively easy to develop, maintain, and extend at low cost. Systems development, on the other hand, products that, in addition to software, require custom hardware and mechanical parts, will remain in the “scarcity” camp: not commoditizable, expensive, and labor-intensive.

Thinking longer term, when fusion energy finally arrives (see my earlier piece on the megatrend of cheap, clean energy here), the whole game changes again: energy becomes nearly free, supercharging the abundance for those who kept their thinking sharp. Once this day arrives (likely not before 2030), all bets will be off anyway, because with sufficient energy, iterating everything (including physical infrastructure) until the result is satisfactory will be a non-issue.

Keep Calm and Carry On

Most of the hype money is still betting on raw LLM models, even as they are fast approaching their own commoditization.

AI is not approaching the mythical AGI anytime soon. Serious analysis shows the productivity miracle is smaller and slower than pitched, especially while LLMs remain unreliable System 1 fast thinkers. In other words, true AGI will literally never be possible as long as we rely on today’s “System 1” software.

While some fear that humans will be eliminated and that AI will do everything, this fear is understandable but misplaced. LLMs produce cheap content, not accountability. For many years to come, clients will always need a human “throat to choke” when millions are on the line. The real danger is not replacement—it’s becoming so dependent on LLMs that we lose our own deep thinking ability.

Let’s Grow the Pie

The “great commoditization” of software (including LLMs) is a revolution—and, as the saying goes, revolutions often devour their children. Many currently hyped companies will disappear and be remembered only by the same people who still remember the “Boo.com” disaster. That said, this revolution is real, and the trillion-dollar AI fairy has reached a scale that is becoming “too big to fail.” The often-cited comparison with the dot-com crash should not be taken lightly—the current AI hype may indeed end up in a similar crash. Once the dust settles, we will likely be surprised by what emerges from this chaos.

In the meantime, the fear that the economic pie will shrink and leave millions living on a “universal basic income” can come true—if we as human beings refuse to adapt. If we don’t adapt, the near future will lead to a tumultuous transition to the “brave new world.”

On the other hand, this transition doesn’t have to be as painful as some assume.  The potential horrors of “everyone gets fired by the AI” rest on a fixed-pie assumption: that work would shrink, and the rest of us would have to fight over the same slice. In my view, that’s a horrible misconception. There will be many changes in the workforce, as mostly boring “box checkers” and bureaucrats may be sent packing home; however, most of us won’t miss them anyway. Instead, the remaining productive engineers and scientists will gain AI superpowers, thereby steeply increasing economic output (a.k.a. “added value”).

In other words, instead of being overly anxious that jobs are supposedly being destroyed, let’s grow the pie.

LLMs don’t just eliminate work; they give us 10× speed to develop everything else—including fusion reactors, new materials, and better medicine. The real competitive edge in the coming decade will belong to those who refuse to let fast AI make them dumber. Cultivate Effective Critical Systems Thinking. Protect open inquiry. Build on solid ground.

For indie builders, consultants, and companies worldwide, this is liberating: we never needed to rent our future from Big Tech anyway. The real game is building sovereign, honest, long-term things while the technology gets cheaper every month.

That’s what technology has always been about—and it’s why I’m genuinely optimistic about the decade ahead.

References

• Daniel Kahneman, Thinking, Fast and Slow, Farrar, Straus and Giroux, 2011. ISBN 978-0374533557
• Kosmyna et al., “Your Brain on ChatGPT” (MIT Media Lab, June 2025) — https://www.media.mit.edu/publications/your-brain-on-chatgpt/
• Acemoglu, Daron. “The Simple Macroeconomics of AI” (NBER Working Paper 32487, 2024) — https://www.nber.org/papers/w32487
• Roman Mildner, “Megatrend: Cheap Clean Energy” (projectcrunch.com) — https://projectcrunch.com/megatrend-cheap-clean-energy/

He hired Peter Steinberger.

Not the company. Not the tech. The guy. The one-man band who, in a few weeks in January 2026, built OpenClaw — the open-source personal agent that actually works on real laptops, not just demos.

It lives in WhatsApp, Telegram, and Slack. Clears inboxes, books flights, runs shell commands, controls your browser, manages your calendar — all while remembering everything as plain Markdown files on your disk. Proactive, local, no cloud “hostage.” 100k+ GitHub stars in weeks.

Then OpenAI hired Peter, who is now driving the “next-generation personal agents” at the lab.

Here’s the part the VC pitch decks don’t want you to see:

If the models were as god-like as claimed, they wouldn’t have needed to hire anyone.

They could have prompted Claude, “Computer Cowork” or their own agents: “Clone OpenClaw, production-grade, fix the edge cases, security, memory, reliability loops.” Weekend project. Cheap commodity. Done.

But they didn’t. They bought the human brain that turned unreliable models into something useful.

That’s the dirty secret still true in February 2026: hallucinations and drift remain a critical bug—and no, it’s not a “feature.” It is a BUG, period. Long-running agents break on tiny changes, need rock-solid sandboxing, and taste no prompt reliably delivers. Even OpenAI looked at one skilled builder’s work and said, “We need him.”

This is why the “AI → deliver” fantasy collapses. Real workflow is still “AI → validate → repeat → deliver.” Speed is real, but the mythical-magical replacement? Nope, it remains a fantasy.

In our CORE SPICE framework, where we automate everything possible but SPEED is everything, this is the exact reality check we live by every day in automotive dev and management: use the AI for velocity, keep the human taste and validation so you actually ship without breaking the product.

The economy will win in the long term, as it did after the Internet boom. But the companies that keep winning stock prices won’t be the ones promising to fire every developer. They’ll sell the shovels (chips, power, cooling), embed AI inside unbreakable moats (Microsoft, Google, Amazon), and rely on rare humans who make the unreliable reliable.

OpenClaw is the perfect case study. One guy with taste and grit shipped something useful. The world’s biggest lab still needed that guy.

So next time someone tells you agentic AI is about to replace every knowledge worker, ask them why OpenAI couldn’t replace Peter Steinberger with a weekend prompt.

The answer is staring us right in the face.

CORE SPICE Approaches replace classical process writing with outcome-driven project definitions. With the CORE SPICE Approaches, teams can quickly kick off engineering activities. They ensure consistent, compliant teamwork while eliminating heavyweight process documentation that nobody reads.

Each CORE SPICE Approach is a short, structured template. It is completed with the project team during the early project phase and serves as a living reference for how the project is actually executed. The goal is clarity, speed, and the avoidance of wasteful, redundant documentation.

The CORE SPICE Approaches are available as templates on the CORE SPICE GitHub repository (LINK). They are free to use under the CORE SPICE Creative Commons license, which allows them to be used for any commercial application.

What problem are we solving?

Most automotive development organizations still rely on classical process documentation. These documents are usually large, slow to update, and expensive to maintain. Worse, they are often disconnected from how engineering teams actually work.

Three problems show up in almost every project:

• Process handbooks are rarely ready during project kickoff. Teams start working without shared rules. When the process finally arrives, it collides with reality and causes friction.
• New hires and suppliers do not study hundreds of pages of process documentation. They learn by imitation and local habits. Long process descriptions quickly become irrelevant.
• Automotive SPICE, functional safety, and cybersecurity requirements are often addressed only through assessment. At that point, process work becomes a bottleneck.

Traditional “process tailoring” does not solve this. It still produces documents that are too abstract, too late, and too remote from the day-to-day engineering decisions.

What are CORE SPICE Approaches?

CORE SPICE Approaches are not process descriptions in the classical sense. They define:

• What outcomes must be achieved
• Who is responsible
• How the project intends to work

They intentionally avoid exhaustive activity lists, redundant standard references, and academic completeness.

An Approach does not try to describe everything. It explains what matters for the project. Each Approach fits on a small number of pages. It is reviewed with the core team. After that, Approaches are updated as needed and can be shown directly to assessors and customers.

In short, an Approach is a strategy and decision aid, not a rulebook.

Two ways to use CORE SPICE Approaches

CORE SPICE Approaches can be used in two ways. Both are valid. The choice depends on timing, team maturity, and constraints.

1. Manually (conventional approach)

2. LLM-accelerated way

In the former case, the approaches are used as inputs and manually elaborated, with each description completed line by line by a dedicated project role.

In the latter case, the CORE SPICE Approaches are used as input to LLMs, quickly generating an expanded document that can be reviewed and discussed with the team immediately.

1. Manually

In the manual approach, a designated role (e.g., Project Lead or Issue Lead—an optional role created for this example only) completes the CORE SPICE template line by line. The draft is reviewed with the core team. Open questions are clarified. Conflicts are resolved. After one or two iterations, the document is approved and becomes part of the project baseline.

This conventional approach makes sense when:

• The team needs deep alignment and discussion
• The customer explicitly demands traditional documentation
• There is enough time before development ramps up

The downside is obvious; even using such a slim CORE SPICE Approach still takes time. In real-world projects, manually creating a complete set of Approaches can take weeks or months.

2. LLM-accelerated creation

The second option uses large language models as drafting accelerators—in this case, ChatGPT 5.1.

The procedure is simple:

• The core team aligns on the key project intent, such as safety level, customer priorities, constraints, or team size.
• The responsible role prepares a structured prompt. Inputs typically include:
  • Project context and goals
  • Architectural scope
  • Applicable standards (ASPICE, ISO 26262, ISO 21434)
  • Organizational constraints
• The LLM generates a complete first draft of the Approach.
• The team reviews, corrects, and adapts the draft.

An important point is that LLM does not make decisions (which can be explicitly ensured by adding specific instructions to the original LLM prompt). It only produces a structured proposal. The responsible project role remains fully accountable for completing the Approach.

Using LLMs reduces drafting time by 70–80%. It allows teams to discuss a concrete document immediately rather than debate abstract ideas.

Example: LLM-driven Issue Management Approach

Let us consider an Issue Management Approach created for a hypothetical Door Lock Control ECU project. The project required:

• Handling defects, change requests, and project tasks
• Full tool support via Atlassian JIRA
• Strong focus on ASIL D and cybersecurity
• Compliance with Automotive SPICE 4.0 without clutter

In addition, a new role was introduced: the Issue Flow Manager, who reports directly to the Project Lead. Using an LLM, the Issue Management Approach template was expanded into a full project-specific document.

The detailed prompt for this approach is provided in the “Appendix” at the end of this article.

The result was a 14-page draft that included scope and objectives, defined roles and responsibilities, and explicit issue lifecycles for defects, change requests, and tasks.

The entire first version was created in one working day, including several rounds of review. Creating the same document manually would typically take several weeks. This does not mean the document was “finished.” In a real project setting, it will still require expert review. But the hard part—structuring and completeness—was already done.

Two additional iterations were needed to fine-tune the level of detail. Workflow visualizations were generated automatically. Because the resulting workflows were purely textual, we used  ChatGPT to generate UML-like state machine graphs using PlantUML (see https://www.plantuml.com). We stored the result in Git (see link in Git)

What about quality, accountability, and trust?

A common objection is that LLMs cannot be trusted to define processes. LLMs can produce incorrect or inconsistent output if not validated and appropriately reviewed. Therefore, every generated draft must be reviewed and owned by the responsible project role. Thus, the resulting approaches must be carefully validated by the project core teams.

• LLMs are not accountable. Project leads are.
• LLMs do not approve documents. Teams do.
• LLMs do not replace expertise. They amplify it.
• Quality comes from review, not from typing speed.

In fact, the LLM-based approach often improves quality because:

• Inconsistencies become visible earlier
• Gaps are easier to spot in a complete draft
• Changes can be applied consistently across documents

The idea that process documents remain unchanged throughout a project is a fiction. Projects evolve. Requirements change. Teams change. Using LLMs enables faster, safer, and more efficient work. That helps avoid the annoying “reworking from scratch,” which often demotivates the team. CORE SPICE Approaches must be easily modifiable, living documents. An Approach is not written once and archived. Only with such “living documents” can approaches serve as references for daily decisions.

This makes CORE SPICE fundamentally different from traditional process frameworks. The goal is not compliance “theater.” The goal is working clarity under real-world constraints.

Conclusion

Modern systems development does not fail because teams lack standards. It fails because the interpretation of standards is too complex, applied too late, and implemented too literally.

CORE SPICE Approaches address this by:

• Defining intent early
• Keeping documentation minimal but sufficient
• Automating everything whenever possible
• Aligning teams around outcomes, not activities

Whether created manually or accelerated with LLMs, CORE SPICE Approaches enable teams to start nearly instantly. In automotive projects, development speed is not a luxury. It is a survival factor. CORE SPICE is not about writing better processes. It is about not needing to “write” processes at all.

Appendix

[1] The Issue Management Approach demo draft: https://github.com/CORE-SPICE/DOORLOCK_DEMO/blob/main/Approaches_Demo/Issue%20Management%20Approach.docx

[2] The full prompt:

Context:
In the example project “Door Lock” (see https://github.com/CORE-SPICE/DOORLOCK_DEMO), develop a full draft of the Issue Management Approach.

Use the “Value” sections only as a support narrative and do not include the “Value” chapter in the final result.

Introduce one additional role that is not part of the CORE SPICE Roles Catalog and that reports directly to the Project Lead.

Assumptions

• The issue management system covers defects, change requests, and project tasks.
• Use Atlassian JIRA as the standard issue management tool.
• If applicable, include other tools that support the issue management system.
• Ensure compliance with the project’s goals regarding ASIL D and cybersecurity.
• Ensure full compliance with ASPICE 4.0 in SUP.1, SUP.8, SUP.9, SUP.10, and MAN.3, without cluttering the Approach with explicit ASPICE references—just be compliant.
• Include a lifecycle for each issue type.

LLMs can write, summarize, and even compose music. But automotive engineering demands more than creativity. It demands compliance, traceability, and precision. So the question is: Can LLMs generate compliant, traceable, and review-ready documentation that meets Automotive SPICE, ISO 26262, and ISO 21434 requirements?

To find out, we conducted a one-day experiment using LLMs to create an end-to-end draft for a Door Lock Control ECU.

The LLM Experiment

The goal was simple: to generate, within one day, a complete documentation draffor a small but safety-relevant subsystem—a car door lock controller.

The intention wasn’t to create production-ready data, but to evaluate how far AI could accelerate early V-Model phases—from requirements elicitation to testing and compliance documentation.

No external tools were used. No DOORS, no Integrity, no code generators. Just LLMs, text prompts, and office formats.

Because Volkswagen’s projects (with KGAS and Formel Q) are known for rigor, VW was chosen as the reference OEM. The work was time-boxed to one Saturday.

Customer Requirements (SYS.1)

Using ChatGPT 5.0 and Grok 4.0, I began with the customer requirements. No existing example was provided; everything was generated from scratch.

After several iterations, the core SYS.1 query became:

Develop a Door Lock Control ECU
Description: Controls electric door locks via key-fob signal or button input, with feedback.
Key points: Response < 500 ms, fail-safe unlock, ASIL A classification, signal authentication.
Deliverable: “Lastenheft-like” specification including ~50 requirements compliant with VW practice and KLH Gelbband 2023.

The resulting document contained 87 customer requirements, ready for trace-down to SYS.2.

Full list: https://github.com/CORE-SPICE/DOORLOCK_DEMO/tree/main/SYS.1

The Left-Side of V

System Specification (SYS.2)

SYS.2 system requirements were derived from SYS.1.

It took several iterations to ensure the system used sufficiently analyzed system requirements, including the verification criteria.

Example of a requirement:

See https://github.com/CORE-SPICE/DOORLOCK_DEMO/tree/main/SYS.2 for the complete document.

System Architecture (SYS.3)

SYS.3 (system architecture) was derived from SYS.2 and contained a textual architecture plus a simple LLM-generated block diagram (a separate query). Though basic, it demonstrated consistent traceability and structure typical for ASPICE-compliant work.

The result was, at best, a glimpse of the architecture, but it gave at least a rough idea of the system architectural design. A full-blown architecture could be further refined using SysML (see SWE.2 examples).

SYS.3 full set: https://github.com/CORE-SPICE/DOORLOCK_DEMO/tree/main/SYS.3

Software Requirements (SWE.1)

33 SWE.1 (software requirements) requirements were derived from SYS.2 and SYS.3, retaining the traceability from both levels.

Similar to SYS-levels, we had to iterate several times to achieve a more realistic level of granularity in the software requirements derived from the SYS.2/SYS.3 documents.

See https://github.com/CORE-SPICE/DOORLOCK_DEMO/tree/main/SWE.1

Software Architecture (SWE.2)

Software Architecture was derived from SWE.1, resulting in a textual of the architecture specification, commonly used in many ASPICE-compliant projects. ChatGPT automatically added relevant aspects of the software architecture:

• SW components
• SW interfaces
• Dynamic aspects
• State machines
• SW data types
• Traceability
• Non-functional requirements elements (e.g., cybersecurity)

In addition, LLMs proposed using PlantUML diagrams and generated them.

(Complete SWE.2, including the images and the PlantUML diagrams, see https://github.com/CORE-SPICE/DOORLOCK_DEMO/tree/main/SWE.2)

SW Detailed Design (SWE.3)

SWE.3 elements … were created on two levels:

• Software detailed design
• Software Units

The detailed design came out very simplified, but we did not drill down further, as our intention was—as throughout the document—to generate a “proof of concept” methodology. Even using a simple prompt, ChatGPT was able to derive requirements, ChatGPT was able to generate a more comprehensive specification in one Excel book, including

• Module Units
• API
• Algorithms
• Data dictionary
• Error handling
• Calibration
• Unit test hooks
• Traceability records

For the very first iteration of the detailed design documentation, the result was pretty impressive.

(see https://github.com/CORE-SPICE/DOORLOCK_DEMO/tree/main/SWE.3/DD for the full content).

The LLM also generated units as C source code.

Software Units were traced from detailed design (SWE.2) and software requirements (SWE.1). The resulting example (C-code) consisted of 34 units.

Example of a simple CAN adapter:
/* ==========================================================================
 * Unit: can_adp (SWU-011) - implementation
 * Trace: SWE.1 SwRS-010, SwRS-019, SwRS-025 | SWE.2 SWD-CMP-011
 * ========================================================================== */
#include "can_adp.h"
#include <string.h>

#define MAX_ID 0x7FFu /* placeholder allowed range */
static uint8_t s_last_seq_table[16] = {0}; /* LUT by (id & 0xF) */

static bool id_allowed(uint32_t id)
{
    /* Placeholder policy: standard ID range only */
    return (id <= MAX_ID);
}

static bool crc_ok(const CANMsg_t* m)
{
    /* Placeholder CRC check stub: always true, to be replaced with real CRC */
    (void)m;
    return true;
}

bool CAN_Validate(const CANMsg_t* m)
{
    if (m == 0) return false;
    if (!id_allowed(m->id)) return false;
    if (m->dlc > 64u) return false;
    if (!crc_ok(m)) return false;

    uint8_t* pseq = &s_last_seq_table[m->id & 0xFu];
    uint8_t last = *pseq;
    if (m->seq == last) {
        return false; /* duplicate */
    }
    /* allow wrap-around; only reject if strictly older */
    if ((uint8_t)(m->seq - last) > 200u) {
        return false;
    }
    *pseq = m->seq;
    return true;
}

Like the rest of the example, it is an exceedingly simplified code, but it appears at least syntactically correct.

(Complete specification is located here: https://github.com/CORE-SPICE/DOORLOCK_DEMO/tree/main/SWE.3/Unit%20Construction

The Right Side of V

System Qualification Test (SYS.5)

Derived from system requirements (SYS.2), a complete set of system test cases were generated, based on requirements and therein specified verification criteria.

In this example (SYS-TC-007), LLM created the following values for this test case:

As a nice by-product, ChatGPT automatically generated a traceability record as a requirements test coverage metric

(Complete system test catalog: https://github.com/CORE-SPICE/DOORLOCK_DEMO/tree/main/SYS.5)

SYS.4, SWE.6, SWE.5, and SWE.4

The remaining test cases on the right side of V have been derived from the respective levels (SYS.3, SWE.1, SWE.2, and SWE.3) in the same way.

See the remaining test catalogs:

• SWE.5 SW integration test: https://github.com/CORE-SPICE/DOORLOCK_DEMO/tree/main/SWE.5
• SWE.4 unit tests https://github.com/CORE-SPICE/DOORLOCK_DEMO/blob/main/SWE.4/Door_Lock_Control_ECU_SWE4_Unit_Test_Catalogue.xlsx

Quality Assurance (SUP.1)

Using Grok, we calculated a very simplified traceability coverage, which revealed a few gaps.

It appears realistic to expand the traceability report to include more complex traceability concepts, but we have not dived into the traceability aspect any further.

After a complete iteration of the door lock system, we also audited the results using Grok 4.0 to identify consistency and traceability gaps, which suggested the potential to automate quality assurance.

(See https://github.com/CORE-SPICE/DOORLOCK_DEMO/blob/main/Door_Lock_Control_Traceability_Coverage.xlsx)

(See https://github.com/CORE-SPICE/DOORLOCK_DEMO/blob/main/2025-10-13_Audit%20Report.docx )

Looking at the generated system specification from a quality perspective, we wondered which gaps and improvements would be necessary to enhance its quality. Using a single prompt, we generated a high-quality report.

This is an excerpt of the audit findings. See https://github.com/CORE-SPICE/DOORLOCK_DEMO/blob/main/2025-10-13_Audit%20Report.docx for the complete document.

The result is, of course, very simplified and most likely incomplete. However, it demonstrated the potential of using LLM-generated documentation for quality assurance and compliance.

Key Observations

We were able to create a “zero draft” of the specification documents required by ASPICE at the SYS and SWE levels, including full traceability, in just one day. The results were impressive at first sight but overly superficial at second sight. However, we must not forget that the documentation was generated in a few hours of work, and even that kind of simple, comprehensive draft would already cost weeks to achieve, at a cost of dozens of thousands of dollars.

The best way to work with LLMs is to Iiterate on the models until the desired level of quality is achieved..

The central insight is that the future of automotive development will be hybrid, combining human expertise with AI-generated work products.

Conclusion

This experiment proved that LLMs can produce consistent, compliant, structured, and traceable documentation for an automotive subsystem in a single day. While far from replacing engineers, they can jump-start the development process and ensure a consistent baseline across the V-model.

Correctness, reasoning, and tool integration remain open challenges—but the trajectory is clear. With proper human oversight, AI will become a standard part of the automotive engineering toolkit, reshaping how projects start and how compliance is achieved.

The CORE SPICE approach captures this philosophy: Automate everything that can be automated—and let humans focus on what truly matters.

Reference

[1] All files created in this example: https://github.com/CORE-SPICE/DOORLOCK_DEMO

[2] VDA KLH: https://vda-qmc.de/wp-content/uploads/2023/11/KLH_Gelbband_2023_EN.pdf

[3] KGAS 4.2 (not publicly avaliable on the net)

This book provides an overview of the many new features becoming a reality in connected cars. It covers everything from the integration of Google and Facebook to services that help you find your parking spot, park your car via an app, or remotely close your sunroof when it’s raining.
The ultimate goal of this development is autonomous driving. The book includes current developments, implementation variants, and key challenges regarding safety and legal framework. It also provides information about the necessary quality standards in developing complex vehicle software-based systems.
Finally, the effects on the economy, society, and politics are described, with special consideration given to vehicle users, manufacturers, and suppliers.

Contents

• From Heritage to High-Tech: The Evolution of the Automotive Industry
• Driving into the Future: Autonomous Vehicles
• Digital Drive: The New Era of Connectivity
• Quality in the Automotive Industry – From Product to Process
• Know the Risks: Mastering Automotive Project Management
• CORE SPICE
• Strategic Roadmap: Shaping the Future of the Automotive Business
• Automotive Perspectives: Resolving the Riddle

Target audience

• Managers and specialists in software development, process quality, systems engineering, suppliers, and vehicle manufacturers
• Drivers interested in the latest developments in automotive technology

The authors
Roman Mildner is a consultant, project manager, and author specializing in project organization and process quality in the automotive industry.

Thomas Ziller is a project manager who shares his extensive knowledge as a lecturer at Heilbronn University of Applied Sciences.

Franco Baiocchi is an Intacs-certified Competent Assessor and project manager working as an independent consultant since 2021.

Enjoy!

Your book, Car IT Reloaded (get it here in Germany or here in the US):