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.
There’s something about geospatial work that seems to break LLMs. I’ve experienced it a lot with latest versions of both Fable and Opus, and it’s the classic nightmare of confidently-spoken-but-wrong.
Yesterday, I had a relatively trivial bit of work in play using distance-weighting to measure stuff, and Claude did really well / but right at the end, despite having a success metric and lots of great results matching it, Claude insisted my maths was wrong and needed changing.
When i asked why, and pointed out that the suggested replacement would cancel out the distance-weighting entirely, it immediately agreed with me and asked to write its fifth project memory about it.
The other big ones it tends to mess up on without strict guardrails are coordinate systems; and measurements, often converting back and forth between a given nation grid and wgs84 latitude/longitude in ways that lose good amounts of precision; and then custom-coding haversine-equivalents to measure a distance that’s otherwise be a simple subtraction via the national grid coordinates. It’s baffling.
I’ve found it to be surprisingly effective lately.
I’ve been renovating a spatial/topology validation system for an OpenLayers driven map editor for robot fleets. I set up a clean interface for spatial indexes and predicates as well as your basic geotoolbox functions.
I was most surprised by a moment where Opus detected that using a union approach to ensure that robot footprints always sat within valid polygons (possibly straddling multiple valid polygons) was slow in testing. So it decided to find the difference between footprint and each polygon within the AABB of it. And if the remaining polygon is zero size, it’s valid. If not, the remaining shape is what is invalid.
I was also surprised just how good it was at recognizing, “in the test data there’s a lot of this kind of feature so we should explore what’s more common: hits or misses?
Before robotics I spent a lot of time building spatial models for data processing and analysis. I find that I can usually just explain the spatial question in natural language and it will figure out the relevant inputs from the dataset and what the process can be. I’m not obsolete quite yet though because maybe 10-20% of the time it goes on a pretty fantastical journey through unnecessary intermediate data products.
Oh don't get me wrong, it's a level-boosting monster even with that.
The worrying bit is if you're not keeping a close eye on it, very easy to think you're getting a solid system, but thanks to the internal madness it's used, your entire grid has in effect shifted 10 metres right, and any spatial measurements are far more approximate than it's letting on.
That was the bad old days for me. Nowadays I keep it locked down to specific systems for projections or actual spatial calculations, and that seems to keep it honest.
And the surprise is awesome when it happens! My favourite is all the QA steps you wish you'd had and that it reasons out on the raw data alone:
"oh hey, this one city has no data but it has a high population, oh right, that's because of this obscure lookup had a row chopped off, there you go, sorted."
LLMs are very good at conceptually simple but tedious classification problems in general.
One that has saved me many hours: given a small subset A and a disjoint sample B of a larger set of, say, complicated JSON objects in a consistent but unknown schema, what do the objects in A have in common that isn't true of any objects in B?
Example result from Claude: The field foo contains dates between August 3 and August 7, 2016 in every record in A, and every record in B contains later dates.
Claude even correctly hypothesized that it was dealing with metadata from a document management system, that field foo was the creation date of the document, and that nearby field bar, identically 10 in all records, was the document retention period in years, and thus A represented documents that would have been purged between August 3 and August 7, 2026.
Oh absolutely. I just had flashbacks to getting outputs where a raster is completely wacko because the input coordinate systems were not the same and so the grids didn’t line up. It absolutely still has to be supervised closely, much more than a lot of more vanilla programming tasks I’ve experienced.
One thing that helped me a ton was making an adapter between my domain specific datasets/systems and QGIS. So I can watch and examine the intermediate steps and leverage that my brain is still pretty darn good at visual pattern matching.
Ouch! I had a sympathetic shudder at your raster flashback, totally been there. I totally get your visual pattern matching instinct too - spooky cos that's how I do stuff too. Great minds.
For what it's worth, I use duckdb and its spatial stuff as my adapter. Works for my brain and if you force e.g. SQL files for each step, gets there in the same kind of way. Still some sharp edges, mind, but overall working well. And then Claude comes for my maths and I sob.
Yesterday I was trying to add a patio to some real estate photos, i.e. "virtual staging".
I uploaded 4 different photos of the same house, from different angles.
I asked Gemini, ChatGPT, and Grok add the same patio to each photo. The results were laughably incoherent (not to mention ugly).
I repeatedly asked them to make the 4 photos consistent in 3D, and it's obvious that they have no way to do this -- no understanding of the scene.
They also could not understand the concept of "back patio" and "side patio" -- relative to the house, when the house was being photographed from different angles. Even when I pointed out which one was the side patio, they would get it confused in a different image.
(I should not be surprised by this, and yeah I know everyone says LLMs have "jagged" capabilities. But to me this shows how bad all the extrapolation of AI I read on say Hacker News has been)
I reckon this type of task is crossing capabilities in a way that the LLMs (very quietly, mind) don't support.
An LLM can describe a photo fine, but it cannot tell you the exact coordinates of what it's describing. When I last tested this, you could sometimes get it to lie about the coordinates, but asking it to draw an approximate bounding box around a given feature - total fail, sometimes laughably so.
Yeah, I tried to have AI arrange some furniture-shaped rectangles on a black-and-white floor plan. Impossible. I could painstakingly guide it through writing a floodfill to find the corners of a room and parse out the dimensions listed in that room, but at that point it wasn't using its image-seeing abilities at all, and it still couldn't do things like putting a particular rectangle against the bottom left corner.
I think they do but only when it's applied to learn some specific spatial task.
We can see for e.g. that frontier models have got really good at CAD sorts of tasks recently. That suggests benchmaxxing RL to a degree but it does mean they've suddenly got quite good at forming simple geometries in a step by step way.
This is my experience too, it has got a bit better but nowhere near as quickly as other domains I deal with. I can usually guide the LLM to a decent solution but there's a lot of hand holding and I'm often left wondering if it wouldn't have been quicker for me to just get stuck in and do it the old fashioned way. Maybe because geospatial stuff is pretty niche so is under-represented in the training data relative to yr standard CRUD apps and React front ends which are ten-a-penny?
They're notoriously, hilariously bad at chess, even today. So yes, agree, their shortcomings come much more forcefully and immediately to light when they attempt spatial tasks.
I mean, it's obvious, no? LLMs operate exclusively on language, and language is an especially poor way to represent geometry, let alone geography to any useful resolution.
At Plotly we are dealing with similar issues. We're doing our best to keep up, but it's genuinely hard not to just cut our losses on passer-by community contributions. 3 page issue writeups nobody has proofread, nobody but a bot to follow up with when we try, huge volume of plausible but weak PRs eating up reviewer time. All while we have core work we really want to be focused on rather than merging another bug fix we don't expect anyone but this bot has really run into.
This has basically been the story for us at Hatchet too, and it’s been similarly challenging. A lot of the OSS PR reviews I’ve done lately from non-core contributors are basically just me going back and forth with Claude via someone else, which is frustrating when I feel like I could 1) just not or 2) do the back and forth with Claude myself and cut out the middle man.
I have a sneaking suspicion that people are having some agent check out 500 repos and just prompting with “find a bug in this repo and fix it” and submitting the results blindly.
> I have a sneaking suspicion that people are having some agent check out 500 repos and just prompting with “find a bug in this repo and fix it” and submitting the results blindly.
From the reports coming from a number of places, I'm absolutely sure this is what is happening. People want the glory of finding a named bug, perhaps they believe some more widely useful reputation gain is heading their way if something that their bot finds is actually massively significant. Though it isn't limited to 500 repos, they tell it to just keep going after every one it scans.
>I have a sneaking suspicion that people are having some agent check out 500 repos and just prompting with “find a bug in this repo and fix it” and submitting the results blindly.
This is unironically suggested as a way to 'get in the door' both in bootcamps and 'spammy' universities.
Well, contributing to FOSS is a prestige accomplishment. It's viewed as a way in. It's now just a metric to game, and to automate that process is too easy.
Combine this with a growing sense of being "left behind" and a highly publicized collapse in software jobs coming any day now and any proof of contribution is highly prized. So why not?
They'll destroy the prestige of it by doing this, though. Unfortunately the OSS model will have to change to cut them off now, and the more people rush it the faster that response will happen.
On the contrary, the prestige will go up - filtering mechanisms, fatigue, and general banning of AI contributions will make it harder to get a PR accepted. If you make it past all that, you are a real one now.
I've seen this with godot. People are letting their agents blindly file AI generated PRs even though Godot specifically bans this, and then coming in and giving a very weak apology when they get called out by the devs. A lot of the bugs are incredibly low priority bugs as well that no reasonable person would ever really run into, with these huge long wordy slop reports
Its kind of appalling that people think this is an acceptable way to behave
We disabled PRs for PgDog, but left the issues open, for now.
Most bugs that are reported via AI-generated GitHub issues are edge cases, which are technically bugs, but not something anyone actually ran into.
Contributions are exclusively AI-generated, and it's much easier to just go off of a GitHub issue myself than asking the bot behind the GH account to remove the 5 redundant tests it added, or to refactor what has become a 3k line file.
AI doesn't care about code quality, maintenability, or long term goals. It's just a local maximum optimized with RL. Great for debugging, OK for reviews, but can't produce anything that's above average.
This is pretty spot on. AI will find some off the ball edge case that is a valid edge case but perhaps an undefined expectation of the code. Avoiding the additional complexity of handling it keep everything more grokable and clean.
Sadly, people seem to think all these edges AI finds are valid and must be fix and were never thought about. Most were thought about and deemed not worth the additional 50 if statements to handle. Cyclomatic complexity has exploded exponentially with AI and everyones response is “no no no you just need to use opus 6.5 and it will work”
Yeah I sympathize with this, but I’ve experienced the other side of this: I ran into a bug (an integration for home assistant has to be manually kicked every time HA restarts due to a bug in the integration) that my AI fixed with a one-liner. It works great for me. I submitted a PR which is languishing for weeks. No problem. My AI will just maintain a personal fork with my patch until my PR gets merged (or not). Previously it was way too much work maintaining your own fork, merging in upstream changes, and keeping your patch working.
I think this is going to be a common outcome from the fact that many people have AI agents that can one-shot fix and deploy. Maybe it’s not a bad thing for those people and the maintainers who each get what they want.
I feel this is something of a temporary and unstable equilibrium. Once the maintainers figure out how to harness agents more effectively, they can just have a daily bot job to poll all the forks and pull back stuff that looks good. We just don’t quite have the tooling and practices to scale the contributor side effectively.
I think OSS is going to look more like the original Git model, or perhaps even further towards “horizontal gene transfer” where memes/alleles get copied across various repos, rather than having a single lineage of phenotypes.
I would be interested if a common outcome was to have a fork with AI PRs and one with AI contributions disabled. Not only does it satisfy both camps, but it provides a longterm anecdote of the effects of agentic code quality and maintainability.
Yeah. I did almost the same with KDE Spectacle. It lacks good shortcut keys for annotations. I've just asked AI to add them. Sent a manually reviewed TINY patch to maintainers, never heard back.
Low quality PRs, along sometimes with concerns of providence that might cause future licensing issues, were a problem before the Eternal LLM September made it easy for far less capable (or caring) people to submit them than before. This is at least part of why a number of projects switched to being “open source but not open contribution”.
I’m a little perplexed though. The problem as stated is there’s too many drive-by contributions with AI slop. Isn’t the solution to define a contributor network (eg a GitHub org that you can apply to) based on trust?
The other option they proposed was a proof-of-humanity by payment, which seems much more in line with the above.
The problem with just banning AI is you didn’t solve trust, and your untrusted users are just going to drop drive-by PRs anyway. How do you know if an untrusted user did or did not use AI? In practice this likely means just aggressively closing “slop-looking” PRs from users you don’t recognize?
But then, you’re preventing your trusted community members from benefiting from AI assistance.
I’ve been advocating for defining a higher standard for AI contributors, eg an AGENTS.md that specifies some meaningful correctness bar. In this case, perhaps the PR that adds you to CONTRIBUTORS.md could to add a large novel and non-trivial end-to-end test; if you can construct problems that are easy to verify but hard to get right, then this is your “proof of work” to establish competence.
From reading the GH issue it does seem this is a placeholder solution, so I hope they find a more stable long-term resolution.
> Isn’t the solution to define a contributor network (eg a GitHub org that you can apply to) based on trust?
Yes but this is fairly tedious people work that most open source maintainers are not interested in. Once the tooling is available to make that easy, it will become more popular.
The linux kernel team set something up that they are pretty happy with. I don't know the details, but they have dealt with the influx and feel comfortable their solution will last.
One thing I've been thinking is something like the DCO checks. Set up some account bridge between (eg.) Discord and GitHub, then auto close anything submitted by accounts not sufficiently involved with a message linking to the new contributor policy and rationale.
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.
This is not just a software problem. I see it everywhere. Folks in business roles just as much as any other role. There is a surface-level operating framework to get a job done but the why/how is sometimes lost.
I always come back to an example in my past. Somehow automated a report. From Excel to Power BI. Then for months Power BI was wrong. Automation (more code involved for sure) made it run faster but then people forgot about the how - how to check/validate/etc. And since it was code - for many non technical people the whole thing was a lot harder to deal with needing to deep investigate issues.
But that is how most of the companies work (and did, for centuries). Very few roles affect critical flight safety, nuclear control or other things that need a bunch of nines for reliability, written and fire-drilled fallbacks, etc.
For everything else the general mode is "can we make it work well enough". And when it breaks, well, we will curse and pry it open and either fix or rebuild it. There are many stories of a particular thing that was built long time ago by folks who are long gone and no one knows how it works or even where it physically is.
And it works fine; usually better than ensuring complete reliability from the get-go, when it is not clear if it is a long-term core feature or a kludge that will be obsolete soon. My 2c.
But I feel like it's a minority that really know how the software they're writing really works. And it's 10x worse for older legacy software.
Mostly because the people doing it don't care. Not judging, just reporting I guess. I know because I used to work in quite a few companies where the "money maker" app was on maintenance for years and nobody was able to answer questions or didn't even know most corners of it still existed.
This desperation mindset also often correlates with people writing code without care for the next maintainer.
And the scary part is that this also correlates with advocacy for going all-AI.
Alas, I think we (collectively) either are, or will be soon. There will be people who keep 100% knowledge of the code in their projects, but I don't think there will be any monetary reward for that, nor reputational outside of their own niche. And I say that from a position of really wanting to be wrong about it.
I recently started using Claude to write an app. I was going to write it by hand but was having trouble getting motivated, and I knew I had to "up my game" in the vibecodery anyway. So far it's been a lot of back and forth, I keep the leash pretty short because I don't want The Claude AI you see everywhere now.
But even with good intentions and the short leash, I find myself saying "yeah, whatever, it looks like it did what I told it to do" and not actually reading all the code. Some yes, all no. And this is for my own project, nobody is my boss here, and it's nothing I couldn't have done by myself.
Now imagine the incentives for someone who's doing it for money, whose boss is pushing them to do more AI and not less, who probably doesn't actually know how to do all the things the AI is doing for them, who looks around and sees who's getting promoted and who's getting laid off...
And remember that most of us, most of the time, no matter how much we might love computers and software, are that person.
But hey, it could be worse! Have you heard about the Literacy Crisis?
> but I don't think there will be any monetary reward for that, nor reputational outside of their own niche
I used to think this but have come around to the opposite. I'm already seeing client projects where they went off and LLMd their way forward. A few hundred KLOC and many rounds of bug fix whack-a-mole later, they have something that's a giant house of cards.
Sure, once in this state the LLMs can repair issues at a faster rate than the humans can, but the damage is already done at that point. And it requires a lot of combined human/agentic effort to unfuck it.
That stops working once the code reach a certain size/complexity limit. It is a different limit for different people, but there is a point where there is just too many parts to be possible to fit in a head. There is also a middle stage where everything fits, but can't be accessed all at once but require some time to retrieve specifics when looking at areas not in recent memory. The middle step is more achievable the easier the code is to reason about by black boxing parts.
I hear this a lot as a reason to accept that only the robots have read the code: "but it's too much code for one person to understand."
Yes, but it's not ever too much code for a team to understand, or a community. The question is whether you can build a team or community with enough trust and integrity that two things are always true:
1. Alice understands the fluxtron renoberator module she wrote.
2. Bob can also shift his attention there and understand it if necessary, because Alice writes clean code that was reviewed by John and Sally.
You can have Alice, Bob, John and Sally all be robots, and you can decide to trust the robots, but (so far anyway) it's a choice, not an inevitability.
But 1 and 2 were rarely true pre-LLMs, not in any code that has substantial active development. Because 3 months later, the fluxtron renoberator module has been modified, fixed and refactored by 5 other people and looks little like Alice remembers it, and Bob, well, he could never shift attention and actually understand it, nor could anyone else, because that's just a nice story we told ourselves that never worked in practice.
> But 1 and 2 were rarely true pre-LLMs, not in any code that has substantial active development.
I'm ready to bet that is untrue. Sure, no one can recite the code, but people can quickly scan the module and refresh their memory as well as understanding the new changes, even after a while. If not, collaboration would have been impossible.
> Because 3 months later, the fluxtron renoberator module has been modified, fixed and refactored by 5 other people and looks little like Alice remembers it
I don't know for which type of projects those things happen, but good design can have a long staying power. Drastic refactoring in a short period is a clear sign of bad engineering.
> and Bob, well, he could never shift attention and actually understand it, nor could anyone else, because that's just a nice story we told ourselves that never worked in practice.
A lot of OpenSource projects are decades old, and while some core maintainers can stay for the lifetime of the project, new contributors came, understood the code, made changes, then left. Same for hires in companies.
> I'm ready to bet that is untrue. Sure, no one can recite the code, but people can quickly scan the module and refresh their memory as well as understanding the new changes, even after a while. If not, collaboration would have been impossible.
I don't understand this part. When I was doing freelance consulting, my job was quite often "come to our office, scan this 40 million lines codebase and fix stuff for the next week". It was never a problem to read and get up to speed completely unknown codebases if you have basic programming ability. Much harder to do something that fits floaty business objectives though.
When I started working in the 80s in my first job, the head of department had banned the PC for administrative tasks. He thought that the old manual process was more reliable and allowed him to better control what was going on.
He retired one year later and the PC were introduced successfully shortly after.
Was he wrong to push back ? At that time, that was what I thought. But now, 40 years later, I don’t think so anymore. I think that that delay gave the proponents of the PC the time to prepare themselves a lot better and is a reason for the success.
I can’t help drawing a parallel with what is going on now. Even though I’m pro AI, I understand why QGIS is stepping back. There are a lot of places where the processes and tools are not ready yet to fully embrace it and you need time to prepare.
The way I like explaining this to people is that I don't think I build products anymore. Now I build the harnesses which build the product. And a massive part of that is ensuring that I can make the AI remain aligned with my way of thinking.
I would even go further that part of the challenge is the "verification" of your way of thinking which is much harder to do since your harness now is "in the way" sorta speak.
I think the economics just change drastically. A few years ago a helping programmer was great help and would implement something that was agreed to be needed to be done by the project or something very important for the contributor (the reason they spent the time to contribute). Now anyone can get a 20$ subscription and prompt away, but so do the project's core developers. So why should they bother separating the wheat from chaff? I totally understand that.
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.
> 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.
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.
This. We’ve just moved the bottleneck from during writing the code to reviewing. The failure mode here is that you can choose to just do a light review since the code “works” but if you had to write the code yourself you would have been forced to consider the design choices and broader implications of the code more.
> We’ve just moved the bottleneck from during writing the code to reviewing
Ah, that's only true if whoever is in charge is willing to _have_ a bottleneck in reviewing. In some software development groups, there is a strong pressure for reviews to pass, i.e. expectation that reviewers approve; and the notion of veto is not common, so that if some reviewer objects, the implementing developer can find others who would be willing to accept, bypassing the objections. Also, few people are willing to conduct long reviews of a lot of code, and even less people are willing to read multiple comments in a long review of a lot of code.
Now, in some projects, there are only one or two "owners" or "marshals" for some areas of the code, so they can apply a strict standard if they want to, but - their time is limited, meaning that long LLM vibe-pull-requests are likely to either be ignored for a long time or rejected off-hand.
I have many years of the experience of of raising concerns, criticism and objections in reviews
The bottleneck they feel during coding is the lack of knowledge. Knowledge of the technical platform and knowledge of the deeper implications of the task’s requirements.
I’ve mentored juniors and the common trait is that they rush to code without understanding, then they spend days trying to fix things. Coding will seem like a real bottleneck for them.
> I’ve mentored juniors and the common trait is that they rush to code without understanding, then they spend days trying to fix things.
As a senior (of sorts), even though I don't quite rush to code, I often find myself starting to code something 'naively', while my understanding is lacking (typically in a tangled, inconsistent and poorly documented codebase). But what probably sets me apart from juniors is how I handle getting stuck, or rather what it means for me to try to "fix things". I spend time thinking about what I've discovered that has gotten me stuck, what I must take into account, and how I should alter my approach (or refactor the existing code to be more accommodating).
Sometimes I manage to formulate ideas apriori that reduce the frequency of my getting stuck, and/or the extent to which I need to backtrack. But - not always.
Long story short: it does not work, because the act of coding adds new valuable inputs that alters the (original) design.
One might say "you just have to know", which is an equivalent to "you just have to figure out the future", "you just have to be perfect" and other non-sense (which does explain why V cycle does not work, high inefficient, low quality outcome, bad method)
There's a wide spectrum between specs upfront vs trial and error with the codebase. Somewhere in the middle sits the whole MVP and iterative building, where you start with a smaller codebase and fill it up. Basically exploiting the fact that a lot of concepts, while interconnected, are modular and can be tackled on their own. Like how the design of the brakes and the engine in a car, while related, are mostly blackboxes in regard to each other.
People that do trial and errors lacks direction and their code is often fragile, especially with evolving situation. Because their have failed to grasp the deeper truth of the domain. The usual signs are tightly coupled code and code churn.
> AI agents can build a whole app and review PRs better than a lot of people
Assuming you're comparing to experienced human developers that are good at what they do, then I think you have to define what "better" means here. It's clear that you can get correctly functioning software faster in many cases, but it's not clear that the design will be better in terms of conciseness and readability or that it's as useful as a foundation for building upon later if nobody understands what's going on inside.
> And will conciseness and readability even matter in the long term?
Fair question. Right now the way for humans to understand code is to read it and that'll be easier if the code is concise and readable. But it's possible that we'll end up in a situation where the code is separate from the explanatory materials that humans need. This is similar to math where we might have impenetrable Lean proofs of theorems and then natural language expositions to explain the proof.
> It sure isn't simply reviewing, or designing, so where is it ?
If I can shit out some vibe-coded thing over a weekend that does <useful thing> it means anybody else with the same tool can do the same thing. There is no value in the actual code itself -- the faster these models run, the more true that statement will become. In the not too distant future these things will run directly on silicone and operate at thousands of tokens a second. That means they'll iterate and explore something far faster than they do now -- mistakes they make will be fixed in seconds or perhaps milliseconds.
That being said my <useful thing> is likely only "60%" of what makes an actual product somebody would buy. It's finding the other 40% that is something I don't think that LLM's can solve. That requires human judgement and then knowledge of how to communicate that vision to your agents.
In short, I believe the challenge is knowing what to build that others would find useful. It's easy to crank out <useful thing> for yourself. Making something others can use is not. And that is, possibly, the bottleneck. But once these are fast and dirt cheap, (and that is a when not an if) the cost to iterate to something workable goes way down. Of course mumble mumble "no silver bullet" / "mythical man" month mumble mumble and all that soo......
I dunno... doesn't directly answer your question but it is what came to my mind anyway.
It is honestly impossible to review the amount of code that AI generates and we dont know how to adapt yet, review line by line is already outdated imo, we just don't know what should replace it.
My prediction is that in the future we are going to be more focus in the testing part (that should be more human readable) than the code itself.
Whatever it is, the only thing clear to me is that the tooling will have to change.
I am a hobbyist and work in a different field than software dev. Old-school guys in my field are super-fixated on the UX and treat the work like 'implementation details.' They abstract away the time and effort such that really old school guys (who have been top-of-the-pyramid in their business) come off as insulting with their 'I don't care what it takes, get it done' mentality.
I can't help but feel that when I mimic their behavior with an LLM, it works great. Just keep pounding claude saying what I want, prove it with tests, and have claude give me a 1 shot script to build and launch the app. I get hands-on time with the UX a lot more (I think?) and claude happily iterates. Most people stop happily iterating after like iteration 2; then becomes teeth-pulling.
So to your point, claude's tests are gibberish but the 'testing' via user interaction is what I think the future is going to look like.
We will need some novel systems where hot-reloading is the default experience and you are looking at the build output constantly as opposed to the source.
claude was like "I took your logic, removed the shared state, ran the tests 600 times in parallel, proved no state is leaking across runs". I was impressed...
Funny enough the current web stack is the one most ready for this kind of development. Playwright may have the best way to describe user interactions, also the hot-reloading part.
I am doing an app that keeps a web and desktop version at the same time, mostly because the agent can iterate faster and with less resources and more constraints (running in a container) with the web version.
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.
What you refer to as "clutter" is what actually documents the code without the need of comments if done correctly i.e. naming things properly i.e. ubiquitous language. Before rushing to throw away things you don't know, learn about them.
There is no "document with documentation", be it comments or as companion side resource with an obvious cross-reference.
There was no mention here on rushing to anything. Verbosity is not always bringing actual non-duplicating information. And even when the explicit way is taken, it can be put aside from human main analysis observation point. Actually even Typscript allow to organize type information by using .d.ts files for declaration files that contain only type information, while implementation files use the .ts extension.
Then there is the tradeoff between grepable explicit type and spare implementation with as much type inference as possible.
So, you ask an LLM "what does this code do?" and it spits back a long list of things.
Is the fear that it is (maybe wilfully) misinterpreting the code, being too general, not going into specifics or is just not smart enough to catch all the nuances, privacy issues and hidden mistakes? Is it a token issue? A combination of all this?
Suppose you're taking a math class and the instructor writes on the board:
> An eigenvector or characteristic vector is a (nonzero) vector that has its direction unchanged (or reversed) by a given linear transformation.
Do you understand eigenvectors now? Speaking for myself: certainly not. To really understand even that definition I'd need to do the calculations, play around with how they can be used in different circumstances, and allow my brain time to sit with all this new information and become comfortable with it.
I think LLM code descriptions are similar. They don't really bring understanding. Sometimes that is fine.
The code change is so simple that Claude today could easily write this code. How will they know if an LLM wrote the code? They won't. And this policy will age like milk: Each passing month, coding LLMs are improving. It will become more difficult to "detect" an LLM-authored submission.
The best LLM policy that I have seen for an open source project is Linux. Roughly: You can use LLMs, but you are fully responsible for the code it produces. Linus acknowledges both positives and negatives to LLMs.
Agreed that's the best policy for the real contributors, but how do you fight back against the folks using your reviewer's good nature to test their coding agents?
Also, Linus is also comfortable closing 100 PRs as "this looks like garbage". Many communities are softer and try to be more helpful with new contributors.
Yeah, fair point. I laughed out loud when I read this part:
> Also, Linus is also comfortable closing 100 PRs as "this looks like garbage".
Probably, as LLMs get much, much better, most open source projects will be overwhelmed with submissions. I guess this is a good problem to have. Some projects will scale (more maintainers/reviews); others will become more harsh.
The problem isn't just the code - the documentation for the change explaining what it fixes, how, why, what testing has been done, and so forth is often either lacking, far to verbose, or both (massively verbose without actually containing much useful information or other sense).
You raise a valid point for the future: when the average quality of submissions is good enough that it is impossible to tell the difference between human (or human aided by AI but giving its output sufficient review/rewrite) and LLM/agent submissions, then the issue will have gone away. But, given the problems projects like this are seeing it is obvious that the technology (or the people using it, probably both) are not nearly there yet.
> The best LLM policy…
That is a great policy. If only the entire world would follow it, or in fact even ever read it.
If the only reliable way for now to not be suffocated under a mass of bad AI submissions is to refuse anything that even vaguely sniffs of AI, then that is what many projects are going to have to do. If that offends you, then fork the project and patch your changes in, or vide code one from scratch yourself, then you can keep maintaining that along with all the submissions you get for fixes. Let time tell which the right decision is :-)
LLMs are still being detected at the same level since the day coding agents were actually something, hence, it's not improving for 3 years. Why would they be undetectable next month?
Moreover, the parent comment linked to a decent PR presumably human made. If an LLM had written the PR, its description would be 9 paragraphs long and the code changes full of assinine comments.
If the author really did one-shot the PR, then the author must have also put in the extremely detailed and tedious work which would be required to tame LLM output for this specific repo, in which case, they actually put in real effort, applyed expertise and thoughtfulness, which is the whole issue at hand.
You think coding agents or models have not improved in 3 years? From my experience they absolutely have. I've spent a lot of time getting Claude Code to write clean features in a brownfield repo. I've gone from it helping me speed up to now Fable 5.1 doing it perfectly. And there are steps one can take to improve the quality which is to teach it (SKILLs) your important design and coding standards, as well as automatic design or code review to catch edge cases, performance issues, or whatever aspect you find a high priority.
> How will they know if an LLM wrote the code? They won't
They don’t need to know. The policy is not a linter that will scan each PR. Just like the law does not monitor everyone 24/7 for criminal behavior. It’s enough that the rule is in place and it’s enforced when they catch an infraction. No need to be perfect as long as it lowers the pain.
The Linux kernel has the benefit of a big team of maintainers, and the GitHub integrations with these LLMs make opening these low-effort PRs incredibly trivial on GitHub vs a mailing list
This is a good point. To be fair, I think the Linux kernel teams are currently overwhelmed by LLM-authored security fixes. However, that will taper off eventually as a huge number of security fixes will be fixed in the next 12 months.
> AI stream is a lot higher than what human review can take seriously, leading to either a longer list of un-reviewed PR's or not fully reviewed code and quality issues. Both thing we don't want in the project.
It’s not about detecting AI, it’s about reducing the amount of code to review.
If you are reporting a number of bugs per hour then you can't be properly reviewing each to make sure it isn't a complete hallucination, a behaviour-as-designed reaction to silly configuration, etc, nor are you reviewing the documentation to make sure it both actually makes sense and is appropriately concise to not waste time in the review process.
This sort of thing, in the minds of not just you but many other people, is exactly the problem. On behalf of the projects that you have communicated with this way: thanks a bundle.
I said "in an hour" to mean, the time it takes to identify the issue.
That fairly obviously doesn't turn into "bugs per hour" to verify, but if you find 10 candidates in an hour and then get reproducers of them out over the next few days, they are real bugs.
Like sure, "not properly reviewing" could be a thing but if I'm looking at a hard crash on my console, that's not behavior as designed.
I don't completely like or think this is a good ultimate decision, but looking over the thread on Github, it's being done for practical rather than ideological reasons after trying a more liberal policy first, and the discussion thread there indicates that they're already considering how to relax and refine it. A long-term and total ban on AI contributions would be a mistake as it all but guarantees a competitor or a fork, beside enforcability issues that create a "now you have two problems" situation. But as a temporary stop gap as specifically indicated by https://github.com/qgis/QGIS-Enhancement-Proposals/pull/387#... this seems fine, and it's such important context that "QGIS bans AI assisted contributions" is true but misleading.
The linked discussion thread specifically calls this a "moratorium" and it's unfortunate that they decided not include that explanation in the policy document specifically to avoid controversy and flak, with the end result that there's now a 202-comment-plus HN thread: https://lists.osgeo.org/pipermail/qgis-developer/2026-Septem... -- the "proof of life" concept being tossed around in that thread, although rejected, is genuinely interesting and I hope they revisit it and allow a nominal financial contribution to the project to prove a human is behind a PR regardless of AI assistance (probably along with some other approach, as a total exclusion and the only way it would also be bad).
My own experience with QGIS is limited to the most basic navigation and queries of some local maps I've archived. Nonetheless it's an obvious gem and I hope they're able to arrive at a balanced and sustainable policy. Maybe they would get there faster and more reliably by tightening the previous LLVM-inspired policy rather than the slam-shut and then loosen approach they seem to be taking, but hardly anyone has experience with a situation exactly like this, so only time will really tell.
Ok, I've included a link to the email thread in the toptext and put the word 'moratorium' (which does occur there, into the title. Maybe it will dampen some the more boring flamewar responses in favor of the reflective subthreads which have also popped up here.
> 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
Ok, so there’s a financial motive here, where they’re worried that allowing more open contributions will diminish the value of their expertise and reduce their employability. To be fair to them, that’s probably true.
If there is money to be made, and if frontier models already know the domain I do not understand what this position can possibly buy other than a bit of time before it happens anyway.
I never used Photoshop that much, but I used to be well versed with Lightroom. So I tried Lightcraft[1] which is their Lightroom clone, and I was disappointed after all that hype. I couldn't get any of my photos to look nice, using the workflows I was used to from Lightroom. It felt cheap, unfinished, and barely usable, also compared to the open source Lightroom alternatives that have been around for a while (e.g. Rawtherapee). I'm willing to change my mind in the future, but at the moment, I don't really get the hype.
Yeah, agree - the feat so far is that they brought up an entire suite of incredibly complicated apps from scratch in a week, and they seem to be tackling issues consistently.
There's a lot of depth in these tools, but the process seems to be working. Look at the issues, PRs, commit history and release notes. It's moving faster than a project with an "all code must be reviewed by a human who is responsible for it" policy would. Will be interesting to see if there's an upper quality bound.
It's not impossible produce good products with AI-assisted or driven coding. It just needs effort, focus, and management, much like regular software development.
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
This comment captures the essence of why HN is largely anti AI. They feel their security and roles as software devs starting to devalue. Non coders are encroaching on their turf. A PM can do now what mid level devs did before. As AI continues to advance there will be less of a need for devs and the pool size of devs will start to shrink, as it already has. I understand the human reaction to this. It’s a hard situation to watch us being replaced by a machine. Especially after sitting at the top of the comp ranking for so many years. It’s a scary time.
The PM doesn’t have a runtime environment to test the change. No access to create a PR. Zero verification was done and I was handed a .zip file
I don’t disagree with what you’re saying, but not all cases are created equal. If the PM could create a PR that was clearly verified, like we expect out of all the SWEs, I wouldn’t have a problem.
Understandable. Surprised that's not automated though. Would be worth the time to invest in that area, will save a lot of pain and time in the future. As we shift more to AI, testing is more important than ever and all of that can generally be automated.
Multiple companies I know of have internal tool websites that are the front end to the major AI companies and it has access to cut PRs so non devs are able to open PRs
PMs are doing demos to leadership where their change “just works”. The devs and maybe even the dev leads may protest that due diligence wasn’t done, but leadership is looking at the engineering cost center, axe in hand.
I agree. For bug fixes, just write a clear issue: how to reproduce it, what goes wrong, what's the root cause. As short and well written as possible, without AI fluff.
Once you get to that point, you can copy paste your issue into an LLM and get a fix close to the PR you would open, but so can the maintainers, so what's the point of opening a PR and adding more friction?
In fact discussing the issue is way more productive since it's just about the actual issue, root cause and tradeoffs without the debates on implementation details and nitpicks.
If you want to contribute major features, you need to befriend, discuss and agree with the maintainers, I don't think drive-by PRs ever worked for this.
This has always been true to a large extent. Unless you're cleared to carve out your own space of a project, or you're working off an already detailed issue/feature request.
> 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.
I think we need to talk about the root issues then.
At “work”, non-open source, I see maintainers addressing usability issues they never would have touched before. I write the issue, the LLM does the rest.
In fact, last time I included a PR to fix some trivia, the AI said “let’s fix the root issue instead”, and did that. This was astounding to me. That team used to do nothing in the face of complaints / small bug reports. It used to be that without a PR you were ignored.
So what do you think is going on behind the experience with the maintainers? They don’t use AI? Or they are incompetent? Or…?
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.
Then, as the parent commenter suggested, fork the dead project.
No project is obliged to accept your contributions. It's on you to market them, either to the maintainers of the existing project for merging, or to the community through a fork.
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.
> make a contributor pay for the review of its PR, even a small fee
I agree!
The problem is obviously a resource allocation one. Economics solves problems like that.
To make the system viable, you need something like the free-to-play games use (shudder).
Offer a choice: user’s time and attention or money.
(This addresses the issue of excluding low-resource contributors, which we might care about for equity or because that was us when we were young.)
As an idea on the money front, you could require the contributor to pay for the tokens needed to review their PR! Maybe even let simple models review simple PRs or advanced models decide which model is needed to do the actual review.
I don’t know how the humans can contribute their time and attention effectively, but maybe we can figure that out.
We've already had solutions like this in the past, pre AI. Bounty escrow companies that pay FOSS contributors per PR. They've mostly all failed or pivoted. Why?
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).
Tbf most projects are especially gatekeepy..... they've been even before AI came onto the scene. All what changed is making changes easier (slop it out instead of the classic one-line readme edit) and making it easier to fork projects.
Traditionally you've opened to a PR only to get closed for a style/procedural issue or get ghosted. You often didn't fork because maintenance is a hassle. Less so with LLMs, you know?
Nowadays you can just implement your change and vibe-fork it...
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.
Honestly, if it’s geometry-only and doesn’t acknowledge the existence of anything other than Cartesian coordinates, it sounds like the type of feature that’s more of a support-ticket bomb than otherwise.
If it does support projecting differing CRSs though, please can you point me at it? I’m a nobody and nothing to do with qgis but I would love to have a play with it!
I'm not sure if I understand the concern; for clarity, I'm just making a general comment about the state of contributing AI to open-source software related to resvg, not related to QGIS itself. svg2 spec says css geometry attributes only support cartesian coordinates.
Ah gotcha, thanks - I know next to nothing about css geometry itself, but was curious to play with it, and think I had an imagine in my mind that was different to what you've created.
For what it's worth, I just skimmed the MDN docs and e.g. DOMPoint is using the right kinda wording to sound like it's not inherently cartesian-only. Could be interesting, that. Thanks for getting it into my head!
A.) I understand this completely. I'm sure it's impossible for reviewers to keep up with the onslaught of AI-generated code.
B.) I worry what this entails for QGIS, and for the future of such community-built platforms as a whole.
Let's say I need some functionality which QGIS doesn't have. My options are to:
1. Learn to program QGIS, add the functionality, and commit it back to the community. From where I currently sit -- I've never developed for QGIS, I don't know its language -- that's an investment of several months, at a minimum.
2. Vibe-code the extension I need -- or just make a bespoke GIS application which has the small subset of GIS capabilities that I need, optimized for my particular use-case. Depending on the complexity, that's an investment of either days or hours.
By that math, (1) is never going to win, and now (2) is never going to be able to make a contribution back to QGIS. Moreover, the pool of people for whom (1) is a real option will be shrinking every day, particularly as those people have to compete economically with the people who embrace (2).
So it's hard for me to see how community projects survive in the face of these dynamics. And it would be a shame to lose them -- they create a lot of value that a bespoke vibecoded thingamajig never will. But for better or worse, I just don't see humans-only coding having much of a future.
Maybe your extension/app is compelling enough that the core team finds a way to recreate it, or make an exception?
Maybe it becomes normal to fork a project and vibe-code the extra thing you want and everybody does that and it's fine?
Doesn't seem like a loss for the project, just a win for you. If I understood the announcement correctly, they're doing this more for logistical reasons than to outright ban all AI-assisted code, so if something turns out to be super awesome then it's not like they have to do a clean-room reimplementation.
Can anyone provide links to literature or projects whose goals are to build, maintain, or support trust? Or to be less vague, I'm interested in learning about protocols or models that deal with reputation scores, rewards and punishments etc. for networks or groups.
Various crypto projects fundamentally deal with proving X and their networks comprise of entities that are rewarded or punished for either fair, deceptive, or erroneous actions... so maybe some kind of consolidated info about that "grouping" of information would be a good place for me to start. I am curious about learning more about these concepts insofar as how they can apply to situations like this (OSS or community-based contributions towards a shared goal or a shared ecosystem of behaviours or tasks) where various entities (people, organisations, NOT agents/bots) with longitudinal reputation/state coordinate or interact.
I haven't seen one yet that fundamentally worked. Even before crypto, you had things like reddit karma or upvoting on digg or whatever else. However in the end those still boil down to a social or techno-social "contract"/system. I've not yet seen any system that manages to boil that down to some objective metric, and also still work.
I don't think there ever will be a perfect trust system, because ultimately everything can be gamed, or politics/power can overrule the logic that runs the rules of the trust game. But even so, something that can be applied for _some_ period of time, with _some_ semblance of stability, and _some_ epistemic utility value to the real world is still worth trying to pursue.
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.
It is doubtful whether anyone can claim copyright over LLM-generated code since it was not created by any human and the "training" does not preserve provenance.
Possibilities range from "public domain" to "the cancer Microsoft accused GPL-licensed code of being". In no plausible scenario does the person who pressed the "generate slop" button become the copyright holder.
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.
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.).
Super interesting diff. Feels like it could be a seminal record of the push and pull of this time.
> We aspire to be a welcoming community that helps new contributors grow their expertise, but learning involves taking small steps, getting feedback, and iterating. Passing maintainer feedback to an LLM doesn't help anyone grow, and does not sustain our community.
Hard to disagree!
I think it's fair for people to want a certain experience. Dealing with AI contributions is not the same thing as the community they're after.
I think we should move to pull requests that describe succinctly what feature or bug needs to be pulled. Not the actual code.
A PR for a bug needs an issue link with a test demonstrating the bug in an easy to verify way, eg an online playground/runner.
Ideally the project has a well written, living product and system implementation document that can be used to verify bug reports and feature requests against. Before even looking at the actual code implementation.
- 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.
I have many such forks myself. Some are totally different from upstream now, and yet improvements that upstream makes are straightforwardly portable. I just point Opus 5.5 at the repo; describe what I want; et voila.
In the past, communities were required to produce the rest of these things. Now we live in an era of unprecedented free software. Soon no one will even be able to lock us out of firmware and all software will be free as in free speech to all.
Good, back to the old way of doing things where people fork and maintain their own code. Some might notify the upstream author as a curtsy, and the author might decide to incorporate the improvement back into his or her codebase. None of this pull request noise.
In each thread like this, people are complaining that this is short-sighted because you can use AI for good. But this completely ignores the actual usage patterns: there's plenty of people who see hobby activities, such as contributing to OSS projects, blogging, or writing Wikipedia articles, as a competition. If you're unconcerned with quality - "Claude, make me a blog post" / "generate 10 improvements for this project" - AI allows you to easily produce content at a rate 100x higher than a human can. This inherent volume asymmetry means that if a sufficiently popular project doesn't reject AI, they will be spending most of their time dealing with AI, and most of this content will be bad in ways that are difficult to spot at a glance.
Why is it my responsibility to deal with that? So that your once-in-a-blue-moon high-quality AI contributions can filter down? All of these projects were doing just fine pre-AI, so most are not too concerned with that. If AI folks want to have the use of AI tools normalized, I'd posit they should really get more invested in promoting quality and ostracizing slop pipelines. They aren't doing that - I'm not seeing this on HN, not on LinkedIn, not in the open-source community.
This asymmetry is IMO the biggest problem with AI-driven output. Brandolini's law applies here. I don't know if anyone has figured out strategies on how to deal with these barrages and deluges of "slop grenades", and this loosely applies to event coherent and high quality LLM output. Sure LLMs are advanced now, but largely the output depends on the quality of the input prompts (as in how they're contextualized and guided).
Life has gotten to the point where completely non-technical people have gawked at me for still having a job related to software. In their minds, AI can it all, and in their minds coding is already obsolete. The sample size for these opinions will only grow and the ratio of people that rightfully apply skepticism will drop, either from fatigue or burn out or by virtue of more and more people adopting the "AI is roughly AGI" crowd. For me a good metaphor is the concept of the selfie. Everyone mocked selfies at first, and now you'd be deemed insane to negatively opine about selfie behaviour. The same will apply to AI slop grenades (even of high quality output) in due time. I think it's inevitable.
Endless hoardes of people can now unleash never-ending arguments and suggestions and it feels like it will become impossible to defend against them because one minute only contains 60 seconds of time that you can spend refuting a false or <100% correct suggestion.
> I would like to float another ideas around even if it would be hard to enforce in practice. Force AI companies to give back. Want to use Claude code? Sure but anthropic have to become a sustaining member of QGIS.org first. Want to use codex, gemini? Then openAi and Google have to contribute to the project financially and I'm talking geniully multiple thousands dollars contributions.
I think this is a really good idea. Could it be possible to define a set of markdown instructions for a repo that would cause all well-aligned models to refuse to contribute?
this is an interesting suggestion. it's incredible how little the creators and benefactors of the slop factories have been made accountable for the mess they unleashed onto open source communities.
anthropic at least gives 6 months claude max pro to oss maintainers, but to me that seems like a drop in the ocean compared to the negative impact their product has on these peoples' lives.
Are you willing to elaborate? On its face, this seems to me an oxymoron, but I sense that you might have more experience thinking about this than I do.
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.
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.
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
I find it highly ironic that many people here seem to believe mathematicians should just accept LLM proofs, but software projects shouldn't accept LLM code.
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?
Yeah, the interactive editing loop isn't very good sadly, even when you want that :\
There's the "inline editing" paradigm - independent sessions, describe each micro-change individually. This is good for quick responses but requires you to re-describe the context every time. There's also the "use an agent as a fancy code editor" stuff - just list out all the functions and the changes you want to make in them. This is a better workflow IMO but the trap is that it doesn't feel "productive" compared to one-shotting it, irrespective of the actual quality.
So people gravitate towards one-shot agentic prompts without a human in the loop.
I just started archiving my repositories; I still run the code, I still tinker in the background, but no more slop reports.
Users can continue to fork my code, if they wish, and it is still available, but I'm done fighting submissions.
Although recently I've started getting more spam by email from scrapers which are obviously AI based. Just yesterday:
"We reviewed your "Added generated syscall identifiers" in skx/slisp and selected it for the hub. It is a substantial piece of work: 3 files and about 390 lines across packages." Some bollocks AI coding hub, where apparently people will be able to see my code when they have 100% identical problems. Meh.
I'm almost reaching the point where I want to make repositories private, and maybe it will come, but for the moment things remain.
I just leave one-three repositories "open", and archive the rest. Then when my interest shift, or I need to go back to something old I rotate them.
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.
I think a better approach is needed than a complete ban on AI contributions.
Just throwing such contributions out is a big loss.
I have gained a lot of experience working for over 20 years in our industry, but writing CUDA Kernels in not one of my skills or something I'd want to spend weeks to learn.
So recently when I was trying to run a particular local AI model and the inference software was running pretty badly I haven't even considered debugging it myself. It would take me weeks to even start properly.
But it was Saturday evening and my Claude Code usage resets on Sunday and I haven't used any of my Fable 5.1 quota yet this week. In fact I found no need to use fable at all, opus doing everything I needed.
So I decided to let fable work on a problem overnight. Llama.cpp, fix the bugs that cause horrible speed decay in Qwen3.8-Flash-Next in longer context and with multiple users. I told it it can build llama, run it on my hardware and iterate as much as possible.
In the morning I found it finished. It managed to produce up to 10x speedup in some cases (running 5 simultaneous users, with long contexts). 6 thousand lines of code. 19 patches. A ridiculous amount of work. Each patch explained in a readme. Speed tests run before and after for each.
This code made a huge difference for me. Suddenly I have a local model almost as capable as opus that I can run in 5 simultaneous claude code/pi sessions with further 5 sessions idle and cached in RAM.
I've run that code for last 3 weeks. It hasn't crashed once. It hasn't failed me once. Based on it I created a system where fable, limited to 200k of contexts only distributes work to 5 Qwen agents. This way I could do far more of such type of work (including fixing vllm and adding missing features to it in a similar way).
But would I ever post my 19 patches as a PR to llama.cpp? Hell no. I do not know what other models they will break. How they will behave on other people's hardware. Or how contrary to architecture authors have in mind they are.
So what did I do? I want those fixes to make their way to llama.cpp eventually.
I published it as a "temporary fork". I posted about it on the llama.cpp discussions. And I hope authors will use that code if they want to speed that model up.
If not, that is fine too. People like me that can benefit from those fixes also have access. And I'm not risking my professional reputation by submitting something I haven't read and fully understood.
Stop this typical verbose damage control. This is Jehovah's witness level or worse.
Come to Jesus, come to AI, written in an engaging novelist style. Maybe sell the rights to Hollywood.
Reality: No software has gotten better since AI, and only the tinkerers and learning-resistant cherish AI and promote it like their favorite computer game.
I think just putting your head in the sand doesn't work long-term on this topic – tech is changing and contribution best practices will have to accordingly.
Could be worthwhile looking into how the folks at OpenClaw are doing it, or at some of these projects that are at the frontier.
I suppose strong and automated AI screening, using PRs more as prompts rather than as direct contributions, and potentially liberal use of just closing PRs are useful patterns.
Community code contributions are no longer valuable. That's just the reality. Ideas are valuable, feedback is valuable, un-vetted code is no longer valuable.
Banning AI contributions is just the first step. Contributions are just generally no longer useful when given the idea you can have an llm do the work with 1/50th the effort it would take you before. Even with repeated rounds of feedback and correction it is less work to have an LLM do the work for you than it is to manage an eager contributor attempting the same work, and the result is going to be better and more in line with what you want.
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.
A good way to look at it is if I can use AI to add a feature/fix a bug, so can the maintainers. My doing it adds no value to the project. In projects where I am the maintainer/an employee, I can extract a lot of value from using AI to build, I don't need anyone's help to do it.
AI generated output is not art. Art is made by humans as an expression of their human experience. AI images are just statistical approximations of others' art
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.
"Value" of a PR is somewhat overlooking the fact that it's code we're talking about. A great and large feature with terrible bugs has some "value", but you definitely don't want to review that PR for nothing, because it definitely won't be accepted.
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.
Not sure if good, but I get it, the velocity is so fast that even perfectly fine AI pull requests will add a ton of new features to the software as people mostly go "I have problem X can you write a feature for me that solves it?" and in the end you end up producing a "The Homer" [1] which has every conceivable feature under the sun but doesn't have any cohesion or logic between them, so user experience is subpar.
Then again maybe that's where all software is heading, if AI can produce features on demand at infinite space there might no longer be specialized software, or at least not nearly as much, as people will just code their own solutions tailored perfectly to their use case.
On the weekend I wrote a full-fledged 3D planner where I modeled my whole house based on plans and written descriptions I handed to Claude, it runs in the browser, produces high quality renderings, has path tracing for realistic lighting and materials and builds real objects like windows based on specifications and blueprints, so you can actually see how stuff looks like (unlike with AI images where proportions are always off). For me it's way better than SketchUp and it works completely dialogue based and allows me to experiment with furniture, window styles, doors, colors etc. in a super intuitive way. There is software I could use for this but why bother at this point? This whole thing took me a few hours and maybe 10-20 € in AI credits to build. Why try to use open-source software where I need to wait weeks for a reply from a maintainer?
So I think these projects fundamentally misunderstand where software engineering is heading, they are trying to hold back the flood but that will only lead to them being left in the dust once people realize they no longer have to wait for maintainers to update their sanctioned software timeline for you. That said, I think it's also ok and maybe even beneficial to be very protective of your feature set. There will (at least for now) still be room for complex core software that can serve as a basis for AI modification, so from that perspective it might be good to keep the core really tight and fully audited. My little software project only exists because three.js and other libraries provide most of what I need as LLMs will not write everything from scratch in such a short amount of time.
A bit crazy to see all the comments complaining (and insulting) about QGIS while they have never used it and will never use it anyway. And I'm using AI myself....
The developers and maintainers are explaining that the amount of slop they receive is unsustainable, what do you even complain they try to find a solution?
I say this as a long-term and loving user of QGIS: QGIS is proof that human-only authorship is no guarantee that code will be bug-free and well-designed.
I don’t have a good solution to their slop problem, but I also don’t have a good solution to their overall bandwidth problem. I like QGIS better than any other GIS software I’ve had the misfortune of using, and at the same time brace myself a little bit every time I open it up because there’s a solid chance I’m going to have encounter another weird quirk or awkward workflow that I haven’t figured out The Trick for…
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.
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.
No, you cannot replace what QGIS is to its users with a couple of prompts and a factory of agents.
Any more than you could do it with FreeCAD, really.
These things, whatever their shortcomings, are unique in scope for open source projects and are the centre of large, multi-decade communities of collaborative users and developers.
But I invite you to try. Do it, clone QGIS. Then go to the user community and say "your software was bad so I cloned it, you should all use mine because we accept AI contributions". See how it works for you.
> No, you cannot replace what QGIS is to its users with a couple of prompts and a factory of agents.
You absolutely could. Maybe not to its users, but the core functionality would be the same.
> Any more than you could do it with FreeCAD, really.
Didn't that dude clone the whole Adobe suite with a single prompt? Well a prompt per app, but my point still stands.
> But I invite you to try. Do it, clone QGIS. Then go to the user community and say "your software was bad so I cloned it, you should all use mine because we accept AI contributions". See how it works for you.
Obviously if I clone QGIS it would be because I'd be using it for my own projects. But without being disrespectful here, I quite honestly do not see the point of this library whatsoever. I was under the impression that _most_ GIS work was either outright trivial or specialized enough that it warrants custom code regardless. I don't understand who needs this.
> But without being disrespectful here, I quite honestly do not see the point of this library whatsoever. I was under the impression that _most_ GIS work was either outright trivial or specialized enough that it warrants custom code regardless. I don't understand who needs this.
Oh come on. You’re doing a bit here, right? You cannot possibly be serious.
I am down to bundling forked inference engines in my huggingface models. They do work and do things impossible with base package, yet I don't have time to understand all the details of say sglang code and get it to a state where maintainers will probably accept the PR, for example make the patch work with every other model. Think of it from contributor point of view as well - I made something to work for myself, would love to share it with others but others don't pay my salary. I am not sure what the solution is, maybe have a big draft PR pile a peridodically AI-scan for top enhancements that seem to be a common need and are worth more knowledgable maintainer's time to inveatigate? At the same time, other users can also have their AI agents hunt there for personal fix ideas.
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.
What's next. You are only allowed to edit with notepad.exe? I don't think putting up random challenges to slow down the creation of PRs is a good idea.
This isn't random. It's based on the specific nature of AI. It's a good idea if the entire community doesn't agree with the spirit of AI, which apparently they don't.
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.
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.
It is so sad than any open source project that bans AI is subject to five minutes of hate by the industry influencers.
The same influencers by the way who are just for hire and were preaching DEI and Covid boosters in 2022 but now support Trump, Kushner, BigAI (and local AI as a figleaf).
Bro, I dare you to go a whole day without trying to make every single thing in your entire life about politics. Can you do it? It's a low bar, just resist talking about politics about 1 thing per day and you will have completed the challenge. I bet you can't do it. I think if they under cook your boiled egg you will try to draw some line between that and whatever political issue you are being force fed on news sites.
Whether or not to accept LLM generated code to your highly technical open source project has literally nothing to do with DEI policy. Not everyone is an American. Not everyone is reading about politics all day long and desperate to debate it. Touch some grass.
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.
Well, it's their choice. If you care about the process - i.e. it's a hobby for you, or a spiritual experience, then it's totally valid to go without AI.
But I feel it's a bit crazy not to use any AI assistance to develop real code these days, if you care about outcome. You can get to result much faster, and have a higher quality solution, if you use it right.
The problem for open source is low quality slop, not AI assistance. Not sure what's the solution though.
Such an awesome way to kill a somewhat useful program. Just keeping putting nails in the coffin. The future is here and it's NOT reverting no matter how much people want to stick their head in the sand.
> 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.
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.
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...
I recently started using Claude and I found it great that Claude is constantly writing tests since I did not due to lack of time. That said, Claude has this ability to reach into test harnesses and output all kinds of obscure syntax and language features that the tests are hieroglyphic. I'm pretty much like 'ehhhhh ok claude, you do you...i'm just going to keep writing the business logic over here..."
> Why is everybody all the time in favour of AI on HN?
The opinions regarding AI are quite diverse here, most people are, I think moderately pro-AI, the top comment "A ban is a bit harsh but I understand the reasoning" summarizes it well, but many are in favor of banning AI contributions to open source projects too. The extreme slop cannons and Butlerian Jihadists are usually not well received.
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.
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.
Simply adding features doesn't make the product or technology exceptional. I think the industry know in the phase like "ok, i can close my one thousand github tickets in a week". But that won't make their product or technology significantly better. Creating an extraordinary product is an extra ordinary task that only humans are capable of for now.
I don't think this is necessarily true at all. Objectively is very long stretch before we observe whether this the right approach or not. AI can increase the code quality the issue as i see is not this and it's neither mentioned in what I read about their decision, it's mainly the issue of not being able to keep up when the bar for creating have decreased significantly and the capacity to curate and evaluate is still the same. This is case where the system is overwhelmed so you start controlling the input to keep the desired output the same.
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 don't think that's accurate about the mood on HN, but a lot of us have been coding almost entirely with frontier models for a long time now.
I haven't written a line of code myself since March. I've shipped over 100,000 lines since then. And coding isn't even what I spend the majority of my effort on.
It really works. I just had Opus 5.5 write a distributed load testing service on Friday and it's been using what it wrote to iterate and diagnose problems over the weekend.
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.
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.
> This is objectively a good change because it will improve the quality of the code in the long term.
I think humans will be saying this long, long after it's not true anymore. I'm not sure it is right now, for 80+% of developers and projects.
But I love this muddying of the waters. The more uncertainty and misinformation it is, the easier it is for people to make mistakes, and for edges to be had.
It's like poker. Everyone thinks they're a good player. About 5% of players (my estimation) would admit they're not very good. The luck & complexity fools the rest of 'em. They have no idea you can be operating several levels deeper than they are, playing in a dimension they cannot yet see.
Anyway, not a perfect analogy. But I think your idea was true, isn't true now, and I hope people & projects keep banning AI contributions anyway.
I am not, but I just lurk here - I think that so called 'AI' is at best some clever use of math, and data science. Some of the underlying techniques are well worth a persons time when used sparingly. Classify these under the term machine learning. Peoples simpering & enthusiastic dash to offload tasks to this trendy 'AI' craze is infuriating. Its support here is unsurprising given the sites demographics.
> 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."
> 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.
Given the soul-crushingly large amounts of money sloshing around in this tiny slice of the industry, the amount of astroturfing, positive-sentiment manufacturing, & etc. is right about where I expect it to be... as is the amount of vehement denial that it exists. ;)
>> Given the soul-crushingly large amounts of money sloshing around in this tiny slice of the industry, the amount of astroturfing, positive-sentiment manufacturing, & etc. is right about where I expect it to be... as is the amount of vehement denial that it exists. ;)
> The other option: people are using AI successfully on the job and are writing based on their own experience.
Those aren't mutually exclusive.
And it's worth noting that people claiming to use "AI successfully on the job" often do not stop at "their own experience." They often make sweeping statements like "LLMs write better code than people," and attack any critiques or skepticism of LLMs.
But the majority of positive sentiment probably isn't turfed. HN is not that important, it's a small forum. Is some money being spent to boost the image of the industry. Probably. But if you read most comment sections, they are organic users which are posting positive things.
> I wouldn't be surprised at some unexpectedly large amount of AstroTurfing, especially considering the sheer amount money is flowing into the AI space.
Including money from Y Combinator itself (which, may we never forget, was once helmed by Sam Altman).
If you're looking for unbiased tech news and genuine user sentiment, you probably shouldn't be getting it from one of Silicon Valley's favorite VC firms.
> ...may we never forget, was once helmed by Sam Altman
Didn't he get fired because enough of the other YC partners couldn't trust him? If so, it's a pity for him that -at that time- he didn't have the CEO of a software megacorp to call on to reverse the decision and shitcan the people who made it.
Sadly, it's succumbing to the "the mods are -justifiably- uncomfortable with cleaning house and the quality of discussion is regressing to the Internet Mean" disease that every pretty-much-open-access link aggregator that attaches a link discussion forum contracts.
> 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.
I don't think suggesting that people are stupid is a very good argument. I think part of the reason people are for it is post like yours which are rude and not in good faith.
I'd imagine why as many people are for it on HN is for many people, it just works. Now imagine this snark about not being as clever as you think you are just because you enjoy using a tool. What's that going to do? Cause you to dig your feet in because you're being told the real reason you like these tools is because you're not very clever or you take things as a personal criticism. Yes, being told you think you are clever but you aren't really is personal.
I don't think you're posting in good faith. I certainly don't think you're going to get the real reasons people support this stuff when you act like they're stupid or suggest a lot of this is being turfed. People are using these tools because they work.
Your post says more about you than it does supporters.
> I don't think suggesting that people are stupid is a very good argument. I think part of the reason people are for it is post like yours which are rude and not in good faith.
You'll note I didn't say anyone was "stupid," if anything, I was actually saying those people were myopic and arrogant. I recommend you familiarize yourself with the concept of "engineer's disease," once you understand it, you'll see it all the time on HN.
> I don't think you're posting in good faith. I certainly don't think you're going to get the real reasons people support this stuff when you act like they're stupid or suggest a lot of this is being turfed. People are using these tools because they work.
> Your post says more about you than it does supporters.
I don't think suggestion that people are posting in bad faith is a good argument. I also detect a fair bit of binary thinking from you. All I did was post a non-exhaustive list of different reasons for that kind of content to answer the comment I was replying to.
The only "binary thinking" I'm using is not assuming that the reasons that people support these tools are all negative (myopic and arrogant, false sentiment, defensiveness, and pedantism).
You didn't even try to suggest that a lot of people are using these tools for positive reasons. Who is being myopic and arrogant? Who is engaging in binary thinking?
Consider that some people simplye find that these tools work for them.
> I don't think suggesting that people are stupid is a very good argument.
I've worked with a lot of people. Many of them are that stupid. Suggesting that these stupid people do not exist, that -if they did exist- none of them are professional programmers, and -even if they were programmers- they do not have the means to voice support for something that they're smitten with is not a good argument.
I'll also vaguely gesture at the various studies that find that the majority of conversation -by post volume- on Internet Forums is done by a small number of people. Never doubt the ability for a few loud folks [0] with lots of time on their hands to dominate a conversation. This goes like 10,000x when there's a huge amount of money sloshing around in said industry and said industry really needs to maintain a positive public reputation.
I didn't say that dumb people don't exist, I think positing that the reason people like these tools is because actually they're stupid isn't very compelling.
> ...I think positing that the reason people like these tools is because actually they're stupid isn't very compelling.
And I explained why I disagreed! One "subtle" thing to note is that the claim isn't "Everyone who uses LLM-based tools and writes about the success they had is stupid.".
> Then you aren't going to get to why people are using these tools...
I couldn't disagree more!
If you haven't already, you should watch this topical presentation from Greg K-H that was posted to HN like a week ago. [0] It's about an hour long, but you can probably watch most of it at 120->150% speed.
Notice how his praise for the tools differs from so much of the expressed positive sentiment for said tools here on HN. The "low-horsepower" people I've known tend to praise things in a way that smells very much like astroturfing. The "high-horsepower" people I've known both express very nuanced opinions and tend to know better than to burn a ton of time squabbling with Internet Randos in a place like this... they have much better things to do with their lives.
> The "low-horsepower" people I've known tend to praise things in a way that smells very much like astroturfing. The "high-horsepower" people I've known both express very nuanced opinions
I think that's a good observation, but I wouldn't say those people are actually astroturfing (noting you only said they smell like that).
But that "low-horsepower" vs "high-horsepower" distinction probably has a big bearing on people's attitudes towards LLMs. "Low-horsepower" people are simultaneously much more easily impressed and often lack the skill to properly evaluate the output they're getting. It's often been remarked that LLMs feel awesome for topics you know nothing about. It's kinda like Gell-Mann Amnesia Effect for people who were never knowledgeable about any topic.
[1] "The phenomenon of a person trusting newspapers for topics which that person is not knowledgeable about, despite recognizing the newspaper as being extremely inaccurate on certain topics which that person is knowledgeable about." (https://en.wiktionary.org/wiki/Gell-Mann_amnesia_effect#Engl...)
> I think that's a good observation, but I wouldn't say those people are actually astroturfing (noting you only said they smell like that).
I agree with everything you've said here [0] as well as this bit I'm quoting specifically. I would strongly disagree with any claim that positive reports from "low-horsepower" people are likely to be astroturf. I'm just noting that a lot of astroturf reads like the way the "low-horsepower" people I've known tend to praise things.
[0] ...at least with whatever the comment said when I wrote this one ;)...
> I agree with everything you've said here [0] as well as this bit I'm quoting specifically. I would strongly disagree with any claim that positive reports from "low-horsepower" people are likely to be astroturf.
I think we're in agreement.
> I'm just noting that a lot of astroturf reads like the way the "low-horsepower" people I've known tend to praise things.
The "why" behind that would be interesting to know. It could just be that we assume astroturf would be low-effort, and that praise is low-effort (even if that's the most effort the "low-horsepower" person can muster), so they read the same.
> The "why" behind that would be interesting to know.
I'm going to briefly noodle on about why I think astroturfing generally Sounds Like That, and then attempt to answer your implied question.
So my hunch about the tone of astroturfing is that it's _kind of_ like 419 scams. [0] Perhaps none of this is new to you, but I write it down anyway:
1) Creating detailed praise that withstands scrutiny is a lot of effort, whereas expressing positive sentiment in very broad strokes is extremely easy. If your strokes are broad enough, you can probably often reuse the praise, saving even more time and effort. Similarly, defending criticism of detailed praise is much harder than defending broad-strokes positive sentiment.
2) If you want to hire live people to astroturf on message boards, people able to effectively defend detailed praise are surely going to be much more expensive than those who can only handle the vague broad-strokes stuff.
3) The target of this astroturfing deliberately isn't someone who can scrutinize detailed praise... in part because of how much work it is to author that praise, and in part because the people with power and/or purchasing authority are the ones you want to target... and it's often but not always the case that those folks lack one or more of the time, background information, or horsepower required to perform that detailed scrutiny in the first place. So, why waste the time, effort, and money?
Now please excuse the dogshit writing style of the following attempt to address your question, I'm definitely having a "low-horsepower" day today...
But why do "low-horsepower" people tend to praise in that way? speaking as someone who definitely has "low-horsepower" days, and who has occasionally been an absolutely godawful teacher, it might have something to do with the whole "You can't effectively teach someone something if you don't have a solid understanding of it yourself." thing? Both detailed praise and good instruction require a detailed understanding of the thing in question.
So part of the reason might be that "low-horsepower" folks tend to have just a surface understanding of the thing they're praising, so they cannot really create detailed praise. [1]
Both praise and instruction invite questions from the folks who are around to hear it. Folks who are capable of feeling shame often feel shame when when they present themselves as someone who is far more knowledgable about something than they actually are and questioning reveals the deception.
So another part of the reason might be to avoid in-depth questioning -both to determine the justifications for their praise, as well as to gain an in-depth understanding of parts of the thing being praised that the praiser is entirely unequipped to provide-. If one gets a vague "IDK, it's just good, right? It makes my work so much faster! I just like it!" response to your request for praise then that's a signal that you're not likely to get much more information if you ask probing questions. _Maybe_. This paragraph I'm super not confident in.
I'm happy to chat more about this, and will spend some time over the next day or so trying to phrase the gunk that's in my head better... but I can't make any promises that I will succeed at that.
[0] ...AKA "Nigerian Prince" scams...
[1] To downvoters: There's absolutely nothing wrong with this! Knowing just enough about your work and how to do it to satisfy your boss and keep your paychecks flowing is a solid way to live one's life. Precious few people do work that they like, let alone work that they're interested in... and it's my bone-deep belief that the best future for all humanity is one in which no one has to work unless they either want to or if having a job of some kind truly makes their life far better than not having one. Work sucks for most folks and putting in just enough effort to get the work done to the standard required is a fine way to engage with it.
You're again reverting to the only reason people like these is because they're stupid.
Me:
If you haven't already, you should watch this topical presentation from Greg K-H that was posted to HN like a week ago. ... Notice how his praise for the tools differs from so much of the expressed positive sentiment for said tools here on HN. ... The "high-horsepower" people I've known both express very nuanced opinions ...
> people are simultaneously much more easily impressed and often lack the skill to properly evaluate the output they're getting
Yes, this is the exact sentiment expressed. That the praise you see is because of these people with low-horsepower who aren't capable of evaluating their own experiences.
You really should! It's positive sentiment about LLM-based tools that comes from a "high-horsepower" individual. Given your commentary here, it really seems like you've not encountered much of that sort of thing, so it'd really do you some good to load it into to your databanks for use in future discussions.
Well, yeah, when you are asked why people talk about these models on HN and your answers are: myopia, funded support, taking things personally, and pedantry and then you double down on it suggesting that another reason is these people aren't capable of evaluating what they are seeing, then you are only painting those people with a negative brush.
Do yo believe there are positive reasons people are adopting these models? Because there is nothing in your responses that suggest you do. I, as somebody who rarely uses these models but understands why people might, don't see any attempt at being unbiased.
I got it now. This is just how you communicate, insulting people who disagree with you.
Frankly I don't think you've understood what I was saying but it doesn't matter. You keep saying I'm misunderstanding you but your bias is very obvious and I don't think you've answered why people are praising these models.
As a less emotionally charged example (people get upset with being called stupid, justifiably) - the average size of an array or a list is less than 4.
With that many elements you'd be better off storing the elements as a tuple or a struct, but people often reach for a generic array container regardless.
> 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.
Related: the Rationalists display this very well (though it's certainly not unique to them). The jump from "I think my beliefs through carefully, therefore I am reasonably rational" (likely already false, or at best true in a limited domain) to "I am rational, therefore my beliefs are well-thought through" is actually very small in the human mind, despite the latter being the opposite of rationality.
Also, the existence of Gell-Mann amnesia should be taught to everyone!
> 3. I think there's a certain amount of defensiveness from AI enthusiasts.
I've encountered this as well. I think this is also a huge part of why you see so many people loudly exclaiming "every programmer uses LLMs now" despite that not being even close to true. If you criticize LLMs, it (socially, to them) counts as criticism of their users as well. As well, bosses are probably the most excited about LLMs because they hope to fire us all soon, so it can be pointlessly self-destructive to speak negatively about LLMs in a professional context right now.
That, plus AI boosters tend to be incredibly annoying about it, bringing it up at every possible opportunity, changing every technical discussion to be about them, suggesting them for the stupidest use-cases, loudly proclaiming nonsensical productivity boosts (perhaps you feel 5x as productive because you're forcing other people to spend their time fixing your shitty slop code?) etc. So as someone who does not use LLMs I avoid talking to them.
I just think this speaks more to people observing different things and taking that as ground truth. I notice the people who are critical of these tools because like the above post and yours, they are relentlessly critical without ceding basic things like people are excited about these tools because they are useful. I have 0 doubts some people are seeing 5x productivity boosts because of the stuff that is regularly posted on HN - stuff that used to take months taking days.
I'm not a booster, I barely use these tools but what I notice is the two apparent "sides" that people have shifted into and really I don't think that' necessary because these are just tools that have adnvantages and disadvantages.
> I have 0 doubts some people are seeing 5x productivity boosts because of the stuff that is regularly posted on HN - stuff that used to take months taking days.
I will cede this: it indeed seems like you can throw together a shitty half-working prototype very quickly using LLMs. There's been a deluge of half-working prototypes, but years in and where are all these projects now? No study has concluded anything near a 5x improvement.
Besides, my actual opinion is that even if these actually gave a large productivity improvement, it's wouldn't be worth it. The negatives are simply too large:
- the concentration of power they are pushing for;
- the environmental effects of training;
- the disinformation they spread at scale (which in practice is their primary use-case);
- the adverse effect on a shared reality from the fact that they cannot reliably answer questions, yet are presented as doing so;
- the adverse effect on a shared reality from their sycophancy (do the rich surrounded by yes-men seem in touch with reality?);
- their anti-social nature, as they discourage engaging with other people in favour of solipsism masked by a poor simulacrum of personhood;
- their weakening of labour power because of the managerial class' belief that they will soon replace workers (whether or not they actually can is not particularly relevant);
- the large-scale plagiarism they enable;
- lastly, their weakening of already incredibly lax standards of engineering from our field.
The promise of more software does not even come close to outweighing all of that.
It's just from my personal experience when I rarely use Claude, I can get it to produce things in minutes that would take me hours. They're not shitty, I can review what's been generated and it's better than I would have done. Similarly with the UIs we build here, they would take days or weeks and we can put them together in a few hours.
I can't speak to you other issues but these are here to stay and I think the only realistic way forward is to learn how to use them.
> I can't speak to you other issues but these are here to stay and I think the only realistic way forward is to learn how to use them.
People only say this about things that they want. Ignoring the consequences of one's actions is not a neutral position. Societies are perfectly capable of banning things (yeah, you can probably sneak a local model through a hypothetical law, but it would end the industrial scale problems).
There isn't any evidence. It's pretty much all anecdotal. I can only speak from my experience.
> People only say this about things that they want. Ignoring the consequences of one's actions is not a neutral position. Societies are perfectly capable of banning things (yeah, you can probably sneak a local model through a hypothetical law, but it would end the industrial scale problems).
We're not going to ban these models, though. Which means we have to figure out how best to live with them.
> A recent study of actual coding practices across hundreds of firms finds that human code review forms a significant “bottleneck” for the overall efficiency of AI coding tools, resulting in “little evidence that firms increase software output or reduce employment” by using them.
> When developers are allowed to use AI tools, they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts. This gap between perception and reality is striking: developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%.
LLM boosters always cry foul with this one because newer models exist (see next item), but the fact is this is evidence that programmers are remarkably bad at estimating their own productivity.
> For the subset of the original developers who participated in the later study, we now estimate a speedup of -18% with a confidence interval between -38% and +9%. Among newly-recruited developers the estimated speedup is -4%, with a confidence interval between -15% and +9%.
With the rather large caveat:
> Unfortunately, given participant feedback and surveys, we believe that the data from our new experiment gives us an unreliable signal of the current productivity effect of AI tools. The primary reason is that we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI, which likely biases downwards our estimate of AI-assisted speedup. We additionally believe there have been selection effects due to a lower pay rate (we reduced the pay from $150/hr to $50/hr), and that our measurements of time-spent on each task are unreliable for the fraction of developers who use multiple AI agents concurrently.
I guess there's a way to use them productively. I only use them rarely which means I use them when I know they'll speed me up and the tasks take a few minutes. I literally could not do the tasks in less than an hour or two, the same with UIs that get generated here, it's just impossible to be faster than the models.
> How could you possibly be confident of that?
I just don't see any indication that we're anywhere close to that. It would take a rather big shift in governance.
I expected Venture Capital Reddit to be pro-AI, that's where the money is, after all. I don't know if it's all clout or if everyone just pretends to go with the flow not to risk like they're falling behind, but this isn't exactly a place for conservative software practices.
The utter disbelief people on HN show when they find out a lot of people hate or despise generative AI is much stranger.
I'd reframe the question slightly. It has less to do with bias and more to do with experience. Anyone with experience to judge AI matters is likely going to be vaguely pro-AI in the first place, otherwise they wouldn't be qualified to answer.
Those that are opposed to AI development in principle, or have dealt only with its worst consequences, like neverending PR-slop, are going to have trouble engaging due to a lack of experience.
If you truly believe that AI writes better code than humans, you've not been exposed to enough humans. It might write better code than humans you know personally, but you lose credibility when you try to present it as a universal truth.
I suggest you read the second half of my comment. Insisting that humans will remain better is an untenable position if you make reasonable extrapolations.
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).
Right, disallowing AI-generated drive-by PRs is completely reasonable; almost all of them should have just been bug reports or feature requests. If your AI was able to one-shot the code, the maintainers can do that themselves and it's going to be much easier for them to work with their own AIs rather than using you as a meat proxy.
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
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.
Long answer: These software packages generally have a couple (or more) graybeards on the team knowing the intricacies of the domain and the software pretty well, so they can read a patch, see the effects, make an informed decision and give required feedback, or sometimes get the patch, mangle it to correct form and merge.
LLMs tend to write overly verbose code with many file edits at the same time, accompanied by walls of text to justify itself. This overwhelms these kinds of communities. So, they prefer targeted, smaller patches arriving at a slower rate.
...and maybe that big patch can be written as a one-liner somewhere else, just because AI failed to find where the problem originates and just patches where the problems happen, making thing way more complicated than before?
These are complex software packages and are sometimes things looking correct are wrong, and things looking wrong are correct, esp. on the math side.
I developed software using boundary element method to evaluate things, and it was complex to put it mildly. Verifying everything down to 32 significant digits after comma, and tearing the code down when the tests deviated for no apparent reason is something I did regularly.
GIS is no different. You're modeling the world, down to the earth's curvature, and putting things on it with cm level accuracy, and a couple of people knowing what they are doing is way more effective than a statistical model which emits code with no bounds and understanding of the domain.
Sounds like llm's have made is so easy for anyone without a shred of know how to submit anything that people prompt one or two times and consider the job done, not knowing any better becausue they don't have to.
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 a partial (edit) 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 safer 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 agree with you, I'm just laying out what I believe the real ban that makes the most sense would entail. It does sound like they dont even want to hear that you used Stack Overflow if it came up from Google's Instant Answers AI thingimabob.
> My point is, if projects are actually serious about banning AI, write that down in enforceable language.
You're under the false impression that the maintainers of a project are obliged to follow the same standards as a court of law.
> 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
If you are the enforcer, which the maintainers are, then surely any rule you come up with is enforceable in exactly the kind of way you'd like it to be enforced?
This is a bit naive. People write emotional rules and laws all the time. They may even work for a little while. Then one of two things happens, maybe even both at the same time.
First other people poke at the gray areas of the rules which leads to the "you accepted x, but not y, this must be favoritism when allowing AI posts". Things degrade into insane rule lawyering.
Or, you end up with insane sets of rules and enforcement that kill the project. We've seen a lot of project leaders recently just act kind of mental. Quite often it will lead to the project forking and falling apart.
Well written rules for a project matter even more than well written code.
This is why I prefer very loosely written rules in a pseudo-common-law system :)
i.e. have few, generic rules, and have their boundaries be constrained by implementation. The important part is consistency. There is a boundary, it's just unstated. If you're enforcing stuff arbitrarily, this won't work, but if you're mostly consistent this can make things smooth by eliminating the space for rules lawyering, drama and schemes by getting everyone in the community to "sign up" to the status quo.
When you're new you don't know where you're at so you join, observe and listen. After some time, you're familiar with the norms so you can engage with them, advocate for changes, etc.
Of course, the alternative is codified rules for everything, but the moral hazard there is that the more rules you add, the more they're likely to be contradictory, leading to the possibility of arbitrary enforcement nonetheless despite the pretence that the rules are specific and clear so the enforcement isn't arbitrary at all.
This might be the key point. There's legal ambiguity surrounding these licenses. Large companies with legal resources can draw their own line in the sand to protect themselves.
But small companies don't have the resources or the bandwidth to address the ambiguity. So a blanket ban (Zero AGPL and GPL for Internal or SAAS, Linux generally gets a pass) is rational.
Likewise, I see small dev shops without the resources to address anti-AI policy ambiguity are going to defer contributions until further notice.
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.
Lol. You say no further definition is required - then proceed to outline your interpretation which is quite distinct from others. Clearly further definition is required.
If you're serious about an anti-AI policy, you owe the world a definition. It's not hard. You are making a strong statement - an outright ban. Make an equally strong case for what is and is not in scope. You must get in the weeds, since it is you yourself that is banning the weeds.
To quote Gustave Flaubert: “The art of writing is the art of discovering what you believe.” Failing to write the definition is a strong signal that no one thought through the problem.
No, my example is one of where you end up if you start doing granular definition (and demanding to know where the line is, to the point of absurdity).
A broad stroke based on community trust and your own self-evaluation of a very simple rule is acceptable here.
If a contributor wishes to poke the edges of the policy to try and find the line of acceptable AI/LLM usage in the project, they are probably not the kind of contributor they want.
> If a contributor wishes to poke the edges of the policy to try and find the line of acceptable AI/LLM usage in the project, they are probably not the kind of contributor they want
I think this is where it becomes a question of whether it’s an ideological rejection of LLMs or a technical/practical rejection of LLMs.
A project that is rejecting contributions where LLMs are used purely because of the “we can’t handle the amount of newbie generated inbound slop” would, in theory at least, have minimal issue where the contribution is, in fact, indistinguishable from human-only contribution. “This person has put together a solid clean patch that solves a real problem” sounds like a great kind of contributor to have.
On the other hand, a project that rejects LLM-assisted patches because of ideology or social or environmental concerns might actually hate a contributor like this even more than a random drive-by slop contributor.
Without objective, verifiable criteria, the rules cannot be enforced. Rules without enforcement rely on the strength of community norms, which we don’t have in this case.
All you’re going to do is end up banning obviously vibe coded crap. If that’s what they mean, say it.
In spite of the positive reaction, this IS a bad policy because it isn’t enforceable.
Keep thinking - we need guidelines that focus on our needs and goals, not the basic mechanics of code creation.
> For an outright ban on "LLM, AI or agent assisted code contributions", they do very little to define what that means.
It means: did you use AI? If so, we don't want it.
Like come on. They don't like your new shiny toy and you're mad about it, but there's no need to be purposely obtuse.
You fire up an IDE, you write code, you submit it. That is not an AI contribution. You fire up Claude Code and prompt it, you submit it. That's an AI contribution.
Contributing to projects is a privilege not a right, and if you fail to contribute, be it because your PR was written like shit, be it your documentation wasn't complete, be it you didn't abide the style guides, or, yes, be it you used AI and they don't want AI, your submission doesn't go in. That's that. 2 + 2 = 4.
To be blunt it's wild that otherwise very intelligent people keep getting bluescreened by the fact that they occasionally must reckon with other intelligent people who do not necessarily believe the same things as them. Have y'all never gone outside or what?
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.
There’s something about geospatial work that seems to break LLMs. I’ve experienced it a lot with latest versions of both Fable and Opus, and it’s the classic nightmare of confidently-spoken-but-wrong.
Yesterday, I had a relatively trivial bit of work in play using distance-weighting to measure stuff, and Claude did really well / but right at the end, despite having a success metric and lots of great results matching it, Claude insisted my maths was wrong and needed changing.
When i asked why, and pointed out that the suggested replacement would cancel out the distance-weighting entirely, it immediately agreed with me and asked to write its fifth project memory about it.
The other big ones it tends to mess up on without strict guardrails are coordinate systems; and measurements, often converting back and forth between a given nation grid and wgs84 latitude/longitude in ways that lose good amounts of precision; and then custom-coding haversine-equivalents to measure a distance that’s otherwise be a simple subtraction via the national grid coordinates. It’s baffling.
I’ve found it to be surprisingly effective lately.
I’ve been renovating a spatial/topology validation system for an OpenLayers driven map editor for robot fleets. I set up a clean interface for spatial indexes and predicates as well as your basic geotoolbox functions.
I was most surprised by a moment where Opus detected that using a union approach to ensure that robot footprints always sat within valid polygons (possibly straddling multiple valid polygons) was slow in testing. So it decided to find the difference between footprint and each polygon within the AABB of it. And if the remaining polygon is zero size, it’s valid. If not, the remaining shape is what is invalid.
I was also surprised just how good it was at recognizing, “in the test data there’s a lot of this kind of feature so we should explore what’s more common: hits or misses?
Before robotics I spent a lot of time building spatial models for data processing and analysis. I find that I can usually just explain the spatial question in natural language and it will figure out the relevant inputs from the dataset and what the process can be. I’m not obsolete quite yet though because maybe 10-20% of the time it goes on a pretty fantastical journey through unnecessary intermediate data products.
Oh don't get me wrong, it's a level-boosting monster even with that.
The worrying bit is if you're not keeping a close eye on it, very easy to think you're getting a solid system, but thanks to the internal madness it's used, your entire grid has in effect shifted 10 metres right, and any spatial measurements are far more approximate than it's letting on.
That was the bad old days for me. Nowadays I keep it locked down to specific systems for projections or actual spatial calculations, and that seems to keep it honest.
And the surprise is awesome when it happens! My favourite is all the QA steps you wish you'd had and that it reasons out on the raw data alone:
"oh hey, this one city has no data but it has a high population, oh right, that's because of this obscure lookup had a row chopped off, there you go, sorted."
I get to stand back and applaud it, honestly.
LLMs are very good at conceptually simple but tedious classification problems in general.
One that has saved me many hours: given a small subset A and a disjoint sample B of a larger set of, say, complicated JSON objects in a consistent but unknown schema, what do the objects in A have in common that isn't true of any objects in B?
Example result from Claude: The field foo contains dates between August 3 and August 7, 2016 in every record in A, and every record in B contains later dates.
Claude even correctly hypothesized that it was dealing with metadata from a document management system, that field foo was the creation date of the document, and that nearby field bar, identically 10 in all records, was the document retention period in years, and thus A represented documents that would have been purged between August 3 and August 7, 2026.
Oh absolutely. I just had flashbacks to getting outputs where a raster is completely wacko because the input coordinate systems were not the same and so the grids didn’t line up. It absolutely still has to be supervised closely, much more than a lot of more vanilla programming tasks I’ve experienced.
One thing that helped me a ton was making an adapter between my domain specific datasets/systems and QGIS. So I can watch and examine the intermediate steps and leverage that my brain is still pretty darn good at visual pattern matching.
Ouch! I had a sympathetic shudder at your raster flashback, totally been there. I totally get your visual pattern matching instinct too - spooky cos that's how I do stuff too. Great minds.
For what it's worth, I use duckdb and its spatial stuff as my adapter. Works for my brain and if you force e.g. SQL files for each step, gets there in the same kind of way. Still some sharp edges, mind, but overall working well. And then Claude comes for my maths and I sob.
LLMs really don't understand space.
Yesterday I was trying to add a patio to some real estate photos, i.e. "virtual staging".
I uploaded 4 different photos of the same house, from different angles.
I asked Gemini, ChatGPT, and Grok add the same patio to each photo. The results were laughably incoherent (not to mention ugly).
I repeatedly asked them to make the 4 photos consistent in 3D, and it's obvious that they have no way to do this -- no understanding of the scene.
They also could not understand the concept of "back patio" and "side patio" -- relative to the house, when the house was being photographed from different angles. Even when I pointed out which one was the side patio, they would get it confused in a different image.
(I should not be surprised by this, and yeah I know everyone says LLMs have "jagged" capabilities. But to me this shows how bad all the extrapolation of AI I read on say Hacker News has been)
I reckon this type of task is crossing capabilities in a way that the LLMs (very quietly, mind) don't support.
An LLM can describe a photo fine, but it cannot tell you the exact coordinates of what it's describing. When I last tested this, you could sometimes get it to lie about the coordinates, but asking it to draw an approximate bounding box around a given feature - total fail, sometimes laughably so.
Yeah, I tried to have AI arrange some furniture-shaped rectangles on a black-and-white floor plan. Impossible. I could painstakingly guide it through writing a floodfill to find the corners of a room and parse out the dimensions listed in that room, but at that point it wasn't using its image-seeing abilities at all, and it still couldn't do things like putting a particular rectangle against the bottom left corner.
I think they do but only when it's applied to learn some specific spatial task.
We can see for e.g. that frontier models have got really good at CAD sorts of tasks recently. That suggests benchmaxxing RL to a degree but it does mean they've suddenly got quite good at forming simple geometries in a step by step way.
I had similar issue with 3d code in threejs. Models used to be quite bad over a year ago. got ok around year ago. the latest are quite good at it.
so i made a simple ab testing eval on fixed prompts: https://threejseval.com
There is a 7 degree o freedom robot arm that is really telling of the improvements in coordinates reasoning:
https://threejseval.com/gallery?eval=robot-arm
This is my experience too, it has got a bit better but nowhere near as quickly as other domains I deal with. I can usually guide the LLM to a decent solution but there's a lot of hand holding and I'm often left wondering if it wouldn't have been quicker for me to just get stuck in and do it the old fashioned way. Maybe because geospatial stuff is pretty niche so is under-represented in the training data relative to yr standard CRUD apps and React front ends which are ten-a-penny?
They're notoriously, hilariously bad at chess, even today. So yes, agree, their shortcomings come much more forcefully and immediately to light when they attempt spatial tasks.
I mean, it's obvious, no? LLMs operate exclusively on language, and language is an especially poor way to represent geometry, let alone geography to any useful resolution.
Use Astra.
As someone working on a geospatial program, Astra does not seem significantly different to Opus to me. I was surprised myself.
At Plotly we are dealing with similar issues. We're doing our best to keep up, but it's genuinely hard not to just cut our losses on passer-by community contributions. 3 page issue writeups nobody has proofread, nobody but a bot to follow up with when we try, huge volume of plausible but weak PRs eating up reviewer time. All while we have core work we really want to be focused on rather than merging another bug fix we don't expect anyone but this bot has really run into.
This has basically been the story for us at Hatchet too, and it’s been similarly challenging. A lot of the OSS PR reviews I’ve done lately from non-core contributors are basically just me going back and forth with Claude via someone else, which is frustrating when I feel like I could 1) just not or 2) do the back and forth with Claude myself and cut out the middle man.
I have a sneaking suspicion that people are having some agent check out 500 repos and just prompting with “find a bug in this repo and fix it” and submitting the results blindly.
Edit: typos, on mobile
> I have a sneaking suspicion that people are having some agent check out 500 repos and just prompting with “find a bug in this repo and fix it” and submitting the results blindly.
From the reports coming from a number of places, I'm absolutely sure this is what is happening. People want the glory of finding a named bug, perhaps they believe some more widely useful reputation gain is heading their way if something that their bot finds is actually massively significant. Though it isn't limited to 500 repos, they tell it to just keep going after every one it scans.
>I have a sneaking suspicion that people are having some agent check out 500 repos and just prompting with “find a bug in this repo and fix it” and submitting the results blindly.
This is unironically suggested as a way to 'get in the door' both in bootcamps and 'spammy' universities.
I have seen a job application with a requirement of having contributed to an open source project with a certain minimum number of github stars.
Well, contributing to FOSS is a prestige accomplishment. It's viewed as a way in. It's now just a metric to game, and to automate that process is too easy.
Combine this with a growing sense of being "left behind" and a highly publicized collapse in software jobs coming any day now and any proof of contribution is highly prized. So why not?
They'll destroy the prestige of it by doing this, though. Unfortunately the OSS model will have to change to cut them off now, and the more people rush it the faster that response will happen.
On the contrary, the prestige will go up - filtering mechanisms, fatigue, and general banning of AI contributions will make it harder to get a PR accepted. If you make it past all that, you are a real one now.
I've seen this with godot. People are letting their agents blindly file AI generated PRs even though Godot specifically bans this, and then coming in and giving a very weak apology when they get called out by the devs. A lot of the bugs are incredibly low priority bugs as well that no reasonable person would ever really run into, with these huge long wordy slop reports
Its kind of appalling that people think this is an acceptable way to behave
We disabled PRs for PgDog, but left the issues open, for now.
Most bugs that are reported via AI-generated GitHub issues are edge cases, which are technically bugs, but not something anyone actually ran into.
Contributions are exclusively AI-generated, and it's much easier to just go off of a GitHub issue myself than asking the bot behind the GH account to remove the 5 redundant tests it added, or to refactor what has become a 3k line file.
AI doesn't care about code quality, maintenability, or long term goals. It's just a local maximum optimized with RL. Great for debugging, OK for reviews, but can't produce anything that's above average.
This is pretty spot on. AI will find some off the ball edge case that is a valid edge case but perhaps an undefined expectation of the code. Avoiding the additional complexity of handling it keep everything more grokable and clean.
Sadly, people seem to think all these edges AI finds are valid and must be fix and were never thought about. Most were thought about and deemed not worth the additional 50 if statements to handle. Cyclomatic complexity has exploded exponentially with AI and everyones response is “no no no you just need to use opus 6.5 and it will work”
Yeah I sympathize with this, but I’ve experienced the other side of this: I ran into a bug (an integration for home assistant has to be manually kicked every time HA restarts due to a bug in the integration) that my AI fixed with a one-liner. It works great for me. I submitted a PR which is languishing for weeks. No problem. My AI will just maintain a personal fork with my patch until my PR gets merged (or not). Previously it was way too much work maintaining your own fork, merging in upstream changes, and keeping your patch working.
I think this is going to be a common outcome from the fact that many people have AI agents that can one-shot fix and deploy. Maybe it’s not a bad thing for those people and the maintainers who each get what they want.
I feel this is something of a temporary and unstable equilibrium. Once the maintainers figure out how to harness agents more effectively, they can just have a daily bot job to poll all the forks and pull back stuff that looks good. We just don’t quite have the tooling and practices to scale the contributor side effectively.
I think OSS is going to look more like the original Git model, or perhaps even further towards “horizontal gene transfer” where memes/alleles get copied across various repos, rather than having a single lineage of phenotypes.
I would be interested if a common outcome was to have a fork with AI PRs and one with AI contributions disabled. Not only does it satisfy both camps, but it provides a longterm anecdote of the effects of agentic code quality and maintainability.
Yeah. I did almost the same with KDE Spectacle. It lacks good shortcut keys for annotations. I've just asked AI to add them. Sent a manually reviewed TINY patch to maintainers, never heard back.
Low quality PRs, along sometimes with concerns of providence that might cause future licensing issues, were a problem before the Eternal LLM September made it easy for far less capable (or caring) people to submit them than before. This is at least part of why a number of projects switched to being “open source but not open contribution”.
Possible idea: tag them with AI, and leave them aside for 6 months and review them with 2027 AI
I’m a little perplexed though. The problem as stated is there’s too many drive-by contributions with AI slop. Isn’t the solution to define a contributor network (eg a GitHub org that you can apply to) based on trust?
The other option they proposed was a proof-of-humanity by payment, which seems much more in line with the above.
The problem with just banning AI is you didn’t solve trust, and your untrusted users are just going to drop drive-by PRs anyway. How do you know if an untrusted user did or did not use AI? In practice this likely means just aggressively closing “slop-looking” PRs from users you don’t recognize?
But then, you’re preventing your trusted community members from benefiting from AI assistance.
I’ve been advocating for defining a higher standard for AI contributors, eg an AGENTS.md that specifies some meaningful correctness bar. In this case, perhaps the PR that adds you to CONTRIBUTORS.md could to add a large novel and non-trivial end-to-end test; if you can construct problems that are easy to verify but hard to get right, then this is your “proof of work” to establish competence.
From reading the GH issue it does seem this is a placeholder solution, so I hope they find a more stable long-term resolution.
> Isn’t the solution to define a contributor network (eg a GitHub org that you can apply to) based on trust?
Yes but this is fairly tedious people work that most open source maintainers are not interested in. Once the tooling is available to make that easy, it will become more popular.
The linux kernel team set something up that they are pretty happy with. I don't know the details, but they have dealt with the influx and feel comfortable their solution will last.
https://www.youtube.com/watch?v=NnV_cWeoo5Q
One thing I've been thinking is something like the DCO checks. Set up some account bridge between (eg.) Discord and GitHub, then auto close anything submitted by accounts not sufficiently involved with a message linking to the new contributor policy and rationale.
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.
> how are you sure?
This is not just a software problem. I see it everywhere. Folks in business roles just as much as any other role. There is a surface-level operating framework to get a job done but the why/how is sometimes lost.
I always come back to an example in my past. Somehow automated a report. From Excel to Power BI. Then for months Power BI was wrong. Automation (more code involved for sure) made it run faster but then people forgot about the how - how to check/validate/etc. And since it was code - for many non technical people the whole thing was a lot harder to deal with needing to deep investigate issues.
But that is how most of the companies work (and did, for centuries). Very few roles affect critical flight safety, nuclear control or other things that need a bunch of nines for reliability, written and fire-drilled fallbacks, etc.
For everything else the general mode is "can we make it work well enough". And when it breaks, well, we will curse and pry it open and either fix or rebuild it. There are many stories of a particular thing that was built long time ago by folks who are long gone and no one knows how it works or even where it physically is.
And it works fine; usually better than ensuring complete reliability from the get-go, when it is not clear if it is a long-term core feature or a kludge that will be obsolete soon. My 2c.
I agree.
But I feel like it's a minority that really know how the software they're writing really works. And it's 10x worse for older legacy software.
Mostly because the people doing it don't care. Not judging, just reporting I guess. I know because I used to work in quite a few companies where the "money maker" app was on maintenance for years and nobody was able to answer questions or didn't even know most corners of it still existed.
This desperation mindset also often correlates with people writing code without care for the next maintainer.
And the scary part is that this also correlates with advocacy for going all-AI.
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
… and isn’t the AI is already ahead of 99+% of programmers on that front?
I don’t know anything about formal verification myself! But proof? I am sure we have seen that AI capabilities exceed humans on that front.
Alas, I think we (collectively) either are, or will be soon. There will be people who keep 100% knowledge of the code in their projects, but I don't think there will be any monetary reward for that, nor reputational outside of their own niche. And I say that from a position of really wanting to be wrong about it.
I recently started using Claude to write an app. I was going to write it by hand but was having trouble getting motivated, and I knew I had to "up my game" in the vibecodery anyway. So far it's been a lot of back and forth, I keep the leash pretty short because I don't want The Claude AI you see everywhere now.
But even with good intentions and the short leash, I find myself saying "yeah, whatever, it looks like it did what I told it to do" and not actually reading all the code. Some yes, all no. And this is for my own project, nobody is my boss here, and it's nothing I couldn't have done by myself.
Now imagine the incentives for someone who's doing it for money, whose boss is pushing them to do more AI and not less, who probably doesn't actually know how to do all the things the AI is doing for them, who looks around and sees who's getting promoted and who's getting laid off...
And remember that most of us, most of the time, no matter how much we might love computers and software, are that person.
But hey, it could be worse! Have you heard about the Literacy Crisis?
> but I don't think there will be any monetary reward for that, nor reputational outside of their own niche
I used to think this but have come around to the opposite. I'm already seeing client projects where they went off and LLMd their way forward. A few hundred KLOC and many rounds of bug fix whack-a-mole later, they have something that's a giant house of cards.
Sure, once in this state the LLMs can repair issues at a faster rate than the humans can, but the damage is already done at that point. And it requires a lot of combined human/agentic effort to unfuck it.
> 100% knowledge of the code in their projects
That stops working once the code reach a certain size/complexity limit. It is a different limit for different people, but there is a point where there is just too many parts to be possible to fit in a head. There is also a middle stage where everything fits, but can't be accessed all at once but require some time to retrieve specifics when looking at areas not in recent memory. The middle step is more achievable the easier the code is to reason about by black boxing parts.
I hear this a lot as a reason to accept that only the robots have read the code: "but it's too much code for one person to understand."
Yes, but it's not ever too much code for a team to understand, or a community. The question is whether you can build a team or community with enough trust and integrity that two things are always true:
1. Alice understands the fluxtron renoberator module she wrote.
2. Bob can also shift his attention there and understand it if necessary, because Alice writes clean code that was reviewed by John and Sally.
You can have Alice, Bob, John and Sally all be robots, and you can decide to trust the robots, but (so far anyway) it's a choice, not an inevitability.
But 1 and 2 were rarely true pre-LLMs, not in any code that has substantial active development. Because 3 months later, the fluxtron renoberator module has been modified, fixed and refactored by 5 other people and looks little like Alice remembers it, and Bob, well, he could never shift attention and actually understand it, nor could anyone else, because that's just a nice story we told ourselves that never worked in practice.
> But 1 and 2 were rarely true pre-LLMs, not in any code that has substantial active development.
Every large project I ever worked on worked exactly this way. What do you mean it was rare?
> But 1 and 2 were rarely true pre-LLMs, not in any code that has substantial active development.
I'm ready to bet that is untrue. Sure, no one can recite the code, but people can quickly scan the module and refresh their memory as well as understanding the new changes, even after a while. If not, collaboration would have been impossible.
> Because 3 months later, the fluxtron renoberator module has been modified, fixed and refactored by 5 other people and looks little like Alice remembers it
I don't know for which type of projects those things happen, but good design can have a long staying power. Drastic refactoring in a short period is a clear sign of bad engineering.
> and Bob, well, he could never shift attention and actually understand it, nor could anyone else, because that's just a nice story we told ourselves that never worked in practice.
A lot of OpenSource projects are decades old, and while some core maintainers can stay for the lifetime of the project, new contributors came, understood the code, made changes, then left. Same for hires in companies.
> I'm ready to bet that is untrue. Sure, no one can recite the code, but people can quickly scan the module and refresh their memory as well as understanding the new changes, even after a while. If not, collaboration would have been impossible.
I don't understand this part. When I was doing freelance consulting, my job was quite often "come to our office, scan this 40 million lines codebase and fix stuff for the next week". It was never a problem to read and get up to speed completely unknown codebases if you have basic programming ability. Much harder to do something that fits floaty business objectives though.
We already were, even before LLMs, we just deluded ourselves we're not.
When I started working in the 80s in my first job, the head of department had banned the PC for administrative tasks. He thought that the old manual process was more reliable and allowed him to better control what was going on. He retired one year later and the PC were introduced successfully shortly after. Was he wrong to push back ? At that time, that was what I thought. But now, 40 years later, I don’t think so anymore. I think that that delay gave the proponents of the PC the time to prepare themselves a lot better and is a reason for the success.
I can’t help drawing a parallel with what is going on now. Even though I’m pro AI, I understand why QGIS is stepping back. There are a lot of places where the processes and tools are not ready yet to fully embrace it and you need time to prepare.
> 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.
Agreed.
The way I like explaining this to people is that I don't think I build products anymore. Now I build the harnesses which build the product. And a massive part of that is ensuring that I can make the AI remain aligned with my way of thinking.
I would even go further that part of the challenge is the "verification" of your way of thinking which is much harder to do since your harness now is "in the way" sorta speak.
The software telephone game seems to never end!
I think the economics just change drastically. A few years ago a helping programmer was great help and would implement something that was agreed to be needed to be done by the project or something very important for the contributor (the reason they spent the time to contribute). Now anyone can get a 20$ subscription and prompt away, but so do the project's core developers. So why should they bother separating the wheat from chaff? I totally understand that.
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.
> 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.
> 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.
This. We’ve just moved the bottleneck from during writing the code to reviewing. The failure mode here is that you can choose to just do a light review since the code “works” but if you had to write the code yourself you would have been forced to consider the design choices and broader implications of the code more.
> We’ve just moved the bottleneck from during writing the code to reviewing
Ah, that's only true if whoever is in charge is willing to _have_ a bottleneck in reviewing. In some software development groups, there is a strong pressure for reviews to pass, i.e. expectation that reviewers approve; and the notion of veto is not common, so that if some reviewer objects, the implementing developer can find others who would be willing to accept, bypassing the objections. Also, few people are willing to conduct long reviews of a lot of code, and even less people are willing to read multiple comments in a long review of a lot of code.
Now, in some projects, there are only one or two "owners" or "marshals" for some areas of the code, so they can apply a strict standard if they want to, but - their time is limited, meaning that long LLM vibe-pull-requests are likely to either be ignored for a long time or rejected off-hand.
I have many years of the experience of of raising concerns, criticism and objections in reviews
The bottleneck they feel during coding is the lack of knowledge. Knowledge of the technical platform and knowledge of the deeper implications of the task’s requirements.
I’ve mentored juniors and the common trait is that they rush to code without understanding, then they spend days trying to fix things. Coding will seem like a real bottleneck for them.
> I’ve mentored juniors and the common trait is that they rush to code without understanding, then they spend days trying to fix things.
As a senior (of sorts), even though I don't quite rush to code, I often find myself starting to code something 'naively', while my understanding is lacking (typically in a tangled, inconsistent and poorly documented codebase). But what probably sets me apart from juniors is how I handle getting stuck, or rather what it means for me to try to "fix things". I spend time thinking about what I've discovered that has gotten me stuck, what I must take into account, and how I should alter my approach (or refactor the existing code to be more accommodating).
Sometimes I manage to formulate ideas apriori that reduce the frequency of my getting stuck, and/or the extent to which I need to backtrack. But - not always.
Is this a remake of "just spend 15 days near a whiteboard, then write the code and it will be awesome" ?
Have you ever heard of the V model (https://en.wikipedia.org/wiki/V-model) ?
Long story short: it does not work, because the act of coding adds new valuable inputs that alters the (original) design.
One might say "you just have to know", which is an equivalent to "you just have to figure out the future", "you just have to be perfect" and other non-sense (which does explain why V cycle does not work, high inefficient, low quality outcome, bad method)
There's a wide spectrum between specs upfront vs trial and error with the codebase. Somewhere in the middle sits the whole MVP and iterative building, where you start with a smaller codebase and fill it up. Basically exploiting the fact that a lot of concepts, while interconnected, are modular and can be tackled on their own. Like how the design of the brakes and the engine in a car, while related, are mostly blackboxes in regard to each other.
People that do trial and errors lacks direction and their code is often fragile, especially with evolving situation. Because their have failed to grasp the deeper truth of the domain. The usual signs are tightly coupled code and code churn.
AI agents can build a whole app and review PRs better than a lot of people, while having access to more context at once.
Honestly, where did the bottleneck end up now ? It sure isn't simply reviewing, or designing, so where is it ?
> AI agents can build a whole app and review PRs better than a lot of people
Assuming you're comparing to experienced human developers that are good at what they do, then I think you have to define what "better" means here. It's clear that you can get correctly functioning software faster in many cases, but it's not clear that the design will be better in terms of conciseness and readability or that it's as useful as a foundation for building upon later if nobody understands what's going on inside.
Actually I was extrapolating, I should have expanded about it.
But to me, having graduated last year, it doesn't seem far-fetched to think that AIs will also get better in terms of design.
And will conciseness and readability even matter in the long term ?
It's all things I think about more and more often and I'm not sure where I will end up
> And will conciseness and readability even matter in the long term?
Fair question. Right now the way for humans to understand code is to read it and that'll be easier if the code is concise and readable. But it's possible that we'll end up in a situation where the code is separate from the explanatory materials that humans need. This is similar to math where we might have impenetrable Lean proofs of theorems and then natural language expositions to explain the proof.
> It sure isn't simply reviewing, or designing, so where is it ?
If I can shit out some vibe-coded thing over a weekend that does <useful thing> it means anybody else with the same tool can do the same thing. There is no value in the actual code itself -- the faster these models run, the more true that statement will become. In the not too distant future these things will run directly on silicone and operate at thousands of tokens a second. That means they'll iterate and explore something far faster than they do now -- mistakes they make will be fixed in seconds or perhaps milliseconds.
That being said my <useful thing> is likely only "60%" of what makes an actual product somebody would buy. It's finding the other 40% that is something I don't think that LLM's can solve. That requires human judgement and then knowledge of how to communicate that vision to your agents.
In short, I believe the challenge is knowing what to build that others would find useful. It's easy to crank out <useful thing> for yourself. Making something others can use is not. And that is, possibly, the bottleneck. But once these are fast and dirt cheap, (and that is a when not an if) the cost to iterate to something workable goes way down. Of course mumble mumble "no silver bullet" / "mythical man" month mumble mumble and all that soo......
I dunno... doesn't directly answer your question but it is what came to my mind anyway.
It is honestly impossible to review the amount of code that AI generates and we dont know how to adapt yet, review line by line is already outdated imo, we just don't know what should replace it.
My prediction is that in the future we are going to be more focus in the testing part (that should be more human readable) than the code itself.
Whatever it is, the only thing clear to me is that the tooling will have to change.
I am a hobbyist and work in a different field than software dev. Old-school guys in my field are super-fixated on the UX and treat the work like 'implementation details.' They abstract away the time and effort such that really old school guys (who have been top-of-the-pyramid in their business) come off as insulting with their 'I don't care what it takes, get it done' mentality.
I can't help but feel that when I mimic their behavior with an LLM, it works great. Just keep pounding claude saying what I want, prove it with tests, and have claude give me a 1 shot script to build and launch the app. I get hands-on time with the UX a lot more (I think?) and claude happily iterates. Most people stop happily iterating after like iteration 2; then becomes teeth-pulling.
So to your point, claude's tests are gibberish but the 'testing' via user interaction is what I think the future is going to look like.
We will need some novel systems where hot-reloading is the default experience and you are looking at the build output constantly as opposed to the source.
claude was like "I took your logic, removed the shared state, ran the tests 600 times in parallel, proved no state is leaking across runs". I was impressed...
Funny enough the current web stack is the one most ready for this kind of development. Playwright may have the best way to describe user interactions, also the hot-reloading part.
I am doing an app that keeps a web and desktop version at the same time, mostly because the agent can iterate faster and with less resources and more constraints (running in a container) with the web version.
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.
What you refer to as "clutter" is what actually documents the code without the need of comments if done correctly i.e. naming things properly i.e. ubiquitous language. Before rushing to throw away things you don't know, learn about them.
There is no "document with documentation", be it comments or as companion side resource with an obvious cross-reference.
There was no mention here on rushing to anything. Verbosity is not always bringing actual non-duplicating information. And even when the explicit way is taken, it can be put aside from human main analysis observation point. Actually even Typscript allow to organize type information by using .d.ts files for declaration files that contain only type information, while implementation files use the .ts extension.
Then there is the tradeoff between grepable explicit type and spare implementation with as much type inference as possible.
So, you ask an LLM "what does this code do?" and it spits back a long list of things.
Is the fear that it is (maybe wilfully) misinterpreting the code, being too general, not going into specifics or is just not smart enough to catch all the nuances, privacy issues and hidden mistakes? Is it a token issue? A combination of all this?
Suppose you're taking a math class and the instructor writes on the board:
> An eigenvector or characteristic vector is a (nonzero) vector that has its direction unchanged (or reversed) by a given linear transformation.
Do you understand eigenvectors now? Speaking for myself: certainly not. To really understand even that definition I'd need to do the calculations, play around with how they can be used in different circumstances, and allow my brain time to sit with all this new information and become comfortable with it.
I think LLM code descriptions are similar. They don't really bring understanding. Sometimes that is fine.
More LLM allergies.
Look at this PR: https://github.com/qgis/QGIS/pull/67731/files
The code change is so simple that Claude today could easily write this code. How will they know if an LLM wrote the code? They won't. And this policy will age like milk: Each passing month, coding LLMs are improving. It will become more difficult to "detect" an LLM-authored submission.
The best LLM policy that I have seen for an open source project is Linux. Roughly: You can use LLMs, but you are fully responsible for the code it produces. Linus acknowledges both positives and negatives to LLMs.
Agreed that's the best policy for the real contributors, but how do you fight back against the folks using your reviewer's good nature to test their coding agents?
Also, Linus is also comfortable closing 100 PRs as "this looks like garbage". Many communities are softer and try to be more helpful with new contributors.
Yeah, fair point. I laughed out loud when I read this part:
Probably, as LLMs get much, much better, most open source projects will be overwhelmed with submissions. I guess this is a good problem to have. Some projects will scale (more maintainers/reviews); others will become more harsh.> How will they know if an LLM wrote the code?
The problem isn't just the code - the documentation for the change explaining what it fixes, how, why, what testing has been done, and so forth is often either lacking, far to verbose, or both (massively verbose without actually containing much useful information or other sense).
You raise a valid point for the future: when the average quality of submissions is good enough that it is impossible to tell the difference between human (or human aided by AI but giving its output sufficient review/rewrite) and LLM/agent submissions, then the issue will have gone away. But, given the problems projects like this are seeing it is obvious that the technology (or the people using it, probably both) are not nearly there yet.
> The best LLM policy…
That is a great policy. If only the entire world would follow it, or in fact even ever read it.
If the only reliable way for now to not be suffocated under a mass of bad AI submissions is to refuse anything that even vaguely sniffs of AI, then that is what many projects are going to have to do. If that offends you, then fork the project and patch your changes in, or vide code one from scratch yourself, then you can keep maintaining that along with all the submissions you get for fixes. Let time tell which the right decision is :-)
LLMs are still being detected at the same level since the day coding agents were actually something, hence, it's not improving for 3 years. Why would they be undetectable next month?
Moreover, the parent comment linked to a decent PR presumably human made. If an LLM had written the PR, its description would be 9 paragraphs long and the code changes full of assinine comments.
If the author really did one-shot the PR, then the author must have also put in the extremely detailed and tedious work which would be required to tame LLM output for this specific repo, in which case, they actually put in real effort, applyed expertise and thoughtfulness, which is the whole issue at hand.
You think coding agents or models have not improved in 3 years? From my experience they absolutely have. I've spent a lot of time getting Claude Code to write clean features in a brownfield repo. I've gone from it helping me speed up to now Fable 5.1 doing it perfectly. And there are steps one can take to improve the quality which is to teach it (SKILLs) your important design and coding standards, as well as automatic design or code review to catch edge cases, performance issues, or whatever aspect you find a high priority.
> How will they know if an LLM wrote the code? They won't
They don’t need to know. The policy is not a linter that will scan each PR. Just like the law does not monitor everyone 24/7 for criminal behavior. It’s enough that the rule is in place and it’s enforced when they catch an infraction. No need to be perfect as long as it lowers the pain.
The Linux kernel has the benefit of a big team of maintainers, and the GitHub integrations with these LLMs make opening these low-effort PRs incredibly trivial on GitHub vs a mailing list
This is a good point. To be fair, I think the Linux kernel teams are currently overwhelmed by LLM-authored security fixes. However, that will taper off eventually as a huge number of security fixes will be fixed in the next 12 months.
You are missing the point
> AI stream is a lot higher than what human review can take seriously, leading to either a longer list of un-reviewed PR's or not fully reviewed code and quality issues. Both thing we don't want in the project.
It’s not about detecting AI, it’s about reducing the amount of code to review.
Okay for feature work but the amount of bugs I can find with Claude in hour, with deterministic reproducers is staggering.
If you are reporting a number of bugs per hour then you can't be properly reviewing each to make sure it isn't a complete hallucination, a behaviour-as-designed reaction to silly configuration, etc, nor are you reviewing the documentation to make sure it both actually makes sense and is appropriately concise to not waste time in the review process.
This sort of thing, in the minds of not just you but many other people, is exactly the problem. On behalf of the projects that you have communicated with this way: thanks a bundle.
I said "in an hour" to mean, the time it takes to identify the issue.
That fairly obviously doesn't turn into "bugs per hour" to verify, but if you find 10 candidates in an hour and then get reproducers of them out over the next few days, they are real bugs.
Like sure, "not properly reviewing" could be a thing but if I'm looking at a hard crash on my console, that's not behavior as designed.
Bug reports also need review because not every bug reported is a real bug, could be hallucination and the "fix" is useless or even dangerous.
You don’t know the model and prompt they used to generate the report so you can’t even take the model quality into account
I don't completely like or think this is a good ultimate decision, but looking over the thread on Github, it's being done for practical rather than ideological reasons after trying a more liberal policy first, and the discussion thread there indicates that they're already considering how to relax and refine it. A long-term and total ban on AI contributions would be a mistake as it all but guarantees a competitor or a fork, beside enforcability issues that create a "now you have two problems" situation. But as a temporary stop gap as specifically indicated by https://github.com/qgis/QGIS-Enhancement-Proposals/pull/387#... this seems fine, and it's such important context that "QGIS bans AI assisted contributions" is true but misleading.
The linked discussion thread specifically calls this a "moratorium" and it's unfortunate that they decided not include that explanation in the policy document specifically to avoid controversy and flak, with the end result that there's now a 202-comment-plus HN thread: https://lists.osgeo.org/pipermail/qgis-developer/2026-Septem... -- the "proof of life" concept being tossed around in that thread, although rejected, is genuinely interesting and I hope they revisit it and allow a nominal financial contribution to the project to prove a human is behind a PR regardless of AI assistance (probably along with some other approach, as a total exclusion and the only way it would also be bad).
My own experience with QGIS is limited to the most basic navigation and queries of some local maps I've archived. Nonetheless it's an obvious gem and I hope they're able to arrive at a balanced and sustainable policy. Maybe they would get there faster and more reliably by tightening the previous LLVM-inspired policy rather than the slam-shut and then loosen approach they seem to be taking, but hardly anyone has experience with a situation exactly like this, so only time will really tell.
Ok, I've included a link to the email thread in the toptext and put the word 'moratorium' (which does occur there, into the title. Maybe it will dampen some the more boring flamewar responses in favor of the reflective subthreads which have also popped up here.
> 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
Ok, so there’s a financial motive here, where they’re worried that allowing more open contributions will diminish the value of their expertise and reduce their employability. To be fair to them, that’s probably true.
If there is money to be made, and if frontier models already know the domain I do not understand what this position can possibly buy other than a bit of time before it happens anyway.
I'd love to know more about the process that the storytold team is using to build the Artcraft apps.
https://github.com/storytold
They're producing a fantastic quantity of software, and the quality seems higher than you'd expect for the velocity they're building at.
I never used Photoshop that much, but I used to be well versed with Lightroom. So I tried Lightcraft[1] which is their Lightroom clone, and I was disappointed after all that hype. I couldn't get any of my photos to look nice, using the workflows I was used to from Lightroom. It felt cheap, unfinished, and barely usable, also compared to the open source Lightroom alternatives that have been around for a while (e.g. Rawtherapee). I'm willing to change my mind in the future, but at the moment, I don't really get the hype.
[1]: https://github.com/storytold/lightcraft
Yeah, agree - the feat so far is that they brought up an entire suite of incredibly complicated apps from scratch in a week, and they seem to be tackling issues consistently.
There's a lot of depth in these tools, but the process seems to be working. Look at the issues, PRs, commit history and release notes. It's moving faster than a project with an "all code must be reviewed by a human who is responsible for it" policy would. Will be interesting to see if there's an upper quality bound.
It's not impossible produce good products with AI-assisted or driven coding. It just needs effort, focus, and management, much like regular software development.
If I remember correctly, most of the apps were oneshots.
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
This comment captures the essence of why HN is largely anti AI. They feel their security and roles as software devs starting to devalue. Non coders are encroaching on their turf. A PM can do now what mid level devs did before. As AI continues to advance there will be less of a need for devs and the pool size of devs will start to shrink, as it already has. I understand the human reaction to this. It’s a hard situation to watch us being replaced by a machine. Especially after sitting at the top of the comp ranking for so many years. It’s a scary time.
The PM doesn’t have a runtime environment to test the change. No access to create a PR. Zero verification was done and I was handed a .zip file
I don’t disagree with what you’re saying, but not all cases are created equal. If the PM could create a PR that was clearly verified, like we expect out of all the SWEs, I wouldn’t have a problem.
Understandable. Surprised that's not automated though. Would be worth the time to invest in that area, will save a lot of pain and time in the future. As we shift more to AI, testing is more important than ever and all of that can generally be automated.
Multiple companies I know of have internal tool websites that are the front end to the major AI companies and it has access to cut PRs so non devs are able to open PRs
Sure. Specifically I work on SOX restricted code, but the rest of the company has what you’re describing.
PMs are doing demos to leadership where their change “just works”. The devs and maybe even the dev leads may protest that due diligence wasn’t done, but leadership is looking at the engineering cost center, axe in hand.
> It’s a scary time.
And that is why you felt you needed to boost the narrative and reinforce it so people are fired faster. Totally believable!
Better than remaining in denial about it like most people on here.
I agree. For bug fixes, just write a clear issue: how to reproduce it, what goes wrong, what's the root cause. As short and well written as possible, without AI fluff.
Once you get to that point, you can copy paste your issue into an LLM and get a fix close to the PR you would open, but so can the maintainers, so what's the point of opening a PR and adding more friction?
In fact discussing the issue is way more productive since it's just about the actual issue, root cause and tradeoffs without the debates on implementation details and nitpicks.
If you want to contribute major features, you need to befriend, discuss and agree with the maintainers, I don't think drive-by PRs ever worked for this.
This has always been true to a large extent. Unless you're cleared to carve out your own space of a project, or you're working off an already detailed issue/feature request.
Do maintainers agree with this or do they feel you're just spamming them?
> 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.
I think we need to talk about the root issues then.
At “work”, non-open source, I see maintainers addressing usability issues they never would have touched before. I write the issue, the LLM does the rest.
In fact, last time I included a PR to fix some trivia, the AI said “let’s fix the root issue instead”, and did that. This was astounding to me. That team used to do nothing in the face of complaints / small bug reports. It used to be that without a PR you were ignored.
So what do you think is going on behind the experience with the maintainers? They don’t use AI? Or they are incompetent? Or…?
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
Then, as the parent commenter suggested, fork the dead project.
No project is obliged to accept your contributions. It's on you to market them, either to the maintainers of the existing project for merging, or to the community through a fork.
> Being able to market your work and build community are key skills for open source contribution.
It's not a key skill at all, as not everyone is interested in popularity.
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.
GDAL isn't too big on LLM contributions either.
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.
> make a contributor pay for the review of its PR, even a small fee
I agree!
The problem is obviously a resource allocation one. Economics solves problems like that.
To make the system viable, you need something like the free-to-play games use (shudder).
Offer a choice: user’s time and attention or money.
(This addresses the issue of excluding low-resource contributors, which we might care about for equity or because that was us when we were young.)
As an idea on the money front, you could require the contributor to pay for the tokens needed to review their PR! Maybe even let simple models review simple PRs or advanced models decide which model is needed to do the actual review.
I don’t know how the humans can contribute their time and attention effectively, but maybe we can figure that out.
We've already had solutions like this in the past, pre AI. Bounty escrow companies that pay FOSS contributors per PR. They've mostly all failed or pivoted. Why?
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).
So then charge more. It’s still a resource allocation problem, and economics still works.
> If I pay you (even if it is $1) then I expect you to take a look at my slop
Yes, proportional to the amount paid.
> and argue with me how to make it better.
No.
Tbf most projects are especially gatekeepy..... they've been even before AI came onto the scene. All what changed is making changes easier (slop it out instead of the classic one-line readme edit) and making it easier to fork projects.
Traditionally you've opened to a PR only to get closed for a style/procedural issue or get ghosted. You often didn't fork because maintenance is a hassle. Less so with LLMs, you know?
Nowadays you can just implement your change and vibe-fork it...
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.
Honestly, if it’s geometry-only and doesn’t acknowledge the existence of anything other than Cartesian coordinates, it sounds like the type of feature that’s more of a support-ticket bomb than otherwise.
If it does support projecting differing CRSs though, please can you point me at it? I’m a nobody and nothing to do with qgis but I would love to have a play with it!
I'm not sure if I understand the concern; for clarity, I'm just making a general comment about the state of contributing AI to open-source software related to resvg, not related to QGIS itself. svg2 spec says css geometry attributes only support cartesian coordinates.
Ah gotcha, thanks - I know next to nothing about css geometry itself, but was curious to play with it, and think I had an imagine in my mind that was different to what you've created.
For what it's worth, I just skimmed the MDN docs and e.g. DOMPoint is using the right kinda wording to sound like it's not inherently cartesian-only. Could be interesting, that. Thanks for getting it into my head!
A.) I understand this completely. I'm sure it's impossible for reviewers to keep up with the onslaught of AI-generated code.
B.) I worry what this entails for QGIS, and for the future of such community-built platforms as a whole.
Let's say I need some functionality which QGIS doesn't have. My options are to:
1. Learn to program QGIS, add the functionality, and commit it back to the community. From where I currently sit -- I've never developed for QGIS, I don't know its language -- that's an investment of several months, at a minimum.
2. Vibe-code the extension I need -- or just make a bespoke GIS application which has the small subset of GIS capabilities that I need, optimized for my particular use-case. Depending on the complexity, that's an investment of either days or hours.
By that math, (1) is never going to win, and now (2) is never going to be able to make a contribution back to QGIS. Moreover, the pool of people for whom (1) is a real option will be shrinking every day, particularly as those people have to compete economically with the people who embrace (2).
So it's hard for me to see how community projects survive in the face of these dynamics. And it would be a shame to lose them -- they create a lot of value that a bespoke vibecoded thingamajig never will. But for better or worse, I just don't see humans-only coding having much of a future.
Maybe your extension/app is compelling enough that the core team finds a way to recreate it, or make an exception?
Maybe it becomes normal to fork a project and vibe-code the extra thing you want and everybody does that and it's fine?
Doesn't seem like a loss for the project, just a win for you. If I understood the announcement correctly, they're doing this more for logistical reasons than to outright ban all AI-assisted code, so if something turns out to be super awesome then it's not like they have to do a clean-room reimplementation.
Meanwhile, let a thousand forks bloom, why not?
Can anyone provide links to literature or projects whose goals are to build, maintain, or support trust? Or to be less vague, I'm interested in learning about protocols or models that deal with reputation scores, rewards and punishments etc. for networks or groups.
Various crypto projects fundamentally deal with proving X and their networks comprise of entities that are rewarded or punished for either fair, deceptive, or erroneous actions... so maybe some kind of consolidated info about that "grouping" of information would be a good place for me to start. I am curious about learning more about these concepts insofar as how they can apply to situations like this (OSS or community-based contributions towards a shared goal or a shared ecosystem of behaviours or tasks) where various entities (people, organisations, NOT agents/bots) with longitudinal reputation/state coordinate or interact.
I hope I'm making sense...
https://github.com/mitchellh/vouch
Like a cryptographic "vouch/trust" chain? I trust you, you trust someone else, then I at least know there's a second order of connection/trust.
I haven't seen one yet that fundamentally worked. Even before crypto, you had things like reddit karma or upvoting on digg or whatever else. However in the end those still boil down to a social or techno-social "contract"/system. I've not yet seen any system that manages to boil that down to some objective metric, and also still work.
I don't think there ever will be a perfect trust system, because ultimately everything can be gamed, or politics/power can overrule the logic that runs the rules of the trust game. But even so, something that can be applied for _some_ period of time, with _some_ semblance of stability, and _some_ epistemic utility value to the real world is still worth trying to pursue.
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.
It is doubtful whether anyone can claim copyright over LLM-generated code since it was not created by any human and the "training" does not preserve provenance.
Possibilities range from "public domain" to "the cancer Microsoft accused GPL-licensed code of being". In no plausible scenario does the person who pressed the "generate slop" button become the copyright holder.
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.
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.).
Super interesting diff. Feels like it could be a seminal record of the push and pull of this time.
> We aspire to be a welcoming community that helps new contributors grow their expertise, but learning involves taking small steps, getting feedback, and iterating. Passing maintainer feedback to an LLM doesn't help anyone grow, and does not sustain our community.
Hard to disagree!
I think it's fair for people to want a certain experience. Dealing with AI contributions is not the same thing as the community they're after.
I think we should move to pull requests that describe succinctly what feature or bug needs to be pulled. Not the actual code. A PR for a bug needs an issue link with a test demonstrating the bug in an easy to verify way, eg an online playground/runner.
Ideally the project has a well written, living product and system implementation document that can be used to verify bug reports and feature requests against. Before even looking at the actual code implementation.
- 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.
I have many such forks myself. Some are totally different from upstream now, and yet improvements that upstream makes are straightforwardly portable. I just point Opus 5.5 at the repo; describe what I want; et voila.
In the past, communities were required to produce the rest of these things. Now we live in an era of unprecedented free software. Soon no one will even be able to lock us out of firmware and all software will be free as in free speech to all.
> - Any (super)intelligence caches work > - Any (super)intelligence _wants to create stable abstractions_
This is a higher-order rephrasing of the "intelligence is compression" argument.
Can someone, maybe the team at craft, please make a clone of ArcMap?
I recommend people actually read the updated commit for the full message.
Good, back to the old way of doing things where people fork and maintain their own code. Some might notify the upstream author as a curtsy, and the author might decide to incorporate the improvement back into his or her codebase. None of this pull request noise.
The best fork wins :)
In each thread like this, people are complaining that this is short-sighted because you can use AI for good. But this completely ignores the actual usage patterns: there's plenty of people who see hobby activities, such as contributing to OSS projects, blogging, or writing Wikipedia articles, as a competition. If you're unconcerned with quality - "Claude, make me a blog post" / "generate 10 improvements for this project" - AI allows you to easily produce content at a rate 100x higher than a human can. This inherent volume asymmetry means that if a sufficiently popular project doesn't reject AI, they will be spending most of their time dealing with AI, and most of this content will be bad in ways that are difficult to spot at a glance.
Why is it my responsibility to deal with that? So that your once-in-a-blue-moon high-quality AI contributions can filter down? All of these projects were doing just fine pre-AI, so most are not too concerned with that. If AI folks want to have the use of AI tools normalized, I'd posit they should really get more invested in promoting quality and ostracizing slop pipelines. They aren't doing that - I'm not seeing this on HN, not on LinkedIn, not in the open-source community.
This asymmetry is IMO the biggest problem with AI-driven output. Brandolini's law applies here. I don't know if anyone has figured out strategies on how to deal with these barrages and deluges of "slop grenades", and this loosely applies to event coherent and high quality LLM output. Sure LLMs are advanced now, but largely the output depends on the quality of the input prompts (as in how they're contextualized and guided).
Life has gotten to the point where completely non-technical people have gawked at me for still having a job related to software. In their minds, AI can it all, and in their minds coding is already obsolete. The sample size for these opinions will only grow and the ratio of people that rightfully apply skepticism will drop, either from fatigue or burn out or by virtue of more and more people adopting the "AI is roughly AGI" crowd. For me a good metaphor is the concept of the selfie. Everyone mocked selfies at first, and now you'd be deemed insane to negatively opine about selfie behaviour. The same will apply to AI slop grenades (even of high quality output) in due time. I think it's inevitable.
Endless hoardes of people can now unleash never-ending arguments and suggestions and it feels like it will become impossible to defend against them because one minute only contains 60 seconds of time that you can spend refuting a false or <100% correct suggestion.
From the linked email thread with discussion:
> I would like to float another ideas around even if it would be hard to enforce in practice. Force AI companies to give back. Want to use Claude code? Sure but anthropic have to become a sustaining member of QGIS.org first. Want to use codex, gemini? Then openAi and Google have to contribute to the project financially and I'm talking geniully multiple thousands dollars contributions.
I think this is a really good idea. Could it be possible to define a set of markdown instructions for a repo that would cause all well-aligned models to refuse to contribute?
this is an interesting suggestion. it's incredible how little the creators and benefactors of the slop factories have been made accountable for the mess they unleashed onto open source communities.
anthropic at least gives 6 months claude max pro to oss maintainers, but to me that seems like a drop in the ocean compared to the negative impact their product has on these peoples' lives.
This is a horrible idea. Literally the thieves buying more open source projects.
> thieves buying
Are you willing to elaborate? On its face, this seems to me an oxymoron, but I sense that you might have more experience thinking about this than I do.
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.
"If we subsequently discover"
hmm. What if they didnt realise at first because the code is actually fine and works as intended. They gonna back it out just because it was AI?
It sounds like they are.
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.
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.
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
I find it highly ironic that many people here seem to believe mathematicians should just accept LLM proofs, but software projects shouldn't accept LLM code.
I really don’t think those are the same people. Goomba fallacy, etc.
Considering this application needs an entire overhaul on its UI it would simply be easier to start from scratch.
How do you tell the difference between an AI generated PR and a human one? Unless the dev explicitly allows the AI to attribute itself on the PR?
Unironically: the vibes
it's not the harness, but the objective. A load-bearing center. We break it down, and adjust.
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?
AI coding does not inherently come with that tradeoff, engineers make a decision to accept it because they think they are 10x more productive.
Yes, sometimes I wonder if the right interface was actually something like Github Pilot’s inline code completions rather than agentic loop.
But if your coworker is shipping 5x more PRs than you your manager couldn’t care less about understanding code
Yeah, the interactive editing loop isn't very good sadly, even when you want that :\
There's the "inline editing" paradigm - independent sessions, describe each micro-change individually. This is good for quick responses but requires you to re-describe the context every time. There's also the "use an agent as a fancy code editor" stuff - just list out all the functions and the changes you want to make in them. This is a better workflow IMO but the trap is that it doesn't feel "productive" compared to one-shotting it, irrespective of the actual quality.
So people gravitate towards one-shot agentic prompts without a human in the loop.
Every heavy handed ban on AI is just an example of an over-moderated and over-opinionated community.
I just started archiving my repositories; I still run the code, I still tinker in the background, but no more slop reports.
Users can continue to fork my code, if they wish, and it is still available, but I'm done fighting submissions.
Although recently I've started getting more spam by email from scrapers which are obviously AI based. Just yesterday:
"We reviewed your "Added generated syscall identifiers" in skx/slisp and selected it for the hub. It is a substantial piece of work: 3 files and about 390 lines across packages." Some bollocks AI coding hub, where apparently people will be able to see my code when they have 100% identical problems. Meh.
I'm almost reaching the point where I want to make repositories private, and maybe it will come, but for the moment things remain.
I just leave one-three repositories "open", and archive the rest. Then when my interest shift, or I need to go back to something old I rotate them.
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/
Qgis is a pretty useful software and a great OSS project, but I wouldn't go as far as putting that low. That honour goes to GDAL/OGR, PROJ, et all.
QGIS is more of a slab/deck that links all those foundations together.
I assume multiple agents are porting the 2.4 M QGIS LoC over to Rust right now.
RIP.
Not a rewrite, but close https://github.com/opengeos/RustGIS
I think a better approach is needed than a complete ban on AI contributions.
Just throwing such contributions out is a big loss.
I have gained a lot of experience working for over 20 years in our industry, but writing CUDA Kernels in not one of my skills or something I'd want to spend weeks to learn.
So recently when I was trying to run a particular local AI model and the inference software was running pretty badly I haven't even considered debugging it myself. It would take me weeks to even start properly.
But it was Saturday evening and my Claude Code usage resets on Sunday and I haven't used any of my Fable 5.1 quota yet this week. In fact I found no need to use fable at all, opus doing everything I needed.
So I decided to let fable work on a problem overnight. Llama.cpp, fix the bugs that cause horrible speed decay in Qwen3.8-Flash-Next in longer context and with multiple users. I told it it can build llama, run it on my hardware and iterate as much as possible.
In the morning I found it finished. It managed to produce up to 10x speedup in some cases (running 5 simultaneous users, with long contexts). 6 thousand lines of code. 19 patches. A ridiculous amount of work. Each patch explained in a readme. Speed tests run before and after for each.
This code made a huge difference for me. Suddenly I have a local model almost as capable as opus that I can run in 5 simultaneous claude code/pi sessions with further 5 sessions idle and cached in RAM.
I've run that code for last 3 weeks. It hasn't crashed once. It hasn't failed me once. Based on it I created a system where fable, limited to 200k of contexts only distributes work to 5 Qwen agents. This way I could do far more of such type of work (including fixing vllm and adding missing features to it in a similar way).
But would I ever post my 19 patches as a PR to llama.cpp? Hell no. I do not know what other models they will break. How they will behave on other people's hardware. Or how contrary to architecture authors have in mind they are.
So what did I do? I want those fixes to make their way to llama.cpp eventually.
I published it as a "temporary fork". I posted about it on the llama.cpp discussions. And I hope authors will use that code if they want to speed that model up.
If not, that is fine too. People like me that can benefit from those fixes also have access. And I'm not risking my professional reputation by submitting something I haven't read and fully understood.
Stop this typical verbose damage control. This is Jehovah's witness level or worse.
Come to Jesus, come to AI, written in an engaging novelist style. Maybe sell the rights to Hollywood.
Reality: No software has gotten better since AI, and only the tinkerers and learning-resistant cherish AI and promote it like their favorite computer game.
Waiting for GisCraft repo to be started.
for what purpose? qgis is already free to use, unlike Adobe's CS
You can always make it shinierer. /s
I think just putting your head in the sand doesn't work long-term on this topic – tech is changing and contribution best practices will have to accordingly.
Could be worthwhile looking into how the folks at OpenClaw are doing it, or at some of these projects that are at the frontier.
I suppose strong and automated AI screening, using PRs more as prompts rather than as direct contributions, and potentially liberal use of just closing PRs are useful patterns.
Community code contributions are no longer valuable. That's just the reality. Ideas are valuable, feedback is valuable, un-vetted code is no longer valuable.
Banning AI contributions is just the first step. Contributions are just generally no longer useful when given the idea you can have an llm do the work with 1/50th the effort it would take you before. Even with repeated rounds of feedback and correction it is less work to have an LLM do the work for you than it is to manage an eager contributor attempting the same work, and the result is going to be better and more in line with what you want.
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.
A good way to look at it is if I can use AI to add a feature/fix a bug, so can the maintainers. My doing it adds no value to the project. In projects where I am the maintainer/an employee, I can extract a lot of value from using AI to build, I don't need anyone's help to do it.
AI generated output is not art. Art is made by humans as an expression of their human experience. AI images are just statistical approximations of others' art
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.
"Value" of a PR is somewhat overlooking the fact that it's code we're talking about. A great and large feature with terrible bugs has some "value", but you definitely don't want to review that PR for nothing, because it definitely won't be accepted.
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.
back to non-GMO organic code
Not sure if good, but I get it, the velocity is so fast that even perfectly fine AI pull requests will add a ton of new features to the software as people mostly go "I have problem X can you write a feature for me that solves it?" and in the end you end up producing a "The Homer" [1] which has every conceivable feature under the sun but doesn't have any cohesion or logic between them, so user experience is subpar.
Then again maybe that's where all software is heading, if AI can produce features on demand at infinite space there might no longer be specialized software, or at least not nearly as much, as people will just code their own solutions tailored perfectly to their use case.
On the weekend I wrote a full-fledged 3D planner where I modeled my whole house based on plans and written descriptions I handed to Claude, it runs in the browser, produces high quality renderings, has path tracing for realistic lighting and materials and builds real objects like windows based on specifications and blueprints, so you can actually see how stuff looks like (unlike with AI images where proportions are always off). For me it's way better than SketchUp and it works completely dialogue based and allows me to experiment with furniture, window styles, doors, colors etc. in a super intuitive way. There is software I could use for this but why bother at this point? This whole thing took me a few hours and maybe 10-20 € in AI credits to build. Why try to use open-source software where I need to wait weeks for a reply from a maintainer?
So I think these projects fundamentally misunderstand where software engineering is heading, they are trying to hold back the flood but that will only lead to them being left in the dust once people realize they no longer have to wait for maintainers to update their sanctioned software timeline for you. That said, I think it's also ok and maybe even beneficial to be very protective of your feature set. There will (at least for now) still be room for complex core software that can serve as a basis for AI modification, so from that perspective it might be good to keep the core really tight and fully audited. My little software project only exists because three.js and other libraries provide most of what I need as LLMs will not write everything from scratch in such a short amount of time.
1: https://simpsonswiki.com/wiki/The_Homer
A bit crazy to see all the comments complaining (and insulting) about QGIS while they have never used it and will never use it anyway. And I'm using AI myself....
The developers and maintainers are explaining that the amount of slop they receive is unsustainable, what do you even complain they try to find a solution?
I say this as a long-term and loving user of QGIS: QGIS is proof that human-only authorship is no guarantee that code will be bug-free and well-designed.
I don’t have a good solution to their slop problem, but I also don’t have a good solution to their overall bandwidth problem. I like QGIS better than any other GIS software I’ve had the misfortune of using, and at the same time brace myself a little bit every time I open it up because there’s a solid chance I’m going to have encounter another weird quirk or awkward workflow that I haven’t figured out The Trick for…
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.
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
This really is exasperatingly unserious.
No, you cannot replace what QGIS is to its users with a couple of prompts and a factory of agents.
Any more than you could do it with FreeCAD, really.
These things, whatever their shortcomings, are unique in scope for open source projects and are the centre of large, multi-decade communities of collaborative users and developers.
But I invite you to try. Do it, clone QGIS. Then go to the user community and say "your software was bad so I cloned it, you should all use mine because we accept AI contributions". See how it works for you.
It's actually quite serious.
> No, you cannot replace what QGIS is to its users with a couple of prompts and a factory of agents.
You absolutely could. Maybe not to its users, but the core functionality would be the same.
> Any more than you could do it with FreeCAD, really.
Didn't that dude clone the whole Adobe suite with a single prompt? Well a prompt per app, but my point still stands.
> But I invite you to try. Do it, clone QGIS. Then go to the user community and say "your software was bad so I cloned it, you should all use mine because we accept AI contributions". See how it works for you.
Obviously if I clone QGIS it would be because I'd be using it for my own projects. But without being disrespectful here, I quite honestly do not see the point of this library whatsoever. I was under the impression that _most_ GIS work was either outright trivial or specialized enough that it warrants custom code regardless. I don't understand who needs this.
> But without being disrespectful here, I quite honestly do not see the point of this library whatsoever. I was under the impression that _most_ GIS work was either outright trivial or specialized enough that it warrants custom code regardless. I don't understand who needs this.
Oh come on. You’re doing a bit here, right? You cannot possibly be serious.
I don't imagine they will care if you do that, there will be no detrimental effects to them from doing so.
I am down to bundling forked inference engines in my huggingface models. They do work and do things impossible with base package, yet I don't have time to understand all the details of say sglang code and get it to a state where maintainers will probably accept the PR, for example make the patch work with every other model. Think of it from contributor point of view as well - I made something to work for myself, would love to share it with others but others don't pay my salary. I am not sure what the solution is, maybe have a big draft PR pile a peridodically AI-scan for top enhancements that seem to be a common need and are worth more knowledgable maintainer's time to inveatigate? At the same time, other users can also have their AI agents hunt there for personal fix ideas.
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.
The community is relying on the obscure process flows they've learned and optimized for their own purpose; replacing QGIS will probably wipe out jobs.
Couldn't happen sooner.
Then I encourage you to kick down that fence.
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.
Lol.. i have 20$ codex 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.
a Rust rewite is silently being crafted somewhere, and TBH - myself really expected QGIS to get a total rewrite much sooner.
It is. Look at this: https://github.com/opengeos/RustGIS/commits?author=giswqs
Dumb mafioso.
ok
What's next. You are only allowed to edit with notepad.exe? I don't think putting up random challenges to slow down the creation of PRs is a good idea.
This isn't random. It's based on the specific nature of AI. It's a good idea if the entire community doesn't agree with the spirit of AI, which apparently they don't.
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.
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.
It is so sad than any open source project that bans AI is subject to five minutes of hate by the industry influencers.
The same influencers by the way who are just for hire and were preaching DEI and Covid boosters in 2022 but now support Trump, Kushner, BigAI (and local AI as a figleaf).
Bro, I dare you to go a whole day without trying to make every single thing in your entire life about politics. Can you do it? It's a low bar, just resist talking about politics about 1 thing per day and you will have completed the challenge. I bet you can't do it. I think if they under cook your boiled egg you will try to draw some line between that and whatever political issue you are being force fed on news sites.
Whether or not to accept LLM generated code to your highly technical open source project has literally nothing to do with DEI policy. Not everyone is an American. Not everyone is reading about politics all day long and desperate to debate it. Touch some grass.
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.
Well, it's their choice. If you care about the process - i.e. it's a hobby for you, or a spiritual experience, then it's totally valid to go without AI.
But I feel it's a bit crazy not to use any AI assistance to develop real code these days, if you care about outcome. You can get to result much faster, and have a higher quality solution, if you use it right.
The problem for open source is low quality slop, not AI assistance. Not sure what's the solution though.
Such an awesome way to kill a somewhat useful program. Just keeping putting nails in the coffin. The future is here and it's NOT reverting no matter how much people want to stick their head in the sand.
calling LLMs "The Future" does not address the concerns they state in that discussion
> 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.
And another open source project consigns itself to irrelevance.
GIS is niche and technically difficult enough that I doubt your comment is right.
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?
Funny to see this while in other threads someone else will ask why HN hates AI so much.
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.
> 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
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...
I recently started using Claude and I found it great that Claude is constantly writing tests since I did not due to lack of time. That said, Claude has this ability to reach into test harnesses and output all kinds of obscure syntax and language features that the tests are hieroglyphic. I'm pretty much like 'ehhhhh ok claude, you do you...i'm just going to keep writing the business logic over here..."
Calling your own opinion objective is not a good practice. This is very much something you can have different opinions on.
> Why is everybody all the time in favour of AI on HN?
The opinions regarding AI are quite diverse here, most people are, I think moderately pro-AI, the top comment "A ban is a bit harsh but I understand the reasoning" summarizes it well, but many are in favor of banning AI contributions to open source projects too. The extreme slop cannons and Butlerian Jihadists are usually not well received.
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.
The LLM changes the cost-benefit analysis. It lowers the cost of fixing papercut-level issues to the point where they make sense to fix.
Plenty of them annoy millions of people but there wasn't any budget or time to fix it.
Is 130 million dollars impactful enough? [1]
[1] https://www.reddit.com/r/Bitcoin/comments/1vddeuy/are_you_ki...
>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.
Simply adding features doesn't make the product or technology exceptional. I think the industry know in the phase like "ok, i can close my one thousand github tickets in a week". But that won't make their product or technology significantly better. Creating an extraordinary product is an extra ordinary task that only humans are capable of for now.
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.
I don't think this is necessarily true at all. Objectively is very long stretch before we observe whether this the right approach or not. AI can increase the code quality the issue as i see is not this and it's neither mentioned in what I read about their decision, it's mainly the issue of not being able to keep up when the bar for creating have decreased significantly and the capacity to curate and evaluate is still the same. This is case where the system is overwhelmed so you start controlling the input to keep the desired output the same.
> 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.
I don't think that's accurate about the mood on HN, but a lot of us have been coding almost entirely with frontier models for a long time now.
I haven't written a line of code myself since March. I've shipped over 100,000 lines since then. And coding isn't even what I spend the majority of my effort on.
It really works. I just had Opus 5.5 write a distributed load testing service on Friday and it's been using what it wrote to iterate and diagnose problems over the weekend.
Typically something is "objectively" the case if there is indisputable evidence for it (of which you provided none).
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.
Because a crazy amount of money is at it, mixed with a good portion of genuine psychosis and a little bit of FOMO.
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.
> This is objectively a good change because it will improve the quality of the code in the long term.
I think humans will be saying this long, long after it's not true anymore. I'm not sure it is right now, for 80+% of developers and projects.
But I love this muddying of the waters. The more uncertainty and misinformation it is, the easier it is for people to make mistakes, and for edges to be had.
It's like poker. Everyone thinks they're a good player. About 5% of players (my estimation) would admit they're not very good. The luck & complexity fools the rest of 'em. They have no idea you can be operating several levels deeper than they are, playing in a dimension they cannot yet see.
Anyway, not a perfect analogy. But I think your idea was true, isn't true now, and I hope people & projects keep banning AI contributions anyway.
Because this is a startup/tech community and people generally look forward to exploring new ideas and tech?
Why are all of these mathematicians in favor of graphing calculators?
I am not, but I just lurk here - I think that so called 'AI' is at best some clever use of math, and data science. Some of the underlying techniques are well worth a persons time when used sparingly. Classify these under the term machine learning. Peoples simpering & enthusiastic dash to offload tasks to this trendy 'AI' craze is infuriating. Its support here is unsurprising given the sites demographics.
> 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."
> 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.
Given the soul-crushingly large amounts of money sloshing around in this tiny slice of the industry, the amount of astroturfing, positive-sentiment manufacturing, & etc. is right about where I expect it to be... as is the amount of vehement denial that it exists. ;)
The other option: people are using AI successfully on the job and are writing based on their own experience.
>> Given the soul-crushingly large amounts of money sloshing around in this tiny slice of the industry, the amount of astroturfing, positive-sentiment manufacturing, & etc. is right about where I expect it to be... as is the amount of vehement denial that it exists. ;)
> The other option: people are using AI successfully on the job and are writing based on their own experience.
Those aren't mutually exclusive.
And it's worth noting that people claiming to use "AI successfully on the job" often do not stop at "their own experience." They often make sweeping statements like "LLMs write better code than people," and attack any critiques or skepticism of LLMs.
...and here's the denial!
A careful reader of my post notices that I neither said nor suggested that there were no honest success stories. ;)
But the majority of positive sentiment probably isn't turfed. HN is not that important, it's a small forum. Is some money being spent to boost the image of the industry. Probably. But if you read most comment sections, they are organic users which are posting positive things.
> HN is not that important, it's a small forum.
cough
It's at least as important as Slashdot was back in the day. I'm not "buying" what you're "selling", dude.
I'm not selling anything.
This link is provided just in case we're in the _unlikely_ situation where you're unfamiliar with the the phrase. [0]
[0] <https://www.quora.com/When-and-how-did-the-meaning-of-the-te...>
> I wouldn't be surprised at some unexpectedly large amount of AstroTurfing, especially considering the sheer amount money is flowing into the AI space.
Including money from Y Combinator itself (which, may we never forget, was once helmed by Sam Altman).
If you're looking for unbiased tech news and genuine user sentiment, you probably shouldn't be getting it from one of Silicon Valley's favorite VC firms.
> ...may we never forget, was once helmed by Sam Altman
Didn't he get fired because enough of the other YC partners couldn't trust him? If so, it's a pity for him that -at that time- he didn't have the CEO of a software megacorp to call on to reverse the decision and shitcan the people who made it.
Name the alternative tech news / user sentiment sources. I want to widen my reading.
lobste.rs
Sadly, it's succumbing to the "the mods are -justifiably- uncomfortable with cleaning house and the quality of discussion is regressing to the Internet Mean" disease that every pretty-much-open-access link aggregator that attaches a link discussion forum contracts.
> 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.
I don't think suggesting that people are stupid is a very good argument. I think part of the reason people are for it is post like yours which are rude and not in good faith.
I'd imagine why as many people are for it on HN is for many people, it just works. Now imagine this snark about not being as clever as you think you are just because you enjoy using a tool. What's that going to do? Cause you to dig your feet in because you're being told the real reason you like these tools is because you're not very clever or you take things as a personal criticism. Yes, being told you think you are clever but you aren't really is personal.
I don't think you're posting in good faith. I certainly don't think you're going to get the real reasons people support this stuff when you act like they're stupid or suggest a lot of this is being turfed. People are using these tools because they work.
Your post says more about you than it does supporters.
> I don't think suggesting that people are stupid is a very good argument. I think part of the reason people are for it is post like yours which are rude and not in good faith.
You'll note I didn't say anyone was "stupid," if anything, I was actually saying those people were myopic and arrogant. I recommend you familiarize yourself with the concept of "engineer's disease," once you understand it, you'll see it all the time on HN.
> I don't think you're posting in good faith. I certainly don't think you're going to get the real reasons people support this stuff when you act like they're stupid or suggest a lot of this is being turfed. People are using these tools because they work.
> Your post says more about you than it does supporters.
I don't think suggestion that people are posting in bad faith is a good argument. I also detect a fair bit of binary thinking from you. All I did was post a non-exhaustive list of different reasons for that kind of content to answer the comment I was replying to.
The only "binary thinking" I'm using is not assuming that the reasons that people support these tools are all negative (myopic and arrogant, false sentiment, defensiveness, and pedantism).
You didn't even try to suggest that a lot of people are using these tools for positive reasons. Who is being myopic and arrogant? Who is engaging in binary thinking?
Consider that some people simplye find that these tools work for them.
> I don't think suggesting that people are stupid is a very good argument.
I've worked with a lot of people. Many of them are that stupid. Suggesting that these stupid people do not exist, that -if they did exist- none of them are professional programmers, and -even if they were programmers- they do not have the means to voice support for something that they're smitten with is not a good argument.
I'll also vaguely gesture at the various studies that find that the majority of conversation -by post volume- on Internet Forums is done by a small number of people. Never doubt the ability for a few loud folks [0] with lots of time on their hands to dominate a conversation. This goes like 10,000x when there's a huge amount of money sloshing around in said industry and said industry really needs to maintain a positive public reputation.
[0] ...and -sometimes- their sockpuppets...
I didn't say that dumb people don't exist, I think positing that the reason people like these tools is because actually they're stupid isn't very compelling.
> ...I think positing that the reason people like these tools is because actually they're stupid isn't very compelling.
And I explained why I disagreed! One "subtle" thing to note is that the claim isn't "Everyone who uses LLM-based tools and writes about the success they had is stupid.".
Then you aren't going to get to why people are using these tools because a lot of intelligent people are using them.
> Then you aren't going to get to why people are using these tools...
I couldn't disagree more!
If you haven't already, you should watch this topical presentation from Greg K-H that was posted to HN like a week ago. [0] It's about an hour long, but you can probably watch most of it at 120->150% speed.
Notice how his praise for the tools differs from so much of the expressed positive sentiment for said tools here on HN. The "low-horsepower" people I've known tend to praise things in a way that smells very much like astroturfing. The "high-horsepower" people I've known both express very nuanced opinions and tend to know better than to burn a ton of time squabbling with Internet Randos in a place like this... they have much better things to do with their lives.
[0] <https://www.youtube.com/watch?v=NnV_cWeoo5Q>
I don't observe the same things on HN that you do. I see a variety of sentiment - positive, negative, low-effort and high-effort.
> I see a variety of sentiment - positive, negative, low-effort and high-effort.
Me too!
> The "low-horsepower" people I've known tend to praise things in a way that smells very much like astroturfing. The "high-horsepower" people I've known both express very nuanced opinions
I think that's a good observation, but I wouldn't say those people are actually astroturfing (noting you only said they smell like that).
But that "low-horsepower" vs "high-horsepower" distinction probably has a big bearing on people's attitudes towards LLMs. "Low-horsepower" people are simultaneously much more easily impressed and often lack the skill to properly evaluate the output they're getting. It's often been remarked that LLMs feel awesome for topics you know nothing about. It's kinda like Gell-Mann Amnesia Effect for people who were never knowledgeable about any topic.
[1] "The phenomenon of a person trusting newspapers for topics which that person is not knowledgeable about, despite recognizing the newspaper as being extremely inaccurate on certain topics which that person is knowledgeable about." (https://en.wiktionary.org/wiki/Gell-Mann_amnesia_effect#Engl...)
> I think that's a good observation, but I wouldn't say those people are actually astroturfing (noting you only said they smell like that).
I agree with everything you've said here [0] as well as this bit I'm quoting specifically. I would strongly disagree with any claim that positive reports from "low-horsepower" people are likely to be astroturf. I'm just noting that a lot of astroturf reads like the way the "low-horsepower" people I've known tend to praise things.
[0] ...at least with whatever the comment said when I wrote this one ;)...
> I agree with everything you've said here [0] as well as this bit I'm quoting specifically. I would strongly disagree with any claim that positive reports from "low-horsepower" people are likely to be astroturf.
I think we're in agreement.
> I'm just noting that a lot of astroturf reads like the way the "low-horsepower" people I've known tend to praise things.
The "why" behind that would be interesting to know. It could just be that we assume astroturf would be low-effort, and that praise is low-effort (even if that's the most effort the "low-horsepower" person can muster), so they read the same.
> I think we're in agreement.
Ditto!
> The "why" behind that would be interesting to know.
I'm going to briefly noodle on about why I think astroturfing generally Sounds Like That, and then attempt to answer your implied question.
So my hunch about the tone of astroturfing is that it's _kind of_ like 419 scams. [0] Perhaps none of this is new to you, but I write it down anyway:
1) Creating detailed praise that withstands scrutiny is a lot of effort, whereas expressing positive sentiment in very broad strokes is extremely easy. If your strokes are broad enough, you can probably often reuse the praise, saving even more time and effort. Similarly, defending criticism of detailed praise is much harder than defending broad-strokes positive sentiment.
2) If you want to hire live people to astroturf on message boards, people able to effectively defend detailed praise are surely going to be much more expensive than those who can only handle the vague broad-strokes stuff.
3) The target of this astroturfing deliberately isn't someone who can scrutinize detailed praise... in part because of how much work it is to author that praise, and in part because the people with power and/or purchasing authority are the ones you want to target... and it's often but not always the case that those folks lack one or more of the time, background information, or horsepower required to perform that detailed scrutiny in the first place. So, why waste the time, effort, and money?
Now please excuse the dogshit writing style of the following attempt to address your question, I'm definitely having a "low-horsepower" day today...
But why do "low-horsepower" people tend to praise in that way? speaking as someone who definitely has "low-horsepower" days, and who has occasionally been an absolutely godawful teacher, it might have something to do with the whole "You can't effectively teach someone something if you don't have a solid understanding of it yourself." thing? Both detailed praise and good instruction require a detailed understanding of the thing in question.
So part of the reason might be that "low-horsepower" folks tend to have just a surface understanding of the thing they're praising, so they cannot really create detailed praise. [1]
Both praise and instruction invite questions from the folks who are around to hear it. Folks who are capable of feeling shame often feel shame when when they present themselves as someone who is far more knowledgable about something than they actually are and questioning reveals the deception.
So another part of the reason might be to avoid in-depth questioning -both to determine the justifications for their praise, as well as to gain an in-depth understanding of parts of the thing being praised that the praiser is entirely unequipped to provide-. If one gets a vague "IDK, it's just good, right? It makes my work so much faster! I just like it!" response to your request for praise then that's a signal that you're not likely to get much more information if you ask probing questions. _Maybe_. This paragraph I'm super not confident in.
I'm happy to chat more about this, and will spend some time over the next day or so trying to phrase the gunk that's in my head better... but I can't make any promises that I will succeed at that.
[0] ...AKA "Nigerian Prince" scams...
[1] To downvoters: There's absolutely nothing wrong with this! Knowing just enough about your work and how to do it to satisfy your boss and keep your paychecks flowing is a solid way to live one's life. Precious few people do work that they like, let alone work that they're interested in... and it's my bone-deep belief that the best future for all humanity is one in which no one has to work unless they either want to or if having a job of some kind truly makes their life far better than not having one. Work sucks for most folks and putting in just enough effort to get the work done to the standard required is a fine way to engage with it.
You're again reverting to the only reason people like these is because they're stupid.
People are writing entire apps in days. You're just jaded if that isn't impressive to you.
Nope.
You:
Me:Thanks but I'm not going to watch it.
> people are simultaneously much more easily impressed and often lack the skill to properly evaluate the output they're getting
Yes, this is the exact sentiment expressed. That the praise you see is because of these people with low-horsepower who aren't capable of evaluating their own experiences.
> Thanks but I'm not going to watch it.
You really should! It's positive sentiment about LLM-based tools that comes from a "high-horsepower" individual. Given your commentary here, it really seems like you've not encountered much of that sort of thing, so it'd really do you some good to load it into to your databanks for use in future discussions.
I've encountered plenty of it on HN and elsewhere, I just don't share your view of the space.
[flagged]
[flagged]
[flagged]
Well, yeah, when you are asked why people talk about these models on HN and your answers are: myopia, funded support, taking things personally, and pedantry and then you double down on it suggesting that another reason is these people aren't capable of evaluating what they are seeing, then you are only painting those people with a negative brush.
Do yo believe there are positive reasons people are adopting these models? Because there is nothing in your responses that suggest you do. I, as somebody who rarely uses these models but understands why people might, don't see any attempt at being unbiased.
[flagged]
You both broke the site guidelines badly and repeatedly in this thread, including by crossing into personal attack.
Can you please review https://news.ycombinator.com/newsguidelines.html and stick to them in the future? We'd appreciate it.
I got it now. This is just how you communicate, insulting people who disagree with you.
Frankly I don't think you've understood what I was saying but it doesn't matter. You keep saying I'm misunderstanding you but your bias is very obvious and I don't think you've answered why people are praising these models.
You both broke the site guidelines badly and repeatedly in this thread, including by crossing into personal attack.
Can you please review https://news.ycombinator.com/newsguidelines.html and stick to them in the future? We'd appreciate it.
As a less emotionally charged example (people get upset with being called stupid, justifiably) - the average size of an array or a list is less than 4.
With that many elements you'd be better off storing the elements as a tuple or a struct, but people often reach for a generic array container regardless.
> 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.
Related: the Rationalists display this very well (though it's certainly not unique to them). The jump from "I think my beliefs through carefully, therefore I am reasonably rational" (likely already false, or at best true in a limited domain) to "I am rational, therefore my beliefs are well-thought through" is actually very small in the human mind, despite the latter being the opposite of rationality.
Also, the existence of Gell-Mann amnesia should be taught to everyone!
> 3. I think there's a certain amount of defensiveness from AI enthusiasts.
I've encountered this as well. I think this is also a huge part of why you see so many people loudly exclaiming "every programmer uses LLMs now" despite that not being even close to true. If you criticize LLMs, it (socially, to them) counts as criticism of their users as well. As well, bosses are probably the most excited about LLMs because they hope to fire us all soon, so it can be pointlessly self-destructive to speak negatively about LLMs in a professional context right now.
That, plus AI boosters tend to be incredibly annoying about it, bringing it up at every possible opportunity, changing every technical discussion to be about them, suggesting them for the stupidest use-cases, loudly proclaiming nonsensical productivity boosts (perhaps you feel 5x as productive because you're forcing other people to spend their time fixing your shitty slop code?) etc. So as someone who does not use LLMs I avoid talking to them.
I just think this speaks more to people observing different things and taking that as ground truth. I notice the people who are critical of these tools because like the above post and yours, they are relentlessly critical without ceding basic things like people are excited about these tools because they are useful. I have 0 doubts some people are seeing 5x productivity boosts because of the stuff that is regularly posted on HN - stuff that used to take months taking days.
I'm not a booster, I barely use these tools but what I notice is the two apparent "sides" that people have shifted into and really I don't think that' necessary because these are just tools that have adnvantages and disadvantages.
> I have 0 doubts some people are seeing 5x productivity boosts because of the stuff that is regularly posted on HN - stuff that used to take months taking days.
I will cede this: it indeed seems like you can throw together a shitty half-working prototype very quickly using LLMs. There's been a deluge of half-working prototypes, but years in and where are all these projects now? No study has concluded anything near a 5x improvement.
Besides, my actual opinion is that even if these actually gave a large productivity improvement, it's wouldn't be worth it. The negatives are simply too large:
- the concentration of power they are pushing for;
- the environmental effects of training;
- the disinformation they spread at scale (which in practice is their primary use-case);
- the adverse effect on a shared reality from the fact that they cannot reliably answer questions, yet are presented as doing so;
- the adverse effect on a shared reality from their sycophancy (do the rich surrounded by yes-men seem in touch with reality?);
- their anti-social nature, as they discourage engaging with other people in favour of solipsism masked by a poor simulacrum of personhood;
- their weakening of labour power because of the managerial class' belief that they will soon replace workers (whether or not they actually can is not particularly relevant);
- the large-scale plagiarism they enable;
- lastly, their weakening of already incredibly lax standards of engineering from our field.
The promise of more software does not even come close to outweighing all of that.
It's just from my personal experience when I rarely use Claude, I can get it to produce things in minutes that would take me hours. They're not shitty, I can review what's been generated and it's better than I would have done. Similarly with the UIs we build here, they would take days or weeks and we can put them together in a few hours.
I can't speak to you other issues but these are here to stay and I think the only realistic way forward is to learn how to use them.
> It's just from my personal experience
I guess let's just ignore the evidence, then.
> I can't speak to you other issues but these are here to stay and I think the only realistic way forward is to learn how to use them.
People only say this about things that they want. Ignoring the consequences of one's actions is not a neutral position. Societies are perfectly capable of banning things (yeah, you can probably sneak a local model through a hypothetical law, but it would end the industrial scale problems).
> I guess let's just ignore the evidence, then.
There isn't any evidence. It's pretty much all anecdotal. I can only speak from my experience.
> People only say this about things that they want. Ignoring the consequences of one's actions is not a neutral position. Societies are perfectly capable of banning things (yeah, you can probably sneak a local model through a hypothetical law, but it would end the industrial scale problems).
We're not going to ban these models, though. Which means we have to figure out how best to live with them.
https://arstechnica.com/ai/2026/10/ai-coding-agents-generate...
> A recent study of actual coding practices across hundreds of firms finds that human code review forms a significant “bottleneck” for the overall efficiency of AI coding tools, resulting in “little evidence that firms increase software output or reduce employment” by using them.
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o...
> When developers are allowed to use AI tools, they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts. This gap between perception and reality is striking: developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%.
LLM boosters always cry foul with this one because newer models exist (see next item), but the fact is this is evidence that programmers are remarkably bad at estimating their own productivity.
https://metr.org/blog/2026-02-24-uplift-update/
> For the subset of the original developers who participated in the later study, we now estimate a speedup of -18% with a confidence interval between -38% and +9%. Among newly-recruited developers the estimated speedup is -4%, with a confidence interval between -15% and +9%.
With the rather large caveat:
> Unfortunately, given participant feedback and surveys, we believe that the data from our new experiment gives us an unreliable signal of the current productivity effect of AI tools. The primary reason is that we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI, which likely biases downwards our estimate of AI-assisted speedup. We additionally believe there have been selection effects due to a lower pay rate (we reduced the pay from $150/hr to $50/hr), and that our measurements of time-spent on each task are unreliable for the fraction of developers who use multiple AI agents concurrently.
> We're not going to ban these models, though.
How could you possibly be confident of that?
I guess there's a way to use them productively. I only use them rarely which means I use them when I know they'll speed me up and the tasks take a few minutes. I literally could not do the tasks in less than an hour or two, the same with UIs that get generated here, it's just impossible to be faster than the models.
> How could you possibly be confident of that?
I just don't see any indication that we're anywhere close to that. It would take a rather big shift in governance.
> you see so many people loudly exclaiming "every programmer uses LLMs now"
I see a lot of people going even further and claim that "it's impossible not to use LLMs now."
Not just among programmers talking about code either, you see it with non-tech people defending their overly long emoji-ladden AIspeak text posts.
I expected Venture Capital Reddit to be pro-AI, that's where the money is, after all. I don't know if it's all clout or if everyone just pretends to go with the flow not to risk like they're falling behind, but this isn't exactly a place for conservative software practices.
The utter disbelief people on HN show when they find out a lot of people hate or despise generative AI is much stranger.
Are you asking why most people from Big Tech, very likely working on AI-adjacent products, have a very strong pro-AI bias?
I'd reframe the question slightly. It has less to do with bias and more to do with experience. Anyone with experience to judge AI matters is likely going to be vaguely pro-AI in the first place, otherwise they wouldn't be qualified to answer.
Those that are opposed to AI development in principle, or have dealt only with its worst consequences, like neverending PR-slop, are going to have trouble engaging due to a lack of experience.
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.
AI already writes better quality code than humans. And you disagree I doubt you will contest that long term it won't be true.
If you truly believe that AI writes better code than humans, you've not been exposed to enough humans. It might write better code than humans you know personally, but you lose credibility when you try to present it as a universal truth.
I suggest you read the second half of my comment. Insisting that humans will remain better is an untenable position if you make reasonable extrapolations.
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).
Right, disallowing AI-generated drive-by PRs is completely reasonable; almost all of them should have just been bug reports or feature requests. If your AI was able to one-shot the code, the maintainers can do that themselves and it's going to be much easier for them to work with their own AIs rather than using you as a meat proxy.
> is myopic virtue signalling.
Would you personally join in to evaluate and review the onslaught of AI generated PR to the project?
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
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.
ok it needs to be reliable. do we believe people are more reliable than ai?
Short answer: Yes.
Long answer: These software packages generally have a couple (or more) graybeards on the team knowing the intricacies of the domain and the software pretty well, so they can read a patch, see the effects, make an informed decision and give required feedback, or sometimes get the patch, mangle it to correct form and merge.
LLMs tend to write overly verbose code with many file edits at the same time, accompanied by walls of text to justify itself. This overwhelms these kinds of communities. So, they prefer targeted, smaller patches arriving at a slower rate.
...and maybe that big patch can be written as a one-liner somewhere else, just because AI failed to find where the problem originates and just patches where the problems happen, making thing way more complicated than before?
These are complex software packages and are sometimes things looking correct are wrong, and things looking wrong are correct, esp. on the math side.
I developed software using boundary element method to evaluate things, and it was complex to put it mildly. Verifying everything down to 32 significant digits after comma, and tearing the code down when the tests deviated for no apparent reason is something I did regularly.
GIS is no different. You're modeling the world, down to the earth's curvature, and putting things on it with cm level accuracy, and a couple of people knowing what they are doing is way more effective than a statistical model which emits code with no bounds and understanding of the domain.
oh. so basically, no low effort patches.
Sounds like llm's have made is so easy for anyone without a shred of know how to submit anything that people prompt one or two times and consider the job done, not knowing any better becausue they don't have to.
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 a partial (edit) 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 safer 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 agree with you, I'm just laying out what I believe the real ban that makes the most sense would entail. It does sound like they dont even want to hear that you used Stack Overflow if it came up from Google's Instant Answers AI thingimabob.
> My point is, if projects are actually serious about banning AI, write that down in enforceable language.
You're under the false impression that the maintainers of a project are obliged to follow the same standards as a court of law.
> 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
False.
If you are the enforcer, which the maintainers are, then surely any rule you come up with is enforceable in exactly the kind of way you'd like it to be enforced?
This is a bit naive. People write emotional rules and laws all the time. They may even work for a little while. Then one of two things happens, maybe even both at the same time.
First other people poke at the gray areas of the rules which leads to the "you accepted x, but not y, this must be favoritism when allowing AI posts". Things degrade into insane rule lawyering.
Or, you end up with insane sets of rules and enforcement that kill the project. We've seen a lot of project leaders recently just act kind of mental. Quite often it will lead to the project forking and falling apart.
Well written rules for a project matter even more than well written code.
This is why I prefer very loosely written rules in a pseudo-common-law system :)
i.e. have few, generic rules, and have their boundaries be constrained by implementation. The important part is consistency. There is a boundary, it's just unstated. If you're enforcing stuff arbitrarily, this won't work, but if you're mostly consistent this can make things smooth by eliminating the space for rules lawyering, drama and schemes by getting everyone in the community to "sign up" to the status quo.
When you're new you don't know where you're at so you join, observe and listen. After some time, you're familiar with the norms so you can engage with them, advocate for changes, etc.
Of course, the alternative is codified rules for everything, but the moral hazard there is that the more rules you add, the more they're likely to be contradictory, leading to the possibility of arbitrary enforcement nonetheless despite the pretence that the rules are specific and clear so the enforcement isn't arbitrary at all.
> 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 many companies do just ban it outright.
> Baby companies do just ban it outright
This might be the key point. There's legal ambiguity surrounding these licenses. Large companies with legal resources can draw their own line in the sand to protect themselves.
But small companies don't have the resources or the bandwidth to address the ambiguity. So a blanket ban (Zero AGPL and GPL for Internal or SAAS, Linux generally gets a pass) is rational.
Likewise, I see small dev shops without the resources to address anti-AI policy ambiguity are going to defer contributions until further notice.
Sorry, "baby" was a typo for "many"! I've fixed it now.
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.
Lol. You say no further definition is required - then proceed to outline your interpretation which is quite distinct from others. Clearly further definition is required.
If you're serious about an anti-AI policy, you owe the world a definition. It's not hard. You are making a strong statement - an outright ban. Make an equally strong case for what is and is not in scope. You must get in the weeds, since it is you yourself that is banning the weeds.
To quote Gustave Flaubert: “The art of writing is the art of discovering what you believe.” Failing to write the definition is a strong signal that no one thought through the problem.
No, my example is one of where you end up if you start doing granular definition (and demanding to know where the line is, to the point of absurdity).
A broad stroke based on community trust and your own self-evaluation of a very simple rule is acceptable here.
If a contributor wishes to poke the edges of the policy to try and find the line of acceptable AI/LLM usage in the project, they are probably not the kind of contributor they want.
> If a contributor wishes to poke the edges of the policy to try and find the line of acceptable AI/LLM usage in the project, they are probably not the kind of contributor they want
I think this is where it becomes a question of whether it’s an ideological rejection of LLMs or a technical/practical rejection of LLMs.
A project that is rejecting contributions where LLMs are used purely because of the “we can’t handle the amount of newbie generated inbound slop” would, in theory at least, have minimal issue where the contribution is, in fact, indistinguishable from human-only contribution. “This person has put together a solid clean patch that solves a real problem” sounds like a great kind of contributor to have.
On the other hand, a project that rejects LLM-assisted patches because of ideology or social or environmental concerns might actually hate a contributor like this even more than a random drive-by slop contributor.
> put enforceable guardrails on the definition
This is the issue!
Without objective, verifiable criteria, the rules cannot be enforced. Rules without enforcement rely on the strength of community norms, which we don’t have in this case.
All you’re going to do is end up banning obviously vibe coded crap. If that’s what they mean, say it.
In spite of the positive reaction, this IS a bad policy because it isn’t enforceable.
Keep thinking - we need guidelines that focus on our needs and goals, not the basic mechanics of code creation.
> For an outright ban on "LLM, AI or agent assisted code contributions", they do very little to define what that means.
It means: did you use AI? If so, we don't want it.
Like come on. They don't like your new shiny toy and you're mad about it, but there's no need to be purposely obtuse.
You fire up an IDE, you write code, you submit it. That is not an AI contribution. You fire up Claude Code and prompt it, you submit it. That's an AI contribution.
Contributing to projects is a privilege not a right, and if you fail to contribute, be it because your PR was written like shit, be it your documentation wasn't complete, be it you didn't abide the style guides, or, yes, be it you used AI and they don't want AI, your submission doesn't go in. That's that. 2 + 2 = 4.
To be blunt it's wild that otherwise very intelligent people keep getting bluescreened by the fact that they occasionally must reckon with other intelligent people who do not necessarily believe the same things as them. Have y'all never gone outside or what?