Whether you’re reviewing a pull request, grading an assignment, or doing due diligence on an acquisition, the question comes up: how to know if code is AI generated? Here’s the field guide — the signals, the tools, their limits, and the approaches that actually settle the question.
How to know if code is ai generated: What Actually Works
After reviewing thousands of AI-assisted diffs, patterns emerge. Comment style: thorough, consistent, slightly formal — every function documented, every tricky line explained. Humans are spottier. Structure: textbook-clean organization, often more structured than the surrounding codebase warrants. Naming: descriptive but generic (fetch_user_data, validate_input) — correct, unmemorable. Error handling: comprehensive to a fault; AI rarely writes the “good enough” error handling humans ship under deadline.
The uncanny valley of quality: the most telling signal isn’t bad code — it’s uniformly good code. Human codebases have texture: brilliant passages next to ugly hacks, consistent style drifting over time. AI-generated code is textureless. Perfectly average, everywhere, all at once.
Detection Tools: Know Their Limits
Code detectors analyze perplexity and pattern signatures, but they’re unreliable as evidence. They false-positive on clean human code (especially from non-native English speakers, a documented bias) and false-negative on lightly-edited AI code. A detector score is a conversation starter, never a verdict. Checking if code was AI-written covers the tool landscape in detail — and what teachers use shows why academic reliance on detectors has caused real harm, including false accusations students have had to fight.
Methods That Actually Work
- Git archaeology. Look at how the code arrived: incremental human commits with mistakes and fixes, or a pristine 800-line debut? History doesn’t lie about process.
- The explanation test. “Walk me through this function’s logic.” Authors explain fluently; pasters stumble. Works in code reviews, interviews, and classrooms alike.
- The modification test. “Change it to handle this edge case.” Real familiarity shows in seconds.
- Style comparison. Compare against the author’s known work. Sudden, dramatic quality shifts are informative (though people do improve).
Building a Team Culture Around Disclosure
The detection arms race is a symptom; the cure is culture. Teams that normalize disclosure — “AI-assisted” labels on PRs, no stigma attached — get honesty instead of hiding. Developers who can say “the agent drafted this, I reviewed and modified these parts” produce better outcomes than developers secretly pasting and hoping nobody notices.
Make disclosure useful, not performative: reviewers should know which parts are AI-generated to focus their scrutiny (hallucinated APIs cluster in generated sections). Celebrate good AI usage openly — “great prompt engineering on this refactor” — so the norm becomes skillful use, not concealed use. And keep the focus where it belongs: review rigor for all code, regardless of origin. A team that reviews well doesn’t need to detect; a team that detects but reviews poorly has the wrong defense entirely. Culture beats forensics.
The Interview Version: What Hiring Managers Do
In hiring, “is this AI-generated?” takes a specific form: the take-home assignment that comes back suspiciously polished. Good hiring managers don’t run detectors — they discuss the submission live. “Walk me through your approach here. Why did you choose this data structure? What would break if the input doubled?” A candidate who did the work (with or without AI assistance) answers fluently; one who pasted blindly collapses within minutes. Many companies now pair take-homes with a 30-minute follow-up discussion for exactly this reason.
The deeper hiring insight: the question is becoming obsolete. When every candidate has AI assistance, “did AI help?” stops differentiating — like asking whether they used Stack Overflow in 2015. What differentiates is judgment: the design decisions, the trade-offs articulated, the edge cases considered. Forward-thinking hiring processes are redesigning around this: live problem-solving, system design discussions, and take-homes that explicitly allow AI but require explanation. If you’re a candidate: disclose your process confidently (“I used AI for the boilerplate; the architecture decisions are mine, here’s why”). If you’re hiring: test thinking, not typing. The typing was never the skill.
When You Should Stop Investigating
Here’s the liberating conclusion: most of the time, stop. If the code is correct, tested, secure, and maintainable — ship it. The industry’s healthiest direction is away from authorship forensics and toward universal rigor: review everything well, test everything properly, disclose AI assistance openly, and judge artifacts on merit. The energy spent detecting could be spent reviewing, and reviewing catches real bugs while detection catches… authorship trivia.
Investigate authorship only when authorship itself is the point — academic integrity, hiring evaluation, IP due diligence. Everywhere else, let it go. The future of software isn’t human-written or AI-written; it’s well-engineered, by humans and AI working together, verified by processes that don’t care who typed the characters. That’s the world worth building toward — and it starts with asking better questions than “who wrote this?”
The Takeaway
Look for textureless perfection in the code, treat detectors as hints not verdicts, and rely on process evidence — git history and explanation tests — for real answers. But keep perspective: in professional work, “is it correct, secure, and maintainable?” matters more than “who typed it?” Judge the artifact; investigate the process only when the process matters.
Related reading: AI content detection limitations on Wikipedia.
