It covers:

• The twelve CORE SPICE principles
• The reference Team Chart, with the Team Capability Coach (TCC), the Project Tools Engineer, and the Feature Owner (new since “Car IT Reloaded”)
• The thirteen Approaches with their default owners (down from fourteen originally)
• The five Effectiveness Accelerators
• How to run an effective Kickoff

Feel free to download and share it. Printed copies are also available. Message me if you’d like one.

The full story is in the book CORE SPICE: Delivering Safety-Critical Projects Under Pressure (Springer, April 2, 2027): https://link.springer.com/book/9783032430502

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

AGI (Artificial General Intelligence) seems like the ultimate goal of AI development, yet nobody seems to agree on what “AGI” actually means. The industry pushes on regardless, and the machines will soon be good enough for 99% of the work. The last 1% is human judgment—and that judgment is inherently non-deterministic. Deciding what is “correct” versus “incorrect” is becoming a scarce skill, because AI threatens the very existence of human expertise.

Intelligence is in the eye of the beholder

What “intelligent” means may appear undisputed, but popular opinion varies. The roughly 230-line chatbot ELIZA was created in 1966. It was a super primitive script that simply kept asking the user open questions, and that already felt magical enough to appear “intelligent” to some. I remember some users talking to this primitive chat script for hours, finding joy and relief in essentially talking to themselves. For nearly everyone else, ELIZA was obviously not “thinking.”

And yet, the idea of having a machine to talk to was groundbreaking. It opened the can of “chat” worms. After all, the idea of the “Turing Test” was that, if a machine can appear to act, talk, and seemingly “think” intelligently, it would be officially “intelligent.”

Is the “Turing Test” a good indication of intelligence? In a 2025 study, GPT-4.5 with a persona was judged to be human 73% of the time. Hilariously enough, ELIZA scored 23% (!). Turing would give GPT-4.5 an A+ for artificial intelligence.

That means that in 73% of the cases, humans thought the machine was actually human. With LLMs advancing at such a breakneck pace, soon most of us won’t notice the difference between an AI and a human during a phone conversation.

Hundreds of billions are being poured into a technology with the ultimate goal of delivering AGI—but even some once-fierce proponents of AGI, like OpenAI and its partner Microsoft, quietly removed the AGI clause from their contract altogether in April this year.

It looks like the experts will probably never agree on the term AGI, or on what it really means. “Intelligent,” in the end, is a human-based verdict—and people’s opinions are volatile.

Why AI expert systems failed to deliver

In one of my favorite books on human expertise, Mind over Machine, the authors (the Dreyfus brothers) argued that experts don’t just follow rules—they act immediately based on patterns from experience. Only beginners must follow the rules—experts “just know” them without even thinking about them. The authors cite driving as an example: a beginner must be aware of each lever, switch, pedal, complex traffic rules, etc. After driving for a long time, the driver no longer notices acting on rules. We just “drive.” We become experts at driving a car.

Which brings us to the core issue of “intelligence”: human experience and the meaningfulness of a rule-based worldview. I am a technologist, and logic is a well-established part of computer science. However, we must still accept that, in everyday life, things that are commonly viewed as “logic” are often not, well, particularly “logical.” For instance, law and the tax code look deterministic, but they are full of terms like “reasonable,” “appropriate,” “ordinary and necessary.” That is intentional: the law must be interpreted, and “common sense” is expected—which is also why people go to court at all, because we have different opinions on what “common sense” means. That’s also why—until those law books are rewritten to be deterministic—lawyers and tax advisors feel immune to AI eliminating their jobs. Just think about it: if law is supposed to be logical—why does a good closing argument often decide whether a lawsuit is won or lost? Purely logically, that makes no sense. And yet, here we are.

In the eighties, “expert systems” were supposed to automate law and tax code. Those systems were based on strict logical clauses. In 1986, researchers at Imperial College London turned the British Nationality Act into a logic program. The same year, the accounting firm Coopers & Lybrand introduced ExperTAX, an expert system for corporate tax planning. I still remember the hype: expert systems were “it.” And yet the lawyers and tax advisors are still here because expert systems failed to deliver on their promise. Sometimes, strict logic doesn’t count for much, after all.

The functional safety standard ISO 26262 rests on the same kind of judgment-based principle. Safety is the “absence of unreasonable risk,” and unreasonable risk is “risk judged to be unacceptable in a certain context according to valid societal moral concepts” (see ISO 26262-1). In my view, this kind of “fuzziness” is the greatest weakness of such standards, and it will remain unresolved for a long time. To exaggerate the point: what is reasonable on Monday may look different on Tuesday, because nobody decides outside a social context.

That’s also why assessors are, in a way, like consultants: two questions—three opinions. Some assume an automated assessor won’t be around anytime soon.

How do we decide what can be automated and what possibly can’t? That’s a great, unresolved dilemma.

“The judgment day”

The human judgment vs. machine dilemma becomes clearer when we look more closely at the current discussion about the safety of self-driving cars. Elon Musk bets that a car can be driven autonomously with cameras alone. Most industry experts disagree; they insist on multiple sensors in addition to vision, such as radar. Waymo’s robotaxis have so many external sensors that they look like experimental test rigs on wheels. The current Waymo generation carries 23 of them—13 cameras, 4 lidars, and 6 radars—while a Tesla Model Y makes do with eight cameras.

So, reluctantly, it all comes down to statistics.

The statistical argument: Tesla claims about 7x fewer major collisions with FSD (Supervised). The sharpest critic arrives at about 1.8x on a like-for-like comparison. Is FSD now “safe enough” to be activated on all roads?

If these numbers hold, FSD means fewer people get hurt; thus, one could argue that approval should be mandatory on statistical grounds. The German Ethics Commission said as much in 2017: licensing is not justifiable “unless it promises to produce at least a diminution in harm compared with human driving, in other words a positive balance of risks.” Thus, statistically, it sounds like approval should be imminent.

And yet, statistics is slippery ground, because here is the caveat: Tesla’s published numbers count collisions, and they include the supervising driver. That means the human driver’s corrections are mixed into the statistics. Again, a statistic is only as good as what it counts and how it was counted, which is the whole point.

To make it more complicated, the functional safety standard ISO 26262 is also all about statistics: it defines exposure and controllability classes in the hazard analysis. It sets a target of less than 10⁻⁸ per hour for a safety-goal violation from random hardware failures at ASIL D, but the math still requires judgment. In theory, FSD seems viable—but it might feel insufficient. Are we talking about “feelings” now?

With a self-driving option, a car would have to make life-altering decisions in a split second: are we ready to delegate our lives to a machine?

On purely statistical grounds, systems like FSD should be not only approved but even “strongly recommended.” A positive balance of risks means the machine will kill people a human driver would have spared, while sparing more of the others. This is a terrible decision to make—and I can clearly see why many of us are reluctant to accept the trade-off.

So, going back to the argument: is a vision-only, autonomous system “safe enough”? ISO 26262 does not prescribe more sensors, so we added yet another standard: SOTIF, ISO 21448. According to SOTIF, the safety of such systems depends on sensor performance. Sometimes it seems that, whenever regulators feel uncertain, their “escape” option is more regulations, which must be interpreted and—once again—demand even more human judgment.

Curiously, entire countries seem to have different opinions on what “safe” is. The Dutch regulator approved FSD (Supervised) in April 2026, and seven more of the 27 EU states have since recognized the approval (German officials are still reviewing it—and so are the EU regulators).

The lengthy FSD approval process reinforces that human judgment in critical design decisions is not going away anytime soon.

How long will the human remain “in the loop”?

The quality of AI-generated results keeps improving. LLMs hallucinate less and reason more. One day, they may be good enough for 99% of “real-life” cases. For that 1%, the final decision will likely remain human for many years to come.

But here is the catch: if human judgment is so critical, the mere availability of experts is a critical condition. Becoming an expert in a technical domain can be a very lengthy process. Judgment must be experience-based—it cannot be codified in some kind of “how-to” manual. An expert becomes an expert only by practicing the basic work for an extended period. The Dreyfus brothers defined five stages in their book, from novice to expert. If coding, testing, and reviews are automated, and no human ever spends time practicing those skills, there is no “expert ladder” to climb. In other words: jumping from 0 to 5 on Dreyfus’s “expert” scale will—once seasoned engineers have retired—never happen, because, one day, no human with sufficient practical expertise will be available anymore.

It sounds like a theoretical concern, but evidence suggests that once “spoiled” by extensive AI use, humans lose the ability to understand their subject matter. The evidence: Doctors’ detection rate without AI fell from 28.4% to 22.4% after months of working with it (link). If this trend continues—and there is no reason to doubt it—we could soon become hopelessly dependent on imperfect AI systems. In that case, no one will be left to judge—the AI will have to take over.

Translated into the world of assessments in technical domains: who will be able to assess safety designs in 2040 if nobody wrote requirements, reviewed code, or designed test specifications?

Human judgment is a fragile good

The idea that “a machine will never do XYZ” usually doesn’t age well. Chess, Go, and even the Turing test did not survive the confrontation with digital reality. Hubert Dreyfus himself lost to a chess program in 1967.

AI becomes omnipotent in many ways. Whether the result deserves the name AGI will remain debatable. In social contexts, people hand down the verdicts “intelligent,” “reasonable,” and “safe,” and an “expert” must sign the safety case, the tax return, the type approval, etc. And yet, the walls are closing in. Machines already decide more than we might realize. For example, the ABS braking system decides automatically how to apply the brakes in critical situations. Automatic emergency braking, now mandatory in new cars in the EU, goes one step further: it hits the brakes without asking the driver. Credit scoring is also fully automated—these are rule-based systems, but AI-powered creditworthiness systems already exist (such as Upstart, which reports that 91% of its loans are fully automated). Even in medicine: back in 2018, the FDA authorized the first AI system that makes a screening decision without a doctor looking at the image. Some of these are deterministic systems, some are already AI-based, and once they are in place, the human is out of the loop.

ISO 26262 and similar standards require human judgment and are thus, at least partially, safe from AI automation. For how long? For as long as a human expert has to sign the safety case and be accountable for it.

Final destination

“Automating everything” is a goal that may never be achieved—at least not in our lifetime—because people will simply never hand over all critical decisions to a machine. “Mind over machine” remains a valid and noble goal. “Machine over mind” must never happen—and probably never will.

Machines will not take over because we won’t let them. The latest LLMs are becoming very effective and hallucinate less and less, but they can’t properly “judge”: judgment—as in the case of the tax code—will not be fully automated anytime soon. A machine can’t judge the validity of an ISO 26262 safety case. In such contexts, humans remain responsible, accountable, and in charge.

Dreyfus’s expert ladder must be kept alive. Skill fades when it is no longer practiced, sometimes within months. Thus, the remedy is to keep practicing. In some disciplines, it is OK for the AI to draft a document, but a human engineer must decide on its validity. Junior developers will have to learn at a higher level. However, they still need to inspect critical ASIL D code line by line, even if it is LLM-generated, and defend the judgment under the supervision of a senior expert.

To preserve substantial judgment skills in such disciplines, engineers must force themselves to write code manually every few weeks, or write a requirement, a design (which probably won’t be AI-automated for a long time), or a test specification without the machine. That costs a few hours per engineer per month, but that’s the price for still having assessors, safety managers, and chief engineers in 2040.

Dreyfus’s expert ladder will still work—although expertise may be built very differently than in the past. Tomorrow’s experts will write less and judge more, and judging was always the hardest part of the job to learn. Whether the machines of 2040 deserve the name AGI is a question the experts can keep arguing about. It doesn’t matter much whether it’s called “AGI” or not; the safety case will still need human expert judgment.

To paraphrase Mark Twain: reports of the death of human expertise have been greatly exaggerated.

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

The narrative has been hammered into our brains so hard that it feels like common sense: Legacy car makers are just too slow to compete against BYDs and Teslas in this brave new automotive world.

Undeniably, “China speed” has now become part of our basic vocabulary. And it’s arguably a commonly accepted fact that 4 or 5 years to develop a new EV is just way—by an unacceptable margin—too slow.

Times are a-changin’ now—at China speed, no less

We have grown tired of hearing excuses such as “China’s cars are just beta” and “Tesla is apparently evil because it’s just too capitalistic.” That doesn’t change anything: if it takes more than 2 years to design a new car, it arrives too late to be successful.

But while legacy car makers are struggling to speed up, Chinese authorities have recently warned China’s car makers that cheap-and-fast is unacceptable. Cranking out new models every few months has its price: insufficient validation, which leads to field defects and safety concerns. In other words: “China speed” is just too speedy for its own good, and it threatens to ruin BYD’s & co.’s reputation.

A different kind of “China speed” is happening, too. China’s carmakers are going through the shakeout the U.S. went through a century ago—only three times faster. At the peak of the automotive frenzy in 1909, there were 272 carmakers in the U.S. alone. By 1941, only 9 were still around. Similarly, there were around 300 Chinese EV makers in 2021. By 2025, about 130 EV brands remained. It is reasonable to expect 10–15 left in 2030. The Chinese car maker shakeout is going through the same cycle the U.S. industry went through 100 years ago—only it’s happening 3x faster now. That’s China speed, too.

The bottom line: we may be at the bottom right now. In the proverbial dungeon of despair and industrial decline, there is a light at the end of this automotive tunnel.

The Japanese speed

Literally everyone is complaining about the slow pace of automotive platform development, and there are many ideas for how to speed it up. Recently, Suzuki’s CEO announced that development will drop from 40–48 months to 24 by 2030. “Chinese manufacturers have incredible speed. To keep up, we need to figure out how to move faster,” he said. Other carmakers announced similar bets: Nissan has already gone from 50 to 37 months (the new Skyline took 26). Renault built the Twingo in 21 months. VW PEP 36: “36 months or less.” BMW: 40+ derivatives from Neue Klasse by 2027.

But how to really make it happen?

A digital helping hand?

Here is the secret sauce that nearly all OEMs use to speed up the cooking (or, on a serious note, development) process:

• Parallel work
• Early supplier involvement
• Digital twins
• Shared platforms
• Fewer decision layers
• AI.

Some of those ingredients really work. For instance, AI-powered tools help develop/draft requirements, derive test cases, and accelerate repetitive tasks (proof-of-concept demo here: https://github.com/CORE-SPICE/DOORLOCK_DEMO). What it still cannot do is make substantial decisions and automatically inspect ASIL D code. Let alone develop a good system design. It is not “intelligent”—but it is very helpful, regardless of our personal view of LLMs and doomers’ AI panic-mongering.

AI can do a lot—for example, LLMs can develop useful test cases from specifications—but it cannot fully validate the design, at least not autonomously. The realization that “China speed” has physical limits has finally cut through the bureaucratic “whatever-it-takes—just make it quick” wall of denial. China’s Ministry of Industry and Information Technology (MIIT) declared on 26 August 2026: “products that have not been adequately tested should not enter the market.” A Beijing Hyundai executive put it more bluntly: “consumers were being turned into test drivers.” Anyone familiar with the bureaucratic “talk” understands: miss a substantial defect, and you’re a “goner.”

It can take many months—even years—to run a wear test on a mechanical part. There is no shortcut to physics—China-speed or no China speed.

Here is the thing: if even the most effective engineering culture is being slowed down—where do we actually stand?

Too many EV makers

Back in 2021, MIIT minister Xiao Yaqing declared: “We have too many EV firms on the market right now.” But which of them will survive?

The American car industry shakeout a century ago revealed that the most inventive firms didn’t win the race; the ones that mastered their production systems did. Ford’s assembly line and GM’s innovative organization made it to the finish line.

This time, the winners of China’s shakeout will be those who combine speed with effective product validation. It’s a race of the same intensity—but a different game.

The legacy car industry is getting faster, while China is being forced to become more thorough. This is a Great Convergence happening as we speak—in “real time.”

And yet, the “test more—or else!” idea has more to it. China’s speed was never explained by lighter regulation—China Compulsory Certification has always been extensive. The speed came from the product-developing organizations. Finding the best engineering talent while keeping projects moving fast has been the recipe for catching up with legacy OEMs. Now, it’s time to do both: “Move Fast. Build Right.”—which is my favorite tagline.

The situation is so compelling because whoever combines speed with thorough quality evidence will win. Believe it or not, this is a turning point where the legacy OEMs can turn the German quality culture back into an asset.

And the silver lining appears to be here: the legacy car industry may finally be bouncing back: the new BMW iX3 is close to 100,000 orders in ten months. ZF has halved two of its development cycles. VW has a realistic speed-up target. The sparks in the dark might be a sign—a wind of positive change that some still might perceive as “management by hope” (or just a chacka-chacka naivety). That may not be tangible proof of the industrial turnaround—but it smells like good German breakfast buns and coffee after a long, dark, cold night.

Hold your horses—or there’s no time like “now”

I like the song “The Long and Winding Road” by The Beatles because it is so calm and lovely—but it might also serve as a warning sign: the road can be very, very long before the desired goal can be achieved.

There are reasons to be skeptical (and if you are a German person, you are 100% skeptical, no matter what—but I digress…). There’s no doubt Chinese (and Japanese, for that matter) engineers put in far more working hours than their German counterparts. In no universe can a German engineer work 2,200 hours a year. In other words, in our universe, it is completely out of the question that a Western engineer would outwork Chinese engineers.

But wait, there’s one more thing (as Steve Jobs would say): Western OEMs compress the same process into fewer months—same steps, same gates, same work products—and it STILL doesn’t come anywhere near China speed. Why? Because novel OEMs like Chinese OEMs, or Tesla for that matter, designed the process for the timeline they wanted. The gap is a process and design gap, not a work-hours gap. This strategy can be effectively replicated, and Honda shows the flip side: it keeps its gates and gives up speed. Speed and rigor only fit together when the process is designed for the timeline.

Translated into morning-coffee thinking: let’s stop following a 1990s playbook—let’s make a new one that has less slack and fewer “categorical imperatives.”

Yes, but…

The usual “yes-but-ism” reveals a reluctance to accept reality: “If we don’t follow the typical process, we sink into chaos—and where would that end up?”

We have given up so much of the old world: instead of fax machines and paper letters, we have adopted e-mail. We tossed away newspapers and now use electronic news media and “social media.” We don’t use the 40kg-heavy Encyclopedia Britannica and Brockhaus; we use AI tools instead. Instead of vinyl records, we listen to music on Spotify and Apple Music. Heck, we even stopped using our beloved horse carriages and hop into the car to drive 1,000 km in just one day.

Do we sometimes miss the “good old days”? Yes, we do sometimes. That is the human, sentimental side of us. Besides, some side effects, like losing privacy with online communications, can be not only annoying but might—theoretically—eventually be our undoing. However, standing in the way of technological progress has never paid off in the long run. Thus, it is only logical to stop worrying and start moving fast.

And the “fast” part is only possible if automotive development becomes a well-structured, fast-paced endeavor. Every car development must become a real project rather than part of a conventional matrix organization we all grew fond of in the past automotive legacy world. In such a project organization, the “sense of urgency” is only possible if the flat but hierarchical team works in unison, following a common purpose and the same goal. Speeding up means compressing a development cycle, and it is only possible if the parallel work is organized with owned handover points and a protected verification and validation track. That’s project leadership at work—and it does work, because it always has worked.

Move Fast. Build Right.

Since the first American car was made, more than 1,500 car makers have come and gone—but only a handful have survived. The Chinese car makers are going through the same cycle—only several times faster. Think about it: Germany’s last great shakeout produced Daimler-Benz, BMW, and Auto Union (now Audi/Volkswagen). It’s a painful process, but consolidation is where strong companies are made.

The thing is: It gets worse before it gets better, and the legacy industry might be at the bottom right now. The next round goes to whoever can move fast and make sure the proper quality comes with it. This is the automotive industry; this is home ground: Move Fast. Build Right.

Remarks

“Move Fast. Build Right.” was adapted from the author’s forthcoming book CORE SPICE: Delivering Safety-Critical Projects Under Pressure (Springer), ISBN 978-3-032-43050-2

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

On 19 August 2026, Unitree Robotics listed on Shanghai’s STAR Market (688836.SH). The original offering price was 150.80 yuan (about $22). Proceeds were 6.1 billion yuan (about $900 million). The stock opened at 1,100 yuan—629 percent above the IPO price—then sold off through the session and closed at 845 yuan, still up 460 percent. (https://technode.com/2026/08/20/why-unitree-became-the-first-humanoid-robot-company-to-go-public-in-china/)

Coincidentally or not, the World Robot Conference opened in Beijing the same morning. (https://technode.com/2026/08/20/why-unitree-became-the-first-humanoid-robot-company-to-go-public-in-china/)

Robotics is a core piece of the new CCP Five-Year Plan. It contains—as usual—a priority list of targets to be implemented during the five years. The proven strategy is always the same sequence of events:

Prioritize → Scale → Reduce costs → Export → Move up the value ladder.

This is the same schedule we previously witnessed with solar and wind energy—and electric vehicles (EVs). And it is extraordinarily effective. In 2024, China produced more than 70 percent of the world’s electric passenger cars and around 80 percent of the battery cells (IEA, https://www.iea.org/reports/global-ev-outlook-2026/manufacturing-and-trade). China was not a late arrival. By 2018 it was already the world’s largest EV market, with about 1.1 million electric cars sold that year and nearly half the global stock (IEA, https://www.iea.org/reports/global-ev-outlook-2019). The Western automotive industry was still unprepared for the export surge that followed.

To avoid being flat-footed again, it makes sense to study the 15th Five-Year Plan (2026–2030) (MERICS, https://merics.org/en/comment/deciphering-15th-five-year-plan). I laid out the same list in German here: https://projectcrunch.de/chinas-fuenfjahresplaene-gestern-waren-es-e-autos-die-neue-strategie-setzt-andere-schwerpunkte/. EVs and the clean-tech chain are treated as mission accomplished; those sectors are now being consolidated, and exports are being intensified. The new plan moves on to the next market segments:

Near-term strategic industries:

• Semiconductors and fabrication equipment
• Industrial software and basic technologies
• High-end machine tools, instruments, advanced equipment
• Advanced materials
• Industrial AI and robotics
• Biotech/biomanufacturing
• Aerospace, the low-altitude economy, drones
• Further development of new energy and new materials

Long-term industries, starting now and planned to continue beyond 2030:

• Quantum computing and quantum technology
• Fusion and hydrogen
• Brain-computer interfaces
• Embodied AI
• Humanoid robotics
• 6G

Industrial AI and robotics are being relentlessly pushed.

Unitree is one stop on this journey. Unitree was founded in 2016 in Hangzhou. It took ten years to get from a lab to a Star Market ticker

The next phase is to focus on the domestic market to prepare for the scale-up later in the sequence. More than 40 percent of Unitree’s 2025 revenue was already overseas—and that’s just the shy start. Europe will be next.

If China has set robotics as its next focus and is pouring billions into it, how should the West react? Western companies cannot compete on unit price—this proverbial train left the station decades ago. We saw it didn’t work with EVs, and there is no reason why it would be different this time with industrial and humanoid robots. The same warning applies to machine tools, industrial software, and the Hidden Champions that used to compete in their unique niches.

Western car makers chose to ignore Chinese EVs—that was a mistake. Making a strategic mistake is bad enough. Repeating this mistake and discounting the new Five-Year Plan as scaremongering would be beyond negligent.

References

• https://projectcrunch.de/chinas-fuenfjahresplaene-gestern-waren-es-e-autos-die-neue-strategie-setzt-andere-schwerpunkte/
• Chan Ho-Him / AP, “Shares in Chinese humanoid robot maker Unitree soar in its Shanghai trading debut.” 19 August 2026. https://techxplore.com/news/2026-08-chinese-humanoid-robot-maker-unitree.html
• Congressional Research Service, IF13204, “China’s 15th Five-Year Plan: S&T and Economic Priorities,” 16 April 2026. https://www.congress.gov/crs-product/IF13204

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

He doesn’t appear hostile—he is just tired. You have seen the look so many times and know what it means.

The first reflex is to fight the resistance. Just like in the Star Trek movie, you feel like the Borg: resistance is futile. Or you often think that you need to socialize it away, get buy-in, or manage around it.            

That is a big mistake.

The skepticism of a good senior engineer is one of the cheapest quality signals you will ever get. Brushing it off as a distraction resets the signal—and the signal gets lost in the white noise of the usual corporate madness.

But here is the thing: he has sat through a decade of process rollouts. He has filled in countless templates nobody read, attended gate meetings that were just excruciating rubber-stamping rituals. Or he hoped for professional traceability tools that turned out to be just spreadsheets. There are so many examples of such disappointing moments that no one even counts them anymore. When he hears that some new awesome processes pop up, what he really hears is: what is in it for my team, for the life of the program?

“What is the added value?”—as annoying as it might sometimes come across—is a legitimate response to a supposedly cool new process step.

Junior engineers don’t ask. They do as they are told. They fill in the template and move on. “There must be a good reason for that,” they think. But an organization learns nothing from the person who does everything you say.

In such a moment, when the senior engineer objects, there are two options:

The first option is to overrule it using the formal authority. There are usually plenty of “good arguments” available. Like, the OEM expects it, the assessor demands it, it’s corporate policy, and so on. It sure works—but what you have taught the team is that process is a “process tax” that must be paid—you pay your dues and move on. It does not really help—except maybe the assessor or a senior customer representative who now feels good about themselves. The real price is that people simply give up. They fill in the template, and that’s it. And they stop asking questions—which is exactly what you can’t afford.

The other option in such a situation is to take the question at face value, and honestly justify it: Why does this new process or process step present a real, tangible improvement?

A new design review record confirms that the team is building the right thing, or a new configuration baseline communicates to the team what “done” means for this release. In other words, a new or changed process must be “sold” to the team. If you can successfully do that, the change is validated, and no one will try to fight or circumvent it.

On the other hand, if you can’t “sell” your process change, then it’s actually great news: your engineer most likely saved you the embarrassment of wasting the team’s time.

Next time, when you think you have a great improvement idea, validate it with your team and listen. It’s called “active listening.” Don’t be shy. In a functioning team, your senior engineers’ feedback is invaluable. You will find that the ideas your team pushed back on are usually the ones worth a second look.

The point of that team feedback, uncomfortable as it may appear, is not a tidier process on paper. It is that your engineering team feels they can genuinely “own” the development process. It becomes less bureaucratic—and reducing bureaucracy is one of CORE SPICE’s core values.

Your senior engineers already know a bad process when they see one. If they keep quiet, it could be because, before you stepped in, the managers raised their eyebrows and treated questions as a discipline problem. Ask them out loud instead. The skepticism of your team is a bitter pill, and it’s good for you and your project.

References

• CORE SPICE — the coaching framework behind “approaches instead of process chains” and “merit instead of bureaucracy”: projectcrunch.com/core-spice
• Roman Mildner, Car IT Reloaded: Disruption in the Car Industry (Springer Vieweg, 2025) — Chapter 6, the full CORE SPICE model.
• Russell L. Ackoff, on why optimizing the parts does not optimize the system — the systems-thinking root of asking what a step does for the whole, not just whether it was completed.

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

For decades, this was the standard automotive architecture. Now, the industry is shifting: hundreds of ECUs are being consolidated into a few domain controllers, and ultimately into a single central operating platform. To put it in a more colorful way: The architecture is moving from a committee of controllers to a single brain.

Individual ECUs were rarely the primary failure point. The problem was the interfaces between them. Coordinating these connections required careful orchestration to prevent system-level failures.

This shift in architecture parallels current trends in artificial intelligence. While many propose using multiple specialized agents, the alternative is a single, integrated central model.

The thinking problem

Today’s language models don’t have a reasoning ability—at least not by default. LLMs answer before they understand. They do it in a perfectly fluent, fast, confident manner—and often confidently wrong. The “hallucination” problem remains unsolved, although the gap has been steadily shrinking: the best frontier models are now down to single-digit hallucination rates on standard benchmarks—roughly four to nine percent depending on model and task, down from 15–45 percent only two years ago.

Artificial intelligence still falls short of true intelligence. Major AI labs are focused on solving the hallucination problem, but this is fundamentally an architectural issue. Addressing it requires redesign, not just incremental fixes. Reasoning models attempt to improve by thinking longer before answering. Thinking before acting sounds like common sense, but the model still has nothing to think about—it simply repeats the same process in a loop, hoping for a better result.

The agentic swarm

The concept behind multi-agent systems is to divide the LLM into specialist components—a planner, a critic, a researcher, a coder—and manage their interactions to produce better results. This approach has become popular, with widespread reports of individuals building successful products by deploying specialist agents on small-scale hardware.

How effective is this approach? “The jury is still out”, to use a popular phrase, but some “judges” have already spoken. A 2025 study out of Berkeley found that agentic models may not be the answer. It turns out that multi-agents tend to clump and amplify their failures. The failure mode happens in stages: agents talk to each other until the original goal gets blurred, resulting in something that looks good but is, at best, suboptimal. A 2026 follow-up put it bluntly: a well-designed model beats the committee of agents at reasoning.

As in automotive development, the AI field is recognizing that complexity increases with the number of interconnected components. The more nodes in the network, the more difficult it becomes to achieve reliable results.

The transputer lesson

I was at university in the early nineties when the transputer was going to solve the compute scalability problem. Transputers are computers in which dozens or hundreds of identical CPUs are orchestrated to solve tasks at speeds that surpass even the fastest mainstream CPUs of their era. Some transputers were quite massive, such as the Parsytec GigaCluster, which orchestrated 1,024 processors in a single cluster—built by Parsytec of Aachen, practically next door to my alma mater. Those massively parallel computing units could, for instance, perform fast matrix operations in record time. However, those systems had, apart from the massive local network load, one critical flaw: engineers had to embed the solution for each transputer configuration, specifying which node did what and in what order. Engineers could hand-assign the work, which was precise and expensive to develop—or they could try to distribute it automatically using an algorithm. It turned out that automatic task distribution did not deliver on its promise because the static algorithms could not learn from their mistakes; they kept guessing, and the results remained the same: suboptimal.

Deterministic design algorithms were promising but ultimately unsustainable due to the high cost of manual code development. The breakthrough came decades later when neural networks achieved sufficient quality to enable massively parallel solutions. Modern AI systems use Mixture-of-Experts models, which contain hundreds of specialist sub-networks managed by a trained router. This router assigns tasks dynamically, rather than following a fixed algorithm. For example, DeepSeek’s model uses 256 experts and activates eight per token, a principle now common in leading models. These specialists operate within a single model, sharing memory and coordinating through mathematical operations rather than network communication.

A practical example of this shift is Tesla’s approach to autonomous driving. Engineers replaced 300,000 lines of handwritten driving rules with a single end-to-end neural network. Instead of programming, the system—one could say—grew a brain. This is the transition from deterministic to neural network-based design.

“One brain” != “monolith”

The analogy of the brain as a model for AI is often oversimplified. The human brain consists of many specialized regions—vision, language, motor control—each performing distinct functions. Neuroscience describes this as the Global Workspace: specialized modules operate in parallel, and relevant information is shared and broadcast as needed. Under demanding conditions, these modules coordinate closely.

The question is whether a future AGI is a sum of all parts or something different, more meaningful, and more effective altogether.

The cutting-edge AI frontier

No one really knows how to define Artificial General Intelligence (AGI), but the cutting-edge experts are working on it day and night. The expectation is that once it is here, the AGI will be able to define itself, thereby rendering a consensus-based definition of AGI obsolete.

The most renowned experts who work on AGI seem to agree on the diagnosis—text-based models will not lead to AGI—but they disagree on how to fix the current LLM dilemma.

• Yann LeCun left Meta in late 2025, raised over a billion dollars, and is building a world model that understands physics by visually experiencing how it works. His bet grounds intelligence in perception. He treats language as a dead end.
• Elon Musk rebranded Tesla as a “Physical AI company.” Tesla is not working on EVs; it works on automated mobility. It grounds intelligence in action—one end-to-end brain, trained on 8.4 billion driving miles, that runs both a car and the Optimus robot. His language brain, Grok, lives in a different company—and since February 2026, that company is SpaceX, which swallowed xAI in a $1.25 trillion all-stock merger while Tesla stayed out.
• Demis Hassabis at Google DeepMind wants to keep all options open. Gemini takes text, images, audio, and video into a single model; the Genie world model plugs in alongside it; agents and robotics hang off the same roadmap. He calls it a component of an eventual AGI system.

LeCun focuses on visual reasoning. Musk wants an AGI to be literally hands-on, while Hassabis wants it all.

Musk is now wiring Grok into his car company under the “Digital Optimus” banner—a joint project across Musk’s companies. LeCun’s world model, to do anything useful, will need a mechanism that integrates planning capability and a persistent, reasoning memory.

It seems like everyone is moving towards the same goal; only the road to get there is different.

One thing appears logical to me: World models are not the only way—they are one piece in the AGI “brain-like” puzzle. The way is to have it all in one “organ”—the AGI.

If you don’t learn from history, it will repeat

No one has solved the “remember yesterday” problem.

It appears that the modern models, with proper orchestration, already have it—but that’s just a superficial view of the current models. They seem to “remember” some of the past interactions. When I start a new chat using Anthropic or Grok, the system remembers my name, some of my past outcomes and queries, and so on. But all it really does is keep notes. A “.md” file is read and reused—that’s all that it can really do. The model itself does not change, nor can it learn from past interactions. The neural network-based weights remain the same. It is like a natural brain that never rewires itself; it is basically a frozen brain, if you will.

AGI—at least, this is my perception of what it is supposed to be like—would naturally recognize the difference between my colleague and my client, based on current and past context. It would learn, over weeks, months, and years, to plan next steps and to understand all risks and opportunities based on current, past, and future context.

Today, even with the permanent notes, it still remains a stranger to you. The system remembers facts about you, but the model learns nothing from you.

And the winner is…

So, who will win the race to achieve the first AGI? Here is my bet: Google is the strongest contender. It integrates everything into one solution. It sucks in everything—images, videos, text—and integrates modalities, compute, distribution, and the best video training set: YouTube.

And Google does not only watch—it touches, too. Waymo’s robotaxis have logged over 220 million fully driverless miles. But hold that number against Musk’s 8.4 billion, and the ratio is roughly forty to one. Waymo’s miles are chauffeur-quality—geofenced, lidar-equipped, curated. Teslas are crowd-scale, messy, and cheap. Which of the two corpora teaches the mind more is one of the open questions of the race.

But there is one thing Google cannot buy at any scale, and Musk already owns it: billions of miles of a machine acting in the physical world and learning from it. You can scrape every video ever made and still not have that. So, the race is still on.

Back to the agents

Which brings the argument back to where it started. Agentic AI is not a dead end as a product—coding agents deliver meaningful results every day. But as a road to AGI, the swarm is scaffolding: a workaround we wire around models that cannot yet hold a task together on their own. Andrej Karpathy said it bluntly: the industry declared the year of agents; he gives it a decade, because agents “don’t have continual learning. You can’t just tell them something, and they’ll remember it.” And the seventy-year pattern of AI research says that hand-wired structure loses to learning and compute every time. The orchestrated swarm is a hand-wired structure. It will be deleted, layer by layer, the way Tesla deleted its 300,000 lines of driving rules.

The key to today is to remember yesterday. Whoever teaches the machine to remember yesterday will win the AGI race.

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

“Need” is what is required, but the “want” wins anyway.

The true trick

In March 1848, two girls in Hydesville, New York—Kate Fox and her sister Maggie—announced that a ghost was answering their questions. At first, it appears to be just a prank, but by November 1849, the sisters were demonstrating their “powers” to nearly 400 paying spectators at Corinthian Hall in Rochester. It was a huge success—today, we would call it “hype.” Spiritualism spread across the United States and Europe, and by the 1880s, an estimated eight million people firmly believed that talking to the dead was a proven fact.

Built on grief and a desire to believe in the supernatural, it spread globally.

However, on October 21, 1888, Maggie Fox walked onto the stage of the New York Academy of Music in front of a packed house and confessed that the whole thing had been a fraud.

Then she proved it to the shocked audience.

She cracked the joints in her toes and produced the famous bone-cracking noise, live and on demand. Doctors climbed onto the stage to confirm the sound was coming from her foot.

One could not ask for clearer evidence—talking to deceased people was obviously an outrageous fraud. The whole thing was debunked so thoroughly, reproduced, demonstrated, and deconstructed that the entire Spiritualism movement was obviously a fantasy.

A full refund was offered right there on the stage.

Surprisingly enough, the global public simply refused to believe the debunking of a proven, demonstrated, and deliberately reproduced fraud. Instead, they explained that Maggie must have sold her confession for money, or made it drunk, or buckled under pressure from the church.

The movement rolled on without her. The zealots flocked to the midnight sessions and insisted they were talking to the dead.

A year later, Maggie recanted her confession, but it was too late. She died in poverty, broke and largely forgotten. By then, they didn’t need her anymore. There were enough imitators who could do the trick just as well as she could.

Easily satisfied when opportune

It is easy to discard the Spiritualism movement as silly or illogical. Millions were not fools. Many of them had buried children in an era when burying children was common, and Spiritualism offered what no one could: five more minutes with their beloved dead. The confession was not just proof of a mistake; it threatened something they had built their inner life around.

If there were no facts, the facts had to be made up or reasoned out.

Believing convenient, alleged facts is a psychologically proven fallacy, and it is not limited to personal life. It also applies to highly skilled and well-trained engineers. It is natural to think that bias is something others suffer from, not ourselves—the credulous, the non-technical, the ones who don’t understand the system.

Regardless of the best intentions, smart, sincere, highly competent people sometimes reject evidence that threatens a belief they are invested in, and the more committed the person is, the harder the reflex becomes.

This kind of “make-believe” is common across industries, including in safety-critical systems development. The best engineer wants to believe the architecture is sound because they designed it. The project lead wants to believe the date holds, because they promised it. The test engineer wants to overlook system issues because they would compromise the SOP deadline.

It is a psychological investment at work.

Shooting messengers

What happened to Maggie when she finally told the truth is a fascinating insight. She was not argued with—she was simply discredited, written off as bitter, broke, and probably drunk. It is the “attack the witness, keep the faith” reaction.

That’s bad enough socially, but it is even worse in safety-critical product development. Pointing out flaws in such projects must not be dismissed without examining the reasons behind them and the facts that support or refute them. Often enough, however, when the news threatens the consensus’s beliefs, those responsible go after the witness. But “don’t shoot the messenger” is not just a fair workplace etiquette. In a safety-critical program, it serves as a survival mechanism because the messenger is sometimes the only person on the team who can prevent a product-related disaster.

ECST is the much-needed remedy

CORE SPICE rests on the Effective Critical Systems Thinking—ECST—principle. One way to characterize it is to prioritize knowing what you need to know over following long-established dogmas, and to challenge those principles if the design’s purpose is violated.

Critical thinking puts evidence ahead of comfort. For example, instead of asking, “Was the critical component tested?”—ask for the test report. Reassurances are comforting but pointless, so it’s better not even to ask for them. Systems thinking means one green light doesn’t guarantee everything else is fine. ECST is the deliberate practice of not doing what the audience did to Maggie nearly 140 years ago: it prioritizes evidence, demonstrates the mechanism, protects the messenger, and then updates the belief to match reality—rather than the other way around.

Management by hope (don’t)

In a safety-critical product development, ignoring those quiet, nagging inner voices could cost lives. And yet, the ability to think critically could be a pretty inconvenient virtue. Nobody wants to be the “crying wolf” because the wolf could possibly be shot. The project status “must” be green—otherwise, the project lead faces scrutiny. The test result “must be ‘passed’—or else.” The supplier status report is taken at face value because chasing the truth would be awkward and slow.

Situations like that happen every day in our project life. A comfortable belief wheeled in to stand where evidence should be, because gathering the evidence poses a personal risk to the investigator.

In our ghost story, the raps were never spirits. They were toe joints, and that was never really a secret—let alone some magic. The truth is out there—and it should be sought and found before the new car hits the road and a tragedy ensues.

People need to know, but want to believe.

As a professional, your job is to know—and not to just believe. It’s a matter of principle, attitude, and the ability and—perhaps most of all—willingness to accept facts.

Sources:

• Smithsonian — The Fox Sisters and the Rap on Spiritualism
• Feynman, Rogers Commission Appendix F

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

Test plans frequently follow this unsettling pattern: forty pages on a standard skeleton—IEEE 829 in the old days, now ISO/IEC/IEEE 29119, an even bigger monster of a template. The result is endless pages of prose, and it is still not clear which test results must be delivered by Monday at 8:00.

Such documents usually contain no decisions. Instead, they contain musings—a description of the author’s feelings about the verification strategy. The actual doing—that seems to be someone else’s problem.

It is not really a test plan—it is a write-only document. A plan consists of a series of decisions.

A decision specifies options, approves or rejects them, and attaches specific names to each task. Amateurish business poetry such as “Testing shall be performed on representative hardware” is definitely not a decision. It is actually a decision not to make any decision at all.

Professional prose would read something like this:

“We test on the B2 sample, revision 3004. If the B2 slips past calendar week 38, we ship the qualification test report on the B1 sample and re-run the smoke test on the B2. Owner: System Test Manager. Delivery deadline: CW 40.”

That sounds like a professional who understands project constraints well.

I used to listen to Mark Horstman’s “Manager Tools” podcast (and his book, The Effective Manager, is a great read). He clearly defined the essence of effective decision-making: who does what by when. THAT is a DECISION. Spell out ten or fifteen of those actual decisions—and you have an effective test plan. No “War and Peace” epics. In some projects, two pages are sufficient. I have seen 120-page plans with fewer committed decisions than that.

Why is creating good test plans so hard? For one, we often write them for the assessor. If that is the main reason a plan exists, then we have wasted a nice bundle of money. Besides, a decision can be wrong, and no one wants to risk their name attached to a failed decision—so actual decisions are shunned. Musing, on the other hand, carries no such risk—nobody was ever blamed for “testing will follow a risk-based approach.” Thus, the safest document, career-wise, describes everything and commits to nothing.

Review checklists often don’t help, either: they ask whether chapter XY is filled, not whether chapter XY decides anything. While such checklists carry some practical value, the actual decisions get made eight months later, in a crisis meeting, by whoever talks loudest.

And, by the way, kicking the can down the road is the worst decision of them all.

Think about it: the role name actually defines the justification of this role’s existence: Test manager. The title means that this person is paid to make decisions. If your plan contains no decisions, the title is meaningless.

Can you handle decisions?

That is: what shall be done, by whom, and until when? Without those elements, a plan is frankly useless.

A test plan is a living document that stipulates the task sequence (“what”), staffing (“who”), and gates (“until when”).

And this rule applies to all “plans”: project plans, configuration management plans, quality management plans, etc.

In CORE SPICE, the “Approach” documents are templates that make it easy to develop a test plan, including its strategy. AI can be used for that. Please, don’t run for the exits yet. I agree that most of us are tired of LLMs generating tons of boring content, but some applications of them can be extremely helpful, after all. Developing a test plan, even based on a good template, is expensive, and we have less and less time to “write plans.” A language model now writes the descriptive part of any plan in an afternoon, in flawless English. So the prose has lost its magic. Nobody cares. What remains is the part the machine cannot own: the decisions. Who will do what, until when?

Next time, especially if you are under time pressure—skip the checklist. Instead, count the decisions. If your plan contains a substantial number of decisions, you have a test plan. If you can’t find them anywhere, you are more likely holding forty pages of a weather report.

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

In this article, I will introduce the program leadership concept, as well as the remaining “walls”: supporting the DMZ engineers’ careers and the security and workspace setup.

The project is run by the Project Lead and the TCC

A DMZ is designed for a specific OEM’s program, including a single budget, a single platform, and a common SOP date. Several suppliers contribute named engineers, but there is one principal. One critical aspect is that the OEM will most likely define the Project Lead. Consequently, the OEM’s Project Lead is partisan, and the other suppliers in the program read every decision the partisan lead makes as an act of OEM self-interest. So the Project Lead is usually not neutral. The solution to this challenge is to pair the lead with a second role that carries the balance: the Team Capability Coach.

The Project Lead, appointed by either the OEM or a superordinate stakeholder group (e.g., a “steering committee” or a consortium), holds the conventional accountabilities—scope, plan, budget, risk, stakeholders, compliance, etc.—on behalf of the project. The TCC works alongside the lead but has no command authority over the engineers, since the TCC is a coaching authority, rather than a line management authority, over people who do not report to either the lead or the coach on any organizational chart.

The TCC’s task is to provide the balance that the Project Lead cannot carry on their own. The first is transparency, which I come to in the next section. The second is fairness across company lines—ensuring that the engineers who participate in the DMZ are not disadvantaged by their participation. By contract, the TCC is bound to the CORE SPICE principles—critical systems thinking, cooperation over confrontation, merit over bureaucracy, transparency, and safety first.

This dual project leadership structure has its limits. Since the OEM funds the program, it also funds the TCC. That party can lean on a coach it pays for. The solution is a contract that binds it to the CORE SPICE principles rather than to instructions, plus a project lead who understands that a biased TCC is worthless to the program as a whole. The OEM must understand that this is the only way to achieve the expected program speed. Otherwise, the entire structure is pointless.

The dual leadership works because it separates two distinct tasks that a single partisan role cannot hold at once: drive the OEM’s outcome and keep the program fair enough that suppliers send their best people and keep them there. Suppliers do not need the Project Lead to be neutral. They need someone in the room whose job is to keep the balance. Together, the Project Lead and the TCC also run the continuous team assessment, which the named-engineers principle depends on—who is admitted by name, who is replaced, and when the right call is “no replacement, we must manage accordingly.”

Strong transparency rules are crucial

Transparency is the TCC’s essential duty. A DMZ falls apart if any key stakeholder is unpleasantly surprised with bad news. Stakeholders—the OEM above all, but also each supplier’s management—can absorb hard truths, but they never accept negligence or a hands-off approach to risk minimization. A hard truth delivered early proves that the program is managed professionally.

For that reason, DMZ reporting must be completely transparent and require minimal effort to maintain. Program status must flow to key stakeholders in near real time, daily, and be automated—pulled from the live toolchain rather than assembled by hand the night before a steering committee or a status meeting. The automation is a crucial tool that is actively set up and continuously managed by a project member (e.g., the Project Tool Engineer, as described in CORE SPICE).

The TCC oversees the setup of the status dashboards, ensuring all stakeholders are “in the loop” on project status.

In addition to the status, the velocity of the project deliverables must also be measured. The reporting must visualize the pace of development: how long cross-boundary changes take, the defect rate, testing velocity, and how quickly process gaps (e.g., unapproved requirements) are being resolved.

Wall 3: careers

Part 2 priced the named engineer commercially and gave the supplier its reasons to say yes. However, it is the engineers who, before joining the DMZ project, wonder about their professional futures. A DMZ assignment of two to three years is a long time for top-notch engineers, and they must meet the expectations of both the OEM and supplier sides.

The risk to those engineers is that they become less visible in their home corporate environments. While our vertically integrated, DMZ-driven program progresses, the home organization continues to promote, reorganize, and re-staff in the engineer’s absence. Out of sight, out of mind. The engineer on secondment may miss the informal moments that drive career advancement at home, such as corporate canteen chats, watercooler discussions, and technical workshops. That is also part of the “retention risk.” Engineers may look for other opportunities because the program has made them invisible to the company that determines their pay grade.

The good news is that three effective mechanisms can greatly reduce those risks and turn them into opportunities for the most capable engineers.

The first retention mechanism is a designated return path. Before the engineer enters the DMZ, the home organization commits in writing to the role band they return to—a level, not a specific desk—as a part of the home company contract.

The second mechanism is a home “anchor.” That is an associated senior colleague (or even a career mentor) whose role is to ensure the DMZ engineer receives proper performance ratings for DMZ work and to advocate for the DMZ engineer. Hence, the engineer remains visible, respected, and on every appropriate internal promotion list. That ensures reviews, advocacy, and visibility for the engineer while on assignment.

The third mechanism is dual visibility. The TCC assesses the engineer’s contribution inside the DMZ, and that assessment feeds the home company’s review cycle. DMZ program performance must be counted at home to prevent the engineer from spending years building a reputation that is not visible to the relevant decision-makers within the home company.

These arrangements offer unique advantages to the engineer. For the highly motivated, most capable engineer, the DMZ can be the assignment of a decade—returning with experience on a next-generation product integrated across an OEM’s full system platform, with cross-company relationships and a breadth of exposure a single-company role rarely offers.

Give an engineer a return path they can use as confirmation of their participation in a leading-edge technology project and a home anchor (or a mentor) who fights for their professional career’s advancement, and they have an excellent reason to return to their employer when the program ends. This is an attractive career strategy given the unique opportunity that a vertically integrated DMZ project offers.

Wall 4: security and workspace

A well-designed technical setup of a DMZ is one of the key enablers of a successful DMZ project.

NDAs offer limited protection to the entire zone; the IP framework also needs physical, IT-infrastructure-based boundaries. These boundaries must ensure a free flow of information within the DMZ. If the engineers participating in the vertically integrated project cannot effortlessly read each other’s specifications and commit code across the boundary, the DMZ becomes a liability. It degenerates into email chains and hermetic data silos that are wasteful and create redundancies, endangering both the project’s efficiency and data integrity.

There are a few possible approaches to the workspace of a DMZ-based project. I will rank the tiers from the lightest to the heaviest.

Tier 1: Virtual tenancy. The DMZ provides a dedicated engineering toolchain for this program, accessible from the engineer’s existing laptop. No new PC hardware is required. Instead, multiuser infrastructure is hosted in a dedicated environment. For example, a dedicated GitLab or GitHub Enterprise instance for source and CI; a dedicated Jira and Confluence site for issues and documentation; a dedicated ALM instance—codebeamer, Polarion, or DOORS Next—for requirements and traceability, all behind one program identity provider with its own SSO, so only a single login credential is required. The DMZ engineers keep their home laptops and access the program via a browser and a VPN or a zero-trust solution (such as Zscaler). In this way, everyone can keep using their favorite setups, while dedicated servers handle the rest. The typical team platform is the “usual suspect”: Microsoft 365, although some people prefer Google Workspace.

Tier 2: Managed program desktop. The engineer’s home laptop becomes a window into a separate, program-controlled PC that lives in the cloud. For instance, a virtual desktop using Azure Virtual Desktop, a Windows 365 Cloud PC, Amazon WorkSpaces, or a Citrix- or VMware-style VDI. The engineer opens a remote desktop client and works on a Windows desktop that the program administers—including program-installed tools, storage, policies, and so on. Program data is never stored on the home laptop’s disk, so if the laptop is lost or the engineer leaves the project, nothing program-related is on it. This tier is used when one company’s security rules prevent its toolchain from being accessed on another company’s hardware. In that way, the virtual desktop serves as neutral ground.

Tier 3: Program-issued hardware. This is the most hardware-intensive variant. The program procures, images, and hands out its own physical laptops, which are joined to the program’s domain and device management (Intune or JAMF for Macs) using program credentials. The engineer carries a second, physical laptop that belongs to the program (not to either employer). The physical workspace (in addition to remote workers) is the bricks-and-mortar office space: a floor or set of rooms with the program’s own badge access, where OEM and supplier engineers sit together, keep their desks clean, and do not use personal devices on the program network. Background IP stays declared and walled off, while the program-generated IP lives within the program environment. Granting and revoking access is run by the Project Lead and the TCC.

There are additional security considerations that must be part of a well-designed DMZ.

The first is government regulations. A cross-company, often cross-border program operates within a regulatory space that includes export controls and dual-use rules, data residency and sovereignty requirements, and data protection laws. Where the tenant is hosted can be a legal decision, including determining which tier to use, which region the tenant lives in, and who is permitted to hold which credentials.

The second sounds trivial, but in my experience, it can be critical. A DMZ team is usually mixed—some engineers on-site, some remote—and the mix changes week to week. A mixed team works only if all team members have the top-notch gear required for their everyday work. Everyone, including the on-site people, needs best-in-class audio and video gear: proper noise-canceling headsets, not laptop microphones, and multiple computer displays. It is a relatively small line in the budget, but it removes a daily source of corrosive friction.

Discussion

There are a few aspects of a DMZ that must be considered while designing a successful DMZ vertical integration program.

Cultural fit. Can completely different working cultures work in a DMZ? It can. The DMZ does not postulate that corporate and personal cultures must become a melting pot. It is asking named engineers to work under the norms of a single program for a limited period. A DMZ-driven program does not necessarily change anyone’s home culture; instead, for the duration of the program, the team forms a shared DMZ culture of its own.

Distributed teams. One could argue that joint engineering teams are hard to control. Part 2’s own VW-Rivian precedent—joint engineering teams in California and Germany—is the obvious example, and it may raise eyebrows. Can they—regardless of the geographical and cultural distribution—be one effective team? Distribution is a real cost, but it can be well managed. The DMZ does not make it worse, and the shared tenant from Wall 4 removes the tool-and-access friction that is what usually makes distributed work fail. Once the DMZ is implemented systematically and thoroughly in accordance with one of the aforementioned security tiers, it can operate without significant friction. Once the infrastructure works flawlessly, ideas and work items follow.

Poaching (one more time). As mentioned in Part 2, and also in the Wall 3 discussion, this is a valid concern. However, the non-poaching clause helps mitigate the issue. Also, the whole idea is that once set up and led by highly motivated engineers, vertically integrated teams offer so many advantages to the engineers and their home companies that the poaching risk—while always possible—becomes negligible.

Ending the DMZ

The DMZ is designed to eventually dissolve. Once the program has passed the SOP, the winding-down is carried out—it is typically already part of the project plan. Program-generated IP is returned in accordance with the Part 2 framework. The tenant is de-provisioned; the DNZ engineers return in line with the written career retention paths, with the knowledge they gathered transferred and retained to their career advantages. As with its inception, the DMZ project leadership owns the dissolution.

The bottom line

The three articles define the vertical integration approach, which enables the best-in-class development environment with excellent engineering, and this strategy gives the joint program a speed and knowledge advantage that would otherwise be impossible to achieve due to the multiple contractual boundaries typical of a multi-supplier setup with conventional contracts.

I want to emphasize that we are not discussing how to fight the dominance of Chinese companies. Instead, it is about matching the speed and learning from how that speed was built. The DMZ is one mechanism for closing the gap. The goal is a European or American program that moves at China’s pace—not more, but no less.

Moreover, nothing in it is specific to a Western OEM. From a Chinese perspective, the same DMZ approach could be initiated by a Chinese OEM that wants to develop a next-generation platform program, and Western suppliers, sensing the opportunity, bring their engineers to it. The DMZ is a way of organizing cross-company work. Whoever runs it well attracts the best engineers, wherever those engineers are employed.

In summary, the DMZ-centric vertical integration project, when well designed, does not just deliver a single program faster. It builds a capability—the ability to assemble a bounded, named, high-trust program around a hard problem, and to take it back down when the problem is solved. That is the prize—not one fast program, but the ability to run such complex projects even faster and more smoothly.

In our trilogy of articles, we have discussed all essential elements of a vertically integrated, DMZ-centric program, including the legal framework, the commercial model, the virtual tenancy, the return path, and the leadership pair. The reason vertically integrated programs are still rare is not a lack of capability, but a lack of willingness to staff named engineers across company lines and to put the right leadership pair in charge of them. You cannot buy your way to “China speed,” but you can run your way there—for one program, with dedicated top-notch engineers, inside a boundary you agree to dissolve when the work is done.

The programs we are called into are usually already paying the integration tax this series describes—the phone rings when SOP is in doubt. If you can see that tax in your own program, we are happy to discuss the options and schedule a short diagnostic call.

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

I use the German keyboard layout. No matter what shortcuts one tries, it won’t offer all the dashes and hyphens that are common in the English language. Fortunately, there is an easy fix for that that I want to share with you.

Why Hyphens and Dashes Exist

English has three horizontal marks of increasing length, each used for different purposes.

“-“
hyphen (the shortest)

“–”
en dash (medium length)

“—”
em dash (the longest)

Here is a cheat sheet that explains how to use them.

The hyphen (-) joins words and breaks long words across lines.

• State-of-the-art process.
• Well-trained engineer.

Every keyboard has a hyphen key, so I will skip past it.

The en dash “–”is the medium one. It connects ranges and pairs.

• Pages 12–18. The Berlin–Munich line.
• The 2024–2026 program.

Typographers call it the N-dash because its width matches a capital N in the font being used.

The em dash “—” is the long one. It interrupts a sentence the way a parenthesis or a colon does, but with more emphasis.

• He left the office—the door was still swinging—and called his lawyer.
• The cause was obvious—failed integration testing.

The convention I usually follow in my writing (projectcrunch.com, books) is unspaced em dashes—the dash sits directly against the words on either side, with no surrounding whitespace. Some style guides put spaces around them; I prefer the version without spaces because the dash reads as part of the sentence rather than a separator, but it’s just my personal preference.

The problem: my keyboard does not have all of the dashes I need

Even on a US English keyboard, the en dash and em dash are not on any key. You can type them with Alt codes, with autocorrect rules, by holding the hyphen key on a Mac, or by digging through the Insert Special Character menu in Word.

On a German keyboard, the situation is worse. The German layout does not even offer the Alt-code shortcut for these on most setups, and the autocorrect-substitution behavior Word does in English (“convert two hyphens to an em dash”) does not produce the expected result.

The tool I have been running on my machines for years to fix this is AutoHotkey (https://www.autohotkey.com/, in short: AHK) on Windows (by the way, on Linux, there is a similar tool called AutoKey).

What it does for me

AHK is an automation tool that can, among other things, type any text content in the current editor when a predefined hotkey combination is pressed.

For my purposes, I use the hotkey pattern: Shift + Ctrl + Alt + one key. That combination is rarely claimed by any application, which means I can take it for myself without breaking anything.

That tool lets me comfortably customize my keyboard. My most frequently used functions include two hyphen shortcuts, five different date stamps, and a handful that focus or launch the applications I live in—Outlook, Word, OneNote, Edge, KeePass, and dict.cc.

Particularly practical are the hyphen shortcuts:

• Shift + Ctrl + –
  … inserts an en dash —
  
• Shift + Ctrl + Alt + –
  … inserts an em dash

After a few weeks, my fingers automatically select this combination without having to think about it. As with all my articles, it was typed using these two shortcuts.

The second useful feature of AHK shortcuts is date stamps. When I am writing meeting notes, naming a file, dating a draft, or timestamping any data, I don’t want to type it by hand. I press a hotkey:

• Shift + Ctrl + Alt + . for an English-format date such as 16-May-2026
• Shift + Ctrl + Alt + L for a German-format date such as 16.05.2026
• Shift + Ctrl + Alt + , for an English-format date plus time such as 16-May-2026, 14:32
• Shift + Ctrl + Alt + ü for a date followed by my Windows username and a colon, ready for me to type a comment
• Shift + Ctrl + Alt + # for an ISO-style date such as 2026-05-16—the one I use for folder names, file prefixes, and anything that needs to sort chronologically

The last one is particularly helpful because it generates an ISO-formatted date (like 2026-05-17) that can then be used when creating files with that prefix, enabling clean, unified timestamps that can be easily sorted.

The rest of the script is application-launching stuff. Outlook, Word, OneNote, Edge, and KeePass each have a three-modifier shortcut that focuses the window if it is already running, or starts the program if it is not. Two more shortcuts open a new Outlook task and a new Outlook mail directly, skipping the main Outlook UI.

Setting it up on Windows

AHK is a free, open-source tool.

1. Download AutoHotkey from https://www.autohotkey.com and run the installer. Choose v1.1 when the installer asks—the script below uses v1 syntax and will not run on v2.
2. Save the script somewhere stable.
   I keep mine in my user folder as AutoHotkey.ahk. Any standard text editor will do, and the .ahk extension makes the file directly launchable; double-clicking it runs the script and adds an icon to the system tray.
3. Set it to auto-start at login.
   Press Win + R, type shell:startup, hit Enter. Open a folder; drop a shortcut to your .ahk file into it. From the next sign-in, the script loads on its own, and the hotkeys are live.

My script

Here is my version of the script. You can use it as a starting point and extend it as you go. Remember to reload the script before your changes take place. Note that some paths (e.g., Outlook) may differ on your machine.

Download and unzip the file. Right-click the AutoHotkey tray icon and pick “Edit This Script” — your default script file opens in Notepad. Paste in the contents of AutoHotkey.ahk (or just save the unzipped file directly in place of your default script), Then right-click the tray icon again and pick Reload This Script. The hotkeys are live from that moment on.

Be faster, more efficient with AHK

Small pieces of waste compound.

If you have to look up today’s date every time you name a new file, the files end up with no date or inconsistent date formats. Little waste compounds into days and months of wasted time—and distracts you from the actual workflow.

If you write a lot on a keyboard that lacks the characters you need, install AutoHotkey, paste this script, and start with the two-hyphen shortcuts. Add the date stamps the next time you find yourself typing a date by hand twice in one day. Before long, you won’t want to miss this little efficiency hack.

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