By Muhammad Faraz · 3 min read
Understand the assistant’s role
GitHub describes Copilot as an assistant for writing, understanding and reviewing software, with features that depend on the plan and environment. A useful starting point is a bounded change with a clear acceptance condition. Ask for an explanation of an unfamiliar function or a focused improvement before handing over a broad feature.
Source: About GitHub Copilot ↗Give the task useful boundaries
Specify the expected behavior, the files involved and any conventions that should remain intact. For example, a form improvement might need accessible labels, server-side validation and an existing error component. Clear constraints reduce the number of plausible but inappropriate solutions. Do not assume the assistant knows decisions that only exist in someone’s head.
Review behavior, not just syntax
Readable code can still do the wrong thing. Check empty input, failed requests and the effect on existing users. For a permissions change, inspect the server-side decision rather than relying on a hidden button. Use tests where they provide meaningful evidence about the risk of the change.
Keep accountability explicit
Someone should understand and own the code that reaches production. Record why a change was made, review dependencies and confirm that any suggested API matches the project. The value of an assistant is easier to assess when you track the complete task, including review and corrections, rather than only the time spent producing a first draft.
Example: improve a checkout error state
Suppose a checkout form currently shows the same error for every failure. A focused task is to distinguish missing input, a declined request and an unavailable service while preserving entered information. Supply the existing component and explain which behavior must remain unchanged. Ask the assistant to describe its intended change before editing. Review the resulting behavior against those requirements, including a retry after a failed request. A more elegant implementation is not sufficient if customers still lose their form data.
Keep the proposed change small enough to inspect
Separate an error-state fix from an unrelated component rewrite. If an assistant changes naming, formatting, dependencies and business logic together, reviewers must examine several kinds of risk at once. Request a narrower patch when necessary. Read the final difference rather than only the assistant’s summary of it. The summary can help navigation, but the actual changed files are the evidence. Preserve the reasoning behind important choices in a short review note.
Avoid a circular definition of correctness
A test generated from the same mistaken assumption as the implementation may simply confirm that both share the mistake. Start with observable acceptance conditions written independently of the suggested code. For the checkout example, entering valid details after a failure should still work, and refreshing must not silently duplicate an order. Select verification appropriate to the action’s consequences. A text change needs less scrutiny than a payment or authorization change.
A useful team agreement
Decide what an assistant may prepare and what a person must approve. The agreement can cover dependency additions, production configuration and access to sensitive files without banning ordinary assistance. Use repository conventions to reduce repeated corrections. During a retrospective, ask whether the tool reduced the complete delivery effort, including review and repair. Teams learn more from that question than from counting generated lines, accepted suggestions or how quickly the first patch appeared.
