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. “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 to 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, No Exceptions

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 exactly 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 does not exist. If a supplier’s feature is red, everyone knows it is red—the supplier, the project lead, and the customer. That is not confrontation. That is professionalism.

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 “sanc” (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 visibility and progress control mechanism. 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

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

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

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.

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 labour. 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):

Refocusing from “compliance” to “project effectiveness”: When projects get stuck, CORE SPICE gets them moving.

There has been considerable pushback against relying on assessment models as a solution to automotive industry woes—a topic that has been a buzz for some time. Condemning such standards has become a good source of clickbait, but there is a grain of truth in that continuous buzz. The German assessment model, Automotive SPICE (also known as ASPICE), is a VDA standard that has gained popularity as an alternative to the failed CMMI appraisal model. ASPICE is a helpful tool tied to the V-model, thus eliminating the need to invent an industry-specific project lifecycle (CMMI did not postulate any specific model like V). Its primary purpose is to assess suppliers’ “worthiness” in terms of risk management, structured approach, and the complex traceability requirements, so that the OEM can contract the most suitable supplier. Since the “software crisis” was proclaimed (see the 1968 NATO Conference [1]), capability models like CMM, CMMI, and ASPICE have played a role in addressing the challenge of software complexity in systems parts development (see [2] for a broader context).

Assessment models can be used as an indicator of compliance, with the expectation that demanding specific compliance elements can be directly translated into efficient processes. However, the high number of failed ASPICE process improvement projects points to an efficiency gap. The root cause of this problem likely lies in the expectation that ASPICE could be “implemented” as a development process. Yet assessment models are not process templates. The fundamental challenge is that ASPICE does not provide a systemic resolution of its expectations. ASPICE is an analytical, highly rational approach to evaluating compliance. In contrast, designing an efficient, well-thought-out systems development process is a systemic task that requires a deep understanding of the organizational context and all reference processes described in ASPICE. Using assessment models as project improvement goals is a risky proposition. In fact, analytical assessments should not be the starting point for process development, as such a strategy is rational rather than systemic.

Russell Ackoff, renowned for his “systems thinking,” emphasized the distinction between analytical thinking (which breaks a system down into its parts and optimizes them individually) and systemic thinking (which focuses on the whole and the interactions between its parts), using the example of an automobile. In analytical thinking, one might assume that assembling the “best” individual components would result in a perfect whole—but Ackoff argued this is flawed because the system’s performance depends on how the parts interact, not just their separate qualities (a recording of the speech is available here). In his remarks, Ackoff explains:

The NY Times reported that there are 457 automobiles available in the U.S. If you had engineers find the best part from each car, the best motor from say a Rolls Royce, the best transmission from a Mercedes, etc., and have engineers take the best parts from each car and instruct them to assemble them. Do we get the best automobile? Of course not, we don’t even get an automobile. Because the parts don’t fit together.

He further explains:

Divide and conquer is the basic principle of Western management. Manage each department separately, and in turn, the whole will be run as well as possible. But this is absolutely false. (…) A system is not the sum of its parts; it’s the product of their interactions.

Assessment models are not process blueprints.

ASPICE is the best V-based assessment model specifically tailored to the needs of the European automotive industry. It can provide valuable insights into weaknesses that help make product development run more smoothly and efficiently. It is, however, not a proper process “blueprint.” I have witnessed dozens of auto part suppliers “implementing ASPICE” literally. In ASPICE, there are several “processes,” including SYS.1, SYS.2, SWE.1, SUP.10, and others—all of which operate within their own siloed organizational structures when such a process blueprint is followed. BPs (base practices) are cleanly sorted in separate chapters. This often leads to team roles and activities that are redundant and poorly integrated into the development practice. For example:

• Once a process “MAN.3” is defined, the team tends to view MAN.3 as a job of the project lead. The other project team members took a “hands-off” approach. “It’s MAN.3—So I am not responsible.”
• If SUP.8 is viewed as a process, other aspects, such as release planning, continuous integration, traceability management, etc., become the responsibility of “SUP.8”—usually the Configuration Manager, which creates a bottleneck within a project organization. For instance, creating a “baseline” seems to be a proverbial fifth wheel; the Configuration Manager often must chase the deliveries instead of collecting and delivering them in the upcoming release package.
• Treating SYS.3 (System Architectural Design) as the architect’s isolated responsibility leads to designs that lack input from integration or test engineers, resulting in architectures that look good. Still, the practical value of the complex SysML model may be viewed as overrated (sometimes referred to as “ivory tower design”).
• SUP.1 (Quality Assurance) is often implemented as a standalone process. The only person who embodies this role is the QA Manager alone. This typically results in a disconnect, where developers and engineers adopt a “throw it over the wall” mentality. Quality issues are deferred until SOP, where an assessment adds to the stressful strain that only increases the risk of losing key engineers and can even lead to health issues and the oft-dreaded “burnout.”

Using ASPICE as a top-down process definition, rather than building a project development approach from the bottom up, typically creates an organizational liability: it becomes a detached entity within an engineering organization. Although it may not be obvious, ASPICE—while it abstractly emphasizes appropriate “resources” and mentions responsibilities and accountabilities—provides no guidance on a structured approach to effective team development. ASPICE features some 200 BPs but misses the forest for the trees: the fundamental intrinsic team motivation. A lack of personal “buy-in” from the team, which suffers from the inherent redundancy of “carbon copy” methodologies and a lack of focus on practical project contributions, is the Achilles’ heel of ASPICE-based projects. Misaligned responsibilities and accountabilities can lead to a leadership vacuum and a “not-my-job” mentality.

The lack of “buy-in” cannot be fixed by imposing ASPICE compliance through recurring, formal assessments; it is the proverbial “spanking that continues until morale improves.” Well-educated and trained engineers know what needs to be done. They must be allowed to do so to maintain the team’s intrinsic motivation and ensure a well-understood purpose for the system under development.

CORE SPICE’s effectiveness accelerators

Since R&D (research and development) projects have the flexibility to shape the project “triangle” of quality, speed, and scope (see, e.g., here), CORE SPICE primarily focuses on “Made-to-Order” (MtO) projects (see the article The Right Genes for Your Project for the explanation of the project typology). CORE SPICE helps prepare a transition from R&D to the MtO stage, but this transition is not the focus of this article. The CORE SPICE coaching approach emphasizes strong team involvement. The team is encouraged to take ownership of their work, a critical factor in the success of MtO projects. The Team Capability Coach (TCC) plays a central role in the CORE SPICE MtO framework. It emphasizes a shared sense of urgency and a quality-focused mindset. Through hands-on coaching, CORE SPICE addresses the “buy-in” challenge directly, making quality and development speed everyone’s responsibility. By following CORE SPICE’s clear principles, teams stay focused and energized, which supports efficient and cohesive project delivery.

The following measures for project speed and quality help the team to focus on effective project velocity:

1. “No task left behind”—own your task
2. Maintain the sense of urgency—there is no time like “now.”
3. Establish the principle of “end-to-end responsibility”
4. Constantly assess the team
5. Automate everything

Measure 1: “No Task Left Behind.”
Whenever a project member identifies a critical risk (e.g., a missing requirement or a design flaw), it automatically becomes a task “owned” by the task creator until the issue is resolved or effectively assigned to the engineer who can address it more efficiently and effectively. This must always involve an explicit “handover” agreed upon bilaterally to avoid the “throwing the problem over the fence” syndrome. While risks must be taken in fast-paced automotive projects, those risks should be either resolved or reduced, so that such problems won’t “blow up in our faces” at a critical project phase.

Corollary to Measure 1: Creating a task in the issue management system (e.g., JIRA) alone does not resolve the issue; instead, it adds to the overall workload—an ever-growing “backlog” of owner-less (or even entirely redundant or abandoned) tasks. It initiates a sequence of steps that must be tracked, managed, resolved, reviewed, and closed. Managing tasks in an issue management system is expensive; creating a “ticket” must have the consequence of monitoring and reviewing the final result for the ticket creator. A good rule is to establish the “what goes around, comes around” principle: when users create new tasks, they will eventually have to deal with them. That negative cybernetic loop helps reduce the number of tickets that otherwise mushroom to an unmanageable dimension during the project lifecycle.

Measure 2: Maintain the sense of urgency.

The phenomenon of work that was initially planned optimistically but then fills out the time buffer and eventually causes schedule overruns is a pattern well-documented in the planning fallacy literature (see Kahneman and Tversky [3]).

Once the “buffer” is established, it is primarily consumed by other activities. Thus, the task is being delayed, and when it is finally addressed, unexpected obstacles arise, which naturally delay the entire task and result in missing the original deadlines.

This conundrum cannot be resolved by “better planning”—it is simply unrealistic to have a waterfall planning approach where the project scope is a stable figure from project start to SOP. However, it also cannot be resolved by just being “agile,” either, which, in reality, frequently means a mindset in which the project scope is subject to arbitrary changes. This is never acceptable in the automotive business (see the “CAR IT Reloaded” [2], Chapter 5 and 6, for more details on this issue).

In our industry’s experience, delayed tasks are addressed by raising the level of urgency, usually facilitated by calling for a joint “surge,” also called “task force” or “bootcamp,” which enforces pragmatic measures to resolve late tasks.

CORE SPICE philosophy is that every MtO development project is already a “task force” without being called that. TCC’s task, among other responsibilities, is to ensure that this high level of urgency is upheld as long as substantial project risks remain unmitigated or poorly addressed, which usually means that it remains in this state until SOP.

Measure 3: Establish the principle of “end-to-end responsibility”

Team fragmentation and silo thinking are typical project anti-patterns, which are exacerbated by naively implemented ASPICE-induced processes. In such settings, different persons handle tasks throughout an implementation cycle. This might be inevitable or even desirable, as it is a good practice for a requirement not to be implemented and verified by the same engineer. However, it can also lead to an exponential multiplication and fragmentation of tasks in the issue management system (like JIRA). For instance, separate tasks may be created for customer requirements approval, another for systems-level requirements, and for systems architecture, as well as further tasks to handle software requirements approval, software architecture approval, and software implementation. In extreme cases, different tasks are created and maintained by other engineers to identify, analyze, review, and approve the exact requirement. On the right side of V, those tasks are often duplicated at least. Thus, for one customer requirement, dozens of tickets (tasks) are created, maintained, and resolved by multiple engineers, which poses “friction” costs that can lead to significant financial “waste”—not to mention the cost of demotivating the team due to the resulting “process management.”

To minimize the “handover” and reduce responsibility fragmentation in the project, a “feature-oriented” approach should be established. In such cases, a chunk of customer functionality is defined as a “feature.” A “feature owner” is a cross-functional person responsible for ensuring that a portion of customer requirements (“feature”) is managed by the same person from inception until its final verification (thus “end-to-end”). Each feature owner acts as a project lead for a specific portion of the functionality, e.g., “active steering safety manager,” and reports to the Project Lead within the project organization. This reduces responsibility fragmentation. For instance, in a feature-owner approach, it is not crucial whether an engineer is a “software” or a “system” engineer. Such an engineer is responsible for supporting the implementation of the feature across all disciplines, rather than focusing on “discipline-bound” tasks.

Measure 4: Constantly assess the team

This measure is as easy to grasp as it is “politically” difficult to enforce. The Project Lead and TCC must constantly monitor team activities to ensure everyone contributes to the project’s success. If the Project Lead and TCC agree that a project member proves to be ineffective in relation to the project’s mission, a swift replacement is necessary. Keeping unhappy and ineffective team members on the team demotivates the rest; thus, such a situation must be addressed immediately. A “pooling” principle, as described in our book “CAR IT Reloaded” ([2], Chapter 5) may be the organizational solution to this issue.

Measure 5: Automate everything

In every project, the team must perform repetitive tasks that, at least after the initial stage, become tedious, monotonous, and frustrating. Every project activity must therefore be automated as effectively as possible. Examples of such repetitive activities could be:

• Creating a peer review for a software component
• Creating links between different elements across the V, like links between software components and software units or test cases.
• Generating standardized project status reports
• Compiling and updating traceability reports
• Running routine regression tests
• Compiling and archiving documentation for compliance audits

Those activities are often mechanical and intellectually unappealing to highly trained engineers. The “Project Tool Engineer” role (as described in CORE SPICE) must be established from the very beginning of the project, which will automate such tasks and reduce the burden on the development team.

These measures are a substantial part of the CORE SPICE mindset. Their advantage lies in acknowledging that automotive product development (particularly MtO projects) is inherently non-deterministic. The project “triangle” is exceedingly inflexible in our industry for several reasons (see Chapter 6 of our book, CAR IT Reloaded [2], Chapters 4, 5, and 6). It can rarely be controlled by negotiating a modified project scope (as the customer seldom accepts it), and it cannot be tamed by enforcing dogmatic obedience to assessment models. Only a systemic approach like CORE SPICE addresses the essential aspects and challenges in complex automotive MtO projects (see the 12 CORE SPICE Principles and ECST—effective critical systems thinking for details).

Applying these five coaching measures revitalizes a project, significantly increasing the likelihood of its success.

Make it happen

CORE SPICE is a straightforward coaching concept inspired by industry needs for compliance, such as ASPICE, ISO 26262, and ISO 21434. There are hundreds of other regulations and standard specifications that an automotive product development team is expected to follow. Most of them are contractual obligations that should be taken seriously—not for the “standard’s” sake, but for the safety and security of the product in development.

The automotive industry has little need for further and more complex regulations and mandatory standards. Time is running out as the electric vehicle breakthrough has intensified competition, demanding rapid innovation. CORE SPICE is a coaching concept that emphasizes the actions required to deliver high-quality products efficiently. Its measures enhance development velocity and product quality, supported by the critical role of the Team Capability Coach. We believe that only true leaders will retain a competitive edge in this fast-paced industry. Those who succeed will shape the future of automotive innovation, and CORE SPICE empowers to lead that transformation.

[1] NATO SOFTWARE ENGINEERING CONFERENCE 1968
http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF

[2] Car IT Reloaded, 2025
Springer Vieweg Wiesbaden, https://link.springer.com/book/9783658476908

[3] “Intuitive Prediction: Biases and Corrective Procedures.”
TIMSS Studies in the Management Sciences, D. Kahneman & A. Tversky

Let’s start a conversation on LinkedIn or X.com (formerly Twitter).

Remember Marc Andreessen’s line about software eating the world? Today, the “software” hype has been replaced by the new “AI” hype.

The amount of money that is being spent on AI solutions is genuinely staggering. Worldwide corporate investments in AI are assumed to have reached at least 150 billion dollars annually. The cumulative global investment in AI has probably crossed 1 trillion US$—and yet, it appears that all we get is fluffy cat videos and creative images. Popular generative AI tools like ChatGPT and co. can generate images, music, videos, charts, and more.

However, the results—while entertaining—are still limited to non-deterministic content: the outcomes are often surprising and creative, but they don’t have to be “correct.” Correctness, however, is what is desperately needed: only correct results are accepted in real-life corporate and legal settings. Sometimes, a single wrong figure in a presentation can ruin your day—or even your entire professional career. Especially in large, bureaucratic organizations, correctness is the be-all and end-all of daily business.

Before the generative AI boom, I assumed that genuine creativity—or at least what most of us accept as such—would be the very last victim of AI devouring the world. I was wrong. Quirky presentations, a catchy tune, or a viral meme? AI delivers, often better than a room full of brainstormers. Content generated by LLMs is fun, flashy—and arguably cost-effective (which is a euphemism for “cheap”). Artists, writers, marketers, etc. appear to become disposable. Those roles could eventually disappear as generative AI pumps out endless variations on demand. It may be “cheap” (as assumed here), but it can pass as “good enough” for a vast number of creative tasks.

Here is the thing: AI excels at creativity precisely because creativity usually doesn’t demand correctness (a.k.a. “accuracy”). Funny cat videos are always, well, funny and entertaining, but let’s take a closer look at a task that is on the opposite end of the creativity spectrum: a tax accountant. Everyone (well, most people who create any commercial value, at least) must pay taxes. In most developed countries, the tax code is overly complicated. A simple limited company (e.g., a German GmbH) must obey dozens of often confusing rules and regulations. A small business can’t run without an exceedingly expensive tax advisor. There are no shortcuts; any deviations from the strict tax code can cause trouble or even land one in jail.

The AI industry is admittedly struggling with “AI reasoning.” The reason for that is that generative AI is not intelligence; it is simply a brute-force extrapolation of the training data that can only approximate the data used to train LLMs. LLMs arguably offer nothing in terms of reasoning. They can smell like it, sound like it, walk like it, look like it—but they cannot actually reason, no matter how much data is thrown at a multi-layer neural network.

Tasks requiring “correctness” can be nearly impossible to solve using brute-force heuristics like LLMs. A disruptive innovation in LLM use could involve combining LLMs with reasoning models. I am convinced that many companies and computer scientists are working on such innovative hybrid “reasoning AI models,” but—at least as of this writing—there is no sign of any such innovations to be seen.

That’s a frustrating state of AI affairs: a correct tax advisor that could replace a German tax consultant who could run even a small German GmbH is nowhere to be seen. All tax advisors I have asked whether AI can replace them soon keep laughing at me: “No way, not anytime soon” is their usual response.

We have to accept that generative AI is not intelligent at all. It is funny, helpful—but not smart in a human sense. The entire discussion about “AGI” (artificial general intelligence) seems to be a smoke screen for the NVIDIA investors.

As long as AI is not correct, it cannot be called “intelligent.”

Alan Turing thought that a “Turing Test” could prove intelligence if an AI entity could not be distinguished from a human being. My impression is that a generative AI agent can fool a human into thinking that an AI entity (e.g., an AI phone agent) is a human. To me, it does not prove much. The real “Post-Turing Test” should be able to reason correctly without the usual AI “hallucination” from which all generative AI tools suffer.

A “correct” AI entity that can pass the “Post-Turing Test” and act indistinguishably from a trained and experienced tax advisor is currently not in sight. It may happen sometime around 2030. Until then, we will continue enjoying AI-powered cat videos and see how long big tech can sustain throwing billions and trillions of dollars at ever more complex LLMs.

Let’s start a conversation on LinkedIn or X.com (formerly Twitter).

Artificial intelligence has exploded like a virtual H-bomb, leaving a mushroom cloud of hype in its wake. But here’s the uncomfortable truth nobody wants to admit: What we call “artificial intelligence” is neither artificial nor intelligent. It’s essentially a sophisticated human-made pattern recognition system with some degree of self-modification and a notorious inclination to hallucinate.

The Blabbermouth Revolution

Ever since ChatGPT became mainstream, everyone has started using it because it can produce endless streams of content at a low cost. The problem with this new digital toy is that it is little more than a digital blabbermouth—the equivalent of that person at every party who can talk about anything but actually knows nothing. Current large language models are like such ennoyingly eloquent individuals with pathologically loose tongues, capable of generating confident-sounding responses on virtually any topic—without any actual comprehension.

And yet, these increasingly popular systems have found their perfect niche. They excel at tasks that nobody really wanted to do in the first place—those “bullshit jobs” that anthropologist David Graeber wrote about. LLMs have become the miracle cure that helps you maintain your workplace sanity while doing essentially nothing productive. They’re the ultimate enablers of busywork, which helps create an endless stream of content that nobody actually wanted in the first place.

The Economics of Fake Intelligence

Here’s where basic economics kicks in. Now that everyone is using these tools, the free market mechanism becomes apparent: since this kind of “AI” is cheap, the results are also cheap. If something is easy to get, it automatically becomes worthless. “It’s the economy, stupid” all over again.

Thus, no matter how much it is hyped and glorified as the supposedly greatest innovation since sliced bread, LLMs might become virtually useless after all. Easy come, easy go. Just think for a minute (and you can still get it right without asking your favorite chatbot): When everyone can generate a thousand-word essay in thirty seconds, what’s a thousand-word essay worth?

For What It’s Worth

We might assume it’s easy to distinguish between LLM-generated and genuine human content. I think most of us still have this ability. However, there is a long-term, subtle effect that is likely to occur gradually, perhaps too slowly to spot it: We will likely witness a “convergence crisis.” The new generation is growing up with LLM-generated content. They could actually stop learning anything else because genuine content will be too expensive. To them, this artificial output is the “real thing”—the mental baseline for what writing, thinking, and creativity are supposed to look like.

The older generation, which can still distinguish between artificial and authentic content, will diminish. Ironically, the older generation—those who remember what genuine human thought and creativity looked like—may become the proverbial one-eyed among the blind. They will retain a form of literacy that is becoming increasingly rare: the ability to recognize authentic human intelligence when they see it.

This “convergence” won’t happen overnight. It will likely take decades for LLMs to become sufficiently advanced to be truly indistinguishable from human output. But the cultural damage is already eroding the way we think and what we perceive as “normal.” We’re training an entire generation to accept mediocrity as excellence, to mistake pattern matching for thinking, and to value quantity over quality.

There’s no such thing as a free lunch. Cheap content—while nearly free—will have its price eventually. That price is the erosion of critical thinking.

The Value of the Authentic

In this digital ocean of infinite, worthless content, only original ideas, authentic creativity, and genuine human insight will likely retain value. The irony of AI conquering the world is that, in creating a system that enhances human intelligence, we have made natural intelligence more precious than ever.

This kind of genuine, human-value-based approach may become scarce. The future belongs not to those who can generate the most content, but to those who can still think original thoughts. Those “old-fashioned” thinkers will still be able to recognize the difference between the real and the artificial. In a world drowning in digital blather, silence and authenticity become revolutionary acts.

The AI revolution promised to extend human intelligence. Instead, it may have created the ultimate test of whether we can preserve what makes us genuinely human in the first place.

Let’s start a conversation on LinkedIn or X.com (formerly Twitter).