Judging a project by the tool that touched it is a proxy

The real-world example that sticks with me is Madsen's Open Vectorizer story. He rewrote an algorithm pipeline, benchmarked it against established tools, caught a bug that artificially inflated his own results, and published the worse numbers anyway. That project still gets flagged because somewhere along the line someone decided "AI-assisted" is a synonym for "low effort." Meanwhile, you can paste a "make me a music streaming app" prompt into an LLM, publish whatever falls out untested, and let it rot — and it gets the same rejection letter.

That's the broken filter.

Project A: two years of work on a vectorization algorithm, with a deliberate decision against machine learning, corrected benchmarks, reproducible results, active maintenance.

Project B: a single prompt, zero testing, no follow-up.

Both get labeled "AI-generated." Both get rejected. Only one deserves a seat in a genuine developer community.

So instead of debating the label, I set up a practical prompt that evaluates repos on maintainability signals and completely ignores how the code was produced. It's a hands-on filter I use when triaging AI-assisted projects:

You are a senior engineering reviewer. Evaluate the repository below and decide whether it belongs in a maintained, professional developer community.

Ignore how the code was created — human, AI-assisted, or fully automated. Provenance is irrelevant to this review.

Assess these signals only:

1. Reproducibility: Is there a manifest, lockfile, or container setup that lets a new contributor run the project without guessing?
2. Testing: Do tests exist? Do they cover the critical paths rather than just happy paths