The question I have is what is an AI assisted contribution? For example, I still right 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.
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 communities 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.
Saw it the other day on twitter, and wondered why is it not part a of the ArtCraft :D Perhaps they didn't realize this ArcPro thing exists. Jokes aside, the rewrite may pave door for many people actually turning to this workflow, and to an actually working GIS software.
Most of the GIS people I know, and I really know some, are totally oblivious about the underlying magic of QGIS or ArcPRO, and many of them would happily go away from both for many reasons.
Mind U - ArcPRO is also an ecosystem, no only maps layer, is actually an ERP of sorts, when tied with the ArcServer and the rest in their design. But is quite heavy, super bloated (ArcPRO brings own Python, Postgres, Java, and perhaps the whole proj+geos libs also and whatnot).
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.
> 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…?
Then replace the maintainers with ones that can do that. Most can.
No need to paste something into a AI tool, just tell the tool which email or which ticket to fix or check. Maintainers who cannot do that, are not worth it.
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.
I've never seen a maintainer complain about receiving correct and well written bug reports. I don't just dump one liners or shower thoughts at them, and my text is all entirely human written and researched. I'll let the maintainers use AI to turn this in to a final code change since that skips the costly review steps.
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.
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.
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...
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.
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..."
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.
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.
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.
AI will soon be the majority of all cognitive intelligence by orders of magnitude. Insisting on human-only contributions to software projects is like insisting on hand-weaving a t-shirt when a loom can do it for a dollar. These projects only do it to limit spam from public contributors.
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.
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.
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.
> 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. ;)
> 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.
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.
> 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.
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.
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.
> 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.
> 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.
> 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.
> 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.
Well, yeah, just today there was an article here on HN about Photoshop AI clones that claimed, with absolute conviction ("trust me bro"), that users of AI were pedophiles just because "AI bad". The anti-AI sentiment has gone so extreme that it's easy to feel judged just for enjoying tinkering with AI, specially when all sorts of weird claims are made towards your character just because internet arguments are serious business and "the other side is evil" and the hate and violence must be justified. "It's okay to attack them guys, they are pedophiles, nazis and fascists, so hurt them as much as possible without any guilt!"
Even if you aren't doing any of the things they are complaining about with it.
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.
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.
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.
> 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.
> 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 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 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.
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
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.).
> 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.
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.
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 explain themselves. 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 and 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.
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.
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.
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.
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.
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
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.
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
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.
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.
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 were 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.
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?
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.
> 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.
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.
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.
> 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.
> 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
> 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.
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.
I don't know if we are talking about the same stuff, also let me first state that I don't like Effect, Zod, and the like, so I'm really talking about types here.
If you get them out of the way, I literally need to do the type inferring myself, not a problem if I'm looking at a small and trivial function, but if I'm trying to understand a "conversation" inside my code I really want that job already done by the compiler, this is also to tell that more of the "dumb/mechanical" computation is done by the compiler/interpreter the better, this is why we always wanted to get rid of syntax because we want to read english but at the same time we cannot use english because we don't want ambiguity. Writing clean code allow for the right compromise. I believe LLMs can write clean code with the right instructions, the same you would tell a junior dev, but one thing they will never succeed (unless they litreally copy) is architecture, because that is not teachable by writing (instructions/guides/etc.), only by doing and feeling.
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.
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.
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.
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.
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.
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 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!
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.
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.
- 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.
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.
"Intelligence is compression" thinks in the realm of the a priori and concepts; I'm applying this to how the world operates.
I'm glad you noticed the comparison, but in practice people will take "intelligence is compression" and then not apply this to how the real world operates. Also there isn't as much of a formal backing between the thing I'm saying as there is "intelligence is compression" (well, specifically, prediction is compression into "prediction is intelligence").
Importantly, my claim is not a claim of "maximally intelligent people compress more and do magic" or some bullshit like that. My claim is a negative constraint on what even a hypothetical superintelligence will depend on.
287 comments
[ 3.8 ms ] story [ 56.7 ms ] threadFurthermore, 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 communities 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.
Most of the GIS people I know, and I really know some, are totally oblivious about the underlying magic of QGIS or ArcPRO, and many of them would happily go away from both for many reasons.
Mind U - ArcPRO is also an ecosystem, no only maps layer, is actually an ERP of sorts, when tied with the ArcServer and the rest in their design. But is quite heavy, super bloated (ArcPRO brings own Python, Postgres, Java, and perhaps the whole proj+geos libs also and whatnot).
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.
And that is why you felt you needed to boost the narrative and reinforce it so people are fired faster. Totally believable!
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.
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
My experience is that maintainers cannot do this. Or rather, that it is useless.
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…?
No need to paste something into a AI tool, just tell the tool which email or which ticket to fix or check. Maintainers who cannot do that, are not worth it.
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.
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...
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
Not to mention that the thought out LLM assisted PRs won't even register as LLM assisted PRs...
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.
Can you explain why you think that?
QGIS is written in C++. Does that affect t your answer to this question at all?
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.
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.
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.
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.
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.
Funny to see this while in other threads someone else will ask why HN hates AI so much.
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."
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. ;)
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.
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.
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.
[0] ...and -sometimes- their sockpuppets...
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.
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.
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.
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.
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'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 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.
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 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.
Well, yeah, just today there was an article here on HN about Photoshop AI clones that claimed, with absolute conviction ("trust me bro"), that users of AI were pedophiles just because "AI bad". The anti-AI sentiment has gone so extreme that it's easy to feel judged just for enjoying tinkering with AI, specially when all sorts of weird claims are made towards your character just because internet arguments are serious business and "the other side is evil" and the hate and violence must be justified. "It's okay to attack them guys, they are pedophiles, nazis and fascists, so hurt them as much as possible without any guilt!" Even if you aren't doing any of the things they are complaining about with it.
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.
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.
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.
The utter disbelief people on HN show when they find out a lot of people hate or despise generative AI is much stranger.
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.
This "human bottleneck" is why we have QGIS in the first place. I think they deserve a bit more respect than that.
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.
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?)
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.
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 explain themselves. 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 and 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.
> 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.
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?
My 2 cents.
Perfectly and succinctly said.
Most often were satisfied with signals and indicators that it works and we build theories and mental models that use to try to avoid the effort of proving anything.
Worse is what happens when you start using LLM models to generate the code for you. I find you start losing the mental model short-cuts; you start to trick yourself into understanding the code. You understand little.
And what few studies there are of code review suggest that we have very little impact on code quality after reading more than a couple hundred lines of code over an hour.
So the current mental leap is, “the AI is a better programmer than I am.”
I think it’s still worth becoming a better programmer regardless. And there’s no royal road. You just have to write code and struggle with writing bad code.
I 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?
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.
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.
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 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.
Every large project I ever worked on worked exactly this way. What do you mean it was rare?
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.
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.
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.
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.
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.
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
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.
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.
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
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.
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.
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.
If you get them out of the way, I literally need to do the type inferring myself, not a problem if I'm looking at a small and trivial function, but if I'm trying to understand a "conversation" inside my code I really want that job already done by the compiler, this is also to tell that more of the "dumb/mechanical" computation is done by the compiler/interpreter the better, this is why we always wanted to get rid of syntax because we want to read english but at the same time we cannot use english because we don't want ambiguity. Writing clean code allow for the right compromise. I believe LLMs can write clean code with the right instructions, the same you would tell a junior dev, but one thing they will never succeed (unless they litreally copy) is architecture, because that is not teachable by writing (instructions/guides/etc.), only by doing and feeling.
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 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...
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.
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.
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?
> 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.
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.
QGIS is more of a slab/deck that links all those foundations together.
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!
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!
- 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.
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.
This is a higher-order rephrasing of the "intelligence is compression" argument.
I'm glad you noticed the comparison, but in practice people will take "intelligence is compression" and then not apply this to how the real world operates. Also there isn't as much of a formal backing between the thing I'm saying as there is "intelligence is compression" (well, specifically, prediction is compression into "prediction is intelligence").
Importantly, my claim is not a claim of "maximally intelligent people compress more and do magic" or some bullshit like that. My claim is a negative constraint on what even a hypothetical superintelligence will depend on.