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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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.
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. 👊
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!
Great perspective. The real issue has never been the tools developers use, but the quality, understanding, and responsibility behind the final product.
AI is just another layer of abstraction, like frameworks, libraries, and compilers were before. A developer who can explain the architecture, test the code, fix problems, and maintain the project is doing engineering — regardless of whether AI helped along the way.
The challenge for communities is learning how to identify low-effort work without attacking innovation. At platforms like codecan.net, where developers and creators share digital products and resources, the focus should always stay on quality, transparency, and real value rather than judging only by the tools used.
Agreed! Engineering is about accountability, architectural understanding, and solving real problems, regardless of what tools sit in your workflow. Thanks for sharing!
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!
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?
I think it starts by rewarding outcomes instead of workflows.
For a long time, we've implicitly rewarded effort because effort was strongly correlated with results. The more time you spent writing code, the more likely you were to produce something valuable.
AI weakens that correlation.
If someone builds a well-architected, maintainable, thoroughly tested system in a week with AI, and someone else builds an unmaintainable one in a month without AI, I don't think the second person deserves more credit simply because they typed more.
Developer communities can help by reviewing what actually matters: architecture, correctness, tradeoffs, testing, maintainability, performance, and whether the author genuinely understands the system they're shipping.
Ironically, I think AI raises the standard rather than lowers it. Since generating code is becoming inexpensive, writing code alone is no longer much of a differentiator. The value shifts toward engineering judgment, system design, and solving problems in thoughtful ways.
In other words, instead of asking, "Did you use AI?", we should be asking, "Why did you build it this way, and can you defend those decisions?" I think that's a much healthier direction for the industry.
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.
The reframe from "AI or no AI" to "can you explain the architecture, will you maintain it" is the right lens and it's the same lens that should've applied to copy-pasted Stack Overflow code a decade ago. Nobody built that filter then because the volume was manageable. Now the volume's exploded, so the community reached for the cheapest possible filter instead of the correct one.
The disclosure-over-ban approach DEV is moving toward seems like the only version of this that scales, honestly moderators can't deep-review every submission's architecture, but they can at least shift the burden of honesty onto the maintainer and let reproducibility/test coverage do the rest of the filtering.
Genuinely curious how you'd handle the gray zone though: someone who used AI heavily, discloses it, but genuinely can't explain why the architecture works the way it does just that it works. Is that still disqualifying on its own, or does working + tested + maintained earn it a pass regardless of how well the person can narrate the decisions?
I think that's exactly the gray area where this discussion gets interesting.
Personally, I don't think the ability to narrate every implementation detail should be the standard. Very few of us could explain every line of code in the frameworks, libraries, or even our own older projects.
The question I'd ask is: Can you successfully own the system?
If a critical bug appears at 2 AM, can you diagnose it? If the requirements change, can you adapt the architecture without breaking everything? Can you tell when AI has produced a bad solution? Can you maintain and evolve the software over time?
Those are all demonstrations of understanding, even if you can't explain every implementation detail line by line.
Conversely, someone can give a beautiful architectural explanation and still be unable to keep the system alive in production.
So I don't think "working + tested + maintained" automatically earns a pass, nor do I think a perfect explanation is required. I'd look at the broader picture: can the person consistently take ownership of the software? To me, ownership is demonstrated through judgment, maintenance, and responsibility over time and not just by how the code was originally produced or how eloquently they can describe it.
The 'did they use AI' question is the keyword search of code review. It compresses a complex reality into a binary filter and then wonders why the signal is gone. Project A and Project B both get tagged 'AI-generated' and treated identically, which is exactly what happens when a platform search for 'Rust developer' returns the same results for someone who led a consensus engine implementation and someone who followed a tutorial. The matching has no dimension for understanding. This is the core argument behind matching-type profiles versus display-type profiles in Opportunity Skill. A display-type profile answers 'what tools do you use' and 'what have you built'. A matching-type profile answers 'how do you work', 'what do you insist on', 'what kind of maintenance commitment do you make', and 'what do you explicitly not do'. Those are the questions your article argues we should be asking. The impressions that an agent distils from daily collaboration capture exactly this layer. Not the origin of the code, but the understanding behind it. Not the tool, but the engineer's relationship to the tool.
I think this is exactly the problem with reducing engineering ability into a single label.
"Used AI" is a very low-resolution signal. It tells us something about the tool involved, but almost nothing about the engineer's relationship with that tool.
Two people can use the same model and produce completely different outcomes. One person may use it as a shortcut to avoid understanding, while another uses it as a force multiplier while still making the architectural decisions, evaluating tradeoffs, and taking responsibility for the result.
This is why I think the conversation needs to move from "what tools did you use?" toward "how do you work?" Tools change constantly. The ability to reason about systems, make good decisions, maintain software, and understand consequences is what remains valuable.
It's similar to how we already evaluate developers today. Knowing someone used Rust, Go, Kubernetes, or a specific framework tells you very little by itself. The more important questions are what problems they solved, why they made certain decisions, and whether they can own the system after it ships.
The origin of the code is one piece of information, but it should not replace the much harder and more meaningful question: does this person understand and take responsibility for what they built?