Abstract: Bosch Lead Engineer Thejeswarareddy R open-sourced an agent system that systematically injects automotive engineering standards into Claude Code, covering 75+ skill categories. I forked it and added autonomous driving safety standards (ISO 21448/34502/4804, etc.), upcoming mandatory Chinese national standards, and in-depth SOTIF engineering practices. This article breaks down the project’s architectural highlights and my additions.
Figure 1
If you are a junior functional safety engineer in the automotive industry, you have almost certainly lived through this scenario:
9 AM. Your project manager pings you: “We need ASIL decomposition for this ADAS function — get me an updated HARA table before the client review this afternoon.”
So you crack open ISO 26262 Part 3. Half an hour to locate the ASIL determination rules. Another 20 minutes refreshing your memory on Severity (S), Exposure (E), and Controllability (C) definitions. Then you open the Excel template and start filling in rows. Halfway through, you are unsure about the ASIL rating for a particular failure mode, so back to the standard. By the time the first HARA draft is done — three hours have passed.
And that is just one step in one standard.
You also need to look up AUTOSAR naming conventions, MISRA compliance rules, ISO 21434 TARA analysis templates, ASPICE work product checklists…
None of this is intellectually hard, but it is extraordinarily time-consuming. By rough estimates, a junior functional safety engineer spends 10–15 hours per week on “flipping through standards, cross-referencing clauses, and filling in templates.”
I have always felt there should be a better way, but never got around to building one. Then last week, I saw what a Bosch engineer had done.
What This Bosch Engineer Built
Thejeswarareddy R, a Lead Engineer at Bosch, did something that genuinely impressed me:
He systematically “injected” the most commonly used automotive software engineering standards and domain knowledge into the AI assistant Claude Code, building a complete open-source agent system.
Figure 2
This is not the “dump a few standard summaries into ChatGPT” style of Q&A. What he built is a carefully architected, engineering-grade system:
Figure 3
Let me spell out what this means in practice.
Previously, doing ASIL decomposition meant flipping through standards, building templates, and filling in spreadsheets yourself. Now you can simply say:
“Run a HARA analysis for the emergency braking function of this L3 Highway Pilot — output the ASIL ratings.”
The AI draws on injected ISO 26262 knowledge to produce a structured HARA table following the standard process. Your job becomes reviewing and making judgments — instead of spending time searching and formatting.
There are several things I particularly appreciate about this project:
First, the architecture is thoughtfully designed. It uses an “append-only” installation approach — your existing development environment is not modified by a single character. All new content carries an automotive- prefix to avoid conflicts. This tells you the author is a real engineer who understands you never mess with someone else’s working environment.
Second, the sheer scale is impressive. 75+ skill categories means he systematically organized the knowledge across ADAS, BMS, V2X, powertrain, diagnostics, OTA, digital twins, zonal architecture, and over a dozen other automotive subdomains. This is not something you put together in a day or two.
Third, it is fully open-source. MIT license — free to use, modify, and even deploy in commercial projects.
My Additions
After all that praise, here comes the “however.”
The project’s center of gravity is traditional automotive software engineering — ISO 26262 functional safety, AUTOSAR architecture, MISRA coding standards, ASPICE process management — all very solidly done.
But two areas are relatively thin, understandably given the author’s work background and geography:
First, specialized standards for autonomous driving safety. A wave of important ADAS/AD safety standards has been published in the past two to three years, and the original project barely touches them.
Second, the Chinese standards and regulatory framework. China is rapidly building its own intelligent connected vehicle standards system, including two upcoming mandatory national standards (GB). The original project has zero coverage here.
These two areas happen to be exactly where I work day-to-day, so I forked the project and made some additions. Here is what I contributed:
Figure 4
Addition 1: Autonomous Driving Safety Standards
In recent years, AD safety assessment has moved rapidly from “no standards to follow” to “the standards framework is largely in place.” The following standards form the current core framework for AD safety evaluation:
Figure 5
In my fork, each of these standards is integrated as structured skill files — not as summaries, but with core frameworks, key concepts, and engineering implementation guidelines extracted.
Addition 2: Chinese Standards and Regulations
For engineers developing L2/L3 products in the Chinese market, two upcoming mandatory national standards are impossible to ignore:
The first is the safety requirements for L2 combined driving assistance systems (mandatory GB standard).
Figure 6
This is China’s first mandatory national standard targeting L2 combined driving assistance systems. It takes effect in 2027, and all newly announced vehicle models equipped with L2 combined driving assistance must comply. It covers ODD definition, functional safety, SOTIF, DMS, HMI, cybersecurity, and more. If you are developing L2 products at an OEM or Tier 1 in China, this standard will be your “client requirement” starting next year.
The second is the safety requirements for automated driving systems (mandatory GB standard).
Figure 7
This is a national strategic-level mandatory standard aimed at L3 market access (still in the public comment phase). It requires ADS safety performance to be at least equivalent to that of a “competent and careful human driver.” The standard introduces Safety Management Systems (SMS), simulation test verification, In-Service Monitoring and Reporting (ISMR), and other systematic requirements, covering L3 and L4. The draft currently runs to 50 pages with a clear structure, and it is essential reading for any team working on ADS product certification.
Beyond these two mandatory standards, another one worth watching is the L3 joint technical requirements for functional safety and SOTIF (GB/T draft, 132 pages). This represents a uniquely Chinese initiative — internationally, ISO 26262 and ISO 21448 are two separate standards, but China is the first to propose a framework for joint analysis of both within L3 systems. The draft defines 11 vehicle-level hazards (with ASIL ratings), residual risk acceptance criteria, and 10 critical hazard scenarios each for highway and urban driving.
All of these are covered in my fork, extracted from the actual standard draft texts.
Addition 3: In-Depth SOTIF Practices
The original project’s SOTIF coverage was limited to basic concepts. I added the full SOTIF engineering workflow: systematic triggering condition identification methods, hazardous scenario construction, scenario-driven test and evaluation frameworks, and SOTIF audit and assessment methods. This also includes the DFM (Driver Foundation Model) evaluation framework built by our team using 10.5M+ real driving trajectories.
It is worth noting that some of the standards mentioned above are still under development or in the public comment phase, and will be continuously updated…
What Does This Mean for the Industry?
Let me share a perhaps premature observation:
The AI-tooling of automotive engineering may arrive faster than we expect.
This does not mean AI will replace automotive engineers. The safety argumentation of ISO 26262, the scenario analysis of SOTIF, the architectural decisions of AUTOSAR — this core work still demands engineering judgment and experience.
But the repetitive tasks — standard lookup, template filling, clause cross-referencing, format compliance checks — these can genuinely be handed off to AI.
Thejeswarareddy’s project proves this is feasible. And my small additions simply demonstrate one fact: engineers with different backgrounds can layer their own domain expertise onto the same open-source framework. That is exactly the point of open source.
If you are an automotive engineer, this project is worth ten minutes of your time. And if you happen to have expertise in an area the original project does not cover — Chinese localization, in-depth cybersecurity practices, chip-level functional safety, or anything else — you are welcome to fork it and contribute your experience.
How to Get Started
Original project (Bosch engineer Thejeswarareddy R):
github.com/theja0473/automotive-claude-code-agents
My fork (with AD safety standards + Chinese mandatory standards + SOTIF practices):
https://github.com/AutoZYX/automotive-claude-code-agents
Installation:
git clone https://github.com/AutoZYX/automotive-claude-code-agents.git ./install.sh
Your existing development environment will not be modified. Run ./install.sh –uninstall for a clean removal.
To be honest, both this GitHub fork and this article were completed within an hour of discovering the Bosch engineer’s project, using Claude Code. There are certainly rough edges — feedback and corrections are very welcome.
I would love to hear from you in the comments: What standard or engineering task eats up most of your time? What other standards, regulations, or best practices would you like to see added? I will keep updating the GitHub repository.