Set up a controlled AI-assisted engineering workflow before accepting any code change.

What you will learn

  • Inline suggestions, chat, and approved agent capabilities: explanation, proposal, and execution are different.
  • Provide relevant files, interface rules, test fixtures, and project instructions; inspect the actual diff.
  • Check execution environment, toolchain access, organizational permissions, and action approvals.
  • Preserve a known Git revision and distinguish reversible file edits from external hardware actions.

Practice focus

Review a focused change to a regression-log utility: a run without its completion marker must be classified as incomplete, while completed-run mappings and the output schema remain unchanged. Inspect the plan and diff, then run the specified checks in an approved isolated environment.

Engineering deliverable

A reviewed workflow checklist covering context, permitted actions, execution evidence, and acceptance.

Lesson transcript

Scene 01

A regression utility can run successfully and still classify an incomplete test as a pass. With GitHub Copilot, the engineering question is not just how to generate code. It is how to control the task, the execution environment, and the evidence used to accept a change.

Scene 02

Use Copilot's inline suggestions while editing, and chat to inspect existing code or discuss an approach. For an unfamiliar verification utility, first request an explanation of its inputs, outputs, and failure handling. Distinguish an explanation, a proposed patch, and an executed change. Chat is an interaction surface, not a guarantee that action tools are disabled.

Scene 03

For a bounded implementation, use Copilot's agent capabilities when they are available and approved. The agent can inspect files, edit code, and run checks through enabled tools. Request a plan before implementation, review its scope, and authorize the relevant actions. If command execution is not permitted, run the checks yourself. Do not bypass the organization's controls.

Scene 04

Give Copilot the relevant source files, interface definitions, approved status rules, and existing tests. State which behavior must remain unchanged. Keep recurring project guidance in the supported instruction files, rather than relying on an old conversation. An open repository is not proof that every relevant requirement is in context. Explicitly reference the sources that matter to this task.

Scene 05

Verify where commands will execute and whether that environment has the required toolchain, dependencies, and licenses. Writing a simulator command does not establish access to the simulator. Keep the exercise in the approved development environment. File editing on your computer does not, by itself, mean model processing stays there. Use only approved data and service configurations.

Scene 06

Consider our training utility for summarizing hardware regression logs. Ask Copilot to classify a run without its completion marker as incomplete, while preserving completed-run status mappings and the output schema. Supply representative fixtures and predefined expectations. First review the plan, then inspect the patch and run the targeted checks. The table shows expected behavior, not evidence that tests have run.

Scene 07

Separate task instructions from enforced permissions. Saying do not modify RTL is not an access control. Configure the available tool approvals and isolation, review commands, and preserve a known Git revision before editing. Keep live equipment disconnected for this exercise. Restoring tracked code cannot undo a firmware flash or an instrument command. Stop and review any action outside the agreed scope.

Scene 08

Before accepting the change, inspect the diff, confirm which checks actually ran, and compare the results with the approved expectations. Record limitations and unresolved issues. GitHub Copilot supports the workflow, but the acceptance decision remains an engineering responsibility. The deliverable is a controlled change with reviewable evidence.

Next