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.

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.

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.

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.

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.

> 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.

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 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.

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.

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.

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...

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).

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.

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

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.

Can someone, maybe the team at craft, please make a clone of ArcMap?

- 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.

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.

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?

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?

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.

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?

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?

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/

I assume multiple agents are porting the 2.4 M QGIS LoC over to Rust right now.

RIP.

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.

Waiting for GisCraft repo to be started.

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.

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'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.

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.

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.

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).

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.

> 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.

And another open source project consigns itself to irrelevance.

[flagged]

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.

[flagged]

[flagged]

[flagged]

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.

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.