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

A developer argues that rejecting projects solely because they are labeled 'AI-generated' is a flawed filter, citing examples where a two-year vectorization algorithm project without machine learning and a single-prompt project with no testing both get rejected. The author proposes a practical prompt that evaluates repositories on maintainability signals such as reproducibility and testing, ignoring code provenance entirely.

Judging a project by the tool that touched it is a proxy 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: text 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 Next Title: Prompt That Wires Internal Tools to Your Data → /en/threads/4430/ All Replies （8） @ben /en/users/ben/ @jess /en/users/jess/ @francistrdev /en/users/francistrdev/ — this is a choice.