Use case
How do you approach this?
How to Validate Copilot Suggestions
Published · Updated
Published by Unrust. Scoring and editorial method
Quick answer
Validate an autocomplete suggestion by treating it as an untrusted draft with a narrow surface area. Read the surrounding function first, compare the completion with the caller's contract, and inspect assumptions about types, empty values, errors, and side effects. Accepting a short suggestion can be fast when the evidence is clear; the speed comes from a bounded verification loop, not from trusting the source.
Read the gap around the completion
A completion is only meaningful in its local context. Inspect the names, type constraints, callers, and nearby tests that tell you what the missing lines must preserve. This prevents a familiar-looking pattern from being pasted into a function with a different ownership or error contract.
Verify assumptions before expanding the diff
Check whether the suggestion introduces a default, coercion, catch block, mutation, or dependency call that changes the function's meaning. If one assumption is unclear, reduce the suggestion to the part you can explain and verify before accepting more generated code.
Check an autocomplete against the first and missing positions
Given an array of string tags and a requested tag, return a boolean indicating membership. The function must work for the first element and for a tag that is absent.
indexOf returns a position or -1, not a boolean. Converting its result directly makes the first position false and absence true. includes expresses this contract directly; the boundary cases should accompany any accepted suggestion.
The outcomes below are checked by executable tests against the exact displayed snippets. NaN and undefined are written by name so they remain visible in the table.
function run(tags, tag) {
return Boolean(tags.indexOf(tag));
}function run(tags, tag) {
return tags.includes(tag);
}| Arguments to run | Before | After |
|---|---|---|
| ["release", "docs"], "release" | false | true |
| ["release", "docs"], "missing" | true | false |
| ["release", "docs"], "docs" | true | true |
Practice loop
- 01Pause before accepting a completion and state the enclosing function's promised behavior.
- 02Name one input edge and one failure path the completion must preserve or handle.
- 03Accept only the smallest portion you can explain, then run the nearest relevant test.
Limits of this page
This process does not replace knowledge of the product or its runtime environment. A timed session may show an uncertain assumption, but it cannot say whether that uncertainty came from an unfamiliar codebase, time pressure, or a broader skill gap.
Source context
Published by Unrust as practical teaching material using public language documentation and original examples. See the scoring and editorial method for scope, checking and limitations.
Check your own starting point
One diagnostic session is a snapshot, not causal proof of why a result occurred. It can help you choose a focused next practice step without making a broader claim about your ability.
Take the free diagnostic