AI writes the code. Who guarantees the quality?

On evidence, verification, and why the toolchain matters more than the model.

Speed is not the constraint. Evidence is.

AI coding assistants have changed what a single developer can output in a morning. Code that once took hours to sketch out gets generated in seconds. For exploratory work and rapid prototyping, the productivity gains are real.

But in regulated embedded development, automotive software under ISO 26262, medical devices under IEC 62304, industrial control systems under IEC 61508, speed was never the bottleneck. Evidence is. Not evidence that the code runs, but evidence that it was produced under defined practices, checked against the right standards, and traceable from requirement to test.

This is the uncomfortable truth about AI assistance as typically deployed: it accelerates the part of the curve that was never the problem, writing code while adding pressure to the part that was already expensive: verification, validation, and compliance attestation.

AI generates code. It doesn’t generate compliance.

Modern AI tools are genuinely capable. They can suggest implementations, complete functions, and generate test skeletons. When you ask for an RPM calculation in C, you’ll get something syntactically correct and often logically sound.

What that output won’t carry is compliance.

 A simple AI-generated function may look fine on first read. A static analyzer enforcing MISRA C 2012 Rule 10.3 will flag the implicit type conversion as a defect, one that must be resolved before the code can be traced to a verified requirement. 

This pattern repeats across every standard that embedded teams work to:

• MISRA C/C++: The baseline for safety-critical C and C++ development. Restricting the language to a well-defined subset minimizes the risk of undefined behavior, non-negotiable in automotive, industrial, and medical domains. As AI tools generate more C and C++ output, MISRA compliance becomes a critical gate on everything that enters the codebase.

• CERT C/C++: Focuses on preventing coding patterns that attackers exploit. Where MISRA targets safety, CERT C/C++ targets security, two concerns that increasingly overlap in connected embedded systems.

• CWE: A catalog of software weaknesses that recur across codebases. For teams reviewing AI-generated code, CWE provides a structured vocabulary for identifying vulnerabilities a model may unknowingly reproduce from training data, because models learn from all of it, compliant and non-compliant alike.

None of these standards is enforced by the model. That’s the developer’s responsibility, supported by the right toolchain.

The verification bottleneck

Verification and validation already consume 40% or more of R&D spend in safety-critical programs. That’s not inefficiency, it’s the cost of building the evidence chain that regulators and certification bodies require.

What happens when AI accelerates authoring but leaves the evidence chain unchanged? More code flows into the verification pipeline. The bottleneck widens. The senior safety engineer reviews a larger trace matrix. The release gate doesn’t move.

 AI tools attack the part of the development curve that was never the constraint. The constraint was always the back half: static analysis, dynamic testing, coverage measurement, traceability, and sign-off. Accelerating authoring without addressing that back half is not a productivity improvement for a team shipping certified firmware. It's upstream pressure on an already strained process. 

Where quality actually lives

Closing the gap means bringing static analysis, dynamic analysis, and coverage measurement into the development loop, not as a downstream audit, but as a continuous inline activity. The right workflow doesn’t separate code generation from compliance checking; it integrates both.

Static analysis inline with the build

C-STAT, part of the IAR toolchain, flags MISRA C, MISRA C++, CERT C, and CWE violations at the point of code entry, before the code reaches a review board or a certification audit. AI suggests, the developer reviews, C-STAT verifies.

 Image: C-STAT analysis report showing violations across MISRA C 2012 and CERT C checks on a real embedded project  

Dynamic analysis in the debug session

C-RUN instruments the code during the debug session and detects memory leaks, bounds violations, integer overflow, and unhandled switch cases, defects that static analysis can’t always catch because they depend on execution state. In an AI-assisted workflow, where generated code may be structurally sound but behaviourally surprising, runtime instrumentation is not optional.

Image:  C-RUN runtime checking heap errors and bounds violations at debug time 

The model suggests. The developer judges.

None of this is an argument against AI. The productivity gains are real. In embedded software, where skilled developers are scarce and project complexity is growing, any tool that accelerates authoring has genuine value.

But in an AI-assisted workflow, the developer’s role shifts from code author to quality curator. The craft doesn’t disappear, it reorients. Instead of writing every function from scratch, the developer evaluates AI suggestions against domain knowledge, runs them through the analysis tools, and makes the judgment calls no model can make: whether the logic aligns with the safety intent, whether the test suite covers the right scenarios, whether the architecture remains coherent.

That judgment layer is what turns generated code into attested code. Attested code is what regulated industries require.

CI/CD: automating the evidence

Inline tooling catches issues at the workstation. But in a team environment, workstation-level checks alone aren’t enough. The pipeline is the enforcement point — where every commit is automatically tested against the standards the organization has committed to, regardless of how the code was produced.

When one developer session can produce more code than a previous week’s output, manually triggering quality checks stops scaling. The checks must run automatically, on every push.

IAR Build Tools provides the same compiler, linker, and toolchain used in IAR Embedded Workbench, packaged for headless execution in CI. Whether the pipeline runs on Jenkins, GitHub Actions, or Azure DevOps, the build in CI is identical to the build on the developer’s machine. ISO 26262 and IEC 62304 both require that the tool configuration used to produce release artifacts be documented and reproducible. IAR Build Tools makes that demonstrable.

C-STAT runs headlessly in CI. Violations are reported as build output. Coverage trends are tracked over time. Architectural drift is visible immediately. The compliance evidence doesn’t need to be assembled at release, it accumulates throughout the project.

The platform underneath it all

The tools above multiply in value when they sit inside a governed development platform, one where builds are reproducible, tool qualification is documented, and the evidence chain from source to certification artifact can be reconstructed.

The IAR Platform is designed around this requirement. Tool qualification support covers ISO 26262 (TÜV SÜD-certified), IEC 61508, and IEC 62304. C-STAT and C-RUN integrate directly into that environment, meaning compliance checks run in the same context as the build.

That is the difference between a productivity story and a compliance story. Not the AI. The platform and the toolchain it sit on.

AI writes the code. The toolchain earns the certificate. IAR gives you both.

What's next?

If you want to see how the IAR Platform holds up in practice, the interactive demo walks through compliance with safety-certified compilers, code analysis, and CI/CD integration.

For a deeper look at AI-assisted workflows in safety-critical development, watch the on-demand webinar "Escaping the 100 M-line Trap", practical demo included.

Or if your domain is industrial automation, "Breaking the Smart Industry Bottleneck" covers how an IEC 61508-certified foundation removes the verification overhead that slows Smart Industry initiatives.