When code looks unusually polished, inconsistent, or unlike a contributor’s earlier work, it can be tempting to reach for an AI detector.
A fair investigation instead starts with the code’s history and context, because a classification score cannot establish who wrote a change or whether a rule was broken.
Start by defining the concern
Clarify what you are trying to determine before reviewing evidence.
The questions “Was an AI tool used?”, “Does this code resemble a known source?”, and “Does the change meet project requirements?” are different questions and call for different evidence.
- AI authorship classification estimates whether text may resemble AI-generated output; such scores do not identify a specific author or reliably reconstruct how a change was produced.
- Code similarity or plagiarism review looks for overlap with other code, such as matching structure or text.
Similarity can arise from shared libraries, common programming patterns, copied examples, or legitimate reuse; it does not by itself prove misconduct. - Engineering review evaluates correctness, security, maintainability, and compliance with the project’s contribution rules, regardless of how the code was written.
Write down the specific concern, the relevant policy or expectation, and what evidence could address it.
If the policy does not prohibit AI assistance, discovering possible AI use may not establish a violation.
Check the rules and explain the process
Review the applicable course, workplace, contract, or open-source contribution policy.
Policies vary: some permit AI assistance with disclosure, some restrict particular uses, and others focus on accountability for submitted work.
Do not assume a rule applies without checking its wording and scope.
Where appropriate, tell the contributor what prompted the review and invite a response.
A neutral conversation can establish whether they used an assistant, consulted documentation, adapted a template, or worked with another developer.
An explanation is context to assess alongside records and technical evidence, not an automatic verdict either way.
Examine the code’s provenance and development history
Begin with ordinary software-development records.
A repository’s version-control history often gives more useful context than a detector result because it shows how the change relates to the project over time.
- Inspect the commit history, pull request discussion, and review comments.
Look for incremental changes, revisions, and explanations of design decisions. - Compare the patch with the surrounding codebase.
Consistent naming, architecture, formatting, and error handling may indicate adaptation to local conventions, but style alone cannot establish authorship. - Review dependency, license, and attribution information.
Check whether copied snippets or generated code introduce obligations or provenance concerns. - Ask the contributor to explain the change, including edge cases, trade-offs, tests, and how they would modify it if requirements changed.
These checks assess understanding and accountability, not whether someone typed every character unaided.
AI-generated code can be revised substantially, while human-written code can look generic or unfamiliar.
Use technical checks to assess the change
Run the project’s normal review process: tests, static analysis, dependency and security checks, and code review.
Examine whether the patch meets its requirements and whether it creates defects, vulnerabilities, or unexplained dependencies.
A failing test is evidence of a technical problem; it is not evidence of AI authorship.
If the concern involves similarity, identify the matching material and investigate its source.
Determine whether the overlap is a standard idiom, permitted reuse, an attributed snippet, or an unexplained copy.
Document the exact files and passages under review, and distinguish a match from the interpretation of that match.
Interpret AI code detector results cautiously
AI writing detectors may estimate whether text resembles AI-generated output, but their scores do not prove who authored a change, which tool was used, or whether a person violated a policy.
Turnitin states that its AI writing model does not reliably detect code.
Its AI writing report is distinct from source-code similarity tools, which look for overlap rather than establish AI authorship.
Codespy is an external source-code detector that may be considered as one limited signal in a broader review.
Treat any output as a prompt for further inquiry, not a finding.
Check what material the service requires, review its current documentation and data-handling terms, and avoid submitting confidential or personal code unless authorized.
Do not substitute a writing detector for a source-code review.
Turnitin states that its AI writing model does not reliably detect code.
Its AI writing report is distinct from source-code similarity tools, which look for overlap rather than establish AI authorship.
Keep the evidence proportionate and documented
Record the question being investigated, the relevant policy, the materials reviewed, and how each finding supports or fails to support the concern.
Separate observations from interpretations.
For example, “the patch uses a library not present elsewhere in the project” is an observation; “therefore it was AI-generated” is an unsupported inference without more evidence.
Give the contributor a meaningful opportunity to explain relevant details before making a consequential decision.
Limit access to the code and investigation notes to people who need them, especially when repositories contain proprietary, customer, or personal data.
Follow applicable retention and privacy rules.
Use the least intrusive process that can answer the question.
A targeted code review and discussion may be enough; broad device searches or demands for private chat histories are disproportionate in many settings and may conflict with policy or law.
Escalate only through the organization’s established review process when the evidence and stakes warrant it.
Make decisions based on the applicable standard
Assess the evidence against the actual rule and decision standard, not against a detector label.
Consider provenance, similarity findings, technical quality, contributor explanations, and available records together.
If the evidence cannot establish a policy breach, record that uncertainty rather than presenting a probability score as proof.
A sound investigation focuses on what can be verified: whether the code is original or properly attributed, whether it meets technical requirements, whether the contributor can account for the work, and whether documented expectations were followed.
That approach supports consistent decisions while recognizing that AI assistance, code similarity, and misconduct are separate issues.