DVAR engineering guide

AI-generated firmware: a practical review checklist

Updated 5 September 2026

AI-generated firmware should enter the same review and test process as any other change. Start with the intended behaviour, inspect the proposed code, then collect evidence from the environments that matter to the product. A plausible explanation or a successful build is only part of that evidence.

Illustrative visual generated for this guide. It does not depict a DVAR customer project or a completed test.

OpenAI recorded the release of GPT-6 Astra on 3 September 2026, including coding among its uses. That makes this a timely opportunity to review how proposed code reaches a device. This guide makes no claim that a particular model produces correct firmware or improves engineering productivity by a measured amount. Source: OpenAI API changelog.

Write the acceptance criteria before the prompt

For a bounded change, write down the expected input, output, error response and constraints. Our suggested starting point is a short change brief containing the target board, software development kit (SDK), compiler, relevant interface documentation and behaviour that must remain unchanged.

For example, asking for a sensor driver leaves many decisions open. A more useful task might ask for a small change to timeout handling while preserving an existing interface. State the expected response to a missing sample and which tests must continue to pass. Let the requirement determine the tests, rather than accepting whatever tests accompany the generated implementation.

GitHub’s guidance similarly recommends checking generated code against the project’s purpose, requirements and architecture, and examining invented APIs, ignored constraints and tests that have been removed or skipped. Here, an API is the interface through which software components interact. Source: GitHub’s review guidance.

Check the change against the actual platform

Review the diff, not just the assistant’s summary. For each new function or dependency, locate the matching documentation for the version in your project. Check that any register, pin, timing assumption or buffer size comes from the relevant requirement or device documentation. Record uncertainties as review questions.

Our practical review questions are: does the code handle errors, respect resource ownership and preserve surrounding behaviour? Can another engineer explain the change? Has the patch altered a test, build setting or dependency outside the requested scope? These are suggested checks to adapt to your product, not evidence that a particular design is safe.

Keep code inspection and execution separate

NIST’s Secure Software Development Framework v1.1 treats review and analysis of human-readable code in practice PW.7, and executable-code testing in PW.8. Both matter to a review record. The framework is security-development guidance; it is not a firmware certification or a substitute for product-specific verification. Source: NIST SP 800-218, PW.7 and PW.8.

For the proposed change, our recommendation is to keep the build output, new warnings, static-analysis findings and actual execution results together. Static analysis examines code without running the application. Each finding needs a disposition: corrected, accepted with a reason, or still open. A compile result should be labelled as a build check, not as an executed functional test.

A suggested review workflow. The required depth and acceptance criteria depend on the product.

Know what a host test actually exercises

Zephyr provides a useful example. Its documented unit_testing board builds selected code and the Ztest harness into a host executable without the Zephyr kernel or driver model; dependencies need substitutes such as mocks. The documented native_sim environment instead builds a full Zephyr system for host execution. They answer different test questions. Source: Zephyr Ztest documentation.

Zephyr’s native/POSIX documentation also states that the environment cannot diagnose hardware/software races or similar timing issues. Use that limitation to decide what needs target evidence. For our suggested sensor example, separate the logic for handling an injected timeout from checks of the actual device interface. Source: Zephyr native-platform limitations.

These Zephyr links refer to the current documentation checked on 5 September 2026. Match instructions to your project’s release, board and toolchain before using them; this article is not a tested build recipe for a particular platform.

Make the evidence concrete

The following example is illustrative. Assume an agreed requirement says a missing sensor sample must produce a fault indication and must not be presented as a new measurement. No hardware experiment or product result is claimed here.

Logic check: inject a missing-sample result into an isolated test and inspect the resulting state and output.
Target check: under an agreed bench procedure, exercise the relevant failure condition on the actual target and compare its behaviour with the requirement.
Recovery check: define how valid readings resume, then verify that sequence separately.
Record: keep the firmware revision, board revision, setup, expected result, observed result and unresolved issues together.

If using Zephyr’s Twister runner, inspect the individual results: its status documentation distinguishes passed, skipped, blocked and not-run cases, and a passing suite may contain skipped cases. The runner also supports execution on appropriately configured hardware. Source: Twister statuses; hardware execution guidance.

Use this checklist at the review

The intended change and acceptance criteria are written down.
Interfaces and dependencies have been checked against the actual project versions.
Build, analysis and test findings have been reviewed, including skipped tests.
Target-dependent behaviour has suitable evidence or is explicitly still unverified.
A responsible engineer has reviewed the change and its remaining limitations.

AI can participate in this process, but it should not approve its own output for use. OpenAI recommends human review before practical use, particularly for code generation. Give the reviewer access to the requirements, source documents and test evidence. Source: OpenAI safety guidance.

If you need help connecting code changes with hardware integration and verification, explore DVAR’s embedded software and firmware and automated test equipment services. Bring the current design stage and the evidence needed for the next decision.