Posted by dcreager 1 day ago
> If you do not understand the ticket, if you do not understand the solution, or if you do not understand the feedback on your PR, then your use of LLM is hurting Django as a whole.
> Django contributors want to help others, they want to cultivate community, and they want to help you become a regular contributor. Before LLMs, this was easier to sense because you were limited to communicating what you understood. With LLMs, it’s much easier to communicate a sense of understanding to the reviewer, but the reviewer doesn’t know if you actually understood it.
> In this way, an LLM is a facade of yourself. It helps you project understanding, contemplation, and growth, but it removes the transparency and vulnerability of being a human.
> For a reviewer, it’s demoralizing to communicate with a facade of a human.
> This is because contributing to open source, especially Django, is a communal endeavor. Removing your humanity from that experience makes that endeavor more difficult. If you use an LLM to contribute to Django, it needs to be as a complementary tool, not as your vehicle.
I am going to try to make these points to my team, because I am seeing a huge influx of AI-generated PRs where the submitter interacts with CodeRabbit etc. by having Claude/Codex respond to feedback on their behalf.
There is little doubt that if we as an industry fail to establish and defend a healthy culture for this sort of thing, it's going to lead to a whole lot of rot and demoralization.
I don’t think anybody’s tracking the actual net-effects of any of this crap on productivity, just the “vibes” they get in the moment, using it. “I got my part of this particular thing done so fast!”
I believe that to be the case, in part, because not a lot of organizations are usefully tracking overall productivity to begin with. Too hard, too expensive. They might “track” it, but so poorly it’s basically meaningless. I don’t think they’ve turned that around on a dime just to see if the c-suite’s latest fad is good or bad (they never want a real answer to that kind of question anyway)
In the pre-AI era it was much easier to identify people in the workplace who weren't paying attention to their work. To write something about a project you had to at minimum invest some time into understanding it, then think about it, then write something on the ticket, e-mail, or codebase.
AI made it easy to bypass all of that and produce words or code that look plausible enough. Copy and paste into ChatGPT, copy and past the blob of text back out, click send, and now it's somebody else's problem to decipher it.
It gets really bad when the next person starts copying it into their ChatGPT so they can copy and past a response back.
There are entire groups of people just sending LLM slop back and forth and hoping that the project can be moved to someone else before the consequences catch up.
I treat jira like product owners treat the code. Which is infinitely humorous to me.
If something's not happening, something else's making it impractical. Saying this as a 10+ years product manager and R&D person with 20+ more years of engineering on top.
I also had to deal with "managers are just complicating things" or "users are stupid and don't understand anything"; do you think I complained? No, I had engineers barter trust of their ingenuity with trust of my wisdom, and brought them to customer calls and presented them to users almost like royalty, which made them incredibly respectful as soon as they saw what kind of crap users had to deal with.
Thats an unreasonable asymmetric effort demand, "Your code does not matter but my precious tickets must have elbow grease put into them."
No, your behavior is the cause of that.
The entire industry isn't broken. There are good company cultures and bad company cultures just like always.
At least own up to what you're doing. Don't blame "the industry" when you're the one doing the thing.
The industry is broken. It's broken in the same sense the railroad industry is broken. It has reached the point of abundance, where we're doing things that don't need doing. That won't get done in an efficient market. But since we're not in an efficient market, there are globs of capital thrown at people building stuff that.. doesn't stand a chance of actually making any return on capital.
But while it lasts, us, the glorified machine-minders (just like railroad engineers, well, minded the engines), get paid large lumps of money, through large hordes of managers, arguing on minutia of conversion optimization, and fundamentally, being paid enough to not to try and do something else, perhaps competitive.
And that is broken. Especially for the "smarter of us" - the graduation ceremony of my physics department rings true - we've trained you to discover the secrets of universe and reach the stars, and most of us will use it.. to gain an edge at Lehman Brothers.
(And I think the root of this problem, is the abundance of low-risk capital, from people who expect a small return and a pension that lasts for decades in retirement)
Petty and getting nowhere. Everyone loses. How about product and engineers also disrespect sales, and sales disrespects customers and everyone else.
I really don't get why this is even a question. Good people do good stuff, and bad people make bad companies.
Its laughably simple to do. I havent touched the jira UI in months.
Just like "etiquette" accomplishes no purpose except letting people easily figure out who put the effort into learning it, vs. who didn't.
Back then this distinguished by class, but ironically, today where's so easy to learn, it finally distinguishes by merit.
The LLM is genuinely better at certain things: interpreting messy input, generating novel responses, reasoning about edge cases. It's not better at "if account is locked, deny access." Burning tokens on that kind of decision is exactly the same category of mistake as using an LLM to write your Django queries.
The hard part is that agent frameworks don't enforce the separation. Nothing stops you from putting decision logic in a prompt because that's the path of least resistance. But you end up with systems where you can't explain why a decision was made, you can't test it without running inference, and you end burning tokens/money that didn't need to be burned to get subpar results you could have gotten deterministicly for free.
Are people generally unhappy with the outcomes of this? As anecdotally, it does seem to pass review later on. Code is getting through this way.
Enshittification Enterprise Edition.
They want AI to write all code but also still be able to fire humans for failure, because an AI can't be blamed right now.
Boy I can't wait for this employment norm. Fired because you weren't allowed to take the time to review important code but "You are responsible"
I wish Executives were required to be that "responsible"
They spelled out exactly their assumptions, the gaps in their knowledge, what they have struggled with during implementation, behavior they observed but don't fully understand, etc.
Their default position was that their contribution was not worth considering unless they can sell it to the reviewer, by not assuming their change deserves to get merged because of their seniority or authority, but by making the other person understand how any why it works. Especially so if the reviewer was their junior.
When describing the architecture, they made an effort to communicate it so clearly that it became trivial for others to spot flaws, and attack their ideas. They not only provided you with ammunition to shoot down their ideas, they handed you a loaded gun, safety off, and showed you exactly where to point it.
If I see that level of humility and self-introspection in a PR, I'm not worried, regardless of whether or not an LLM was involved.
But then there's people that created PRs with changes where the stack didn't even boot / compile, because of trivial errors. They already did that before, and now they've got LLMs. Those are the contributions I'm very worried about.
So unlike people in other threads here, I don't agree at all with "If the code works, does it matter how it was produced and presented?". For me, the meta / out-of-band information about a contribution is a massive signal, today more than ever.
Will humans take this to heart and actually do the right thing? Sadly, probably not.
One of the main issues is that pointing to your GitHub contributions and activity is now part of the hiring process. So people will continue to try to game the system by using LLMs to automate that whole process.
"I have contributed to X, Y, and Z projects" - when they actually have little to no understanding of those projects or exactly how their PR works. It was (somehow) accepted and that's that.
They hint at Django being a different level of quality compared to other software, wanting to cultivate community, and go slowly.
It doesn't explain why LLM usage reduces quality or they can't have a strong community with LLM contributions.
The problem is that good developers using LLM is not a problem. They review the code, they implement best practices, they understand the problems and solutions. The problem is bad developers contributing - just as it always has been. The problem is that LLMs enable bad developers to contribute more - thus an influx of crap contributions.
> Use an LLM to develop your comprehension.
I really like that, because it gets past the simpler version that we usually see, "You need to understand your PR." It's basically saying you need to understand the PR you're making, and the context of that PR within the wider project.
This ain't an AI problem, it's a people problem that's getting amplified by AI.
If I were hiring at this moment, I'd look at the ratio of accepted to rejected PRs from any potential candidate. As an open source maintainer, I look at the GitHub account that's opening a PR. If they've made a long string of identical PRs across a wide swath of unrelated repos, and most of those are being rejected, that's a strong indicator of slop.
Hopefully there will be a swing back towards quality contributions being the real signal, not just volume of contributions.
Don’t blame the people, blame the system.
Identifying the problem is just the first step. Building consensus and finding pragmatic solutions is hard. In my opinion, a lot of technical people struggle with the second sentence. So much of the ethos in our community is “I see a problem, and I can fix it on my own by building [X].” I think people are starting to realize this doesn’t scale. (Applying the scaling metaphor to people problems might itself be a blindspot.)
And I’m 100% sure there are dozens of startups working on that exact problem right this second.
Some projects ( https://news.ycombinator.com/item?id=46730504 ) are setting a norm to disclose AI usage. Another project simply decided to pause contributions from external parties ( https://news.ycombinator.com/item?id=46642012 ). Instead of accepting driveby pull requests, contributors have to show a proof of work by working with one of the other collaborators.
Another project has started to decline to let users directly open issues ( https://news.ycombinator.com/item?id=46460319 ).
There's definitely an aspect here where the commons or good will effort of collaborators is being infringed upon by external parties who are unintentionally attacking their time and attention with low quality submissions that are now cheaper than ever to generate. It may be necessary to move to a more private community model of collaboration ( https://gnusha.org/pi/bitcoindev/CABaSBax-meEsC2013zKYJnC3ph... ).
edit: Also I applaud the debian project for their recent decision to defer and think harder about the nature of this problem. https://news.ycombinator.com/item?id=47324087
Instead of people buying the tokens themselves, they should just donate the money to the core contributors and let those people decide how to spend on tokens.
So people may be less likely to donate an extra amount beyond their "ai budget" to an OSS project for tokens. Large OSS projects are also likely to get free tokens from major providers anyway.
But I like the idea of crowdfunding specific features.
This is so important. Most humans like communicating with other humans. For many (note, I didn't say all) open source collaborators, this is part of the reward of collaborating on open source.
Making them communicate with a bot pretending to be a human instead removes the reward and makes it feel terrible, like the worst job nobody would want. If you spent any time at all actually trying to help the contributor underestand and develop their skills, you just feel like an idiot. It lowers the patience of everyone in the entire endeavor, ruining it for everyone.
As for open source PRs, I wonder if for trust's sake you would need to self identify the use of AI in your response (All AI, some AI, no AI). And there would need to be some sort of AI detection algorithm flag your response as % AI. I wonder if this would force people to at least translate the LLM responses to their own words. It would for sure stop the issue of someone's WhatsApp 24/7 claw bot cranking out PR slop. Maybe this can lessen the reviewers burden. That being said, more thought is needed to distinguish helpful LLM use that enhances the objective vs unhelpful slop that places burden on the reviewer.
For instance I copy pasted the above to gemini and it produced an excellent condensing of my thoughts, "It is now 10x easier to generate a "plausible" paper or Pull Request (PR) than it is to verify its correctness."
Then again, we see how well robots.txt was honored in practice over the years. As with everything in late-stage capitalism, the humans who showed up with good intentions to legitimately help typically did the right things, and those who came to extract every last gram of value out of something for their own gain ignored the rules with few consequences.
I watched someone ask Claude to replace all occurrences of a string instead of using a deterministic operation like “Find and Replace” available in the very same VSCode window they prompted Claude from.
Although I'm afraid big part of these LLM contributions may be people trying to build their portfolio. Some known project contributor sounds better than having some LLM generated code under your name.
> If you do not understand the ticket, if you do not understand the solution, or if you do not understand the feedback on your PR, then your use of LLM is hurting Django as a whole.
Hey I thought you were a proponent of "no one needs to look at the code" ? dark factory, etc etc.
The linked article makes a very good argument for why pasting the output of your LLM into a Django PR isn't valuable.
The simplest version: if that's all you are doing, why should the maintainers spend time considering your contribution as opposed to prompting the models themselves?
You'd have to manage the contributions, or get your AI bots to manage them or something, but it would be great to have honeypots like this to attract all the low effort LLM slop.
Well let them put their money where their mouth is. Let's see what happens, see what the agents create or fail to create. See if we end up with a new OS, kernel all the way up to desktop environment.
In this case, offloading yet more work onto the maintainers of the package, because you can't be bothered, but still want credit.
I've used an LLM to create patches for multiple projects. I would not have created said work without LLMs. I also reviewed the work afterward and provided tests to verify it.
[…]
> If you use an LLM to contribute to Django, it needs to be as a complementary tool, not as your vehicle.