Was this written by a person, or generated?

Method

How the number is arrived at

Every signal carries a weight in log-odds, and the weights are summed against a starting assumption that a given page is not generated. The result goes through a logistic curve to become a percentage. That is the whole trick, and it matters far less than which signals are weighted how.

Evidence is not equal, so it is not weighted equally

1. Platform fingerprintsA builder's own runtime, badge, upload path or generator tag. This is a positive identification and it settles the question by itself.
2. Repository historyOne enormous opening commit, hundreds of lines in minutes, a trail of one-line fixes behind it. The hardest thing to fake after the fact, and the reason the third tab exists.
3. Structural signalsUniform comment density, the same problem solved four ways, fully-built code wired to nothing. Hard to produce by accident, hard to fake.
4. Code-style tellsWhat-not-why comments, blanket try/catch, swallowed exceptions, tests that assert nothing, emoji in comments.
5. Content and securityStatistically generic testimonials, placeholder secrets, textbook-insecure defaults. The security profile decays slowest of all the tells.
6. AestheticsIndigo gradients, the default icon set, three identical cards. Counted, capped, and never enough on their own to reach a verdict.

Rules the scoring will not break

• Aesthetic evidence is capped as a group. A purple page with no other tells cannot score above 55%.
• Every category has a ceiling. Signals within one are not independent, so eight weak style tells must never outweigh a single hard fingerprint. Fingerprints are the only category with no ceiling.
• A reading never reaches 0% or 100%. Certainty is not available here.
• Short input is explicitly discounted rather than quietly guessed at.
• Signals pointing at human authorship subtract, and they are weighted as heavily as the ones pointing the other way.

The full catalogue, with every signal, its weight, and why it earns that weight, is in docs/SIGNALS.md.

Limits

Where this is wrong

Signs run in one direction only

Finding a fingerprint identifies a builder. Finding none proves nothing at all, because agentic editors write into an ordinary repository and leave nothing behind in the served page.

The tells overlap with good practice

Tailwind, semantic HTML, thorough error handling, descriptive names and consistent formatting are what careful developers do. That is the central false-positive risk and no amount of weighting removes it.

Masking is cheap

Renaming variables, stripping comments or running the file through a formatter erases most of what this reads. Minified bundles are excluded from code-level analysis for exactly this reason: the signal has already been normalised away.

What it can only see if you show it

The strongest signal available is repository history: one enormous opening commit followed by a trail of micro-fixes. That lives in git, not in a served page, so the URL tab cannot reach it — you have to paste a git log into the third tab, which means having the repository in the first place. When you do have it, start there and treat the other two tabs as corroboration.

Even then it reads the shape of the work rather than who did it. A developer who commits carefully while an agent writes the code produces a history that looks entirely human, because in every respect that git records, it is.

The better question

Authorship is usually not what anyone actually needs to know. Reviewed, tested, understood AI code is just code. The useful question is whether anyone understands this system and can secure it, which is why the security signals are here, and why they are the ones that will still work in five years.

Provenance

Half of this was vibecoded

Roughly half and half. The code was generated by an AI agent: the detection engine, the page you are reading, the PDF writer, the logo, the test suite. The other half is human and it is the half that decided anything — the research the signal catalogue is built from, which tells were worth trusting and what each one is worth, the calibration, the design decisions, and the bug reports that fixed what the machine got wrong.

So: a half-vibecoded app for detecting vibecoded apps.

Point the detector at this site and it returns 55%, inconclusive. For a codebase that is genuinely half generated and half not, that is arguably the most defensible number it has ever produced. It is also luck. It arrived there by failing to detect the generated half, not by weighing the two:

• Nothing to fingerprint. Agentic editors write into an ordinary repository. No badge, no builder subdomain, no injected runtime. Signs run in one direction only, and this site is the direction they do not run in.
• The tells were avoided on purpose. No what-comments, no docblock on every trivial function, no indigo gradient, no Inter, no three-card grid. That is masking, and masking is cheap. It took no particular effort.

The number sits at 55 because the aesthetic cap holds it there: some stylistic signals fired, no structural ones did, and the scoring refuses to reach a verdict on stylistic evidence alone. The guard rail is doing its job. That it lands on a defensible answer for indefensible reasons is the honest summary of what this kind of tool can do.

Which is also the argument for the thing this site keeps insisting on. The score is the least interesting item on the results page; the evidence underneath it is the point. If reading this makes you trust the number less, that is the correct response, and it is why the number was never shown to you on its own.