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 (57)
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
You're overlooking two aspects:
Two separate arguments here.
On the first point, I agree that many people still think of "building" as personally writing the application code on top of existing abstractions. Others draw the line much lower and argue that if you didn't write your own compiler, runtime, garbage collector, operating system, or even hardware drivers, you didn't really build it. People place that line in different places, and there's nothing inherently wrong with that.
What I don't think follows is that wherever someone chooses to draw the line automatically becomes the definition of ownership or authorship.
Someone can manually type every line from an existing repository and we wouldn't say they built it. On the other hand, someone can use scaffolding tools, code generators, or even AI while making the architectural decisions, reviewing the implementation, fixing bugs, understanding every tradeoff, and taking responsibility for the final system.
To me, the defining factor has never been who produced the text, but who contributed the engineering judgment.
I actually think this is related to another point I wrote about here: dev.to/adamthedeveloper/the-illusi...
My argument there is that software is never created from a true clean slate. Every system inherits knowledge, constraints, patterns, and lessons from what came before. If that's true, then authorship has never been about having a "pure origin." It's about what you contribute on top of everything you've inherited.
I also don't think AI itself needs to be capable of creating genuinely new ideas for humans to create something genuinely new with it. AI may be recombining existing knowledge, but the human is still defining the problem, introducing constraints, rejecting bad solutions, recognizing good ones, and ultimately deciding what gets built. Novelty can emerge from that process even if the tool itself isn't independently creative.
On your second point, I think there are legitimate discussions to be had about consent, compensation, and how AI models are trained. But saying everything built with AI carries "theft in its DNA" assumes that learning from existing works is equivalent to copying them. That's a much bigger claim, and I don't think it's as clear-cut as that.
No, because there is no learning involved. Training AI on someone else's content, be that code, or anything else, without their consent is 100% blatant theft. Anything built by those models is really just obfuscated plagiarism.
I think you're conflating two separate questions:
I'm sympathetic to concerns around consent, compensation, and how training data is sourced. Those are legitimate discussions. But even if we conclude that certain training practices were wrong, it does not automatically follow that everything produced by the model is itself plagiarism.
A tool's origin and the ownership of the thing created with that tool are not always the same question. If a carpenter's tools were obtained improperly, that does not mean every table they build is stolen property. The problem is with how the tool was acquired, not automatically with every future output.
More directly, plagiarism is about presenting someone else's work as your own. If a model generates a suggestion and I evaluate it, modify it, integrate it, test it, debug it, and take responsibility for the software I ship, that is a different situation from copying someone else's work and claiming it as my own.
Yes, AI models are trained on large amounts of existing data, much of which has creators, licenses, and ownership considerations. That deserves discussion. But the relationship between training data and generated output is not automatically equivalent to copying. Influence, learning patterns, and direct reproduction are different things.
Where I would agree with you is that someone who blindly generates code, fails to review it, and ships duplicated work without understanding it is a real problem. But that is ultimately a problem of engineering responsibility and judgment, not proof that every AI-assisted output is inherently plagiarism.
But is this the right analogy though? What if the carpenter stole the wood and turned that into a table?
I think the important question here is whether the AI is the stolen hammer or the stolen wood, and I think it is a weird mix of both. It's true that AI is used as a tool in creating "new" code, but at the same time, all of its output are the result of its inputs, which in my view makes the stolen input part of the output, hence my statement that it carries theft in its DNA, not necessarily that it is itself wholly plagiarized.
Is it though? AI isn't capable of authorship; all of the things you list are, again, the the result of partially stolen training data. The code is a permutation of stolen code, the tests are a permutation of stolen tests, the evaluations are permutations of stolen prose, etc.
I like to think about it backwards: If you removed all the stolen code from the process, what would that change? Let's be honest here: If you re-trained all the big models without stealing training data, you wouldn't end up with the models that exist and people wouldn't be able to use them as they do.
This makes it obvious that the theft is an essential part of the process and AI-assisted work relies on it. That's the part that, imho, makes it undeniable that anything built by AI is, inherently built on a base of stolen content.
Ignoring this and focusing only on the technical reasons why people might dismiss AI-generated code is short-sighted. Yes, there are technical reasons too why someone might look at something built with AI and dismiss it without closer inspection; human brains love heuristic decision-making, for better or for worse.
But it's also a very legitimate position to see something built with AI and say "I don't support content theft so I don't care about this." That's a part of the puzzle that needs to be considered.
Mmm, I like how you framed it with the "stolen wood" vs. "stolen hammer" analogy. does a good job of highlighting where our perspectives diverge.
Now. Where I part ways is in how AI models actually process and represent information. They don't store raw snippets of code to slice up and paste into future projects. Instead, they learn abstract patterns, syntax, and statistical relationships between concepts.
In practice, that's pretty much similar to how humans learn. We read thousands of public repositories, documentation, books, and examples until we internalize how software is built. If learning from publicly available work, without reproducing it verbatim, is considered "incorporating stolen wood," then we'd have to apply that same standard to human learning as well.
I also think there's an implicit assumption that authorship is tied not only to manually implementing the code, but also to the learning that comes from doing so. I absolutely agree that writing software by hand is one of the best ways to deepen your understanding of a system, I still do a lot of it myself. Where I disagree is with treating that process as the thing that determines authorship or engineering ownership. Those have always been about intent, problem-solving, architectural decisions, and ultimately taking responsibility for how the system behaves.
That said, I completely respect your conclusion. If someone chooses to avoid AI-assisted projects on principle because of concerns about how training data is sourced, that's a perfectly reasonable ethical position to take. My issue isn't with people having ethical reservations, it's with using "Was AI involved?" as a proxy for technical quality.
I think another useful analogy to showcase how I disagree here is sampling in music. You can write a song and use samples of someone else's song.
This makes you the author of the new song while still using stolen content from another author.
I think it's the same here: You can have overall authorship over a project while parts of it are based on stolen content. You can claim authorship over the big picture engineering decisions, without being the author of the lower-level implementation.
It can be true at the same time that one person is the author of a project as a whole and that the project is based on plagiarism. Much like how the carpenter still made the table and can claim authorship over its design, the woodwork, etc.
Yea, that's fair. I think it's okay to use "was AI involved" as a heuristic though; it doesn't prove that something is bad or low-quality, but it's one indicator someone might use to conclude that it's not worth making sure.
For example I usually don't click on youtube videos with obvious AI thumbnails. Not because I know they're going to be bad, but because the odds of it being slop and how I value my time simply put those videos below the threshold where I want to give them a chance.
Of course that doesn't mean it's okay to turn that into an assertion that something is actually slop. I think that's a fair place to draw the line.
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.
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.
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!
I'm the case you're arguing about, and I'd complicate your test a little.
I'm not a developer. AI writes nearly all of the code for the internal tools I build, which a hospital now runs on. So "judge by understanding, not origin" is a standard I'd fail almost as badly as the origin test. There are parts of my systems I could not explain to you line by line, and claiming otherwise would be the actual dishonesty here.
What I can do is the maintenance-receipts version a couple of people landed on upthread, so let me make it concrete — I think it's stronger than understanding, and unlike understanding it's testable by a stranger who doesn't trust me.
I can show you a planted defect and the check catching it. I can show you a guard broken on purpose, the exact red line it produced, and the same guard restored and green again. I can show you what my deploy tool claimed and what the URLs actually returned twenty seconds later. None of that asks you to believe anything about my mental state.
Understanding is one way to earn trust, and it's the one most people in this thread already have. Demonstrable behavior under deliberate failure is another, and it's the only one available to me. It's also harder to fake, which is not something I can say about a confident explanation.
I don't think it's an alternative to understanding so much as another form of evidence. If I watched you intentionally break guards, inject faults, catch regressions, fix them, and repeatedly ship reliable software, I'd have a hard time arguing you didn't build something valuable.
Where I'd still be cautious is treating observable behavior as a complete substitute for understanding. Passing tests, successful deployments, and maintenance receipts tell me the system behaves correctly. They don't necessarily tell me whether someone could adapt it when requirements fundamentally change, debug an entirely new class of failure, or reason about architectural tradeoffs.
That said, I think your point is important because it shifts the discussion from "trust me, I understand it" to "here's evidence that I can operate and evolve this system successfully." That's a much more objective standard than asking whether AI wrote 10% or 90% of the code.
Ultimately, I think engineering is about earning trust. Understanding, good architecture, reliable maintenance, fault injection, testing, and operational track records are all different ways of earning it.
Your caution is right, and I'd rather be specific about where I fail it than argue the edges.
Fault injection proves a guard catches what I thought to plant. That's the whole limit in one sentence: my evidence covers failure modes I've already conceived of and says nothing about a class I haven't. That's exactly where understanding pays, and I don't have a substitute for it.
Of your three, I'd only claim one honestly.
Architectural tradeoffs — I had a real one this week. Someone pointed out that my scoring double-charges overlapping rules, and that the error can only land on projects that already have defects, so it skews the bottom of the distribution. Sound argument. I built the measurement instead of the fix, the data didn't support it, and I shipped nothing. But I could only evaluate that because it reduced to a prediction I could test. Tradeoffs that don't reduce that way, I probably get wrong and wouldn't know.
Adapting to fundamentally changed requirements: untested. No evidence, and I won't pretend otherwise.
New classes of failure is the interesting one, because I've hit three this month and found none of them by reasoning. I found them because a stranger handed me the concept and I went looking with it. Which points at something narrower than "receipts": the ones that count aren't the receipts I generate, they're the ones where somebody else chose what to break. Eight real defects in my systems came out of comment threads on this site, and not one of them was a category I'd have thought to plant.
So — evidence, yes. And the strongest kind is the kind I didn't design.
Agreed .... and I'd push it one step further. This is the era of builders, and precisely because generation is cheap, the expensive part is now the stuff we used to only debate at conferences: architecture, quality attributes, trade-off analysis, testability. Those were "academic" concerns for years. Now they're the only differentiator left between Project A and Project B, because the typing isn't one anymore.
Ironically, the most academic era of software engineering is the one where nobody has to type.
And of course, with code generation becoming inexpensive, we've raised the bar for what counts as impressive engineering. It's no longer enough to just produce code. Increasingly, the differentiator is the architecture, the tradeoffs, and the genuinely clever ideas behind the system. What was considered awesome in 2019 is often just "mid" in 2026 because the baseline has moved.
This resonates deeply. The origin policing in AI-assisted work is something I've been thinking about a lot — especially as someone who's been building with AI tools daily and shipping open-source projects. What matters is whether the system works, is maintainable, and you understand why. Not which percentage of keystrokes came from which source. Curious: have you had pushback on this from teams or communities that are more skeptical of AI-assisted work? How did you handle it?
Thanks! and yah, the key to handling pushback is demonstrating total ownership. When people see you’ve vetted the code, written strong tests, and can defend every design decision, the skepticism usually shifts from "you used AI" to judging the project on its actual technical merit.
I apologize for my earlier comments, I shouldn't have generalized every AI project.
I do believe that while my concerns are valid, not every AI assisted project is vulnerable slop as it does depend on if it was properly vetted by someone who understands the code.
this post has kinda helped me understand everyones point of view
@unitbuilds @madsendev
I appreciate the follow up, Blake.
And yes, the tool isn't the problem. it's whether there's a maintenance receipt and a human who actually knows hidden edges of the code.
True, but my point being, AI is not to blame, that's always been the case, if you cut competence, you lose understanding, which produces garbage. Whether that's hiring a junior to do it for you, or using AI. That's why software companies ran through employees before AI, because it takes a while to get someone who actually doesnt produce slop. Now it's the same, just a single extra layer of abstraction.
No stress, me going at you wasnt directed at what you had to say, it was that you directed it, without vetting it. I imagine you didnt pull his repo and have a thorough look through? Which means you were judging a book by it's cover, disregarding it's content as slop, without ever reading a single line of it. As a community, we're facing an existential crisis right now with AI, do we accept it, do we shun it and there's no right answer... But standards and principles are what keep code clean and a community healthy. Being kind, while critiquing is what keeps people posting and growing, regardless of if they have 3h to write a thoughtful piece, or just run their repo through an AI to write a post about it. Feedback and healthy critique leads to growth and further understanding. I'll be honest, 99% of the time, you'd have been right, AI slop, but you shouldnt just assume. Read their documentation, run their repo, see whether it actually works, before judging.
Take a case from a few months ago, I saw a post where a guy made a portfolio page, to showcase how he wired up a LORA trained voiceover ai to narrate the page and answer questions. He clearly used AI for everything, but I went to his page, tried it out, had a chat with his AI and gave him insight into a ton of things that were buggy, broken, poor practice, or outright liability risks. They responded with a post thanking me and asking me to re-evaluate their updated site, while also answering my questions. I did and they re-iterated again. They built some pretty cool tech, but all you'd see at first glance is an AI voice-over with scripted transitions and dialog. But underneath the hood, they custom trained it and built the harness themselves. That's the engineering aspect you dont see behind AI generated projects and it's why it's wiser to question, than to judge.
Sorry for preaching, I hope it makes sense and doesnt come off harshly, I'm not angry, or upset, just trying to steer you into the direction of positive feedback, so we can keep the community clean and healthy. Developers are a dying breed and we need to stick together now more than ever.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.