Abstract: An article about a Bosch engineer’s open-source project garnered over 150K impressions, yet only about 50 people actually forked and used it. Behind this “many spectators, few doers” phenomenon lies a structural mismatch in AI tool adoption — the people who truly need AI tools don’t know how to use GitHub, and the people who know GitHub don’t need generic tools. The ceiling of any AI tool is determined by the domain depth of the person injecting knowledge into it, not by AI’s capabilities alone.
After the article went live, this comment appeared:
Figure 1
“I’m a frontline engineer at an automaker. The pressure right now is crushing. Seeing a project like this gives me mixed feelings — the countdown to being swept away by this wave has probably started…”
That article, across both my WeChat Official Account and LinkedIn, reached over 150K people — nearly 30K reads and 2,000+ shares on WeChat, nearly 130K impressions and 1,400+ likes on LinkedIn.
Yet when I checked GitHub — only about 50 people had actually forked it.
150K spectators. 50 doers. A conversion rate under 0.03%.
At first, I assumed it was a technical barrier — maybe people didn’t know how to use GitHub or Claude Code.
Turns out it’s not that simple.
1. The Real Barrier Isn’t Technical — It’s a Structural Mismatch
Over the past few weeks, I’ve discussed this with all kinds of people — OEM and Tier 1 engineers, AI Agent startup founders, university professors, consultants. The conclusion I reached surprised even me:
The people who truly need these AI tools don’t know how to use GitHub. The people who know GitHub don’t need these generic open-source tools.
This isn’t a joke. It’s a structural mismatch. Let me explain.
How AI-Native Companies See This Project
The team I work closely with — nearly everyone uses Claude and Cursor for daily work. Everyone is figuring out how to automate their own tasks with AI. Their reaction to generic open-source projects like this?
Not very interested.
Not because it’s bad, but because they’re already building their own — customized AI tools tailored to their company’s processes, their team’s know-how, their product’s requirements. A generic “functional safety Agent” is nowhere near as useful as their own version, packed with internal case studies and templates.
How Traditional OEMs See This Project
On the other side, a consultant friend reached out. A major OEM client wants to “boost efficiency with AI” — building AI Agents simultaneously for chassis, body, and autonomous driving domains. The idea: let AI read requirements documents and automatically generate test cases.
The demand is real and urgent. But these frontline engineers work with Excel and Feishu (Lark), not GitHub and Terminal. Ask them to fork a repo, configure Claude Code, and set up a .claude directory — they can’t, and they don’t have time to learn.
Figure 2
Two Cases, One Contrast
Case A: A consultant took on an OEM project to build AI Agents for multiple domains simultaneously. The problem: he lacks deep engineering experience in those domains. His only option is to collect documents from the client and do “black box” training — dump documents in and let AI extract what it can. My assessment: some value, but hard to go deep.
Case B: An entrepreneur in Germany with 20+ years of cockpit development experience. His company builds cockpit products as a Tier 1 supplier for OEMs worldwide. He’s also building AI Agents for the cockpit domain. The difference: he has two decades of cockpit development experience and an existing product portfolio. He knows exactly which pieces of know-how are worth feeding to AI. My assessment: this one might actually work.
Where’s the Gap?
It’s not a gap in AI capability. The same Agent or Skill, used by two different people, produces wildly different outputs.
The gap is in the domain depth of the person injecting knowledge.
The ceiling of an AI tool = the injector’s domain depth x AI capability.
Figure 3
AI capability is the same for everyone. What determines the outcome is what you pour into it — the pitfalls you’ve encountered in this industry, the failure modes you’ve witnessed, the judgment criteria you’ve built over the years. That’s the raw material AI is truly missing.
A recent article from a16z (“Institutional AI vs Individual AI”) captured this well:
Domain-specific solutions built for particular tasks consistently outperform general-purpose large models — and this advantage compounds over time.
Translated into automotive industry terms:
Anyone can generate a generic AI Agent, but an AI infused with domain know-how becomes a weapon — and that weapon gets sharper with use.
2. Full Disclosure — I Haven’t Used It Myself Either
Here’s an honest admission: my GitHub fork, plus the WeChat article about it, took roughly 2 hours total. It was a Sunday morning, and I did it almost entirely with Claude Code’s automation.
I haven’t personally run a single HARA analysis in Claude Code, nor have I used it to generate a SOTIF triggering condition report.
The reason is simple — these specific analyses are done by the engineers on the team. They’re the ones working with tools, standards, and real projects every day. My day-to-day is more about setting direction, defining methodology, and reviewing outputs. The team I work with just received the Outstanding Contribution Award from China’s Automotive Functional Safety Standardization Center — an award earned not by any single person, but through the practical experience of frontline engineers and team collaboration. The fact that I haven’t personally run this tool actually proves a point:
For AI tools to be truly useful, you need both frontline engineers with hands-on experience AND someone who can systematically inject that experience into the tool — these are two different types of value, and you need both.
A few days ago, an open-source project lead from Renault Group commented directly on my LinkedIn post:
This project is “AI slop” — AI-generated froth. An LLM’s built-in knowledge is enough to produce this stuff.
He was half right. Generic Agents can indeed be whipped up in seconds — ask Claude to write a “functional safety engineer Agent” and you’ll have one in 5 seconds. But that kind of Agent is nothing like what you get when a veteran engineer with 15 years of HARA experience injects every pitfall, every case review, every judgment framework they’ve built. The former is AI slop. The latter is a weapon.
Another peer on LinkedIn put it more practically:
A tool’s value lies in helping you produce a first draft faster, so you can spend your energy on judgment and revision instead of starting from scratch. But at the end of the day, the person who signs off is still you.
That’s the right expectation: AI produces the draft, the expert makes the judgment. AI won’t replace functional safety engineers, but it will double the effectiveness of good ones.
3. An Unexpected Piece of Good News — Copyright Isn’t as Bad as You Think
The LinkedIn comment section also hosted a discussion that never surfaced in China:
Does extracting know-how from standards like ISO 26262 using AI constitute copyright infringement?
This thread was kicked off by the CEO of a safety-critical software company. It drew 12 likes and 15 in-depth replies — the most active discussion thread under the entire post.
Eventually, an industry expert dug into ISO’s copyright policy and delivered the key conclusion:
The verbatim text of standards is copyright-protected. But know-how, workflows, and methodologies derived from standards can be freely used and shared.
This conclusion has barely been discussed in China, but it’s enormously important for teams building AI tools — especially those targeting international markets. It removes the biggest psychological barrier: “Is it illegal to feed standards knowledge into AI?”
Of course, the prerequisite is that you don’t copy-paste the standard’s text verbatim. Distilling key points, summarizing methods, designing workflows — these derivative outputs are fair game. For precise boundaries, consult an IP lawyer.
4. Why Did the Original Repo Go Private?
Many readers asked in the comments: why did the Bosch engineer set the original repository to private?
My reading: with hundreds of thousands of impressions on LinkedIn, that level of visibility likely made his organization uneasy. When a personal side project suddenly goes viral, it’s understandable for a corporate IP team to step in.
But the story isn’t over.
The Bosch engineer and I are already exploring other potential collaboration models — finding more reasonable ways to open-source valuable AI tools. The tension between large corporations and individual innovation, between corporate interests and the open-source ethos, deserves its own article.
More to come as things develop.
5. Back to That Frontline Engineer
Let’s return to the comment I opened with — the one that made me stop and think for a long time.
That frontline engineer’s anxiety is real. But here’s what I want to tell him:
The data analysis you do every day, the safety requirements you write, the issues you flag in review meetings, the pitfalls you’ve discovered during vehicle testing — that know-how is exactly what AI tools are missing.
AI can generate a perfect-looking HARA table in 5 seconds. But judging whether that table is correct, whether it’s missing something, whether it’s thorough enough — that takes you.
The future winners aren’t the people who can use AI — eventually everyone will use AI, just as everyone now uses a smartphone — but the people who can systematically inject domain know-how into AI.
You’re not the person being replaced by AI. You’re the person who makes AI actually work.
Is your company building AI tools in-house, or looking for external solutions?
Share your observations in the comments — your insight might be featured in the next article.