18. Maintain the Workflow and Choose What Comes Next

What you will be able to do

You will evaluate the whole effort of an AI-assisted task, maintain the sources and tools your project relies on, and apply the workflow to one bounded change of your own. Start with the completed core capstone and its evidence bundle. Your deliverable is a personal workflow and maintenance plan supported by a real transfer exercise. You do not need a new framework, another subscription, or a different board to finish this chapter.

Measure verified delivery

The first generated answer is easy to notice. The work that follows can be less visible: understanding the patch, finding an incorrect assumption, repairing it, running checks, and updating the handoff. If you measure only generation time, you can conclude that a workflow is faster while spending more effort getting to a result you can trust.

Define the end of a task before comparing approaches. For Sensor Monitor, a small maintenance task is finished when the requested artifact is correct, its diff is reviewed, relevant checks have actual results, and the documentation states any remaining limits. A proposed patch or a confident response is an intermediate state. The end point should be the same whether you work manually, use an agent, or combine both.

Track active effort and waiting separately. Active effort includes task preparation, review, diagnosis, repair, and evidence writing. Waiting may include generation, compilation, downloads, or account limits. These categories answer different questions. A workflow can reduce active effort while increasing elapsed time, or shorten generation while increasing repair. Record both rather than hiding the tradeoff in one attractive number.

A practical worksheet has task identity, starting source, acceptance criteria, approach, preparation time, generation or editing time, review/repair time, verification time, waiting time, final result, and limitations. Record the units and measurement method. You do not need precise instrumentation for a small comparison, but you do need to avoid presenting remembered estimates as measured observations.

Compare on representative work

Choose a task you actually perform. A spectacular one-off demonstration may reveal a capability but tell you little about routine maintenance. Useful comparison tasks include clarifying an error message, adding a missing boundary case, reviewing a bounded parser diff, or improving a setup instruction. Keep the starting source and acceptance criteria stable enough that the results are comparable.

Do not give one approach a perfect brief and the other an ambiguous request. The quality of task preparation is part of the workflow, but it should be visible. If the agent needed several rounds of clarification, count that effort. If a manual approach relied on knowledge you already had, record that advantage. The purpose is to understand your work, not to prove that one category must always win.

Output can vary across model runs and tool versions. A single run supports a limited observation, not a permanent ranking. When a decision matters, repeat representative tasks and look for recurring strengths and weaknesses. Preserve actual prompts, versions, and artifacts so a future comparison does not depend on vague recollection of which assistant seemed impressive.

Use a rubric that includes correctness, scope, evidence quality, explainability, and total effort. A fast patch that you cannot explain may impose a maintenance cost later. A longer first pass that creates a clear test or source record may reduce the next task's effort. Evaluate those consequences against your project needs rather than rewarding output volume.

Worked example: clarify two kinds of failure

Use a disposable CP09 copy and choose this maintenance task: improve the README's explanation of a malformed fixture versus an intentional invalid sensor sample. The acceptance criteria are small. The documentation must distinguish exit 2 with a fixture line diagnostic from a valid replay that intentionally reaches FAULT and can exit 0. It must preserve synthetic labeling and avoid implying physical sensor failure.

For approach A, read docs/formats.md, inspect the relevant fixtures, and write the paragraph yourself. For approach B, start from the same unmodified copy and ask an agent for the same bounded clarification using the supplied project sources. Do not tell the agent to change parser behavior; the task concerns explanation. Preserve both resulting paragraphs and their diffs.

Here are two original instructional candidates to evaluate, not claimed outputs from those approaches:

A malformed fixture is rejected with a line-number diagnostic and exit 2. A valid synthetic fixture can intentionally produce FAULT while the replay process exits 0.

A FAULT result means the program failed; rerun until every reading is normal.

The first candidate distinguishes input-file validity from policy state. The second misinterprets a legitimate fault scenario and encourages hiding useful evidence. The difference can be established from the project's documented format and actual reproduction, regardless of which author or tool produced the text.

Run the relevant replay commands in the preserved exercise root:

.\scripts\replay.cmd fixtures/invalid.csv
.\scripts\replay.cmd fixtures/normal.csv

The first fixture is intentionally malformed; preserve its diagnostic rather than editing it during this comparison. The second contains a nonfinite sample that legitimately produces FAULT. Read the actual process results and output. Record them as synthetic software evidence. The expected distinction is defined here; your evidence record must contain what your own run actually did.

Score both approaches against the same criteria. Did the paragraph preserve the distinction? Did it change only the requested documentation? Can you trace its explanation to the source and actual check? How much preparation, review, correction, and verification did it take? Leave timing fields unmeasured if you did not measure them; do not supply plausible numbers to complete a table.

The exercise can reveal different outcomes. An agent may draft the correct distinction quickly but require careful scope review. A manual pass may take longer to locate the source but produce a paragraph you understand immediately. Report the result of your actual attempts. Neither outcome should be generalized beyond the available evidence.

Maintain sources as dependencies

A source link can become stale even when the code still compiles. A manufacturer may revise a board, a library may change behavior, or a tool may move a setting. Record the source version or access date where it matters, and recheck the claims that an update could affect. Updating every document on every session creates unnecessary work; ignoring relevant changes creates hidden assumptions.

The exact product identifier is more durable than a remembered family description, but it still needs a relevant source. The project's dependency record preserves the tested target and tool inputs. When those inputs change, record the reason, inspect the difference, and repeat the affected checks. A successful old build does not certify a new toolchain configuration.

Separate a documentation refresh from an implementation change. A page may move without changing a technical fact. A library update may require both source edits and new tests. A revised model interface may affect skill discovery while leaving the C++ program unchanged. Classify the change so verification addresses the affected behavior rather than treating every update as a complete project restart.

Keep a short maintenance table with the item, current recorded version or source, review trigger, relevant check, and last verified result. For the compiler, a trigger is changing its version or runtime setup. For a skill, it is changing the description, instructions, or host behavior. For a hardware fact, it is changing the exact board or encountering a source discrepancy.

Preserve a working baseline before updates

Use a separate branch or exercise copy for an update. Record the current source identity and relevant passing evidence before changing dependencies. Read the official release or installation guidance for the component you are changing. Do not silently replace the tool in every environment and then discover that the earlier reproduction path has disappeared.

After the update, run the smallest relevant set that can establish the effect. A compiler change calls for builds and behavior checks. A skill trigger change calls for positive and negative selection cases. A wording-only link repair calls for link and rendered-content checks. Broaden testing when the change, a failure, or an unresolved concern justifies it.

If the update fails, preserve its result and return to the documented working baseline in the disposable environment. A rollback should restore a known state, not erase evidence of why the update was rejected. Record the missing capability or incompatibility and the next useful investigation. You can continue independent project work while that update remains unresolved.

Avoid maintaining multiple unexplained command paths. One tested wrapper plus clearly labeled platform notes is easier to support than several copied command lines that gradually diverge. The primary Windows course path uses .cmd wrappers; host appendix commands have their own evidence boundary. Do not infer Windows behavior from a macOS test merely because both compile C++.

Share deliberately

A useful release contains the source, setup, dependency information, permitted fixtures, documentation, and evidence needed by its audience. It should not accidentally contain private credentials, unrelated history, authoring service configuration, or personal screen captures. Review the actual package rather than assuming a clean repository view proves that every exported asset is appropriate to share.

Repository visibility and licensing answer different questions. A private candidate can be reviewed without a public launch. A public repository does not by itself communicate all intended reuse permissions. GitHub's repository licensing guide explains why a deliberate license record matters. Preserve existing dependency notices and distinguish original code, written material, images, and other assets when recording their rights.

Do not let an agent assign broad reuse rights to material whose origin is uncertain. Identify what you created, what came from dependencies, and what is linked rather than redistributed. A source citation supports provenance but does not automatically grant permission to copy a whole document. The release decision should reflect the material actually included.

Keep publication separate from verification. A private release can satisfy the engineering task. A public release adds audience, support, and distribution decisions. You can prepare a complete reviewable package before making those choices. The course does not require a public upload to demonstrate competence with the workflow.

Transfer without copying assumptions

When moving to another board or project, copy the workflow before copying hardware facts. Keep the pattern of exact identity, sourced constraints, explicit requirements, isolated policy, and bounded checks. Replace the target-specific details using the new project's primary material. A pin mapping, memory option, or peripheral-power alias should not travel merely because the processor family sounds familiar.

Identify which parts can remain unchanged. Hardware-independent parsing or state logic may be reusable if its requirements still apply. An acquisition adapter, timing assumption, output channel, or build target may need new verification. Document that boundary before asking the agent to port everything. A successful compilation on the new target still does not establish physical behavior.

For a software-only transfer, choose a small feature whose result you can observe without new equipment. Add a missing error-path test, improve a reproducible setup step, or clarify a report format. The same workflow applies: establish the starting state, write acceptance criteria, make the bounded change, review it, run relevant checks, and update the handoff.

If your own project contains sensitive material or actions outside the current task, keep the transfer scoped to an appropriate local copy and available tools. The useful habit is deciding what evidence and access the task needs. An instruction file cannot replace the actual permission boundary, and a reuse exercise should not quietly expand into unrelated operations.

Choose a next learning question

A real-time operating system can introduce scheduling, synchronization, and ownership questions that a simple loop does not expose. Study one of those questions in a bounded example before replacing the project's architecture. The useful outcome might be a testable queue or timeout contract, not a complete port. The official FreeRTOS documentation is a starting reference for that optional direction.

PCB assistance can apply the same source discipline to a schematic or layout review: exact components, constraints, and reviewable changes. AI interpretation of an image does not replace checking small labels, connectivity, or design rules in the actual engineering files. Begin with one limited review question and a way to verify the answer independently.

Local model experiments shift the evaluation toward the capabilities, resource needs, and data handling of a particular runtime. Do not assume that a local deployment matches a hosted model's tools or skill discovery. Compare representative tasks using the same total-effort rubric and preserve the exact configuration. No local model installation is required to finish this course.

TinyML introduces model inference on a constrained device, which is different from using an assistant to help write firmware. Google's LiteRT for Microcontrollers overview describes one supported runtime direction. A future TinyML task needs its own model, input, memory, latency, and quality checks. The present Sensor Monitor contains no on-device AI inference.

LAB18: complete one transfer task

Choose a bounded task in your own appropriate project or use the README clarification from the worked example. Write a brief naming the goal, starting source, relevant context, scope, and observable acceptance condition. Record the baseline and preserve a recovery path before editing.

Complete the task using the workflow you want to evaluate. Keep a simple effort record that separates preparation, editing/generation, review/repair, verification, and waiting. Save the actual diff and relevant results. Do not add a new tool merely to make the exercise appear more advanced.

Write a short maintenance plan with three items that matter to this task: the current source or tool version, the trigger for review, and the check that would establish continued behavior. Finish with a handoff naming the next bounded action or explicitly stating that this task is complete with its evidence.

Submit the brief, artifact, diff, results, effort record, and maintenance plan. If comparing two approaches, use separate preserved starts and common criteria. Do not invent timing measurements or human feedback. The transfer succeeds when you can explain both the result and how you know it meets the stated requirement.

Failure, recovery, and completion

The common failure is declaring the fastest generator the fastest workflow while ignoring repair and verification. Recover by returning to the same completion definition and including the omitted work. If timing was not measured, report the comparison qualitatively and plan a better measurement next time. False precision is not an improvement.

Complete this chapter when your transfer task has an observable result, actual evidence, a current handoff, and a maintenance plan tied to realistic change triggers. Finish the core course with the capstone rubric and evidence intact; optional future topics do not add hidden completion requirements.

Why count review and repair? They are part of reaching a result you can use and maintain. Generation alone is an intermediate step.

Does a tool update require every check? It requires checks relevant to what changed, broadened when failures or uncertainty justify it.

What should transfer to another board first? The workflow and evidence habits. Hardware-specific facts must be re-established for the exact new target.

Is public visibility the same as licensing? No. Distribution visibility and reuse permissions are distinct decisions, and included material needs accurate provenance.

Does this course run AI on the device? No. It teaches AI-assisted engineering. A TinyML extension would require a separate implementation and validation task.

Sources and figures

Project behavior and commands come from the matching CP09 release. Optional directions and sharing references: GitHub licensing, FreeRTOS documentation, and LiteRT for Microcontrollers, checked September 12, 2026. Figures: SS18-01 measured comparison including review/repair, SS18-02 actual transfer task, SS18-03 maintenance plan. Illustrative paragraphs in this chapter are authored examples, not invented agent outputs or observed timing results.