SimpleOne shows why Claude and AI reviewers can't tell AI code from human code

SimpleOne offered a simple test: tell human-written code from AI-generated code. It turned out to be hard not only for developers but also for the AI reviewer itself, which checks code against the same patterns that produced it.

Why it's hard

In its article, the team assembled several pairs of functions: email validation, an API request, configuration loading and a discount calculation. In each pair, one version was written by a human and the other by a model. On paper the task looks easy: AI code usually has more typing, more comments and a pseudo-tidiness. In practice it is messier. Some examples do give themselves away with excessive correctness, but by the third or fourth pair it becomes clear that style alone often cannot reveal the author.

The strongest example is the discount calculation function, where the difference between the versions almost vanishes. Both snippets work, both pass static analysis, both look reasonable. But the real error hides not inside the function but at the place where it is called. If a discount must be fixed at the moment an order is placed, recalculating it every time the page is opened is wrong. That is no longer a question of syntax or best practices but of business logic and project context, which an automated reviewer usually lacks.

What gives synthetic code away

SimpleOne identifies several signs by which AI code can sometimes still be spotted. These are not gross errors but a suspiciously "perfect" style: the code looks tidy but behaves as if it is trying to impress the reviewer rather than solve a specific production task. These signals surfaced most often in the email, API and config examples.

• Overly detailed docstrings listing Args, Returns and every exception, even for a tiny function.
• Extra edge cases and checks that nobody asked for and that do not follow from the task statement.
• Invented entities around the code: custom exceptions, loggers or required fields that do not exist in the project.
• "Safe" fallbacks such as data.get('user', {}) that do not fail immediately but mask the real problem.

Hence the main risk: AI often writes not plainly bad code but code that looks convincing. It is typed, formatted, commented and covers a host of scenarios. But some of those scenarios are taken out of thin air, and some of the defensive constructs only complicate debugging. Such code is easy to mistake for quality if you look at form and do not check how it fits into a specific system.

Where review breaks down

The problem SimpleOne describes is not limited to the quality of a single model. If Claude generates code and another AI tool then checks it against the same patterns, the team ends up with a closed loop of synthetic confidence. Everything looks green: there are types, error handling and comments. But the review may fail to notice that UserFetchError does not exist in the project, that secret_key appeared out of nowhere without any requirement, or that a "silent" return of an empty dictionary will later cost hours of bug hunting.

"The AI reviewer found 2 of 5."

The team tested this on real production bugs. The automated reviewer caught only two simple cases: an unused variable and a missing null check. It missed the issues that require project context: a logic error in a calculation, a race condition under parallel requests and a wrong migration order.

The takeaway is practical: AI works well as a first filter but does not replace a human in critical areas where understanding domain logic and the consequences of changes matters.

What this means

Widespread use of AI in development changes not only the speed of writing code but also the quality-control process itself. Checking generated code with another generative tool is useful but not enough. If a team does not test its reviewer on old bugs and does not keep a human in the decision chain, it risks getting not quality but a very plausible imitation of it.