Passing tests can show that code behaves as expected for the cases those tests cover, but they cannot prove who wrote it or whether it is original.
Understanding the difference between software testing, code similarity, and AI authorship classification helps you interpret evidence fairly.
What does passing a test actually show?
A test checks an observable result against an expectation.
A unit test might confirm that a function returns the right value for a given input, while integration tests check whether components work together.
A test suite can also examine edge cases, error handling, performance, or security, depending on how it was designed.
When code passes, the narrow conclusion is that it produced the expected results in the tested conditions.
Tests do not automatically cover every input, execution environment, or failure mode.
They also say nothing by themselves about where the code came from.
Original code, copied code, and AI-generated code can all pass the same tests.
Why functional correctness is different from originality
Correctness and originality answer different questions.
Testing asks, “Does this implementation behave as expected?” An originality review asks whether the implementation contains material that is substantially similar to another source, and an authorship inquiry asks who created or contributed to it.
These questions may overlap in a review, but one kind of evidence cannot stand in for the others.
A passing test is evidence about behavior.
It is not a source comparison, provenance record, or reliable authorship determination.
Likewise, a failed test does not indicate copying; it may simply reveal a bug or an incorrect assumption.
What can code similarity tools tell you?
Source-code similarity tools compare code with other material in a reference set or corpus.
Depending on the tool and its design, they may identify matching or structurally similar passages, repeated patterns, or likely overlap.
A match can provide a lead for human review, but it does not by itself prove misconduct.
Common programming patterns, standard algorithms, short expressions, required templates, and code produced from the same assignment constraints can look alike without one person copying another.
Conversely, substantial reuse can be difficult to identify if code has been renamed, rearranged, or rewritten.
Reviewers should examine the specific passages, their context, the tool’s comparison scope, and any relevant explanation or source history.
Codespy currently lists JavaScript, Python, Java, PHP, C/C++, and C# among its supported languages.
If considering it, treat its output as a signal to inspect, not as a verdict or an independently verified finding.
This article does not report a hands-on evaluation of the product, and a detector’s results should be interpreted according to its documented scope and limitations.
Can an AI detector identify who wrote code?
AI authorship classifiers estimate whether content resembles patterns associated with machine-generated output.
They do not establish authorship with certainty.
Code adds difficulty because programming languages use constrained syntax, shared conventions, libraries, and recurring solutions.
Human-written and AI-generated code may therefore share surface characteristics.
An AI classification score is not proof that a person used AI, just as a low score is not proof that they did not.
False positives and false negatives are possible, and results can depend on the code sample, language, detector, and surrounding material.
A score should not be treated as an accusation or a substitute for a transparent review process.
Turnitin has stated that its AI writing model does not reliably detect code.
Its AI writing report should not be confused with source-code similarity tools, which address overlap between code samples rather than whether text appears AI-generated.
These are distinct kinds of analysis, with different inputs and limitations.
What evidence is more useful in an originality review?
A fair review combines relevant evidence instead of relying on a single test result or detector score.
Useful material may include:
- Version history: Commits or other saved drafts can show how an implementation developed over time, though they do not alone prove who made every change.
- Source attribution: Comments, citations, licenses, and documentation can clarify whether a snippet came from a permitted source.
- Similarity context: Review the matching code, its length and distinctiveness, the comparison sources, and whether standard patterns explain the overlap.
- Technical explanation: The author can describe design choices, trade-offs, and how the code handles particular cases.
This is one part of review, not a definitive authorship test. - Applicable rules: Check the assignment, organization, or project policy for requirements on reuse, attribution, collaboration, or AI assistance.
Policies vary across schools, employers, clients, and open-source projects.
The same reuse may be permitted in one context and restricted in another, so assess the code against the rules that actually apply rather than assuming a universal standard.
How can developers document their work?
Developers can make later review clearer by keeping meaningful version-control commits, recording sources for borrowed snippets, and documenting substantial design decisions.
When AI tools or outside collaborators are involved, follow the relevant disclosure rules and preserve enough context to explain the work where required.
These practices do not guarantee acceptance under every policy, but they make provenance easier to discuss.
They also help teams maintain code, investigate bugs, and distinguish intentional reuse from accidental duplication.
Tests remain valuable: they support confidence in behavior, while documentation and source review address different questions.
How should you interpret a passing test and a detector result?
Interpret each result according to what it measures.
Passing tests support a limited claim about tested behavior.
Similarity results point to potential overlap that needs contextual review.
AI detection scores estimate authorship patterns and should not be treated as proof.
None of these findings, alone, establishes originality or misconduct.
A sound judgment depends on the code itself, its development history, relevant sources, and applicable rules.
Keeping those questions separate makes technical reviews more accurate and helps avoid turning a useful signal into a claim it cannot support.