Hacker News

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.

LLMs really don't understand space.

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.

Use Astra.

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

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.

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.

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.

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.

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.

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

> 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

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.

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.

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

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.

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.

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?

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.

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.

[1]: https://github.com/storytold/lightcraft

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.

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.

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.

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.

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

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!

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?

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.

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.

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.

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

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.

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

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.

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.

The new policy says:

> If we subsequently discover that you have used an AI, LLM, or any agent-based workflow for your contribution, you will be subject to code reversion and contributor rights sanctioning.

Policies like this have an element of trust to them. That's not new: open source projects have needed to trust contributors not to paste in proprietary licensed code since open source began.

Of course, if you sneak in a simple patch that an AI agent wrote for you, nobody might notice. The fact is, maintainers of big OSS projects are increasingly dealing with patches in the 10kLOC range, all at once, coming from people with little to no previous engagement with the project: that's usually a dead giveaway.

I really don’t think those are the same people. Goomba fallacy, etc.

Unironically: the vibes

AI coding does not inherently come with that tradeoff, engineers make a decision to accept it because they think they are 10x more productive.

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.

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.

for what purpose? qgis is already free to use, unlike Adobe's CS

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.

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…

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

I don't imagine they will care if you do that, there will be no detrimental effects to them from doing so.

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.

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.

but you can just fork the entire repo and continue development with AI yourself, why the need to rewrite it from 0?

a Rust rewite is silently being crafted somewhere, and TBH - myself really expected QGIS to get a total rewrite much sooner.

Dumb mafioso.

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.

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.

calling LLMs "The Future" does not address the concerns they state in that discussion

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

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?

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.

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.

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

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?

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

Are you asking why most people from Big Tech, very likely working on AI-adjacent products, have a very strong pro-AI bias?

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.

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.

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.

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.

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.

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?

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

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.

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