When an AI coding tool reports a match to public code, attach that finding to the proposed change before the session disappears. Preserve the generated fragment, matching source and revision, available license information, and the question awaiting review. A match should lead to an inspectable decision; neither accepting the suggestion nor editing it should silently close the finding.
For a developer or engineering manager, this is a handoff problem. The person reviewing a pull request may never see the assistant’s original response or session log. A passing build tells them about behavior under the checks performed. It does not reconstruct the source evidence that appeared earlier.
This guide proposes a review record and a fictional change exercise. It does not determine copyright ownership, license obligations or the legal effect of similarity. Those interpretations belong with the organization’s designated reviewer. We have not tested Copilot or a code-matching tool for this article.
Establish which surface produced the signal
GitHub’s current IDE documentation describes references to public-code matches. Its index excludes private repositories and code outside GitHub, and periodic refresh can leave gaps. For inline suggestions, the documented reference behavior covers accepted, unchanged suggestions. Chat and delegated agent references appear in their respective review contexts. These are vendor-documented capabilities, not findings from our own trials.
The current agent application card identifies an important surface distinction: the cloud agent may generate matching or near-matching public code even when the public-code policy is set to Block. Do not extend an IDE setting’s assumed effect to every delegated workflow. Confirm the current behavior for the surface your team actually uses.
Our recommendation is to record the product, interface, relevant policy and evidence location together. Write “reference found in this agent session” rather than “all generated code was filtered.” If you have not checked the actual configuration, leave it unverified. Product names alone are too broad to describe what happened to a particular change.
Distinguish similarity, possible origin and a reuse decision
The CodeGenLink paper, submitted October 1, 2025, describes retrieving candidate web links, comparing code similarity and suggesting available license information. Its authors explicitly distinguish similarity evidence from guaranteed origin. The preliminary evaluation concerns filtering relevant links; it does not certify ownership or establish that a missing match means no related code exists. This historical research informs the distinction here, rather than validating today’s Copilot behavior.
Keep three questions separate in the review record. What code resembles the generated fragment? What evidence connects that source to the fragment under review? What decision has the responsible person made about the intended use? A tool can help discover candidates without answering all three.
Avoid turning a matching repository into a definitive authorship claim. Several repositories may contain similar code. A repository-level label may also leave questions about the particular file. Preserve the observations and their locations instead of asking the assistant to choose the most convenient interpretation.
Make the finding survive a pull-request handoff
Our proposed record has a stable finding identifier attached to the pull request or the team’s existing review system. It links two concrete objects: the generated change at the time of the finding and the source that was reported as similar. Neither side should be represented only by a mutable branch name.
For the proposed change, retain a commit or patch reference, file path and fragment location. For the reported source, retain its URL, revision where available, file path and the relevant notice or declaration. Record what the tool supplied separately from what a person subsequently inspected. If a source cannot be opened, say so.
Then add the intended delivery context and a disposition owner. A small team may keep this in one pull-request comment. An enterprise may link an existing review ticket. The purpose is the same: another reviewer should be able to reconstruct the question without access to the original chat.
Do not copy an entire confidential assistant session into a broadly visible issue. Retain the evidence needed for this finding through the team’s approved process. The record needs enough context to investigate the fragment, not every prompt or unrelated file the assistant saw.
Work through a fictional parser change
Imagine a fictional team asking a background coding agent to add a text parser. The session reports a match for one helper function in a public repository. The generated pull request passes its behavioral tests, but its description mentions only those tests. A developer later renames variables and moves the helper into a different file.
There are now two separate events: the behavior was tested, and the matched fragment changed. Neither event records what happened to the public-code finding. Our proposed review would preserve the following distinctions:
| Change or finding | Evidence to retain | Next decision |
|---|---|---|
| Original helper has a reported match | Session reference, patch location and reported source revision | Inspect the actual matching file and available notices |
| Tool supplies no license information | The missing value, rather than an invented label | Ask the designated reviewer what evidence is needed |
| Variables are renamed and the helper moves | Link from the original finding to the revised diff | Establish whether the affected material remains |
| Helper is removed | Diff showing removal and checks for other affected locations | Record the scope of what was removed |
| Reviewer accepts a stated use | Decision, evidence, scope and any required release work | Verify that work in the delivered artifact |
These are invented cases, not observations about a named repository. The exercise is useful precisely because the apparent shortcut—“the code changed, so the warning is gone”—does not explain the disposition. A new identifier, location or wording does not itself resolve the earlier question.
If the team replaces the helper, record what was replaced and why. Do not describe rewriting as a universal legal remedy. If interpretation remains unresolved, carry that status forward rather than allowing an assistant-generated completion summary to convert it into approval.
Decide what silence from a matcher means
“No match reported” is an observation about a particular operation. It is not a complete history of the code. Record the tool and scope of the check when that distinction matters to a review. Also distinguish a completed operation from a failed, unavailable or uninspected one.
Haksung Jang’s June 8, 2026 practitioner analysis separates dependency inspection from matching fragments embedded in source code. It is personal analysis, not a controlled comparison or legal authority. That distinction helps define this guide’s boundary: checking a package manifest does not account for every generated helper in a diff.
Our existing dependency-license evidence guide covers the separate package-intake record. Use it when the assistant adds a dependency. For a fragment match, keep the evidence tied to the affected code. Avoid forcing both into a single “license passed” field that hides what was actually inspected.
Close the finding against the code being delivered
Before merging, ask whether the finding has an explicit disposition for the current diff. Before releasing, check whether any resulting release work was completed for the artifact actually being supplied. An approval note and a delivered notice are different evidence items.
Keep behavioral and security checks visible alongside this record. Similarity review does not establish that the parser is correct, and successful parser tests do not settle source questions. Our code-review guide addresses verifying a technical finding before applying a fix.
Start with one fictional generated change and ask a colleague to reconstruct its public-code finding from the pull request alone. Include a moved fragment, an unavailable source and an unresolved notice. Revise the handoff wherever the colleague needs the original chat to understand what remains open. This is a proposed workflow exercise, not a validated compliance program or a test we have performed.