Many of developers communities are asking the wrong question.
Not because they're wrong to worry about low-effort work, no, but the filter they're using doesn't actually separate maintained engineering from generated slop. It just separates projects based on which tools were involved in their creation.
Imagine trying to share a work that you're really proud of, with the help of AI assisting it, the idea's yours but your work gets flagged, rejected, or buried under comments like "no you didn't" and "I hate how there's so many AI projects these days." Someone definitely felt righteous after saying this, believing they're protecting themselves from low-effort slop.
Except that's not actually what they're protecting against. They're protecting against a label.
The Distinction
I read @madsendev 's article regarding Open Vectorizer and Madsen wants to share the project with other people and in hope that someone would like to contribute as well.
Apparently, difference between "AI-generated" and "maintained engineering" has become invisible to gatekeepers who've simplified the filter down to a single binary question.
the wrong question.
" AI or no AI "? ( they didn't literally ask this but that's the filter in practice )
Here's why: imagine 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 are labeled "AI-generated." One belongs in a developer community. The other is exactly what communities should be filtering out.
Guess which one gets rejected? yah, both get rejected. The luckiest you can get is being rejected later because the gatekeeper was busy arguing with you and changing their community name to: " i miss what was it like to program on punch cards and a ciggy in my mouth " ahhh yes, the identity crisis.
The Problem With Using "AI-Generated" as a Quality Filter
The gatekeeping argument seems reasonable at first glance. But it has real problems:
The dismissal: "no you didn't (via @deammer). This response requires ignoring the actual technical work, but Madsen rewrote an entire algorithm pipeline, tested it against established tools, and caught a bug that made his own benchmarks look better, then published the worse numbers anyway. That's not someone slapping a prompt onto Claude and calling it a day.
The broader concern: @blakebeckcoding points out something real, unvetted AI-generated code has introduced security vulnerabilities. That's a legitimate worry about maintainability and accountability. Where the argument breaks down is treating that as sufficient reason to reject every AI-assisted project before evaluating its technical merits. The concern about low-quality code is valid. The heuristic of "reject based on tool choice" doesn't actually address it.
Think of it differently: we don't reject all Rust packages because Rust makes memory safety easier, nor do we assume all C projects are insecure because C makes memory errors possible. Language choice affects probabilities, but it doesn't determine quality. The same applies to AI.
The nostalgia play: "Dev.to used to be good" (same dude, you know who, bro's just nostalgic). There's an assumption that developer communities were higher-quality before AI tooling arrived. But humans have been publishing terrible code since the 1980s, spamming them has always been a problem and it isn't new, AI just makes it easier and cheaper to spam.
The Real Problem (And Why It Requires Actual Work)
Developer communities are being flooded and it's not the AI-generated projects specifically but low-effort projects, period. and like I said up there, the flood's rising fast at an overwhelming rate because AI made it cheaper to produce them.
The solution, though? It's not "ban the AI ones."
It's understanding what actually separates signal from noise:
- Can the maintainer explain the architecture, or does it sound like they're reading 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 lab experiment?
These questions work equally well for human-written code. And they're expensive to verify, they require actual reading, thinking, and judgment.
"Was AI used?" is cheap. One checkbox. Feels principled. Lets moderators move on.
"Is this maintained engineering?" requires actually engaging with the work.
The Pointed Out Irony
In the comment thread, @unitbuilds delivered the most sensible take on all of this:
"Software development is an orchestration process where the ultimate value is the working, audited, and tested software—not just human typing time."
And then:
"If that's the kind of comments you leave, go to X and join the cesspool, or Reddit, they'll love you there. Please keep Dev.to a safe space for all developers."
hits good, doesn't it? it's not defending AI in the abstract. It's defending communities staying communities, places where people can share work and get feedback, not face purity tests based on which tools they used.
The person who said they used 99% AI to ship a 3000-line game while working full-time deserves to share that. So does someone who used GitHub Copilot for routine completions. So does the Open Vectorizer author who made architectural decisions with AI assistance but wouldn't ship something they couldn't explain.
What none of them deserve is dismissal based on a label that tells you nothing about the quality of the work.
The Historical Perspective
This is something that might seem beside the point but isn't: software development has always worked this way.
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. From Stack Overflow copy-paste to IDE refactoring to GitHub Copilot autocomplete.
Each step increased abstraction. Each step generated concern that developers were getting lazy, that standards were dropping, that the craft was 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?"
That's been the real standard all along.
AI is just the next step on that continuum. It's more aggressive, more visible, and it generates more mediocre output faster. But it's not fundamentally different from any other tool that lets developers offload rote work to focus on decisions that matter.
The question isn't whether AI should be accepted.
In short, people have been saying software development is dead since the first high level programming language was invented... just, circling around the same anxiety cycle over and over.
The Good Moderation Requirements
no, it's not "open the floodgates." it's about what you're really filtering
Good moderation would:
- Require disclosure of substantial AI involvement (transparency matters)
- 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 its origin story
- Create space for people who are learning while filtering out low-effort republishing
Bad moderation does what's happening now:
- Blanket bans that assume all AI-assisted work is equivalent to prompt-and-publish
- Dismissive comments that never engage with technical substance
- 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 great. It puts the burden on the creator to be honest, then lets the community decide based on the actual work.
What Actually Matters
@unitbuilds had it right: a developer community's job is to share work and get substantive feedback, not police the method.
The questions that separate good engineering from slop are straightforward:
- Can you explain the architectural decisions?
- What broke, and how did you fix it?
- Are benchmarks reproducible?
- Will you maintain this?
- Are you willing to be corrected?
They work regardless of whether code was typed by a human, generated by Claude, or mixed. Because they're about understanding and accountability - what has always determined quality.
Engineering should be evaluated on understanding, correctness, maintainability, testing, and accountability. Not keystrokes.
Top comments (32)
apologies for the sloppy writing, found and edited a bunch of typos.
Thank you for speaking up on the topic. I find that far too many people write off AI-generated as 'they dont know how the system works', instead of judging it on the merit of the project. If it can run a standardized benchmarking suite against competition, it's provable and reproducible. If that's good enough for a scientific discovery, it's good enough for programming. I dont like this cancel culture going on around AI. Job interviews now require that you explicitly dont use AI for assessments, which is understandable, they want to see your judgement, but it's the wrong means of answering the question. Rather give them a multiple choice question on 'which route should the AI take', given the findings and the code, so they can see if the person can actually steer an AI. That imo, is a more valuable skill than the simple task of splitting a Kotlin repository's monolithic files. We all use AI, we all rely on it daily and the burden of the developer has shifted from recalling syntax into pattern recognition and flow dynamics. Senior devs are used to reviewing juniors' code, giving feedback and making minor corrections, enforcing company standards, except all of these should be put into writing, either by the senior, or the junior taking notes. That's the dynamic with AI, it's brilliant, but you need to teach it your procedures and patterns, it takes notes and it remembers and it applies. It just takes time and training, but the burden of correctness is and has always been, the developer who signs off on the PR. So whether a junior wrote the module, or AI, atleast AI's code is well documented... I work for a software company and I know for a fact that the modules I've written, none of them know how it works. I sign off on it, if it breaks, I'm the one held accountable and I'm the one who fixes it. That's how it's always been whether written by AI or not. If it's not a single page baby app with sub 10k LOC, you cant presume anyone knows the codebase back to front.
and thanks for speaking up in the Madsen's article, i'm also just so tired of people pretending that having a scaffold generated for you is not better than writing everything themselves. they tie their identity to writing everything from scratch and lying to everyone that they barely touched AI in the era of AI.
it's also as if they believe using Intellij to write Java is better than someone using AI to generate their Java code as if there's no other people using VScode, setting up everything manually and looking at Intellij users as inferior... the chain goes on.
Someone in 1995 might look at modern developers and say:
Someone in 2005 might say:
Someone in 2015 might say:
tool evolves, gatekeeping's still there, too tired to ignore haha.
Anytime, just pissed me off that someone made something genuinely cool, actually understood their work, yet still got a "bleh, you used AI, you're fake" commentary. They deserve better than that
To me, as long as the developer(s) fully know and understand the code of whatever project they're using, I don't really mind. As a guy who likes coding on his own and sometimes uses AI to help here and there, I don't really get the massive hate for when a project might use AI here and there.
I remember seeing the news where the Mr. Linux man himself, Linus Torvalds, said that Linux isn't an anti-AI project; he said himself that it was "just a tool," and I agree. But soon after, I saw some guy complain about it on Reddit, cursing at Linux. It was at an anti-AI subreddit, but even the comments were against the OP. So I'm glad I wasn't the only one who found that reaction extreme...
I know that AI gets flack in other areas like music and art (and I agree that AI should stay away from those), but I didn't know it got hate in the programming world to this extent. I think we should save the energy to encourage people to work on any project they want, with or without AI, because as long as the code...
.... I don't see much of a problem. That's just my two cents, though. This was a good read :]
Haha, i like how you call him mr Mr. Linux man.
but yeah, Linus was initially skeptical from what i remember but later on, he just accepts it and takes advantage of it as well.
This is a great perspective. Evaluating code by its architecture, test coverage, and correctness rather than whether AI helped write it feels like the only sane path forward—how do you think developer communities can shift the culture away from 'tool-shaming' toward actual code review?
Great question. you can't shift everyone away from 'tool-shaming' and gatekeeping. it's been happening since the dawn of computers.
Part of me prefers to keep them going because i like seeing people being nostalgic about something they tie their identity to, that the world's already moved on from.
That’s a really interesting take! You’re so right that gatekeeping usually stems from people attaching their identity to a specific era or way of doing things.
I guess as long as the code itself holds up to scrutiny, letting people hold onto that nostalgia isn't the worst thing—even if tech keeps moving fast regardless.
I don't really care whether AI wrote the first draft. If the maintainer understands the code, fixes bugs, reviews PRs, and sticks around six months later, that's the project I'd rather contribute to.
Preach!!! an attractive project is the one where the maintainers refuse to give up on maintenance!
Spot-on take regarding AI slop vs. genuine AI-assisted engineering. How do you suggest open-source maintainers filter out low-effort, unreviewed PRs without making builders using AI feel unwelcomed?
Are you an agent by any chance?
Wait, what? 😂 No, I'm just a real person typing out a question. Did I sound that much like a bot?
No, but you commented twice, 2 separate comments concluding the same points, i just thought the account had some sort of comment automation 😭
Ah my bad! 😭 Honestly, I've been trying to engage more on DEV lately, so I've been reading a ton of articles and commenting everywhere. I completely forgot I had already read yours and left a comment, so I wrote another one thinking I hadn't yet. Sorry for the confusion!
I think the useful filter is whether the project has evidence outside the prompt trail. Can I run it, test it, inspect the failure cases, and see what the maintainer changed after the first generated version? Origin is a weak proxy. Maintenance receipts are much harder to fake.
Yeah, I probably should've emphasized that more.
"Maintenance receipts" are a much better filter than an origin story.
test, refactor, bug fixes, responding to issues and maintenance.
they're also real signals of quality, regardless of whether AI was involved and its the filter I was arguing for. thanks!
Really enjoyed reading this, Adam. It's pretty surreal seeing something I wrote spark an entire response article. 😅
What I especially appreciate is that you took the argument further instead of simply agreeing with it.
The hardest part of my argument is exactly what you point out: "Is this maintained engineering?" is a much better question than "Was AI used?", but it's also a much more expensive question to answer. Blanket rules are easy. Actually evaluating understanding, accountability and quality requires effort.
Interestingly, the discussion around my article has already got me thinking about whether we could make that easier. What if an AI-assisted project could include a simple standard that lets a maintainer use their own coding agent to quiz them on their repository? Not to prove that AI wasn't used, but to demonstrate that someone actually understands and takes responsibility for what was built.
Still just an idea, but it came directly out of conversations like this.
And I absolutely agree with the core point here: engineering should be judged by understanding, correctness, maintainability, testing and accountability, not by who physically typed the keystrokes.
Thanks for taking the time to write this.
Haha, no problem and thanks for reading as well! I normally write once a week and this article wasn't supposed to be my main one this week but when I was reading the article of yours, i couldn't ignore the guy who believes himself to be superior for not using AI going around dismissing technical arguments and everything else.
what a pain in the ass. heck, dude even said he only logged on just to delete his dev.to account haha.
The AI or no AI filter is the same mistake as filtering candidates by university or employer brand. Origin is cheap to check and nearly useless as a quality signal. Understanding is expensive to verify and almost everything. I built Opportunity Skill around this exact insight for professional matching. The impression system captures how someone works, what they insist on, what they reject, not where they came from or which tools they use. Semantic matching on substance rather than pedigree.
preach! i think i could also compare to a project being rejected because someone built a Java project using intellij which involves alot of automatic generation and the one that got approved is the one the was written using VSCode because they're so hardcore by setting up their build manually and writing everything without suggestion.
This reminded me of something Lena said — she was the main character in the final chapter of my previous series, and she's still one of the main protagonists in the current 36 Stratagems series:
"AI is a tool. Code is a tool. Test reports are a tool. Tools don't decide who wins. The people holding them do."
"It wasn't AI that lost. It was people who thought technology could beat politics."
And then she closed with:
"His AI ran on a GPU cluster. Mine ran on a laptop with a broken cooling fan and café Wi-Fi. Still running."
The whole chapter was about a bidding war where the competitor had a 97.2% coverage AI system and Lena's team had a spreadsheet and a fake quote. They won not because of better tools — but because they understood the game better.
Your article captures the same truth: the value isn't in which tool you used. It's in whether you know what you're doing with it. 👊
Some comments may only be visible to logged-in visitors. Sign in to view all comments.