AI Coding Agents and ISO 26262: Classify the Use, Not the Tool

An agent opens a merge request on a Tuesday afternoon. Four hundred lines, a new diagnostic handler, unit tests included, coverage at the target, analyzer report clean. It took eleven minutes. The question a functional safety engineer has to answer is not whether the code looks good. It is what, if anything, this changes in the safety argument.

Less than the enthusiasts hope, and more than the skeptics fear.

What the standards say, and what they do not

ISO 26262:2018 was written before coding assistants existed and does not mention them. The newer ISO/PAS 8800:2024 is about AI inside the vehicle, such as a perception model in a driver assistance function, and its scope offers no dedicated guidance for development tools that are themselves AI-based.

That is good news: the existing rules already cover the case. Code that an agent writes is code. It meets the project coding guidelines (ISO 26262-6:2018, Clause 5.4), goes through unit design, implementation and verification (Clauses 8 and 9), and lands in the same configuration management. The assistant itself is a software tool, and ISO 26262-8:2018, Clause 11 says how to decide how much confidence a tool needs.

Classify the use, not the product

Clause 11 asks two questions about each use of a tool. Could a malfunction introduce an error into the product, or fail to detect one? That is tool impact. How confident are you that something else in the process will prevent or catch that error? That is tool error detection. Together they give the tool confidence level, from TCL1, which needs no qualification, up to TCL3. Our guide to tool confidence covers the method in detail.

The standard's own example for a code generator is the key. When the generated source is verified the way ISO 26262 requires, confidence that its errors are caught is high. An AI assistant drafting code sits in the same position. If every generated change goes through the planned review, the rule-set analysis and requirements-based tests with structural coverage, the case for TCL1 is straightforward.

The same assistant lands very differently depending on what you let it do.

The last row is the one to watch. The qualification methods for TCL2 and TCL3 all assume a tool you can identify and hold still: a track record with that exact version, a review of the vendor's process, testing against your own use cases, or a tool built to a safety standard. A hosted model that is updated without notice gives you none of that. An AI reviewer can add findings, but its silence must never count as approval.

Where it genuinely helps

None of this argues against the tools. Used well, they take on the work engineers least enjoy and most often rush. Explaining a legacy unit nobody has touched in six years. Turning a terse analyzer finding into a readable account of which rule fired and why. Proposing test cases from a requirement for an engineer to review. Writing the first draft of a deviation rationale that a human then tightens and signs.

In each, the output is cheap to check and a person stays in charge.

Where it bites

Four failure patterns keep coming back.

The analyzer goes quiet. Ask an agent to bring the static-analysis findings to zero and it will. Some of its fixes are a cast or a suppression comment that makes a real defect invisible. Every suppression needs a recorded reason, a demonstrated false positive or an approved deviation. One without a record is worse than the finding it hid.

Tests that mirror the code. Generate unit tests from the source file and the expected values come from the code under test. Coverage climbs to the target, and an off-by-one limit check now has a test that passes. Coverage measures how complete your requirements-based tests are. It never says the expected values are right.

Confident references that do not exist. Models produce rule numbers, clause numbers and API behavior that sound exact and are wrong. A deviation that cites a MISRA rule which says something else becomes a finding at the next audit.

Review becomes the bottleneck. Generation got faster; review did not. A reviewer facing a 400-line generated change skims it, and skimming is not the review method in your safety plan. Keep generated changes as small as your review method assumes.

Agents raise the stakes

An assistant suggests. An agent acts: it edits files, runs the build, reads the results and tries again until everything is green. That loop is useful, and also the risk: green is whatever the agent can see. If it can edit the analyzer configuration, the coverage exclusions or the expected values in the tests, the shortest path to green runs through them.

So protect the gates: an agent may propose changes to them, never merge them. Run agents with least privilege: a sandbox, no signing keys, no production credentials, no access to the tool that flashes a test vehicle.

A policy that fits on one page

• Generated and hand-written code take the same verification path. No lighter route, and no extra paperwork that tempts people to hide it.
• Each use of an AI tool appears in the tool list with its tool impact, its error-detection argument and the resulting TCL.
• The tool and model identifier are recorded, and no argument depends on a hosted model behaving the same next month.
• The reviewed commit is the evidence. The prompt is not, because the output cannot be reproduced from it.
• AI review adds findings. It never replaces the review the safety plan defines.
• Gates are protected, and agents run with least privilege.
• Every standard, rule or API reference a model produces is checked against its source.

The engineer still signs

The tools will keep improving, and the argument above will not change, because it never depended on how good the tool is. It depends on the process that catches the tool's mistakes. The engineer who commits a change and the reviewer who approves it are accountable for it, whoever typed it first.

The Software Coding Guidelines concept page follows the full route from rule set to safety case, including where each AI use fits.