Before you begin

The promise of this book is practical: you will learn to use an assistant while retaining the ability to explain, review, and reproduce the result. You will not be asked to trust a program because its author was an AI, or reject useful assistance because it can be wrong. You will learn to connect a claim to the code, source document, or observation that can support it.

The intended reader has basic firmware experience. You should recognize a function, an input, a conditional, and an output. You need not already understand Git, Markdown, agent instructions, or skills. Those are introduced in sequence. The glossary is available whenever a new term interrupts the flow, and the terminal reference explains the small command vocabulary used here.

The book is about AI-assisted development. The reference firmware does not need to run a language model or contact a cloud service. Its core behavior is ordinary C++ policy, parsing, reporting, and timing logic. That makes the engineering decisions visible while we learn how to work with a model and its tools.

What you need

Use a computer that can run the selected editor, Git, the supported native C++ compiler, and Arduino CLI with the recorded board platform. The demonstrated learner environment is Windows 11 ARM under a standard user account. The supported-version reference distinguishes that path from the separately checked macOS host route and unverified Linux guidance. A similarly named application or a different architecture is not automatically the tested combination.

The selected AI path is browser chat followed by Codex in VS Code using the available subscription sign-in route. No separately billed API client or project API key is required. Account eligibility, limits, and interface controls can change; check the current official guidance linked in the setup chapter and your actual account. Saved original reference responses let you practice analysis when a live interaction is unavailable. Label those exercises honestly rather than inventing a new model run.

Use a GitHub account you control for the private practice repository. Public publication is unnecessary. The book's demonstration accounts are separate from the author's working accounts. You should similarly understand which project contents you share and keep credentials and unrelated material out of learning artifacts. Private sign-in intervals are intentionally omitted from recordings.

No board, sensor, cable, bench instrument, or hardware purchase is required for the core chapters, course, or capstone. The documented example target is the ESP32-S3 Feather variant identified in the project hardware reference, with a BME280 as an optional future acquisition target. The required firmware acquires synthetic values. Cross-compilation and host tests do not turn those values into physical measurements.

How to use the chapters and lessons

Read each chapter's outcome and starting checkpoint first. Work through the example, then attempt the lab before consulting the separate instructor key. Finish the checklist, three explanatory review questions, and transfer task. A chapter lab produces an artifact such as a brief, a reviewed commit, a constraints table, or a test record. Keep those artifacts together in your learner project or notebook.

The course has eight modules with five lessons each. A lesson focuses on one action and an observable check. Watch or read the demonstration, pause to perform the exercise, and compare your result with its criteria. The lesson text remains useful when you cannot play media. Narration and captions support the same content; neither replaces the actual commands, files, and evidence you produce.

Each module ends with a challenge and a five-question self-check. Four correct answers is the recommended quiz threshold, with unrestricted retry and immediate explanations. This is a learning aid, not a professional credential. A progress acknowledgment records that you reviewed a lesson; the practical artifact determines whether you performed its engineering task.

In the standalone website, progress belongs to your browser. Use its export function before clearing browser data or moving to another device, and import your saved progress when needed. Reset deliberately when you want a fresh self-study record. The LMS package stores its attempt through the LMS instead; do not assume a browser-local progress file and an LMS attempt are the same record. Neither kind of progress is evidence that a board was physically tested.

Use the chapter resources at their named stage. CP00 is an inspection packet. CP01 is a fixed synthetic host/firmware baseline with no automated assertions or threshold policy. Later stages add documents, instructions, skills, normal/fault behavior, tests, and finally the configurable capstone. Extract each checkpoint into a new exercise folder rather than overwrite useful work. ZIPs provide content; the separate generic history bundle provides the graph needed for branch, conflict, and revert exercises.

Some introductory examples are deliberately simpler than the final project. Chapter 1's original string-return function and Chapter 2's fictional BenchNote note use OK/WARN/FAULT. CP00 and the final reference project have their own defined state names. Chapter 3 includes an original validity fixture distinct from CP00's log. The text names these boundaries so that a useful simplification does not become an accidental project requirement.

What counts as evidence

Documented means a specific applicable reference supports the claim. Code-supported means the supplied source supports the statement within its input assumptions. Observed or tested means a named action actually ran and its result was recorded. Synthetic means the input was deliberately generated for software work. Illustrative means a passage or output was constructed to explain an idea. Unresolved means the current material is insufficient to decide the claim.

Expected output is a prediction or acceptance criterion until your command executes. Preserve actual failures and their context. If a video is an edited replay, it should be labeled accordingly; editing for readability must not change the displayed test result or imply an uncut chronology. The evidence reference provides a small record format that keeps input, action, result, and limitation together.

A compiler checks a program against its build rules and selected target. A host test exercises specified software behavior. A synthetic replay demonstrates that behavior for controlled events. A primary document can establish intended pin or interface constraints. A physical instrument measures an actual assembly. Each is valuable, and each has a scope. The habit of saying exactly what passed is central to the course.

Keep your own pace. Installation, reading, and debugging take as long as they take. Short recordings can omit waiting intervals with an explicit transition; that is not a promise that your machine will finish in the same time. If a check fails, use the troubleshooting index to classify the problem, preserve the evidence, and continue independent work where possible. Your aim is a result you understand well enough to maintain.