Start from a working sample
Choose a supported board and build an official sample unchanged. Record the Zephyr revision, SDK, board identifier and build command. Confirm flashing and the expected device output before editing. This establishes a baseline, helping distinguish a later regression from cable, debugger or initial environment problems. Keep the successful build log with the project.
Give AI a small contract
Request one patch, such as handling a sensor read timeout. Supply the interface, units, error behavior and blocking constraints. Ask for assumptions and tests before implementation. Separate data parsing from peripheral access so boundary values can be exercised without the board. Check suggested APIs against the documentation for your selected revision, rather than accepting plausible names.
Check several layers
Build with the recorded configuration and investigate new compiler warnings. Test a valid response, malformed data and timeout behavior. Ztest provides test structure and assertions; select an appropriate test platform. Then check reset, reconnection and actual operation duration on hardware. Compilation success does not establish correct peripheral behavior, and a host test cannot verify board wiring.
Leave a reproducible trail
Attach configuration, test results and a short hardware record: board, wiring, input conditions, expected result and observed result. Keep the original failure reproducer. Use that evidence as context for the next AI request. The useful deliverable is a small verified change and a regression test that protects its behavior during later edits.
Checks before accepting the result
Every AI-proposed patch needs build checks, automated tests and a hardware observation record.