{"slug": "understanding-over-origin", "title": "Understanding Over Origin", "summary": "A developer argues that developer communities are asking the wrong question by filtering projects based on whether AI was used, rather than evaluating technical merit. The post contrasts two hypothetical projects—one involving years of careful engineering with AI assistance, another a low-effort AI prompt—and notes both get rejected under current gatekeeping practices. The developer warns that rejecting all AI-assisted work fails to distinguish maintained engineering from generated slop.", "body_md": "Many of developers communities are asking the wrong question.\n\nNot 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.\n\nImagine 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.\n\nExcept that's not actually what they're protecting against. They're protecting against *a label*.\n\nI read read [@madsendev](https://dev.to/madsendev) 's article regarding [Open Vectorizer](https://dev.to/madsendev/i-built-something-good-with-ai-now-some-developer-communities-dont-want-to-see-it-20mo) and Madsen wants to share the project with other people and in hope that someone would like to contribute as well.\n\nApparently, difference between \"AI-generated\" and \"maintained engineering\" has become invisible to gatekeepers who've simplified the filter down to a single binary question.\n\nthe wrong question.\n\n\" AI or no AI \"? ( they didn't literally ask this but that's the filter in practice )\n\nHere's why: imagine two projects.\n\n**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.\n\n**Project B:** Someone types \"make me a music streaming app\" into an AI prompt, publishes whatever emerges without testing it, and disappears.\n\nBoth used AI. Both are labeled \"AI-generated.\" One belongs in a developer community. The other is exactly what communities should be filtering out.\n\nGuess which one gets rejected? yah, both get rejected. The luckiest you can get is being rejected later because the gatekeeper was busying 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.\n\nThe gatekeeping argument seems reasonable at first glance. But it has real problems:\n\n**The dismissal:** *\"no you didn't* (via [@deammer](https://dev.to/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.\n\n**The broader concern:** Blake Beck 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.\n\n**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.\n\n**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.\n\nDeveloper 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.\n\nThe solution, though? It's not \"ban the AI ones.\"\n\nIt's understanding what actually separates signal from noise:\n\nThese questions work equally well for human-written code. And they're *expensive to verify*, they require actual reading, thinking, and judgment.\n\n\"Was AI used?\" is cheap. One checkbox. Feels principled. Lets moderators move on.\n\n\"Is this maintained engineering?\" requires actually engaging with the work.\n\nIn the comment thread, [@unitbuilds](https://dev.to/unitbuilds) delivered the most sensible take on all of this:\n\n\"Software development is an orchestration process where the ultimate value is the working, audited, and tested software—not just human typing time.\"\n\nAnd then:\n\n\"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.\"\n\nhits 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.\n\nThe 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.\n\nWhat none of them deserve is dismissal based on a label that tells you nothing about the quality of the work.\n\nThis is something that might seem beside the point but isn't: software development has *always* worked this way.\n\nWe 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.\n\nEach step increased abstraction. Each step generated concern that developers were getting lazy, that standards were dropping, that the craft was being diluted.\n\nEach 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?\"*\n\nThat's been the real standard all along.\n\nAI 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.\n\nThe question isn't whether AI should be accepted.\n\nIn 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.\n\nno, it's not \"open the floodgates.\" it's about what you're really filtering\n\n**Good moderation would:**\n\n**Bad moderation does what's happening now:**\n\nDEV'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.\n\n[@unitbuilds](https://dev.to/unitbuilds) had it right: a developer community's job is to share work and get substantive feedback, not police the method.\n\nThe questions that separate good engineering from slop are straightforward:\n\nThey 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.\n\n**Engineering should be evaluated on understanding, correctness, maintainability, testing, and accountability. Not keystrokes.**", "url": "https://wpnews.pro/news/understanding-over-origin", "canonical_source": "https://dev.to/adamthedeveloper/understanding-over-origin-4685", "published_at": "2026-07-28 09:36:21+00:00", "updated_at": "2026-07-28 10:02:39.358199+00:00", "lang": "en", "topics": ["ai-ethics", "developer-tools"], "entities": ["Madsen", "Blake Beck", "Open Vectorizer"], "alternates": {"html": "https://wpnews.pro/news/understanding-over-origin", "markdown": "https://wpnews.pro/news/understanding-over-origin.md", "text": "https://wpnews.pro/news/understanding-over-origin.txt", "jsonld": "https://wpnews.pro/news/understanding-over-origin.jsonld"}}