M01-L01 — Meet the workbench assistant
Outcome: Classify three useful tasks and choose an appropriate verification step.
Start: CP00 and basic familiarity with a firmware function.
An assistant can help you understand a function, propose a small edit, or organize a test table. Choose a first task whose result you can inspect. Asking for an explanation of a supplied comparison is a better defined exercise than asking for a complete unknown system. The goal is to make the work reviewable.
A model generates output; an application provides an interface; an agent can use permitted tools to read, execute, or edit. A command shown in chat has not necessarily run. In an agent interface, inspect the action record and execution context as well as the final explanation. Codex IDE extension
For the worked example, use the original report_state excerpt in Chapter 1. It returns WARN for an ordinary finite Celsius input at or above 28.0 and OK below it. Ask for an explanation separating code-supported statements, document-dependent statements, and physical claims. Keep the actual response. If access is unavailable, analyze the explicitly illustrative response in the chapter.
The statement about the comparison is supported by the code. The function alone cannot establish how often a sensor is sampled, which board pins are used, or whether the physical reading is accurate. Its parameter name expresses an intended unit; inspect the caller to know what actually arrives. Write a claim, label, supporting line or reference, and next check for every consequential statement.
The core sensor-monitor project uses controlled synthetic input and cross-compilation. Host tests can establish behavior for that input; compilation can establish a build for the selected target. Neither establishes a physical measurement. A useful result is precise about its positive scope: “The boundary cases passed in the host program” is informative without suggesting a board was tested.
The demonstration ends with an evidence worksheet, not a verdict that all AI output is reliable or unreliable. A strong worksheet preserves a useful explanation and rejects only the claims that outrun the evidence.
D01. The engineer defines acceptance; the model proposes; tools act; compiler, tests, and instruments supply different evidence.
Practice and completion
Complete the exercise, then compare your artifact with the separately distributed instructor answer. A lesson acknowledgment records your own progress; it does not certify that a physical test occurred.
Chapter 1. Resources: Original reporting excerpt. Figure references: SS01-01–03; D01.
Recording transcript
Welcome to the workbench. In this lesson we will use an assistant for a small engineering task and decide what evidence its answer needs. You do not need a board on the desk. You need a short piece of source code, a place to keep notes, and enough curiosity to ask what each statement actually establishes. Our result will be an evidence worksheet that you can use throughout the course.
The running project is a sensor monitor. We will explain it, change it, test its software behavior, and preserve a useful history. AI helps with those development activities. The finished firmware does not need to contain a language model or call a cloud service. Keeping development assistance separate from AI running on a device makes this first project easier to understand and verify.
Look at the short reporting function in the lesson. Its input is a floating point temperature. The comparison asks whether that input is greater than or equal to twenty-eight. If so, the function returns the word WARN. Otherwise it returns OK. The function is deliberately small. There is no sensor read, no timer, no pin configuration, and no communication with a board in the excerpt.
Before asking for help, identify the task you can judge. We want an explanation of this supplied function. We do not want the assistant to invent an entire acquisition system around it. The prompt asks it to separate statements supported directly by the code from assumptions needing a document or a physical test. This gives the answer a useful shape without demanding that it use exactly the same words as the instructor.
An actual model response may differ from the saved instructional example. Preserve what your session returns. If your account is unavailable, use the chapter's clearly labeled illustrative response. You can practice evaluating claims without pretending that a new conversation occurred. What matters here is whether you can connect each claim with an appropriate check.
Start with the statement that twenty-eight produces WARN. For an ordinary finite input, the comparison supports that statement. Equality is included by the greater-than-or-equal operator. We can make the boundary visible with three example values: twenty-seven point nine, twenty-eight point zero, and twenty-eight point one. Those examples separate an inclusive threshold from a strict greater-than comparison.
Now consider the statement that the function samples a BME280 once a second. The excerpt contains no sampling call or scheduling code. The statement might describe some larger program, but it is not supported by the material we supplied. In the worksheet, mark it unresolved and identify the next check: inspect the caller and the actual timing code. Do not add a timer to the function merely to make an explanation become true.
The same discipline applies to a pin number. An assistant may recognize a board family and suggest a familiar mapping. Before relying on that number, identify the exact variant and consult its manufacturer pinout or schematic. A similarly named board can differ in a consequential way. Our worksheet records the source needed and leaves the claim open until that source is inspected.
A physical accuracy claim needs a different kind of evidence. A manufacturer specification can describe performance under stated conditions. It cannot show that your particular assembly is wired correctly or that your measurement matches a reference. If you choose the optional hardware lab later, you will define and record appropriate observations. For the core course, software tests and documented constraints are enough, provided we describe their limits honestly.
Notice another small distinction in the code. The parameter name says temperature underscore c. That tells us the intended unit is Celsius. The function itself cannot inspect the meaning of a number. If a caller passes Fahrenheit, the comparison still runs. To support the complete claim that the input is Celsius, inspect the caller contract and conversion path. A useful code explanation can reveal exactly where more context is needed.
Open the evidence worksheet and make one row per consequential claim. Use columns for the claim, current evidence label, supporting line or source, next check, and result. Keep the next check concrete. Write inspect the caller for its scheduling condition, rather than verify later. Write compare three boundary values against the requirement, rather than make sure the program works.
There are several kinds of assistant around the workbench. A model generates output. An application provides the chat or editor interface. An agent can use tools, depending on the permissions and features available. A command printed in an answer is proposed text until something executes it. Later lessons will show how to inspect tool actions, command results, and changed files instead of relying only on a final summary.
For your exercise, classify three claims and rewrite the broad conclusion that the device is ready to deploy. A better conclusion identifies the positive result: the shown function implements the stated finite threshold comparison. It also names the remaining questions: acquisition, invalid values, timing, and physical operation. You are preserving what the evidence supports while making the next work visible.
Check your worksheet before continuing. Can another person see which line supports the comparison? Can they tell which reference is missing? Can they distinguish a synthetic test from a physical observation? If so, you have created a useful engineering artifact. The goal is not to make the assistant sound less confident. The goal is to make your own decision traceable.
Consider how you would record a check that has not happened yet. Leave its result blank or write pending, and keep the proposed method beside it. That small distinction prevents a plan from becoming a success claim when you return days later. When a real check occurs, add the date, input, and actual result. The worksheet then becomes a record of learning rather than a list of reassuring predictions.
Finish by choosing one task from a project you already understand. Name the material you can provide, the result you want, and the check you would accept. Keep that short note. We will expand it into a complete engineering brief after exploring why context helps a language model and why context alone never guarantees correctness.
Download transcript
