A coding agent can build a perfect traceability matrix in one session, which means a perfect matrix no longer proves the work happened in order.
A trace used to be decent evidence on its own. Linking a requirement to a design, to code, to a test, and to a result took people real time, so a clean matrix meant the work had probably been done the way the V-Model says. An agent can now draft the requirement, write the code, generate the test, and create every link at once. Under ISO 26262 and Automotive SPICE®, the evidence that still means something is the process that produced the work products, not the work products themselves.
Assessors have started to say so. VDA QMC describes the Automotive SPICE assessor's role moving from artifact inspection to governance inspection, with questions about AI usage policy, provenance records, and metric calibration. We covered that session in What changes for Automotive SPICE® assessors. This page is about the safety side.
Can you use AI-generated code under ISO 26262
ISO 26262 does not prohibit it, and it does not name AI coding tools. It does expect confidence in every software tool used to develop safety-related software, and Part 8 sets out the reasoning. Ask two questions about the tool: could a malfunction introduce an error into the product or fail to detect one, and how likely is that error to be caught by the measures around it. The answers set how much confidence you need. When the measures around a tool are very likely to catch its errors, the standard's reasoning lets you rely on those measures rather than qualifying the tool.
For a generative coding agent, that second question carries the whole case. Qualifying a large language model as a tool is not practical for most teams. So the argument becomes: whatever the agent gets wrong, our reviews and tests will catch, at the rigor the ASIL calls for.
Where that argument breaks
The error detection argument is made about the process, so it only holds if the process ran. Two things quietly undo it.
A skipped step. The argument says every agent change is reviewed and tested. One agent change that went around review is a change the argument does not cover, and a policy that says it cannot happen is not evidence that it did not.
A test the agent also wrote. If the same agent produces the code and the test that verifies it, the test is not independent evidence that the code is right. A shared misreading of the requirement passes both. The detection your tool confidence depends on has to come from something the agent did not produce: a human review, or tests derived from the requirements by someone else.
ISO/PAS 8800, published in 2024, does not help here. It addresses AI used inside safety-related vehicle systems, such as a perception model, not the coding assistant your engineers use.
What the record shows that the matrix does not
When a global tier-one automotive supplier rebuilt one project's record into 133,729 process events, it found 18% of stories had bypassed code review, a bypass rate that tracked its regression rate, with regressions making up 72% of defects. Every one of those stories had its work products. What it lacked was a step, and only the process record shows a missing step. That was before agents.
What to have ready
- A tool evaluation for each AI tool. What it does in your lifecycle, what could go wrong, and which measures catch it. For a coding agent, name the reviews and tests the argument relies on.
- Separate authorship of code and verification. For safety-related items, the tests that verify agent code should not come from the same agent session that wrote it, or should be reviewed as if they did.
- Provenance for each work product. Who or what produced it, against which work item, and whether it passed review the first time or came back.
- Proof per change. Records that show the reviews and tests in your argument actually ran on every agent change, captured from the first agent session, not rebuilt the month before the assessment.
The record behind the matrix
The matrix will keep looking perfect. Bloomfilter shows what it cannot: the order the work happened in, which steps an agent did, and where a review or test was skipped, rebuilt from your ALM, version control, CI, and agent sessions. That is the record your tool confidence argument and your next assessment rest on. How Bloomfilter supports regulated software teams.