Someone on tintotint.eu went through every app in the September 12, 2026 F-Droid update batch, 102 apps, and classified each one by how likely it is that an LLM wrote it. Mostly AI, hard to say, no signs of AI. One student, one batch, a few tiers, done.
The results are less interesting than the method, because the method is the honest part.
Here's how they classified: no slop detector, no code analysis. Just repo aesthetics. Commit tone. Emoji density in the README. Whether the repo has Claude Code or Codex agent infrastructure wired in. Whether there's an AI disclosure line in the README at all. One data point I trust: anything with the agent harness present got thrown straight into "mostly AI";
I'm a fan of this because the author states the limits up front. No way to know for sure, tiers are loose, the rating is superficial. That's the same caveat I keep running into and it deserves more attention than the headline number that everyone will extract from this.
Anyone who has done code review on a repo that ships quickly knows the tell is not the code. It's the commit messages being perfectly uniform, the PR description covering exactly the changed lines and nothing else, the changelog using the same boilerplate every release. None of that tells you whether the logic is correct. It tells you how the author works.
Here's the part that matters for review, and specifically for the "review the growing volume of AI-generated code" question that keeps coming up. You cannot reliably detect whether code was AI-authored, even looking at the full repo with its history and branding. If the author of this survey is right, and they're pretty careful, then provenance is not resolvable. Which means the whole idea of gating review on "is this AI code" is a dead end.
What you actually have is the code in the diff. That's the thing to review, regardless of who or what wrote it.
So stop trying to label AI code and review the properties that hold no matter the author. Does the change touch auth before or after the validation? Is the error path handled or just the happy path? Does the new dependency have a tag? Those answer the question "should this merge?" The provenance questions answers "what can I blame if it breaks?" and that one is not yours to answer.
If you're building the review gate on top of "detect the LLM output," you're building it on a signal the survey just showed is unreliable even with full repo access. Review the diff. Origin-independent review is the only framing that survives contact with this data.