How to tell if a repo was written by an AI

Let's set the moral question aside, because it isn't the interesting one. Plenty of excellent software is written with heavy AI assistance, including some of ours. Nobody should be judged for it.

The reason to care is narrower and more practical: a generated repo and a built repo fail in different places. A built project is usually rough at the edges and solid in the middle — the author fought the hard part and left the polish. A heavily generated one is often the reverse: beautifully consistent surface, and nothing behind three of the doors. If you're buying, you want to know which you're looking at, because it changes where you should spend your review time.

Here's what actually distinguishes them.

The strong tells

Elision comments. This is the one that matters most:

`` function processPayment(order) { // ... rest of the implementation unchanged } ``

Variants: // ... existing code ..., # ... remainder of the function, /* same as above */. These appear when a model is asked to modify a file it can only partly see, and the answer gets committed verbatim. The file does not contain what it appears to contain. In a repo you're buying, that isn't a style question — it means the thing you're paying for is partly missing.

Uniform comment density. Human code has comments where the author was confused and none where they weren't. Generated code tends to comment everything at the same rate, including the obvious. A file where every single function has a tidy three-line docstring and nothing has an exasperated note is unusual.

Docstrings that restate the signature. /** Gets the user by ID. @param id The ID of the user. */ describes nothing the reader didn't already know. One is nothing. A hundred is a texture.

No dead ends. Real projects contain the archaeology of decisions: an abandoned helper, a commented-out approach, a file named utils2.ts. A repo with no scar tissue at all was either heavily cleaned or never fought.

The weak tells

Worth noticing, not worth concluding from:

• Placeholder names that survived — example.com, John Doe, your-api-key

in code paths rather than docs.

• README polish out of proportion to the code — a beautiful badge-laden README

over 200 lines of implementation.

• Suspiciously complete error handling on paths that were never run.
• A single enormous first commit. Could be a generated repo. Could equally be

someone who squashed, or moved the project between hosts. On its own it means nothing.

What isn't a tell

• Consistent formatting. That's a linter.
• Modern idioms used correctly. That's a competent developer.
• Good test coverage. Generated tests are often shallow, but so are plenty of

human ones, and plenty of generated code is genuinely well tested.

Being wrong about this in public is a good way to insult someone who simply writes tidily. The tells are for calibrating your own review, not for accusations.

What to do about it

Nothing dramatic. Adjust where you look:

1. Run it. Generated repos disproportionately fail to build, because nothing

ever forced them to. This one check settles more than any amount of reading.

1. Open the file that does the hard thing — the payment logic, the sync

engine, whatever the project is actually *for*. Surface consistency is cheap; a correct hard part is not.

1. Search for elision markers before anything else. grep -rn "rest of the"

takes two seconds and is the highest-yield check on this list.

1. Ask the seller what they'd change. Someone who built a thing has opinions

about its worst part. It's a hard question to answer convincingly about code you didn't write.

What we do about it

Cinderella runs these checks before a listing goes live, because a marketplace that scores "readiness" has an obvious problem if readiness can be faked. Listings are scanned for elision markers, unimplemented stubs and untouched starter scaffolding, and the findings go to a human reviewer. Vendored and generated code is excluded from the valuation, so committing a vendor/ directory can't inflate a price. And we run the build in a sandbox and publish the result — including when it fails.

None of that is a lie detector, and it isn't meant to be. It's meant to make the cheap ways of faking readiness stop working, so that what's left is the thing you actually wanted to buy.