Implement a small, authorized change while preserving the public interface and collecting real execution evidence.

What you will learn

  • Inspect the existing decoder, callers, return contract, dependencies, and tests.
  • Restrict the patch to frame-length validation and signed conversion; preserve scale and output format.
  • Review semantic correctness, boundary handling, units, dependencies, and unrelated edits.
  • Run targeted and regression checks in the approved environment; record command, revision, environment, and result.

Practice focus

Implement or review the decoder patch against the predefined positive, negative, and incomplete-frame cases. If execution is unavailable, label the patch unverified rather than reporting a pass.

Engineering deliverable

A focused code change, reviewed diff, and recorded checks with explicit limitations.

Lesson transcript

Scene 01

An AI-generated patch can be syntactically valid and still violate a hardware interface contract. Unit two established the decoding requirements. Here, we move from that reviewed task to a controlled implementation: understand the existing code, authorize a bounded change, inspect the diff, and collect execution evidence.

Scene 02

Use GitHub Copilot to locate the decoder, its callers, and the existing tests. Ask it to explain the input type, return structure, dependencies, and current error behavior before proposing edits. In our training project, the caller supplies bytes and expects a status and measurement. Preserve the public function signature and every behavior outside the approved change.

Scene 03

Request a plan, not a subsystem rewrite. The approved change has two parts: reject frames of the wrong length, and interpret complete samples as signed values. Preserve the scale factor and output format. Restrict edits to the decoder and its tests. New dependencies or changes elsewhere require a separate review.

Scene 04

The proposed implementation checks the frame length before conversion. Invalid input returns a status without a numeric measurement. Valid input uses the documented byte order and signed interpretation, then applies the approved scale. The signed flag is a functional requirement, not a formatting preference. No register access, device configuration, or calibration logic belongs in this patch. At this stage, the code is a proposal, not a verified result.

Scene 05

Review the actual diff against the task, not the agent's explanation. Check signedness, units, boundary handling, and preservation of the return contract. Here, the intended changes are the length guard and signed conversion. An altered scale factor, unrelated file edit, or added dependency should trigger review, even when the code looks cleaner. Never hide an error by substituting a valid-looking zero. A small diff still needs semantic inspection.

Scene 06

Run the prepared checks in the approved environment. Where tool access permits, ask Copilot to run the specified command and report what actually executed. Otherwise, run it yourself and provide the output for review. Read warnings and failures, and record the command, revision, environment, and results. If execution is unavailable, report the change as unverified. An agent's assurance is not execution evidence.

Scene 07

Compare the outputs with the acceptance examples established before implementation. Positive and negative frames must produce the expected measurements; an incomplete frame must produce an invalid status. Also rerun existing tests for unaffected behavior. A successful run supports only the conditions exercised. It does not establish sensor accuracy, timing compliance, or readiness to deploy on hardware.

Scene 08

Before accepting the patch, make sure another engineer can connect the requirement, the code change, and the recorded checks. Keep any untested conditions explicit. The deliverable is not simply generated code; it is a reviewable change with evidence that supports the claimed behavior.