Automotive testing is broken

Automotive testing is broken. Not failing quietly at the edges — structurally broken, in the way a method breaks when the thing it was built for stops existing. The V-model, the requirement-by-requirement trace matrices, the armies of engineers hand-assembling ASPICE evidence: all of it was designed for a car that was mostly metal, with software bolted on. That car is gone. What replaced it is a computer that happens to have wheels, and the way we verify it never made the jump.

I spent years inside that world — writing requirements, tracing them, sitting in the assessments where the compliance evidence gets torn apart line by line. This is the honest version of why the traditional approach is buckling, why it is not a tooling gap you can patch, and where the bridge to something that actually works is being built.

What the V-model was actually good at

It is worth being fair to the V-model, because it was not stupid — it was right for its era. Its core assumption is that you can specify a system fully up front, decompose it top-down, then verify your way back up against that fixed specification. For a braking system that is machined, tested, and frozen, that is a genuinely good model. The specification is stable, the states are countable, and a human can hold the whole trace in their head and on paper.

The V-model treats verification as a phase — something you do on the way back up the right-hand side, against requirements you nailed down on the way down. And it leans, entirely, on people to keep the links alive: this requirement maps to this design, to this code, to this test, and here is the paper that proves it. In a slow-moving mechanical world, that is affordable and it holds.

What broke it

The software-defined vehicle broke every one of those assumptions at once. When the logic is the product — when features ship as over-the-air increments, when the same hardware behaves differently every quarter — the specification is no longer something you finish and freeze. It is a moving target. And the number of states, interactions, and edge cases stops being countable by a person.

• The spec never freezes. A model that assumes a complete up-front specification cannot verify a system that ships in weekly increments. You are always verifying against yesterday.
• Complexity outran human bandwidth. The interaction space of modern vehicle software is combinatorial. No amount of diligent engineers hand-enumerating test cases keeps pace with that growth — the gap widens every sprint.
• Verification is continuous now, not a phase. In a software-defined vehicle, assurance has to be a property you hold all the time, not a gate you pass once. The V-model has no natural place to put that.
• Traceability became a moving job, not a fixed one. The links between requirement, code, and test — the heart of ASPICE — used to be built once and audited. Now they have to be re-established every time the code moves, which is constantly.
• The paperwork ate the engineering. More and more skilled hours go to producing and re-producing compliance evidence rather than building or genuinely verifying the product. That is the tell that a method has outlived its fit.

The V-model did not fail because it was wrong. It failed because it was answering a question — "does this finished thing meet its frozen spec?" — that a software-defined vehicle never stops changing the answer to.

The part almost nobody prices in: the cost of doing it by hand

Here is the piece I know best, because I lived on the receiving end of it. ASPICE, done the traditional way, is a monument to human hours. Every requirement written by a person, traced by a person, cross-checked by a person; the audit trail assembled and re-assembled by a person, every time the system moves. On a serious program that is thousands of hours of skilled engineering work that produces no feature — only proof that the features are sound.

That was tolerable when software changed slowly and margins were fat. It is not tolerable now. When the code ships continuously, keeping the compliance evidence current by hand stops being a one-time cost and becomes a permanent, compounding tax — an entire class of engineers whose full-time job is to keep the paper synchronised with reality. In my experience that hand-assembly is one of the largest hidden costs in a modern automotive software program, and it is almost never named out loud.

The bridge: verification and evidence at machine scale

The way out is not to test less or to care less about ASPICE — the assurance is not the problem, the manual production of it is. The bridge is to separate the two things the old model fused together: human judgment and mechanical bookkeeping.

The mechanical part — maintaining traceability links as code moves, checking consistency, assembling and continuously updating the evidence, flagging where a change has left a requirement unverified — is exactly the kind of work that can now be done at machine scale by AI-assisted tooling. This is the thesis behind what we are building with Vera: not to replace the assessor's judgment, but to take the hand-assembly of ASPICE evidence off the humans and let the tooling keep it current while the code keeps moving.

The human still owns the hard calls — what to verify, how much assurance is enough, how to read an ambiguous requirement, what a gray-area finding means. That judgment is not going anywhere. What is going away is the idea that a person should be the one manually re-stitching a trace matrix at two in the morning before an assessment.

What this signals for anyone building or selling into automotive software

If your work touches this world — as a supplier, a tool vendor, a founder, an engineering leader — the breaking of the old testing model is not background noise. It changes what buyers value and what they will pay for.

1. The budget moves from "more test engineers" to "less manual compliance." A program under margin pressure will not fund ever-larger armies to hand-maintain evidence. It will pay for anything that provably takes those hours out.
2. Assurance still can't be compromised. Cost-out that lowers real safety confidence is a non-starter in automotive. The winning message is same rigour, machine scale — not cheaper, weaker testing.
3. Proof beats pitch. Buyers under this kind of pressure discount claims and reward evidence. "Here is the trace matrix that stayed current through a full sprint cycle" outperforms any feature list.

And there is a positioning lesson underneath the industry one. The people winning attention in this market are the ones naming the structural truth out loud — "automotive testing is broken" — instead of politely selling around it. Saying the true, uncomfortable thing that insiders already feel is what makes them stop scrolling and recognise their own reality.

Why this post landed — the anatomy

The argument above started as a single LinkedIn post — three words, "Automotive testing is broken" — that resonated hard across the automotive engineering world. It was not luck, and it was not reach-hacking. It followed a repeatable structure that any technical founder can copy to build pipeline and credibility with VCs and OEMs. Here is the teardown.

• The hook is one blunt, true claim. "Automotive testing is broken." Three words, zero adjectives, and the thing every engineer in the field has thought and no one says in public. It works because it is unambiguously extractable and, to the people living it, unambiguously true — that is what makes them stop and read.
• The structure is claim → why it worked → what broke it → what it means. One blunt assertion, then a fair account of what the V-model was good at, then the specific thing that killed the fit, then the consequence for the reader. That arc keeps a skeptical technical audience reading past a provocative hook without a single clickbait move.
• The specifics are named and unhedged. The V-model, ASPICE traceability, the software-defined vehicle, the hand-assembly of evidence — concrete, industry-exact terms, no "some may find friction." Precision is the credibility; the people who live it recognise the exact pain and that recognition is what makes them comment and reshare.
• The point of view is earned, not borrowed. "I sat in the assessments where the evidence gets torn apart line by line." Insider authority beats outside analysis every time — it is the difference between commentary a VC scrolls past and commentary an engineering leader forwards to their team.
• The restraint is the multiplier. No link in the body, no CTA, no "DM me." Pure value, let recognition do the work — the funnel link lives in the first comment. A post that asks for nothing gets shared; a post that sells gets skipped.

Virality on engineering-grade content is not volume or luck. It is a true, uncomfortable, specific claim, told with earned authority, that lets the right people recognise their own reality — and then raise their hand.

The recipe: recreate this for your industry

This is the copy-paste part. Drop these prompts into Gemini or Claude, swap in your sector, and you have the same structure working for your own pipeline. The visual step is where most people leave value on the table — do not skip it.

1. Find the story. "You are a veteran practitioner in [my sector]. List 5 things the industry has always done a certain way that are now visibly breaking — a method, a process, a ritual everyone knows. For each: what it was good at, what changed, and why an insider would nod instantly. Rank by how many people in the field would recognise the pain immediately."
2. Write the hook. "Turn item #1 into a single blunt opening line: a plain declarative, under 8 words, zero adjectives — the true thing everyone thinks but no one says. Give me 5 variants."
3. Build the post. "Write a LinkedIn post using this arc: blunt claim → why the old way genuinely worked → the specific thing that broke it → what it means for [my ICP]. First person, insider POV ('I spent years in…'), named specifics, no hedging, no CTA, no link in the body. 180–220 words."
4. Make the visual value drip. "Here is a real artifact from my field — a V-model diagram / a trace matrix / a test report. Using image editing, annotate it like a marked-up working page: circle the breaking point in coral, hand-draw an arrow to the gap, add one short margin note in my handwriting-style font. Keep it looking real and captured, not like a slick data-viz card." A marked-up real artifact outperforms a designed graphic because it reads as lived evidence, not marketing.
5. Place the funnel link in the first comment — never the body — with your UTM parameters, so the reach compounds into tracked pipeline instead of leaking away.

Where this sits

The way to win in a market this far into transition is to say the true thing clearly and let the people living it raise their hands — then work the ones who do. That is the core of the software-defined vehicle reality check, and it is the same structural squeeze that is forcing German auto suppliers into record losses. The mechanics of turning that recognition into pipeline are in turning LinkedIn engagement into B2B pipeline. If you sell into the industry specifically, see GTM for automotive-software founders.

FAQ

More on the engine behind this content: the loop — ingest, publish, mine, extract, reconcile, re-steer. One flat price, we ran it on ourselves first.