1. AI at the Embedded Workbench

After this chapter, you will be able to choose a useful AI task and identify the evidence needed to accept its answer. You need basic familiarity with a firmware program: a function accepts inputs, performs work, and produces an output. You do not need a board, paid API access, or previous experience with a coding agent. Start with checkpoint CP00 and keep a plain text file named evidence-annotation.md beside your copy of its resources.

Imagine that a temperature monitor reports a plausible number but never raises its warning. An assistant suggests changing a comparison, replacing the sensor library, and moving a wire. Those suggestions involve three different kinds of knowledge. The comparison is in your code. The library interface belongs to a particular software version. The wire exists on a physical assembly. A fluent paragraph can mix them so smoothly that the distinctions disappear. Your first engineering task is to put the distinctions back.

This book develops a sensor monitor because it gives us a small, understandable system with real decisions to make. The central skills apply equally to a motor controller, garden logger, instrument, or classroom robot. We will use AI to reduce the effort of understanding and changing the project, while keeping its behavior explainable. The finished result includes code, requirements, tests, a useful history, and instructions that let another session resume the work.

1. Choose assistance with a visible result

AI is useful when you can give it relevant material and assess what comes back. Ask it to explain an unfamiliar function, identify missing cases in a test table, compare a change against a requirement, or turn a rough setup note into a sequence you can actually follow. Each request has an artifact you can examine. An explanation names lines. A test table lists inputs and expected outputs. A review connects a finding to the changed code. A setup guide succeeds when a second checkout can follow it.

Start with work you can already judge. If you know enough C++ to recognize a changed comparison, use the assistant to explain it and draft a boundary test. If you have never read a sensor datasheet, ask the assistant to help locate the relevant section and define the terms. Do not make its first answer the sole basis for a connection you do not understand. There is value in having a patient guide, but the guide's confidence does not increase a component's voltage rating.

Choose the size of the task to fit your review capacity. “Design the complete firmware” creates a large result with many hidden decisions. “Explain how this function decides whether to raise a warning, without changing files” is small enough to check. Once that explanation is sound, a second request can ask for a specific change. This sequence preserves your ability to stop at a clear boundary.

Useful assistance also includes saying what is missing. If a request asks whether a library call is supported but omits the library version, a good response identifies the missing version. Treat an explicit unknown as progress when it prevents an unsupported decision. The next step is now concrete: inspect the dependency record or official reference, rather than ask for a more confident answer.

2. Separate model, application, and agent

A model is the learned system that processes input and generates output. An application supplies the interface around it: a chat box, attachments, conversation history, account settings, and available tools. An agent is a workflow in which model output can lead to actions, such as reading a file, executing a command, or making an edit. The exact capabilities depend on the application and its permissions. The official Codex IDE documentation describes an editor interface connected to project work; it does not make every chat window an editor agent. Codex IDE extension

These distinctions resolve a common misunderstanding. A browser answer can contain a shell command without having executed it. An agent can report that it ran a command, but you still need to inspect the tool result and execution context. A compiler can successfully build a different folder from the one you intended. “The AI checked it” is therefore an incomplete record. Name the action, file or folder, command, and result.

The interface can help you see those details, but an attractive summary is not a substitute for them. During later lessons, you will ask the agent to identify the files it inspected and will compare its edit with a Git diff. A diff is a view of changes between versions. You will also run selected checks independently of the agent's final message. That does not require repeating every action; it means checking the evidence that matters to the decision.

We use browser chat for the first conceptual exercises and Codex in a project editor for subsequent work. Other assistants can support the same habits, but their controls, instruction discovery, account limits, and access rules differ. Follow the tested path first. Once you have a representative task and a verification method, you can compare tools without changing the meaning of success.

3. AI at development time and AI on a device

Our monitor uses AI during development. The learner asks questions, edits source, reviews changes, and tests behavior with assistance. The resulting firmware need not contain a language model, contact a cloud service, or perform machine learning. Removing the assistant from the workbench does not remove a threshold comparison from the compiled program.

Running AI on an embedded device is a separate design problem. It introduces questions about model size, memory, timing, energy, input quality, and how inference affects system behavior. Those can be worthwhile projects, but they are not prerequisites for this one. Keeping the two activities distinct lets you use an assistant on an ordinary embedded program without claiming the program itself is an AI product.

The distinction also improves debugging. If a host test fails because a comparison excludes the threshold value, the failure belongs to the software requirement and implementation. You do not need to understand model training to investigate it. If the assistant proposed the comparison, that explains how the defect entered the workflow; it does not change the technical evidence needed to fix it.

4. Allocate responsibility before accepting a claim

Use three labels in your notebook. Code-supported means the supplied source directly supports the statement, subject to its stated inputs and dependencies. Document-dependent means the statement requires a particular reference, such as a library API or board schematic. Measurement-required means a physical observation is necessary to establish the claim for the actual assembly. Add unresolved whenever the available material does not justify a conclusion.

These labels are about the current evidence, not permanent categories for all time. A pin assignment can move from unresolved to document-supported when you inspect the exact board revision. A claim about successful electrical communication remains unmeasured until you run the appropriate physical check. A source document can describe what should happen; your assembly can still be wired incorrectly.

Figure D01 depicts this division of work: the engineer defines and judges the requirement; the model proposes or explains; tools read and modify artifacts; the compiler checks a program against its build rules; tests exercise specified behavior; instruments observe physical signals. The figure's arrows represent exchanges of information, not a transfer of responsibility. A passing check has a scope.

D01. The engineer defines acceptance; the model proposes; tools act; compiler, tests, and instruments supply different evidence.

For example, compilation can detect many language and interface errors, but it cannot establish that a connector is seated. A synthetic input test can establish that the compiled policy returns the expected state for supplied numbers, but it cannot establish sensor accuracy. Reading a schematic can identify the intended signal path, but it cannot measure a broken trace. State the useful positive result, then state the remaining question.

5. Worked example: annotate a small program

The following is an original teaching excerpt, not a complete sensor driver. Its input is already a number. A copy is supplied as report-state.cpp. CP00 uses a separate inclusive-comparison excerpt returning a Boolean; compare the two ideas without treating their function names or return types as identical.

const char* report_state(float temperature_c) {
    if (temperature_c >= 28.0f) {
        return "WARN";
    }
    return "OK";
}

Ask a browser assistant: “Explain this function in plain language. Separate statements directly supported by the code from assumptions that require another source or a physical test. Do not change it.” Supply the complete excerpt. Keep the response as received. Your wording may differ from the instructor's saved response; the exercise assesses the claims, not whether the model repeats a particular sentence.

Here is an intentionally mixed illustrative response, written for this exercise: “The function returns WARN at 28 degrees Celsius or above and OK below that value. It samples a BME280 every second through the board's default I2C pins. The measurement is accurate to the sensor's specification, so the device is safe to deploy.” This is not a recorded model response. It contains useful statements and unsupported additions on purpose.

Annotate the first sentence as code-supported for ordinary finite numeric inputs: >= includes equality, and the two string literals identify the returned labels. The parameter name expresses an intended unit, but the function cannot prove that its caller actually supplies Celsius. Record that caller contract separately. The function contains neither a sensor read nor a scheduler, so the sampling and I2C claims are unsupported by this excerpt. Exact interface details would require the full source and target documentation.

The accuracy claim needs much more than a part name. You would need a specific documented condition, the actual sensor configuration, and measurements suitable for the intended use. The deployment conclusion does not follow from this function. Mark it unresolved and replace it with a bounded statement: “The comparison implements the stated threshold for the shown inputs; acquisition, invalid values, timing, and physical operation are not established here.”

Your worksheet can use these columns: claim; current label; supporting line or source; next check; result. For the first row, the next check is to evaluate 27.9, 28.0, and 28.1. For the sampling row, inspect the caller and its timing code. For pin mapping, locate the exact board documentation. For physical accuracy, define a bench comparison if you elect to perform the optional hardware work. Avoid a vague “verify later” that leaves nobody knowing what to do.

SS01-01 shows the submitted request; SS01-02 preserves the actual answer. SS01-03 is the instructor's annotated worksheet. Its constructed teaching claims remain separate from the recorded response; none establishes physical operation.

6. Lab LAB01: evaluate a second answer

Start a new section in evidence-annotation.md. Consider this original scenario: a reporting routine receives {valid: false, temperature_c: 31.0} from a synthetic fixture. A proposed explanation says, “The room is hot, the alarm must turn on, and the sensor cable is disconnected.” Your independent task is to classify those three claims and propose a better response. You may ask an assistant to help, but write your own final judgment.

First identify which part of the input is an observation and what produced it. The fixture is authored software data, not a room measurement. Second decide whether the invalid flag should affect the interpretation of the temperature. You have not yet been given a complete fault policy, so record that requirement as missing. Third ask whether this tuple can uniquely establish cable disconnection. It cannot distinguish that physical explanation from a failed conversion, a deliberate test input, or another source of invalid data.

The expected observation is a worksheet that preserves the invalid flag, labels the input synthetic, and declines to treat a numeric field as a trustworthy reading merely because it is present. A strong revised response says: “This fixture represents an invalid sample. Consult the fault requirement before selecting a state. It does not establish room temperature or a physical cause.” Save that response and the next check you would perform.

7. Failure and recovery: an unsupported pin claim

Suppose the assistant supplies a pin number and cannot identify a reference. Do not turn the number into a wiring instruction by repeating it in a README. Preserve the proposed value as an unverified claim, identify the exact board variant, and inspect its manufacturer pinout and schematic. The Feather family includes variants; the example target in this course is the documented ESP32-S3 Feather. Adafruit target guide

If the source is unavailable, stop that connection decision and continue work that does not depend on it: annotate the policy, write host tests, or refine the task brief. The recovery is complete when the claim has a traceable source or is explicitly unresolved. Inventing a plausible number to keep moving makes the later work less reliable.

Completion checklist

• I identified three useful assistance tasks and an observable check for each.
• I separated model output, tool actions, compilation, synthetic tests, and physical evidence.
• I annotated the worked response and completed LAB01 independently.
• I replaced an unsupported conclusion with a bounded statement and next action.

Review questions with answers

1. Why is a correct code explanation insufficient evidence of a working sensor? It addresses the supplied program text. Sensor operation also depends on the acquisition code, configuration, electrical assembly, and actual communication. The explanation is useful within its scope, but those additional claims need their own checks.

2. Is an answer that reports missing information a failure? Not when the information affects the decision. Naming the missing board revision or fault requirement turns uncertainty into a specific research or design task. Guessing would hide that task.

3. Can a synthetic test be valid evidence? Yes. It can establish software behavior for controlled input and is central to this course. It becomes misleading only when described as a physical measurement or used to support claims the test did not exercise.

Transfer exercise

Choose one task from a project you already understand. Write a five-line note naming the task, material you can supply, result you want, evidence you will accept, and an explicit unknown. Prefer a task you can review in one sitting. Keep the note: Chapter 3 will turn it into an engineering brief.