Communities are asking the wrong question. Not because the underlying worry is invalid — it isn’t — but because the filter being applied doesn’t actually catch what it’s trying to catch.

Let me be precise.

The Wrong Question

Two projects. Project A: someone spends two years redesigning a vectorization algorithm, investigates whether machine learning could improve it, decides against it, implements a deterministic approach, discovers their own benchmark was inflated and fixes it anyway, publishes reproducible results, and actively maintains the code. Project B: someone types “make me a music streaming app” into an AI prompt, publishes whatever emerges without testing it, and disappears.

Both used AI. Both get labeled “AI-generated.” One belongs in a developer community. The other is exactly what communities should be filtering out.

Which one gets rejected first?

Both. At the same speed. Because the filter isn’t “is this maintained engineering?” The filter is “was AI involved?” That’s a single binary check. It feels principled. It moves fast. It tells you nothing about the work.

The Actual Standard

Here’s what separates signal from noise in any software project, AI-assisted or not:

Can the maintainer explain the architecture, or does it sound like they’re reading from Stack Overflow? Are there meaningful tests? Can claims be independently reproduced? Are benchmarks transparent? Are weaknesses disclosed? Does the maintainer actually review changes and take responsibility? Will this be maintained in six months, or is it a one-off experiment?

These questions work equally well for human-written code. They’re expensive to verify — they require actual reading, thinking, and judgment. That’s exactly why they’re the right ones.

A Note on the Historical Pattern

This isn’t new. We moved from assembly to C and nobody said “you didn’t really code because you’re using a compiler.” We moved from manual memory management to garbage collection. From raw SQL to ORMs. From writing Dockerfiles by hand to templates.

Each step increased abstraction. Each step generated the same concern: developers are getting lazy, standards are dropping, the craft is being diluted.

Each time, the question that actually mattered wasn’t “what abstraction level did you use?” It was: do you understand what was generated? Can you defend it? Will you maintain it?

AI is the next step on that continuum. More aggressive, more visible, generating more mediocre output faster. Not fundamentally different from any other tool that offloads rote work so developers can focus on decisions that actually matter.

What Good Moderation Looks Like

Require disclosure of substantial AI involvement. Transparency matters. Then judge projects on reproducibility, test coverage, and maintainer accountability. Fast-track projects with public benchmarks or active bug resolution. Catch obvious slop by its lack of depth — not by its origin story.

Bad moderation does the opposite: blanket assumptions that all AI-assisted work is equivalent to prompt-and-publish. Rejection based on the presence of a tool, not the absence of rigor.

DEV’s shift toward requiring disclosure rather than banning AI-assisted content is the right move. It puts the burden on the creator to be honest, then lets the community evaluate the actual work.

The Real Standard

Software development is an orchestration process. The ultimate value is working, audited, tested software — not human typing time.

Engineering should be evaluated on understanding, correctness, maintainability, testing, and accountability. Not keystrokes. Not tool choice. Not origin.

That’s always been the real standard. AI just made it easier to ignore.