Part of this is an alignment problem, but on the human side: the bottleneck is no longer writing code but staying aligned with it, knowing what it does and whether it does what you meant. In my own work, that’s now most of the job, even for code I asked for. For maintainers reviewing large PRs from strangers, it's certainly much worse. A ban is bit harsh, but I understand why they’re rationing their attention.
Knowing what your software does is such a hard problem. Most developers have an idea but if you ask, how are you sure?, the answers reveal how little they know.
Most often we’re satisfied with signals and indicators that it works and we build theories and mental models that use to try to avoid the effort of proving anything.
Worse is what happens when you start using LLM models to generate the code for you. I find you start losing the mental model short-cuts; you start to trick yourself into understanding the code. You understand little.
And what few studies there are of code review suggest that we have very little impact on code quality after reading more than a couple hundred lines of code over an hour.
So the current mental leap is, “the AI is a better programmer than I am.”
I think it’s still worth becoming a better programmer regardless. And there’s no royal road. You just have to write code and struggle with writing bad code.
I fully agree with you. But I feel like I have taken the opposite approach. Staying aligned with the code is such a burden that I don't think AI is making my job easier so I stopped using it.
That's why I'm now considering what are the ratio for each language in term of exposing the business logic nub that human can grab (mostly) correctly vs all the clutter that is here mainly to bring additional type safety and please the compiler in some way.
One approach that Ruby took for type introduction was to put that in a different file. That comes to my mind.
Typescript brings some niceties, but also some boilerplate all other the place. Combined with something like Effect, Zod, and the like and line count explode. Not sure OCAML or Haskell would provide more compactness for equivalent safety.
The bottleneck has never been the writing of the code. It's all the rest that takes the majority of the time. Of course, it is often the writing which lets you expand your understanding or your awareness of challenges and pitfalls, which then puts you back on the drawing board.
> but staying aligned with it, knowing what it does and whether it does what you meant
That’s the old “Programming as Theory Building” stated by Peter Naur. Writing code, once you learned a language and a few libraries has always been easy and can be made easier by using tooling. Having a good understanding of what has been written and what needs to be added is the difficult part.
I think for every line of code I’ve written, I spent 2 to 5 hours reading specs and docs. Creating software is always about understanding. If you’re thinking too much about syntax and libraries symbol, you’re just at the beginner phase of coding. Like thinking about grammar when learning a second language or being hyperaware of the car as a beginner driver.
I think this is the end of open-contributions, the maintainers already having too much on their plate.
Plus it is becoming exceedingly rare of finding a contributor that save time, as in can do better than the maintainer itself using LLM and reviewing it itself.
My experience lately is the best way to contribute to open source now is to just write detailed issues. The maintainer can then paste them in to an AI tool themselves and go back and forth faster than they could comment feedback to you and wait for changes.
That’s what I’ve been telling my PM: I don’t need your half-baked PR you one shotted from a prompt: put that prompt in GitHub Issues for the team to use later
> The maintainer can then paste them in to an AI tool themselves and go back and forth faster than they could comment feedback to you and wait for changes.
My experience is that maintainers cannot do this. Or rather, that it is useless.
if someone wants to contribute, they need to prove they produce value to the project. I dont think this is controversial at all.
The fact of being open source means if your contributions are rejected, you simply need to fork. The open market competition will soon determine if your contributions were truly valuable and whether the original project's owner misjudged, or that contribution was essentially worthless.
I agree with fellow commenter, now with LLM the forks will NOT been distinguished as much by their technical differences/features as their trustworthiness (which is already the case today, but tomorrow will be skewed even more). Massively increasing inertia and favouring initial/well-known work/founder/team.
> That's not entirely true: my work might get zero traction because nobody will know about it.
Being able to market your work and build community are key skills for open source contribution. The history of forges is littered with interesting code that never got enough attention to go anywhere.
It can still work. For example if you look at https://github.com/emdash-cms/emdash/issues they have a whole bunch of tooling that uses AI to automatically triage and come up with PRs automatically.
It's the end of open-contributions for one specific repository, that is all.
It only covers QGIS, the UI application, not GDAL/GEOS and the other libraries that give it its functionality.
Additionally, in the past few years the number and popularity of new open-source projects that do accept open contributions far exceeds the few old ones that do not.
Expanding on that, the issue is aggravating the maintainers bottleneck, because how do you find new maintainers if you do not accept outside contributions?
Another option would be to make a contributor pay for the review of its PR, even a small fee, to deter AI-slop, at least for new contributors. It could/would exclude students or people with the lowest wage though, but I'm optimistic even a 1$ bill or less would be enough.
I'm purely focusing on the effectiveness of the measure keeping the open-source ecosystem alive, not discussing much about fairness.
The current contributors are already massively skewed towards people with more ressources and time and 75% of the world, so I do not expect a sharp decrease in contributions.
It also creates wrong expectations. If I pay you (even if it is $1) then I expect you to take a look at my slop and argue with me how to make it better. Just closing it will prove that you're a scammer (and not even a successful one, because you'll get at most $5 altogether).
For an outright ban on "LLM, AI or agent assisted code contributions", they do very little to define what that means. This is a terribly written policy - I sincerely urge the QGIS maintainers to put enforceable guardrails on the definition.
This reminds me of the legal ambiguity behind the GPL and its definition of "derivative work". A careful analysis of the GPL shows that using GPL software doesn't trigger any other clauses. But distribution does. What is the legal definition of distribution? Who knows!?! That's why most software companies have an outright ban on GPL software. Even companies that are willing to comply with the GPL, they cannot feasibly come into compliance with such a vague definition. So it's better not to engage.
Same will happen with anti-AI policies. Even contributors who are fully willing to do things "by hand" will start avoiding these projects. No way to know if you'll accidentally run afoul of someone's AI radar. There's nothing to protect enforcement from becoming a witch hunt.
Some people blindly hate AI, what everyone actually wants to ban is fully automated coding, or at least “vibe coded” submissions, if you cannot support your change without an LLM you shouldnt be pushing it into a major project.
People can 100% still use LLMs without “vibe coding” in a meaningful capacity and understand the output, and still be drastically more productive.
My point is, if projects are actually serious about banning AI, write that down in enforceable language. As of today, your personal interpretation of what the policy might mean likely conflicts with other's interpretations. There's no clarity on what exactly has been banned.
Put simply, if you're so convinced that AI contributions will ruin your project, you owe the world a full and complete definition of what "AI contribution" means.
I don't feel like any further definition is required. You would surely know if you had used an LLM, AI or agent while creating the code. Keeping things broad allows for simpler enforcement, otherwise you end up in the weeds arguing if seeing the Google AI search summary counts as LLM influence.
Why is everybody all the time in favour of AI on HN? This is objectively a good change because it will improve the quality of the code in the long term.
> Why is everybody all the time in favour of AI on HN?
Many reasons:
1. The people on HN tend to think they're very clever, but they're often not as clever as they think they are. That has a lot of wide-ranging implications, from classic "engineer's disease" thinking to stuff a lot dumber.
2. I wouldn't be surprised at some unexpectedly large amount of AstroTurfing, especially considering the sheer amount money is flowing into the AI space. My understanding is HN has some influential people reading it, and is influential on a certain fraction of the wider group of software developers.
3. I think there's a certain amount of defensiveness from AI enthusiasts. They've enthusiastically adopted AI to a certain degree, so critique/skepticism of their choice is felt as a personal criticism.
4. HN is a pedantic place (see 1), so "everybody all the time in favour of AI" will be interpreted literally as false, when it really should be interpreted as "why is there so much pro-AI activity."
There's a few major flaws or logical fallacies or whatnot in your comment:
1. "everybody all the time in favor of AI" - this is not true (objectively)
2. "This is objectively a good change because it will improve the quality of the code in the long term." - this cannot be considered "objectively" a good change because quality is subjective. Second, it makes the assumption that human written code is always (objectively) better than LLM generated, which is also not true.
But this is a software engineering project - the code is only part of the whole project / product, and the (subjective) quality of the code is only part of that. LLMs could write perfect code by whatever quality metrics they use, but if a reviewer is overwhelmed by a morbillion other perfect code contributions from LLMs it's moot.
AI assistance doesn't necessarily imply lower code quality. It can help with improving it in a lot of ways. Full vibe-coding without careful review is what results in low quality code. I think a lot of projects are having trouble getting to the sweet spot, though: if they allow LLM-assisted contributions then no matter how much they write to try make sure the result is high quality they're going to be inundated with far more low-quality contributions and have to work harder to filter through and reject them than if they just have a blanket ban which then makes it a lot easier to reject everything. The linked discussion is specifically with a view that not all LLM assisted contributions are bad but that they need to stem the flow for now and figure out how to open up afterwards.
I haven't actually looked at any open source project PR queue, but what is the ratio between actual thought out LLM assisted PRs and vibe coded PRs that are spammed unread? My bet is 1:100.
Not to mention that the thought out LLM assisted PRs won't even register as LLM assisted PRs...
Will it? Plenty of open source projects have bugs unfixed for decades because it's too tedious to fix by hand and would take five minutes with AI these days. I've also found that good LLMs can be more diligent in updating comments, tests, etc.
> I'd like to open another topic about the usage of LLM for review, auditing and security purposes, but I think this is a very separate thread, and we'll open discussions at the user conference before any formal discussions.
Will it? With proper guidance llms produce much better code and find more bugs than I ever could. For example I have never been bothered to fix python typing for my project and left it hanging for years. But with llms and one prompt later I fixed it all at once.
That does not mean the product becomes more useful. I could rewrite Windows 1-to-1 with better code quality and no one would care because it still provides the exact same features. Unless "better code" means "better features", better code is useless.
This is extremely short-sighted. Software is not a static product. "Improve code quality" translates into being able to add features more quickly and with less risk of bugs. For an open-source project, this also gives readers the opportunity to understand the codebase and learn from it.
This was true when adding features cost a lot of time and mental effort.
Nowadays, it's just a prompt away. LLM's can still run around in circles when the code quality is bad enough, but LLM's are also getting exceedingly better at catching that and writing code that's good.
We're all in a different phase of the collective grieving process, some are still in denial, I would put you in the bargaining phase judging from the comment.
QGIS is actually one of the big portable/cross-platform hybrid Python/C++ apps, which makes it arguably more complex for an LLM to cope with properly than one or the other, and makes code quality a rather more entrenched/storied problem.
In this way it is very much a spiritual cousin of FreeCAD (also cross-platform Python/C++/Qt6), though that (at least currently) has a somewhat more liberal ("humans in the driver seat") policy.
I'm in favor of AI, but if I was a maintainer for an open source repo, I would also favor banning AI contributions. At least for the wild, maybe people who have built a reputation in the community could stay. I think AI can write quality code. What I doubt is if the average contribution will involve quality code or even human input.
For me, it is the way AI has kept suggestions to either open issues with maintainers or make PRs to fix an "issue" it found. I know it hasn't researched the issue in depth enough to be talking with the confidence it has, and I know I am in no position to be bothering someone else unless I want to spend considerable time investing to make sure the issue is exactly what the AI is claiming, it isn't a known issue, and it is justified to bother the maintainer with it. But there are far too many who will see that option and just tell the AI to do it.
It isn't that I'm against AI. It is that opening a PR or filing an issue use to have significant enough gatekeeping that most low effort low quality work simply wouldn't pass it, but that has now changed. So a new gate is needed to ensure those who aren't willing to put their own time into the work before asking for the time of others, and banning AI is one of the better options I've seen.
This also doesn't even end AI interacting with the project, just changes it. If you have some unique use case that AI finds, you can download it locally, have the AI make the change just for you, and have AI keep updating when necessary. Each user gets the customization they want while maintainers are protected from low effort low quality spam.
First, just check out the comments on any "I'm tired of reading slop" submission to refute your first point, the circle jerk is real.
Second, while I sympathize with not wanting to be inundated with low effort PRs, putting a ban on AI assisted contributions in response is myopic virtue signalling.
I think in this case it's not about signalling: in the linked discussion they are saying that the problem is the workload created by the AI-assisted creations, not the AI use in and of itself, and they are open to relaxing the restriction in future once they can figure out how to manage it.
(The issue is, I think, if you allow AI, no matter how many paragraphs you write about taking responsibility and ensuring high quality contributions, you're gonna get a lot of bad ones just because by sheer volume there's enough people who aren't gonna read it, and that's gonna take a disproportionate amount of effort to filter out).
For those who, like me, had no idea what QGIS was: It is a free Geographic Information System (GIS), which means that it deals with creating, managing, analyzing, storing, and visualizing geospatial information. Think of (3D) maps and stuff like that.
Ironically I lost my use case for QGIS since LLMs can readily write scripts for manipulating and converting point clouds (lidar data). I'm not a pro by any measure, mostly just making contour maps, but it massively streamlined things. To me it reveals the future of software
It's true that simple data conversion is now more easily performed using vibe coded scripts. But the real value of QGIS lies in it enabling managing data large complex projects (infrastructure, urban/environmental planning, etc.).
- Any (super)intelligence caches work. This is just how the physical world
works. You use the results of your previous work to do more work.
- Any (super)intelligence _wants to create stable abstractions_. Now this is a
claim, not a fact. but I'd say this it's pretty clear. I can cache all of the
work in the world, and maybe even re-use some of it, but that's different from
the synthesis of creating an _abstraction_.
- Abstractions are lossy. They can lose a posteroi, in that they don't match the
contract as specified. They can lose a priori - the specific set of problems
and solutions they claimed was their goal and role, are wrong for whatever
reason (discovered, the world and requirements changed, etc). Someone or
something needs to maintain it now.
What's at the end of the tunnel. Is it reasonable to say that a few labs will carve up ownership of all the open source projects of the world? Or will there be more community lead projects than ever? There are also some nastier routes, such as making things so coupled and "holistic" that you can't use anything else besides a few products.
The difficulty of forking and modifying an open-source project has been drastically lowered so I predict we'll see more projects than ever before. But many of them will essentially be duplicates of each other.
My expectation is that those AI primary forks will degenerate quickly. Maintaining OS requires a lot of judgement, direction, agents tend to turn softeare into big pile of disconnected features.
wouldn't it make more sense to tighten the rules and requirements for contribution? how would you even identify AI assistance if the result is immaculate? it seems to me that banning AI is conflating low-quality or low-effort with using AI. I understand those correlate statistically and also causally ... but latter only for specific lazy cohorts. if the AI assisted contribution is of high quality why would you ban it? especially given that you couldn't even identify it or would they still discard it because some comments exhibit Claudisms? tests, linting, more tests, style guide abidance, even more tests and banning contributors who fail to deliver.
If you can't tell that the contributor used AI, the PR is good - how would they know to forbid it? This rule hopefully stems the tide of low level fly-by contributions. As they said, it's also not set in stone, there will be enough time to change it later if needed.
I see this as a good thing, QGIS is already a bit of a mess to begin with (seriously, what mapping program starts you off without a base map? Even Google Earth gives you a starting globe to lay your info upon) and could really use the bandwidth to focus their attention on making things actually make sense rather than goofing off with AI-'assisted' coding where the 'programmer' doesn't even know how things work.
GIS work has very complex inner mechanics that are hard to reason about at a high level without very explicit abstractions to ease the costs and cognitive burden of manual review. Sometimes earlier, longer-lived FOSS projects may have grown organically without the benefit of retrospective appreciation because that path has not been trodden (at least out in the open) at the time.
I implemented css geometry properties for svg2 in resvg with claude. I know it works and I've read the relatively small diff. But I'm afraid to send a PR because it might offend a artisanal handcrafted free-range software enthusiast. I guess any other AI enjoyer who needs this feature, which is standard functionality in svg2, will just burn a few tokens and do it themselves to keep the luddites from smashing the factories.
The question I have is what is an AI assisted contribution? For example, I still write code by hand, but I make many prototypes using AI before committing to a specific implementation. My code is clearly AI "assisted", but all of my final code is written by hand (no autocomplete either).
From February to 09-24 the policy was "human in the loop". Any tool was fine as long as the contributor read the code and could answer questions about it.
Banning does not imply verification. The policy is just a warning. So now you know, if they suspect that a PR is AI-generated, then there may be further consequences. I don’t think someone is going to apply a stamp on each PR.
The most egregious examples are always lazy (big diff, lengthy descriptions, weird phrasing,…). Now there’s a section in the policy to point to for the quick rejection.
The discussion is not about ownership of the code, that doesn't interest the people who have written the policy in question.
"Assisted" does not necessarily mean "authored", which is the point of the comment you're replying to; helping you review the code is "assistance", even if no code was written.
If you didn't mention it, how would they know if your contribution was written by AI or not? What happens to contributors who sneak in their AI-assisted commits where it's not obvious?
> If we subsequently discover that you have used an AI, LLM, or any agent-based workflow for your
contribution, you will be subject to code reversion and contributor rights sanctioning.
Policies like this have an element of trust to them. That's not new: open source projects have needed to trust contributors not to paste in proprietary licensed code since open source began.
Of course, if you sneak in a simple patch that an AI agent wrote for you, nobody might notice. The fact is, maintainers of big OSS projects are increasingly dealing with patches in the 10kLOC range, all at once, coming from people with little to no previous engagement with the project: that's usually a dead giveaway.
Contributions that are valuable, are valuable. These "No AI Contributions" nonsense is like saying AI art is not art. It's just not valuable for you, has nothing to do with AI. The QCIS project simply doesn't want to go over each PR and see its value? Because AI-generated things are not valuable for them, has nothing to do with AI, PRs, contributions, etc.
To play the devil’s advocate - AI generated code is incompatible with human generated code. I think this is a tradeoff most projects should make, but I can imagine some projects wanting to work the old way. I would question their relevance in the future, but I can respect that.
There is no need for them to accept AI contributions from third parties. Whenever they want AI code, they can just ask for it themselves, ensuring the model has the correct context and specifications in the prompt.
the argument is not that AI PRs are inherently not valuable. but if you have to spend a lot of time triaging them because of slop AI PRs it is just draining and inefficient.
In fact, this change seems quite logical. AI is certainly a useful tool, but that doesn't mean it must be uded always and everythere. Edpecially when doing so could compromise the final quality of projects. Let's see where all this leads
the biggest problem I have with "the users" right now is trying to spot issues people are having that actually matter. So many bugs now are just someone with their LLM/fuzzer finding frivilous issues that affect nobody, but the folks doing this are beginning to deploy dark tactics to get their reported issues to look "legit". careful language choices and other github accounts coming in to "agree" they have this issue also. I'm starting to think of how to identify people using "dark" patterns like this and just ban them outright.
Good, QGIS is one of the projects that can be put closer to the bottom of the stack in that XKCD comic. I've seen QGIS being used just as a visualisation tool, and i mean it's good at it too, but even in a limited use case i am aware of it was used to do important infrastructure work like planning water pipelines and predicting failures for said pipelines.
For open source projects which are free of high growth expectations that come with VC funding this might be the right move.
AI coding comes with the tradeoff that you lose understanding of your own code. That is an acceptable tradeoff when getting it out to users matters more than understanding code. But free of capitalistic pressures, why would you accept AI slop?
I’ve been able to contribute to projects recently using ai. And another project banned this so I didn’t bother. The second was a bug fix for an issue I was having. The first was a new feature.
Either way my bug got fixed but if a project maintainer doesn’t want it who am I to fight it.
You can always fork it. I suspect my contributions are higher quality because I use different model providers to review each other but whatever.
QGIS is not your run of the mill project, though. This is specialized software and a rare breed. It's in their right to decide either way, and this is the right call for this niche, IMHO.
GIS is basically "serious mapping software", and when it's used for city planning or other large GIS-relevant activities, accuracy and precision are non-negotiable requirements.
IOW, your city might be using QGIS to plan the city and verify everything being done on it, down to cm level accuracy. So, any subtle bug is a big deal for these kinds of software packages.
While doing construction work (regardless of infrastructure or buildings), the plans are laid and verified to that level. The haphazard spray paints on the ground are indeed big deal, and has a digital copy in the GIS software.
It's not only used by municipalities and/or governments either. Research teams use GIS packages extensively as well. I briefly worked with a research team working at Antartica. These GIS software and related ecosystem is their both bread and butter and foundation to anything they do.
A patch generated by an AI model breaking these software packages have cascading and important effects. So, the software needs to stay dependable and reliable.
I think think its a good thing a lot of people are banning AI contributions. This will clearly differentiate and make space for the free market to pick the best winners.
And neither of us will get any traction, because the QGIS team has a history and proven track record within the GIS community, and neither of us are attempting to solve a problem that community has.
Oh no, don't want to hurt the tech billionaires' feelings.
The majority of LLM use is to make slop or answer simple questions that could have been searched. The mythical AI-Chad Coders are so rare that catching them in the anti-slop dragnet will not meaningfully decrease the quality of a big project.
I bet millions of moved to deno, the javascript runtime... and they are ending support next year... after running for a few years only. You seem to be not questioning them.
Second, majority of apps do not last 2 decades.. and that is okay... someone else can fork the repo and continue if needed.
I'm a non-native english, so I change the code myself, but I tend to participate in communities while using a translator.
If I use AI, I can fix bigger things, but most of what I contribute to open source is finding small bugs, so I don't use AI for open source contributions. (I mostly don't even have the ability to make big changes.)
Looking around open source like that a few times, I can understand the hatred toward AI to some degree: too many requests pour onto a single individual. Of course, that doesn't mean AI isn't helpful. In my view, AI writes code blocks better than I do, and it might even be better to use AI for some of the open source I've contributed to... but overall, I feel that some kind of system for filtering AI-based PRs is needed.
Lucky for AI companies that OSS projects are doing this, otherwise where will they get their carefully created training data from? They would be reduced to training off the slop their tools produce! /s
> QGIS is trusted by organisations because they know they can contribute back, they can hire contributors for support, training and feature. As a community project, this is something we really want to protect
We have gone from "LLM-slop is gonna ruin open source projects" to we wanna "protect" humans so they can make some dough on the side training and stuff. If human coders become the bottleneck in the chain, the solution is obvious and there's only so much protection anyone can do.
Looking at the scope of their code, the quality, the testing rigor etc. it's clear that they feel threatened by AI. Realistically a couple of prompts coupled with a factory of agents can replace this entire codebase in a matter of hours.
Furthermore, how will they prove whether code is AI generated or not?
And... I was correct. See their other PR
> QEP 429: Add exception to the AI policy for trusted contributors - #388
Aka only the trusted maintainers can use LLMs for speedups, the rest can suck it? Very mature behavior from the maintainers.
Part of this is an alignment problem, but on the human side: the bottleneck is no longer writing code but staying aligned with it, knowing what it does and whether it does what you meant. In my own work, that’s now most of the job, even for code I asked for. For maintainers reviewing large PRs from strangers, it's certainly much worse. A ban is bit harsh, but I understand why they’re rationing their attention.
Knowing what your software does is such a hard problem. Most developers have an idea but if you ask, how are you sure?, the answers reveal how little they know.
Most often we’re satisfied with signals and indicators that it works and we build theories and mental models that use to try to avoid the effort of proving anything.
Worse is what happens when you start using LLM models to generate the code for you. I find you start losing the mental model short-cuts; you start to trick yourself into understanding the code. You understand little.
And what few studies there are of code review suggest that we have very little impact on code quality after reading more than a couple hundred lines of code over an hour.
So the current mental leap is, “the AI is a better programmer than I am.”
I think it’s still worth becoming a better programmer regardless. And there’s no royal road. You just have to write code and struggle with writing bad code.
Are we now really this far knees down in the gutter already? Are we?
Maybe. I’m not certain the pages and pages of informal markdown specifications for the agents really add anything for me.
Yes the bar will be raised to formal verification and actually strong mathematical proof skills to be a real software engineer
> the bottleneck is no longer writing code but staying aligned with it, knowing what it does and whether it does what you meant.
Perfectly and succinctly said.
I fully agree with you. But I feel like I have taken the opposite approach. Staying aligned with the code is such a burden that I don't think AI is making my job easier so I stopped using it.
That's why I'm now considering what are the ratio for each language in term of exposing the business logic nub that human can grab (mostly) correctly vs all the clutter that is here mainly to bring additional type safety and please the compiler in some way.
One approach that Ruby took for type introduction was to put that in a different file. That comes to my mind.
Typescript brings some niceties, but also some boilerplate all other the place. Combined with something like Effect, Zod, and the like and line count explode. Not sure OCAML or Haskell would provide more compactness for equivalent safety.
> the bottleneck is no longer writing code
The bottleneck has never been the writing of the code. It's all the rest that takes the majority of the time. Of course, it is often the writing which lets you expand your understanding or your awareness of challenges and pitfalls, which then puts you back on the drawing board.
> but staying aligned with it, knowing what it does and whether it does what you meant
That’s the old “Programming as Theory Building” stated by Peter Naur. Writing code, once you learned a language and a few libraries has always been easy and can be made easier by using tooling. Having a good understanding of what has been written and what needs to be added is the difficult part.
I think for every line of code I’ve written, I spent 2 to 5 hours reading specs and docs. Creating software is always about understanding. If you’re thinking too much about syntax and libraries symbol, you’re just at the beginner phase of coding. Like thinking about grammar when learning a second language or being hyperaware of the car as a beginner driver.
I think this is the end of open-contributions, the maintainers already having too much on their plate.
Plus it is becoming exceedingly rare of finding a contributor that save time, as in can do better than the maintainer itself using LLM and reviewing it itself.
My experience lately is the best way to contribute to open source now is to just write detailed issues. The maintainer can then paste them in to an AI tool themselves and go back and forth faster than they could comment feedback to you and wait for changes.
That’s what I’ve been telling my PM: I don’t need your half-baked PR you one shotted from a prompt: put that prompt in GitHub Issues for the team to use later
> The maintainer can then paste them in to an AI tool themselves and go back and forth faster than they could comment feedback to you and wait for changes.
My experience is that maintainers cannot do this. Or rather, that it is useless.
if someone wants to contribute, they need to prove they produce value to the project. I dont think this is controversial at all.
The fact of being open source means if your contributions are rejected, you simply need to fork. The open market competition will soon determine if your contributions were truly valuable and whether the original project's owner misjudged, or that contribution was essentially worthless.
I agree with fellow commenter, now with LLM the forks will NOT been distinguished as much by their technical differences/features as their trustworthiness (which is already the case today, but tomorrow will be skewed even more). Massively increasing inertia and favouring initial/well-known work/founder/team.
That's not entirely true: my work might get zero traction because nobody will know about it.
> That's not entirely true: my work might get zero traction because nobody will know about it.
Being able to market your work and build community are key skills for open source contribution. The history of forges is littered with interesting code that never got enough attention to go anywhere.
The history is also littered with dead open source rejecting useful improvements, so your criterion doesn't help either
Not really, even if you have a great improvement, you need to spend the overhead to keep it up to date long enough to gain traction.
Then marketing it to convince others to even try... If the idea is too niche it might never hit that threshold for uptake.
It can still work. For example if you look at https://github.com/emdash-cms/emdash/issues they have a whole bunch of tooling that uses AI to automatically triage and come up with PRs automatically.
It's the end of open-contributions for one specific repository, that is all. It only covers QGIS, the UI application, not GDAL/GEOS and the other libraries that give it its functionality. Additionally, in the past few years the number and popularity of new open-source projects that do accept open contributions far exceeds the few old ones that do not.
You're forgetting QGIS's own plugin ecosystem, which afaik doesn't prohibit slo-... err, vibe and assisted-coded contributions.
Although that would probably change of the AI-assisted spam shifted over to it.
Expanding on that, the issue is aggravating the maintainers bottleneck, because how do you find new maintainers if you do not accept outside contributions?
Another option would be to make a contributor pay for the review of its PR, even a small fee, to deter AI-slop, at least for new contributors. It could/would exclude students or people with the lowest wage though, but I'm optimistic even a 1$ bill or less would be enough.
It would also exclude 75% of the world.
I'm purely focusing on the effectiveness of the measure keeping the open-source ecosystem alive, not discussing much about fairness.
The current contributors are already massively skewed towards people with more ressources and time and 75% of the world, so I do not expect a sharp decrease in contributions.
It also creates wrong expectations. If I pay you (even if it is $1) then I expect you to take a look at my slop and argue with me how to make it better. Just closing it will prove that you're a scammer (and not even a successful one, because you'll get at most $5 altogether).
For an outright ban on "LLM, AI or agent assisted code contributions", they do very little to define what that means. This is a terribly written policy - I sincerely urge the QGIS maintainers to put enforceable guardrails on the definition.
This reminds me of the legal ambiguity behind the GPL and its definition of "derivative work". A careful analysis of the GPL shows that using GPL software doesn't trigger any other clauses. But distribution does. What is the legal definition of distribution? Who knows!?! That's why most software companies have an outright ban on GPL software. Even companies that are willing to comply with the GPL, they cannot feasibly come into compliance with such a vague definition. So it's better not to engage.
Same will happen with anti-AI policies. Even contributors who are fully willing to do things "by hand" will start avoiding these projects. No way to know if you'll accidentally run afoul of someone's AI radar. There's nothing to protect enforcement from becoming a witch hunt.
Some people blindly hate AI, what everyone actually wants to ban is fully automated coding, or at least “vibe coded” submissions, if you cannot support your change without an LLM you shouldnt be pushing it into a major project.
People can 100% still use LLMs without “vibe coding” in a meaningful capacity and understand the output, and still be drastically more productive.
My point is, if projects are actually serious about banning AI, write that down in enforceable language. As of today, your personal interpretation of what the policy might mean likely conflicts with other's interpretations. There's no clarity on what exactly has been banned.
Put simply, if you're so convinced that AI contributions will ruin your project, you owe the world a full and complete definition of what "AI contribution" means.
> most software companies have an outright ban on GPL software
That doesn't sound right: most software companies, for example, make extensive use of Linux.
The standard I'm used to is:
* Internal use of GPL software is fine.
* SAAS products with GPL software are fine.
* GPL software leaving company infra is fraught. Either just don't do it, or bring in legal if there's a strong business need.
This is different from, say, AGPL, where baby companies do just ban it outright.
I don't feel like any further definition is required. You would surely know if you had used an LLM, AI or agent while creating the code. Keeping things broad allows for simpler enforcement, otherwise you end up in the weeds arguing if seeing the Google AI search summary counts as LLM influence.
Why is everybody all the time in favour of AI on HN? This is objectively a good change because it will improve the quality of the code in the long term.
> Why is everybody all the time in favour of AI on HN?
Many reasons:
1. The people on HN tend to think they're very clever, but they're often not as clever as they think they are. That has a lot of wide-ranging implications, from classic "engineer's disease" thinking to stuff a lot dumber.
2. I wouldn't be surprised at some unexpectedly large amount of AstroTurfing, especially considering the sheer amount money is flowing into the AI space. My understanding is HN has some influential people reading it, and is influential on a certain fraction of the wider group of software developers.
3. I think there's a certain amount of defensiveness from AI enthusiasts. They've enthusiastically adopted AI to a certain degree, so critique/skepticism of their choice is felt as a personal criticism.
4. HN is a pedantic place (see 1), so "everybody all the time in favour of AI" will be interpreted literally as false, when it really should be interpreted as "why is there so much pro-AI activity."
There's a few major flaws or logical fallacies or whatnot in your comment:
1. "everybody all the time in favor of AI" - this is not true (objectively)
2. "This is objectively a good change because it will improve the quality of the code in the long term." - this cannot be considered "objectively" a good change because quality is subjective. Second, it makes the assumption that human written code is always (objectively) better than LLM generated, which is also not true.
But this is a software engineering project - the code is only part of the whole project / product, and the (subjective) quality of the code is only part of that. LLMs could write perfect code by whatever quality metrics they use, but if a reviewer is overwhelmed by a morbillion other perfect code contributions from LLMs it's moot.
AI assistance doesn't necessarily imply lower code quality. It can help with improving it in a lot of ways. Full vibe-coding without careful review is what results in low quality code. I think a lot of projects are having trouble getting to the sweet spot, though: if they allow LLM-assisted contributions then no matter how much they write to try make sure the result is high quality they're going to be inundated with far more low-quality contributions and have to work harder to filter through and reject them than if they just have a blanket ban which then makes it a lot easier to reject everything. The linked discussion is specifically with a view that not all LLM assisted contributions are bad but that they need to stem the flow for now and figure out how to open up afterwards.
I haven't actually looked at any open source project PR queue, but what is the ratio between actual thought out LLM assisted PRs and vibe coded PRs that are spammed unread? My bet is 1:100.
Not to mention that the thought out LLM assisted PRs won't even register as LLM assisted PRs...
> Why is everybody all the time in favour of AI on HN?
It is useful?, it works most of the time?
> This is objectively a good change because it will improve the quality of the code in the long term.
It depends?, sure, banning hit-and-run massive AI generated PRs will help.
These were problems before AI too, people just want to get their name on things without putting in effort.
This also bans possibly high quality PRs that fix things or add something new.
Either way, we'll see, anyone can still fork and if it's a better project then that will win over
Calling your own opinion objective is not a good practice. This is very much something you can have different opinions on.
Are you asking why most people from Big Tech, very likely working on AI-adjacent products, have a very strong pro-AI bias?
Will it? Plenty of open source projects have bugs unfixed for decades because it's too tedious to fix by hand and would take five minutes with AI these days. I've also found that good LLMs can be more diligent in updating comments, tests, etc.
Sure, which is why in first comment they say
> I'd like to open another topic about the usage of LLM for review, auditing and security purposes, but I think this is a very separate thread, and we'll open discussions at the user conference before any formal discussions.
If the bugs remain unfixed for decades, then they were clearly not important or impactful enough.
Is 130 million dollars impactful enough? [1]
[1] https://www.reddit.com/r/Bitcoin/comments/1vddeuy/are_you_ki...
AI already writes better quality code than humans. And you disagree I doubt you will contest that long term it won't be true.
Will it? With proper guidance llms produce much better code and find more bugs than I ever could. For example I have never been bothered to fix python typing for my project and left it hanging for years. But with llms and one prompt later I fixed it all at once.
>it will improve the quality of the code
That does not mean the product becomes more useful. I could rewrite Windows 1-to-1 with better code quality and no one would care because it still provides the exact same features. Unless "better code" means "better features", better code is useless.
This is extremely short-sighted. Software is not a static product. "Improve code quality" translates into being able to add features more quickly and with less risk of bugs. For an open-source project, this also gives readers the opportunity to understand the codebase and learn from it.
This was true when adding features cost a lot of time and mental effort.
Nowadays, it's just a prompt away. LLM's can still run around in circles when the code quality is bad enough, but LLM's are also getting exceedingly better at catching that and writing code that's good.
We're all in a different phase of the collective grieving process, some are still in denial, I would put you in the bargaining phase judging from the comment.
Better code allows you to write new features with less risk to disrupting your current features.
Software design and architecture is about creating a system that can be built well, run well, and modify well.
If you just throw things together without thought you get an unmaintainable mess.
Because this is a startup/tech community and people generally look forward to exploring new ideas and tech?
> This is objectively a good change because it will improve the quality of the code in the long term.
Can you explain why you think that?
QGIS is written in C++. Does that affect your answer to this question at all?
QGIS is actually one of the big portable/cross-platform hybrid Python/C++ apps, which makes it arguably more complex for an LLM to cope with properly than one or the other, and makes code quality a rather more entrenched/storied problem.
In this way it is very much a spiritual cousin of FreeCAD (also cross-platform Python/C++/Qt6), though that (at least currently) has a somewhat more liberal ("humans in the driver seat") policy.
> Why is everybody all the time in favour of AI on HN?
Funny to see this while in other threads someone else will ask why HN hates AI so much.
I'm in favor of AI, but if I was a maintainer for an open source repo, I would also favor banning AI contributions. At least for the wild, maybe people who have built a reputation in the community could stay. I think AI can write quality code. What I doubt is if the average contribution will involve quality code or even human input.
For me, it is the way AI has kept suggestions to either open issues with maintainers or make PRs to fix an "issue" it found. I know it hasn't researched the issue in depth enough to be talking with the confidence it has, and I know I am in no position to be bothering someone else unless I want to spend considerable time investing to make sure the issue is exactly what the AI is claiming, it isn't a known issue, and it is justified to bother the maintainer with it. But there are far too many who will see that option and just tell the AI to do it.
It isn't that I'm against AI. It is that opening a PR or filing an issue use to have significant enough gatekeeping that most low effort low quality work simply wouldn't pass it, but that has now changed. So a new gate is needed to ensure those who aren't willing to put their own time into the work before asking for the time of others, and banning AI is one of the better options I've seen.
This also doesn't even end AI interacting with the project, just changes it. If you have some unique use case that AI finds, you can download it locally, have the AI make the change just for you, and have AI keep updating when necessary. Each user gets the customization they want while maintainers are protected from low effort low quality spam.
In favor? There's a whole spectrum between "complete ban" and "slop all the way", IMO.
Dude maybe if it was ChatGPT 2.0.. AI has come a long way.
First, just check out the comments on any "I'm tired of reading slop" submission to refute your first point, the circle jerk is real.
Second, while I sympathize with not wanting to be inundated with low effort PRs, putting a ban on AI assisted contributions in response is myopic virtue signalling.
I think in this case it's not about signalling: in the linked discussion they are saying that the problem is the workload created by the AI-assisted creations, not the AI use in and of itself, and they are open to relaxing the restriction in future once they can figure out how to manage it.
(The issue is, I think, if you allow AI, no matter how many paragraphs you write about taking responsibility and ensuring high quality contributions, you're gonna get a lot of bad ones just because by sheer volume there's enough people who aren't gonna read it, and that's gonna take a disproportionate amount of effort to filter out).
> is myopic virtue signalling.
Would you personally join in to evaluate and review the onslaught of AI generated PR to the project?
For those who, like me, had no idea what QGIS was: It is a free Geographic Information System (GIS), which means that it deals with creating, managing, analyzing, storing, and visualizing geospatial information. Think of (3D) maps and stuff like that.
What's next. You are only allowed to edit with notepad.exe?
Ironically I lost my use case for QGIS since LLMs can readily write scripts for manipulating and converting point clouds (lidar data). I'm not a pro by any measure, mostly just making contour maps, but it massively streamlined things. To me it reveals the future of software
It's true that simple data conversion is now more easily performed using vibe coded scripts. But the real value of QGIS lies in it enabling managing data large complex projects (infrastructure, urban/environmental planning, etc.).
- Any (super)intelligence caches work. This is just how the physical world works. You use the results of your previous work to do more work.
- Any (super)intelligence _wants to create stable abstractions_. Now this is a claim, not a fact. but I'd say this it's pretty clear. I can cache all of the work in the world, and maybe even re-use some of it, but that's different from the synthesis of creating an _abstraction_.
- Abstractions are lossy. They can lose a posteroi, in that they don't match the contract as specified. They can lose a priori - the specific set of problems and solutions they claimed was their goal and role, are wrong for whatever reason (discovered, the world and requirements changed, etc). Someone or something needs to maintain it now.
What's at the end of the tunnel. Is it reasonable to say that a few labs will carve up ownership of all the open source projects of the world? Or will there be more community lead projects than ever? There are also some nastier routes, such as making things so coupled and "holistic" that you can't use anything else besides a few products.
The difficulty of forking and modifying an open-source project has been drastically lowered so I predict we'll see more projects than ever before. But many of them will essentially be duplicates of each other.
My expectation is that those AI primary forks will degenerate quickly. Maintaining OS requires a lot of judgement, direction, agents tend to turn softeare into big pile of disconnected features.
wouldn't it make more sense to tighten the rules and requirements for contribution? how would you even identify AI assistance if the result is immaculate? it seems to me that banning AI is conflating low-quality or low-effort with using AI. I understand those correlate statistically and also causally ... but latter only for specific lazy cohorts. if the AI assisted contribution is of high quality why would you ban it? especially given that you couldn't even identify it or would they still discard it because some comments exhibit Claudisms? tests, linting, more tests, style guide abidance, even more tests and banning contributors who fail to deliver.
If you can't tell that the contributor used AI, the PR is good - how would they know to forbid it? This rule hopefully stems the tide of low level fly-by contributions. As they said, it's also not set in stone, there will be enough time to change it later if needed.
I suggest reading the issue comments.
I see this as a good thing, QGIS is already a bit of a mess to begin with (seriously, what mapping program starts you off without a base map? Even Google Earth gives you a starting globe to lay your info upon) and could really use the bandwidth to focus their attention on making things actually make sense rather than goofing off with AI-'assisted' coding where the 'programmer' doesn't even know how things work.
GIS work has very complex inner mechanics that are hard to reason about at a high level without very explicit abstractions to ease the costs and cognitive burden of manual review. Sometimes earlier, longer-lived FOSS projects may have grown organically without the benefit of retrospective appreciation because that path has not been trodden (at least out in the open) at the time.
I implemented css geometry properties for svg2 in resvg with claude. I know it works and I've read the relatively small diff. But I'm afraid to send a PR because it might offend a artisanal handcrafted free-range software enthusiast. I guess any other AI enjoyer who needs this feature, which is standard functionality in svg2, will just burn a few tokens and do it themselves to keep the luddites from smashing the factories.
The question I have is what is an AI assisted contribution? For example, I still write code by hand, but I make many prototypes using AI before committing to a specific implementation. My code is clearly AI "assisted", but all of my final code is written by hand (no autocomplete either).
From February to 09-24 the policy was "human in the loop". Any tool was fine as long as the contributor read the code and could answer questions about it.
Banning does not imply verification. The policy is just a warning. So now you know, if they suspect that a PR is AI-generated, then there may be further consequences. I don’t think someone is going to apply a stamp on each PR.
The most egregious examples are always lazy (big diff, lengthy descriptions, weird phrasing,…). Now there’s a section in the policy to point to for the quick rejection.
No, you retain full authorship of your code regardless of how it's generated.
> My code is clearly AI "assisted"
No such thing, it's 100% your code, regardless of how it came to be.
The discussion is not about ownership of the code, that doesn't interest the people who have written the policy in question.
"Assisted" does not necessarily mean "authored", which is the point of the comment you're replying to; helping you review the code is "assistance", even if no code was written.
Curiously, https://github.com/qgis/QGIS-Enhancement-Proposals/pull/387#... shows that at least some contributors realize the vagueness of the policy, but they don't seem to care, which is rather unfortunate.
If you didn't mention it, how would they know if your contribution was written by AI or not? What happens to contributors who sneak in their AI-assisted commits where it's not obvious?
The new policy says:
> If we subsequently discover that you have used an AI, LLM, or any agent-based workflow for your contribution, you will be subject to code reversion and contributor rights sanctioning.
Policies like this have an element of trust to them. That's not new: open source projects have needed to trust contributors not to paste in proprietary licensed code since open source began.
Of course, if you sneak in a simple patch that an AI agent wrote for you, nobody might notice. The fact is, maintainers of big OSS projects are increasingly dealing with patches in the 10kLOC range, all at once, coming from people with little to no previous engagement with the project: that's usually a dead giveaway.
Contributions that are valuable, are valuable. These "No AI Contributions" nonsense is like saying AI art is not art. It's just not valuable for you, has nothing to do with AI. The QCIS project simply doesn't want to go over each PR and see its value? Because AI-generated things are not valuable for them, has nothing to do with AI, PRs, contributions, etc.
My 2 cents.
To play the devil’s advocate - AI generated code is incompatible with human generated code. I think this is a tradeoff most projects should make, but I can imagine some projects wanting to work the old way. I would question their relevance in the future, but I can respect that.
There is no need for them to accept AI contributions from third parties. Whenever they want AI code, they can just ask for it themselves, ensuring the model has the correct context and specifications in the prompt.
the argument is not that AI PRs are inherently not valuable. but if you have to spend a lot of time triaging them because of slop AI PRs it is just draining and inefficient.
I recommend people actually read the updated commit for the full message.
In fact, this change seems quite logical. AI is certainly a useful tool, but that doesn't mean it must be uded always and everythere. Edpecially when doing so could compromise the final quality of projects. Let's see where all this leads
the biggest problem I have with "the users" right now is trying to spot issues people are having that actually matter. So many bugs now are just someone with their LLM/fuzzer finding frivilous issues that affect nobody, but the folks doing this are beginning to deploy dark tactics to get their reported issues to look "legit". careful language choices and other github accounts coming in to "agree" they have this issue also. I'm starting to think of how to identify people using "dark" patterns like this and just ban them outright.
Good, QGIS is one of the projects that can be put closer to the bottom of the stack in that XKCD comic. I've seen QGIS being used just as a visualisation tool, and i mean it's good at it too, but even in a limited use case i am aware of it was used to do important infrastructure work like planning water pipelines and predicting failures for said pipelines.
Edit: https://xkcd.com/2347/
For open source projects which are free of high growth expectations that come with VC funding this might be the right move.
AI coding comes with the tradeoff that you lose understanding of your own code. That is an acceptable tradeoff when getting it out to users matters more than understanding code. But free of capitalistic pressures, why would you accept AI slop?
I’ve been able to contribute to projects recently using ai. And another project banned this so I didn’t bother. The second was a bug fix for an issue I was having. The first was a new feature.
Either way my bug got fixed but if a project maintainer doesn’t want it who am I to fight it.
You can always fork it. I suspect my contributions are higher quality because I use different model providers to review each other but whatever.
QGIS is not your run of the mill project, though. This is specialized software and a rare breed. It's in their right to decide either way, and this is the right call for this niche, IMHO.
they own the project of course it is their right.
if someone disagrees they can fork.
I don't understand why it would be the right call. not my field.
haven't seen a good explanation in the comments. (yet?)
GIS is basically "serious mapping software", and when it's used for city planning or other large GIS-relevant activities, accuracy and precision are non-negotiable requirements.
IOW, your city might be using QGIS to plan the city and verify everything being done on it, down to cm level accuracy. So, any subtle bug is a big deal for these kinds of software packages.
While doing construction work (regardless of infrastructure or buildings), the plans are laid and verified to that level. The haphazard spray paints on the ground are indeed big deal, and has a digital copy in the GIS software.
It's not only used by municipalities and/or governments either. Research teams use GIS packages extensively as well. I briefly worked with a research team working at Antartica. These GIS software and related ecosystem is their both bread and butter and foundation to anything they do.
A patch generated by an AI model breaking these software packages have cascading and important effects. So, the software needs to stay dependable and reliable.
Data portal for South Korean team: https://kpdc.kopri.re.kr/
They're not the team I was working with, though.
Waiting for GisCraft repo to be started.
for what purpose? qgis is already free to use, unlike Adobe's CS
I think think its a good thing a lot of people are banning AI contributions. This will clearly differentiate and make space for the free market to pick the best winners.
Omarchy is on the opposite spectrum.
Seems it's time to clone them from scratch using AI.
Go for it. I bet you could do it in a week.
I'll fork it in about 30 seconds.
And neither of us will get any traction, because the QGIS team has a history and proven track record within the GIS community, and neither of us are attempting to solve a problem that community has.
I don't care about traction. I hate AI-haters.
You have absolutely no idea of the complexity of QGIS or its place in the world.
You don't need to understand things if you have a maxed out Claude subscription.
Oh no, don't want to hurt the tech billionaires' feelings.
The majority of LLM use is to make slop or answer simple questions that could have been searched. The mythical AI-Chad Coders are so rare that catching them in the anti-slop dragnet will not meaningfully decrease the quality of a big project.
You can clone anything in 15 minutes with AI. Just like you can start a child in 15 minutes.
The question is whether or not you are willing to support your creation for the next two decades.
I bet millions of moved to deno, the javascript runtime... and they are ending support next year... after running for a few years only. You seem to be not questioning them.
Second, majority of apps do not last 2 decades.. and that is okay... someone else can fork the repo and continue if needed.
Are you even remotely aware of what the project this thread is about is?
If not you may want to familiarize yourself:
https://en.wikipedia.org/wiki/QGIS
but you can just fork the entire repo and continue development with AI yourself, why the need to rewrite it from 0?
It's my impression that forks like these last only until they make the HN front page and then are quietly abandoned.
Wrong... I support all such clones: https://github.com/goodappsstore ... drop your misplaced assumptions.
You've supported them for all of "checks git history" 2 days!
What a track record!
Still better than your assumptions.
A 2 days old anonymous Github repo of random slop is your proof? Okay.
And your proof is what? Your assumptions? Okay.
I'm a non-native english, so I change the code myself, but I tend to participate in communities while using a translator. If I use AI, I can fix bigger things, but most of what I contribute to open source is finding small bugs, so I don't use AI for open source contributions. (I mostly don't even have the ability to make big changes.) Looking around open source like that a few times, I can understand the hatred toward AI to some degree: too many requests pour onto a single individual. Of course, that doesn't mean AI isn't helpful. In my view, AI writes code blocks better than I do, and it might even be better to use AI for some of the open source I've contributed to... but overall, I feel that some kind of system for filtering AI-based PRs is needed.
And another open source project consigns itself to irrelevance.
Lucky for AI companies that OSS projects are doing this, otherwise where will they get their carefully created training data from? They would be reduced to training off the slop their tools produce! /s
> QGIS is trusted by organisations because they know they can contribute back, they can hire contributors for support, training and feature. As a community project, this is something we really want to protect
We have gone from "LLM-slop is gonna ruin open source projects" to we wanna "protect" humans so they can make some dough on the side training and stuff. If human coders become the bottleneck in the chain, the solution is obvious and there's only so much protection anyone can do.
> If human coders become the bottleneck in the chain
This "human bottleneck" is why we have QGIS in the first place. I think they deserve a bit more respect than that.
> If human coders become the bottleneck in the chain, the solution is obvious and there's only so much protection anyone can do.
Which chain? It’s not like there’s much productivity going on. There’s a lot of activity for very little impact.
Looking at the scope of their code, the quality, the testing rigor etc. it's clear that they feel threatened by AI. Realistically a couple of prompts coupled with a factory of agents can replace this entire codebase in a matter of hours.
Furthermore, how will they prove whether code is AI generated or not?
And... I was correct. See their other PR
> QEP 429: Add exception to the AI policy for trusted contributors - #388
Aka only the trusted maintainers can use LLMs for speedups, the rest can suck it? Very mature behavior from the maintainers.
> Realistically a couple of prompts coupled with a factory of agents can replace this entire codebase in a matter of hours
you are the reason for this policy change
I don't imagine they will care if you do that, there will be no detrimental effects to them from doing so.