How to Detect AI-Generated Code in Pull Requests and Take-Home Tests

A reviewer's guide to spotting AI-generated code in pull requests and take-home interview tasks, why it matters, and how to review it without guessing.

AI coding assistants now write a meaningful share of the code that shows up in pull requests and take-home interview submissions. Often that is perfectly fine. But reviewers have good reasons to care where code came from: an author who did not write a change may not be able to maintain it, generated code can hide plausible-looking bugs, and a take-home test is meant to show what the candidate can do. This guide covers what to look for, how to respond, and how to keep the process fair.

Why the origin of code matters in review

• Understanding. Whoever opens a pull request is expected to support it. If they cannot explain how it works, bugs and follow-up questions will land on someone else.
• Plausible bugs. Generated code tends to look confident and well structured even when it is subtly wrong, for example handling the common case perfectly while mishandling an edge case, or calling an API method that does not exist in the version you use.
• Fit with the codebase. Chat-generated code is written without the full project in view, so it often duplicates existing helpers or ignores local conventions.
• Licensing and provenance. Some projects require contributors to certify that they have the right to submit their code. Knowing how code was produced is part of that.
• Hiring signal. In a take-home task, the point is to see the candidate's judgment. Fully generated code tells you little about it.

Signs in the diff

Look at the change as a whole rather than hunting for a single giveaway:

• Large, fully formed changes from a contributor whose earlier pull requests were small and incremental.
• Comments that explain the obvious and docstrings on every trivial function, in a codebase that does not do that.
• Reinvented utilities. New helpers for things the project already has, such as a fresh date-formatting function next to an existing one.
• Generic error handling wrapped around everything, with messages like "An error occurred" instead of the project's own error types.
• Unfamiliar APIs or outdated patterns. Calls to library functions that do not exist, or patterns from an older version of a framework.
• Tests that mirror the implementation rather than probing behavior, or that only cover the happy path.
• A pull request description that is polished and generic but does not mention the actual trade-offs or the issue being fixed.

None of these proves anything on its own. Senior engineers write clean code, formatters erase personal style, and some contributors are simply thorough. Use the signals to decide where to spend review time.

Review questions that reveal understanding

The most effective approach is to ask questions you would ask about any change, and pay attention to the answers:

• "Why did you choose this approach over using the existing helper in utils?"
• "What happens here if the request times out?"
• "How did you test the edge case where the list is empty?"
• "This adds a new dependency. What does it give us that we did not have?"

These questions are fair whether or not AI was involved. An author who understands their change answers them easily. An author who does not will tend to reply with vague or generic explanations, and that is worth addressing regardless of how the code was produced.

Take-home interview tasks

Take-home tests are particularly exposed, because candidates work unsupervised and the tasks are often self-contained problems that assistants handle well. A few practices make them more informative:

1. State the AI policy up front. Tell candidates whether AI tools are allowed and whether they should say how they used them. Many companies now allow it and assess how well the candidate guides and checks the tool.
2. Ask for a short write-up. A paragraph on design choices, trade-offs and what they would do with more time reveals judgment that is hard to fake without understanding.
3. Use the follow-up interview. Have the candidate walk through their solution, then ask them to extend it or fix a small bug you introduce. This is the single most reliable check.
4. Look at the history. If you ask for a Git repository, a series of meaningful commits says more than one large initial commit.
5. Do not auto-reject on a score. A detector flag is a prompt for better follow-up questions, not grounds for rejection on its own. False positives are real, and rejecting a strong candidate for writing clean code is a costly mistake.

Using a detector in your workflow

An AI code detector is handy for quick triage: paste a suspicious function, read the verdict and, more importantly, the reasons. If the reasons match what you noticed in review, you have a clearer picture of what to ask. Paste a meaningful chunk, ideally a complete function or file section, because short snippets give unreliable results. Never paste secrets, keys or code your employer does not allow you to share with third-party services.

Remember the limits. A detector sees only the snippet, not the author's history, the project conventions or the conversation around the change. It can be wrong in both directions, and edited AI output is particularly hard to classify. Treat the result as a second opinion that helps you decide where to look.

Write it down as a policy

Most friction around AI code comes from unclear expectations. A short line in your contribution guide or interview instructions goes a long way: whether AI assistance is allowed, whether it should be disclosed, and that the author is responsible for understanding, testing and having the right to submit everything in the change. With that in place, review can focus on what matters most: is the code correct, and does the author own it?

Frequently asked questions

Try the detector

Have a snippet you are unsure about? Paste it into the free AI Code Detector to get a verdict, an AI probability and the reasons behind it. No sign-up, and your code is not stored.