> any use of Cargo to download dependencies dramatically increases supply chain security risk.
> Currently the best solution is to not use programming language package managers, but GNOME’s Rust code depends heavily on Cargo.
That's what an ostrich would say. How is your manual alternative to manage supply chain any better than this explicit one where transparency is standardised?
> I don’t want to downplay the severity of security issues either.
That's exactly what you're doing
> Security vulnerabilities are not even the biggest digital security threats ... a distant third place
Downplaying the 3rd biggest issue
> Security bugs are just bugs, and they’re not necessarily more important than other bugs.
ostriches hiding their heads in the dirt to escape danger is a common allusion for someone or something irrationally ignoring real looming danger and just denies the existence of the danger instead
in this case it would be organizations refusing to adapt more rigorous quality tooling alongside the rate of release, similar to the footgun allusion
as a fun sidenote, it does look like the ostrich sticking its head in the sand was a mistaken inference by the Romans and in actuality they do that to build and maintain their underground nests
I am quite a seasoned dev myself, and “insanely difficult” is not what I consider writing code to be. Perhaps if you have a crazy coupled system that is very hard to reason about, or you’re going about things in a very cowboy fashion. Or perhaps you’re writing under very challenging constraints.
Care to explain the circumstances/context that you mean?
I work with distributed systems. It gets difficult when you have to deal with table sharding, replication, cache, realtime updates (targeted/efficient), distributed processing, streaming in batches without missing any rows while the data is being updated live...
When I worked with blockchain before, that was another level because each node had to talk with thousands of other nodes; each running different versions of the code and they had to propagate messages throughout the network in a secure and scalable way without missing any nodes or reaching the same node twice (spam vulnerability) so your code is basically talking to different versions of itself which feels a bit like recursion, but harder and with a network between which adds latency and errors; and you can encounter tricky issues like message storms among others where the nodes keep bouncing and replicating a message between themselves. Or if any kind of propagated processing doesn't deduct tokens, then that's a massive spam vulnerability. Also, if the peer-discovery algorithm is structured, then the network is vulnerable to eclipse attacks. Also, most parts of the code had to be fully deterministic and idempotent or else some nodes could fork off the network. Stamping out non-deterministic, non-idempotent logic is hard work, especially when you have to do it across multiple distinct nodes running on different machines operated by different people! Paradoxically, some parts of the code actually benefited from being non-deterministic like the P2P networking and peer discovery logic since that made it harder to game/carry out eclipse attacks. So you need deep, nuanced knowledge to get it right.
For the kinds of systems I work on, loose coupling + high cohesion is mandatory, but building reliable systems is still difficult and time consuming regardless.
That blockchain project I mentioned wasn't architected well in the beginning and it was a nightmare to work with; it had to be rewritten because it was literally impossible to add new features on top (in a reliable way); nobody could do it, even the people who were there since the beginning couldn't explain how it was working. Making it modular allowed us to make it reliable and extensible but each module was still difficult to work on in the sense that every feature required careful discussion and debate with team members because so many tradeoffs had to be considered.
I mean … trees, what you’re describing is a challenging situation. But also, you don’t have to take that all on at once all the time. You ought to have corners of your code where you have guarantees and invariants you can trust that make your life easier. At least I would hope.
Also you made a general statement about writing correct code being insanely hard. I mean, writing hard code is hard, but many if not most of the things we do in this profession are not in that category. And most of the correctness we need to achieve isn’t insanely hard. Agreed that there are of course areas where the confluence of challenges can be extremely challenging.
My experience is that for a lot of complex systems, there are many exception cases which need to be handled, many interpretations, gaps and sometimes contradictions in the spec. It just takes a lot of effort and a long time to handle all possible cases.
Sometimes even something which sounds really simple, isn't simple at all once you consider all the possible formats, modes of interaction and all the things which could go wrong.
So yes, "for a lot of complex systems" writing some of that code can be hard. Writing code in general, isn't "insanely hard".
You want to write the next Google Spanner - probably challenging. You want to write another instagram - probably mostly straightforward with some intense challenge peppered around.
We all have to deal with exception cases, ambiguity, etc. That's not "insanely hard" - that's just the expectation for this career. No different (easier?) than engineering, etc.
And moving goal posts into the bleachers doesn't make for an enjoyable game.
The statement was about the difficulty of creating _correct_ code. Agreed security is important. So is performance, memory usage, etc - and we're not talking about those either.
If it truly was "insanely difficult", we would have almost no products. Clearly that's not the case. Of course most products are highly imperfect, but here we are.
And not all code is the same. To a huge degree - most things are pretty straightforward, and the hard stuff is usually a minority of the whole.
Correct code might not be sufficiently tested, it might waste memory, it might do dumb things with the wrong data structures, it might be terribly factored, it might be commented in sanskrit - and yet it can still be "correct". Don't muddy the waters by bringing in all these other factors. Those are not correctness, even though it might be something that you (and I) strongly desire, or things that are necessary to ship with. Correctness is not "done".
And I agree that any code released into the wild should be as secure as you can make it. Though a scientist running a sim on their desktop might not be remotely concerned at how secure their fortran code is.
Imagine a very complex piece of software, now imagine a venn diagram where every feature is a bubble. Now imagine those bubbles overlapping by the number of users who use/have-access-to the feature.
Any of those little junctions between features could very well have <10 users even on multi-million users pieces of software. Now every one of those little possible cross-sections in the venn diagram is another possible state the software can be in and that needs to be tested.
In the software I work currently we have one of such case, a combination of 3 different features that almost no users use in conjunction, but if they do it breaks the system. I am aware of it, my manager is aware, the product owner is aware, the fix is not trivial (in fact it would require rewriting large portions of the system).
It just stays there and we have monitoring and customer-support manually handling it. The product is fundamentally not correct (in fact the correct behavior is not even defined), yet it still works for 99.99% of the users.
Practical example? I have ran multiple times in multiple different products (even ones I worked) where if you login with Google/Apple/Whatever that makes your account completely borked to be used with SAML/OIDC if you get invited into one later. You basically need to call support to ask them to remove your user and be invited again. All those software were, by definition, not correct.
You can definitely engineer situations where you make your life far harder. Combinations of mutually incompatible feature flags is a great example. I get that some orgs just stroll down this road with disregard for the costs, but that's an aside.
Even in the presence of this sub-optimal situation, I would argue you can probably carve out areas where you're able to reason about the logic you're adding. If you can't - then that's a very strong signal your codebase is factored poorly.
This still doesn't counter the opinion that in general getting correctness right is "insanely hard". It certainly can be in some circumstances, like you're alluded to here. I would say step 1 is probably making changes to reduce the complexity you're dealing with. Or perhaps find a different gig!
3) is not possible given the other two, since there is no worldwide consensus on what is a valid name or address. Often developers over-constrain the inputs without good reason.
The tidal wave of reports will continue, until reporters stand to lose real money from submitting bad reports.
Reporters that submit useful, quality reports, should not only get their money back, but also a dividend on the money taken from low-quality reporters.
I’d posit that well over half of tokens spent should go not just to write new code/software alone, but in review, testing, as well as tooling. Every bit of code an agent writes should at the very least have an adversarial review loop.
my rebuttal to his point is that AI generated code does not essentially have to be low quality. And it very well mean higher quality code if supervised properly
> GNOME is primarily written using unsafe programming languages where simple mistakes in our code lead to devastating consequences for our users, and we make these mistakes all the time. No matter how much we try, GNOME developers will fail write secure code when using unsafe languages like C, C++, or Vala: it’s just too hard for even experienced developers to do properly.
Once I saw that I knew that this article was a ridiculous stack of bullshit.
Gnome might have some bugs and shortcomings but now millions desktops are using Gnome based window manager for decade and the world didn't collapse yet.
And let's not forget the ridiculous assumption that you can't handle a software quality without using AI...
What was good enough in the past may not be good enough now. In the past these overflow defects were as hard for attackers to find as they were for developers, because they had the same tools available.
Now we have LLMs, and they can apparently find all sorts of problems that, for whatever reason, weren’t being found with manual review, static analysis and fuzzing. We have to assume that hackers will use the technology to find vulnerabilities. If maintainers don’t do the same, then they are ceding an advantage and leaving their users unnecessarily exposed.
I don’t know that I completely agree with the above. (For example, I don’t know how scrupulous GNOME has been in the past about non-AI tools for automated defect discovery, or how well they compare to AI.) But it at least feels like a much more charitable interpretation of the article’s main thrust.
It remains viable as long as frontier models remain subsidized, too. How long will it take before these providers have to raise the prices to such a degree that such attacks would be reduced to only the most determined, financially capable attackers?
And even then there is the risk that the frontier model providers collapse. There’s no indication yet that these companies are going to become profitable. And open source models simply piggy back on frontier ones and are generally not powerful enough for this level of adversarial attacks as far as I know.
And finally are LLMs the only method to hardening software? There is still a lot left on the table that could still allow a project to resist attacks from a frontier model.
Sure, humans are bad at catching this stuff. But in order to drive an LLM you have to be able to catch this stuff. Otherwise your only option is to trust the model and give up.
To the point about LLMs being the only method to harden software - that's why I'm not sure I'm convinced by the argument. The article says the bulk of the defects were integer overflow bugs. This is out of my league a bit, but that feels like the kind of thing that should be detectable with static analysis, possibly both less expensively and more reliably than with LLMs.
Perhaps using static analysis generates false positives in cases where the code can't be proven safe? But when I was working on a project where we used Sonarqube, we ended up deciding as a team that we'd prefer changing the code to eliminate false positives over "wontfix"ing them, and I was happy with that decision. It led to more regular coding practices that ultimately made the codebase easier to read and understand. For largely the same reasons as Dijkstra was getting at in "Go To Statement Considered Harmful."
I think your expectations may be a little out of date. Existing models, including open weight models you can run yourself, are already quite incredible at finding defects. Even if the technology never gets better (it will) we are already at the point were LLM-wielding attackers have a dramatic advantage over non-LLM-wielding defenders.
There is no excuse for not having an LLM look for flaws in your codebase. Your attackers are using them already.
This remind me of OpenBSD's code. Not saying there isn't any bugs there, but the risk is mitigated by writing simple and clean code. They do not rush to add the latest ideas and wishes to the codebase.
> Currently the best solution is to not use programming language package managers, but GNOME’s Rust code depends heavily on Cargo. Accordingly, I recommend against using Rust for writing GNOME software.
It didn't seem like the article was really about Rust, honestly.
I must say, I had this thought. While everyone thought AI written code will inevitably lead to slop, bugs and security issues, I had the feeling the exact opposite happens. I can task an AI agent with striving for the quality metrics I want to see, and it will always work along them. No fatigue that leads to errors, almost no oversights even in more complex systems, etc.
This may actually be the time where it becomes feasible to create high quality software with reasonable (human) effort.
What we are seeing with AI generated incident reports causing issues is maybe mostly an impedance mismatch between people who have fully adopted AI and people /projects who haven't.
You can do this by vibe coding extensions, and it appears many people are doing this. Ironically this probably makes GNOME the easiest DE to customize at this point.
KDE cannot be modified by extensions in the same way GNOME can. This is a fact. The problem is the extension needed to be written. They are trivial to vibe now. You can make them do whatever you want.
Yes, you can do some light scripting or create your own plugins for specific apps (krunner). This is not near what you get with gnome extensions, which allow you to essentially execute arbitrary code in the shell’s main process.
The shell got a lot of hate for being written in gjs, but you won’t get that kind of functionality from a shell written in a compiled language.
Not really. That would require re-compiling, ensuring binary compatibility with the rest of the system, etc. GNOME extensions are just scripts injected into the main process.
I feel like you are being intentionally dense. Show me some examples of customized KDE builds, at the source level. You don’t even have to look to find 100s probably 1000s of gnome extensions. They are not the same.
It's the opposite, I'm at the level of your aspiratons for vibe coding while you're ignoring the basics.
First, you should subtract from those "100s probably 1000s" what's possible via the identical KDE mechanism that you were aware of in the other comment ("some light scripting or create your own plugins").
Then once you get to a less-obviously-wrong number you should think about the all the vibe coding that resulted in nothing useful, also a very common pastime nowadays, and not count those towards achieving the goal of "easiest DE to customize"
Think think about whether there might be other factors besides "ease" that could lead to the difference. Like, maybe the base KDE is already more customizable, so you wouldn't need to vibe code any custom builds to achieve the same.
Say what you like about the random word sequence generation machine, but it does actually seem to be usefully good at generating sequences of random words that correspond to problems in your software. And if you're inclined to write the code by hand, it's probably going to be easier to fix up your existing shit than rewrite it all. (And if you're going to use AI, then you're hardly going to listen to me.)
The purpose of this is to address a practice common in certain open source ideologies of banning all AI contributions - including vulnerability reports. Basically they are choosing to ignore security vulnerabilities because they had to read too much slop last year.
> Basically they are choosing to ignore security vulnerabilities because they had to read too much slop last year.
That's not only an uncharitable take, it's also wrong.
If 999 out of every 1000 "reports" from a specific source is wrong, then it is not irrational to disregard all 1000, especially when they can be generated faster than you can read.
I mean, it's just probabilities, right? If you're okay trusting output from an LLM, you should be okay with using statistics in general as a source for informing decision-making.
The TFA is making the assertion that most vulnerability reports by AI in 2026 are valid. They reference the fact that the curl maintainer agrees. That has been my experience as well. Are you arguing something different?
> The TFA is making the assertion that most vulnerability reports by AI in 2026 are valid. They reference the fact that the curl maintainer agrees. That has been my experience as well. Are you arguing something different?
Right, but that assertion does not contradict what I said: there's a difference between the articles premise (AI reports are mostly valid) and what I said (3rd-party submitted AI-reports are mostly invalid).
See my reply to a sibling poster who also implies I did not read the article.
I think the disagreement here is whether this constitutes a "specific source" or not. I've seen some people produce things with incredibly quality and others produce useless slop all with the same AI tools and models, so defining that as one single source doesn't seem like a very good way of viewing things.
Lets assume your argument is valid, and further assume hat only the high-skill people submit AI-reports.
Out of, say, 40 bugs that SOTA models can find, you're still going to have to sift through all the hopeful wannabes who each submit that same list of 40, but differently worded, differently explained and with different PoC code.
The problem still remains when welcoming AI-reports from the world: you could potentially spend all your time on examining and then discarding these reports without even getting to any new bugs in those reports.
You could make the same argument for rejecting all reports from third-parties in a pre-AI world though. It just seems like you're picking an arbitrary property to extrapolate a trend from when there are plenty of other similarly arbitrary properties you could extrapolate similar trends from. If I noticed that most bug reports that come on Tuesdays are low quality, I don't think it would make sense to have any bugs that get reported on Tuesdays get auto-closed, regardless of the statistical trend.
Projects were already doing this by making you jump through hoops to submit an issue. It filters out the low effort chaff. I think asking for people (instead of their agents) to submit reports is on the same level.
> You could make the same argument for rejecting all reports from third-parties in a pre-AI world though.
No one did though, because the friction involved in finding and submitting bug reports meant that a single individual could not overwhelm a project in spurious reports.
If a single individual overwhelms a project now, it's possible to just reject their reports without mandating no AI help at all. I can't tell if you're claiming that all LLMs (or specific vendors/models) should be treated as a single individual or if you're missing the point I've been trying to make.
If you won't read TFA, source being the RedHat employee paid to triage Gnome vulnerability reports since 2020:
> Have you heard that most AI bug reports are “slop?” Not so in 2026. That was true for most of 2025, but the quality of AI-generated vulnerability reports has drastically improved. That is not to say that we no longer have problems with bad vulnerability reports, but in general, nowadays most of them are pretty good. (Daniel Stenberg reports the same pattern for curl.)
> If you won't read TFA, source being the RedHat employee paid to triage Gnome vulnerability reports since 2020:
I read the article very carefully, including the bit that you quoted. Here's what I read:
> Red Hat’s scan of GLib found 118 vulnerabilities. Or at least, it claimed to. However, due to the way we ran the scans, several of these are actually unnecessary duplicates of each other, which we have not fully deduplicated yet, so the number I report is not entirely trustworthy. Moreover, 46 of these “vulnerabilities” are bugs in gobject-introspection, mostly in the typelib support, which is evidently not very robust. A typelib controls how your program calls libraries; it is effectively calling convention, so it must inherently be fully trusted: a malicious typelib would be able to induce vulnerabilities even without any bugs! I would expect an AI ought to have been able to figure that out, but apparently not. These bugs are still real problems that we ought to fix, but all maintainers agree they are not security vulnerabilities, so let’s count all of them as false positives. That alone creates a 40% false positive rate. Ouch.
And that's with them running the scanner, not with submitted reports by 3rd-parties! When you welcome AI reports, everybody is going to submit the same report, just differently ordered and differently worded.
I mean, he even said:
> I requested that the bug bounty program end because I was overwhelmed with incoming AI-generated issue reports. The final issue was reported on February 23, 2026. Here are the results:
Sure, he attributes it to a financial incentive, but it's clear that submitted AI reports will overwhelm, and the only way they got to a measly 40% real-bugs was by do the scanning themselves.
(Also, I wish all these sibling posters implying that I did not very carefully and thoroughly read the article would, themselves, read the article!)
Yes. They will need to use AI to process the increased load of AI reports.
I hope you understand that software engineering is now going to require the use of AI. In the same way that software engineering requires the use of compilers. Sure, some people refuse... but...
"use the tool to fix issues created by using the tool" is not a valid solution. The solution is to stop using bad tools.
> I hope you understand that software engineering is now going to require the use of AI. In the same way that software engineering requires the use of compilers.
When LLMs actually can reliably do their jobs (which compilers do), then they might be an essential tool. Not before. For now, they are slop machines used by people who care more about going fast than getting things correct.
You are out of touch unfortunately. Your logic was correct last year, but things have changed radically and super fast. You need to re-evaluate, and this article by a core GNOME developer specifically doing security work should have made you do that re-evaluation!
The last 1000 times someone has said "nah bro AI was bad last year but this year it's good trust" have been wrong, I am also comfortable being informed by evidence.
They did this the last 999 times and always came to the same conclusion: that the AI promoters were talking nonsense. At what point should you stop listening to people who only talk nonsense so far, to avoid getting DoS attacked? Must the villagers look for the wolf every time the boy cries?
No. But when the wolf experts announce that there are a dangerous number of wolves - and you ignore it - that's a problem.
The people writing this article are experts. They cite other experts.
If you can cite real data from the last few months that still claims there are no wolves - and it's not just insane anti-wolf propaganda - I'd love for you to show me.
> The people writing this article are experts. They cite other experts.
"Economists have predicted 18 of the last 2 recessions".
I mean, c'mon! You have never read that?
Besides, when "expert in $FOO" means "familiar with $FOO that's only 6 months old", then it's not unreasonable to be skeptical.
In other fields, an expert is someone who's studied the specific field $FOO for decades. Here we're talking about a skill level that is not distinguishable between "1 weeks experience" and "two years experience".
Let's return to actual data: the article we are discussing is experts claiming that AI should be used to report errors in software.
Do you have data to support your side?
EDIT: I did a little research. These projects accept AI contributions: Python, NumPy, SciPy, pandas, scikit-learn, Django, Kubernetes, the Linux kernel, Firefox, Flutter, Homebrew, curl and PyTorch.
Why do you think they do, if it's such a bad idea? Are they all idiots? They have no idea what they're doing? Linus? Really?
Yea well.. we've all been there. But after a sufficient round of improvements, things start to actually become good. Just sticking your head in the sand isn't rational when dealing with tech that moves this fast.
You can read how skeptical I was if you dig through my comments if you want. But at some point it's not skepticism, but pigheadedness.
This same statement has been said countless times, replacing “AI” with whatever trend is big at the time. It has also been wrong in every case where that thing is said to replace QA.
just from first principles its really not. given its propensity to just make shit up and cheat, ai is really useful when there is some kind of formal or exhaustive checking as a wall for it to throw crap at. so if you rigorously define success and spend a bunch of tokens, you could easily save time and money. but if you ask the ai 'is this correct' and it says 'yes!', or even 'no!', then you've really learned nothing. this isn't a can you can kick arbitrarily far down the road.
I think writing tests is a great use of ai, but only if the tests themselves are throughly reviewed or are themselves validated by statements in a formal system.
I think you could use AI for this if you do it properly as a sort of adversarial coding project. Have it build tests to break the code. Don't give it the job of making a test suite that passes.
I think people higher up are warning against a naive mistake, which is asking one agent to write both the product and the test suite. Here, making things up and cheating becomes a problem of quality theater...
Totally agree. My point is simply that this aligns with existing roles.
The QA role (regardless of whether it's performed by an AI or a human) typically involves breaking tests, not writing them. (This applies more to unit tests, integration tests blur this line.)
For me QA is tasked with making sure that the product functions as intended. that means coming up with clever test suites to explore the spaces that the developers didn't think to, making sure the coverage for operational problems is adequate, and also long term tracking of performance and memory utilization.
this doesn't sound like your model, and I'm unclear what it means to break a test. maybe test automation, in which case, sure that seems fair game for AI, but that not where the real meat is.
> For me QA is tasked with making sure that the product functions as intended. that means coming up with clever test suites to explore the spaces that the developers didn't think to, making sure the coverage for operational problems is adequate, and also long term tracking of performance and memory utilization.
This pretty much. My last job didn't really have QA so I did the next best thing which is writing a bunch of integration tests for the use cases that matters for the product. They were not an indication for correctness, but more like a canary to warn me if I break something while developing. Bugs reported by consumers usually warn me of area not well covered.
QA would play the same whole. They shouldn't need to check for code correctness, their most useful task is to surface bugs that breaks the product requirements (performance, security, business logic,...). And for that, having knowledge of the implementation is unnecessary. In the above example of writing integration tests, I took care of only using the public interface of the modules.
That largely aligns with my view. I think in a large enough codebase (roughly the size QA becomes necessary/relevant) it becomes impossible/infeasible to guarantee correctness. I think the line "clever test suites" highlights the distinction.
In my mind, tests are everyone's responsibility, but the goal differs. A regular developer adds features and should be writing tests to prove their code functions as intended. QA does not add features, so their goal is finding holes in code added by others.
It's the adversarial relationship mentioned by a parent:
> Have [QA] build tests to break the code. Don't give [QA] the job of making a test suite that passes.
The article makes a strong point that the slice that needs humans is dwindling quickly. The article seems to suggest our ability to write prose for other humans is our main differentiator.
Even that is not a differentiator. LLMs are perfectly capable of following writing style guides, it's just that their default writing style has tells and clichés, and most people don't care enough to instruct it to deviate from that style with any specificity.
They should be using an automated AI agent to validate vulnerability reports. Have it pull up the code base, confirm the bug exists, try to reproduce, then update the ticket. You might even run another AI agent pass to clean up the text before humans look at it. AI writing quality improves a lot with multiple passes.
"Vibe reviewing" is an underrated way of dealing with vibe coded PRs. There's going to be a lot of low-quality noise that's probably better to just close without a human looking at it, but it would be unfortunate to ignore the stuff that might be worthwhile because of that.
> any use of Cargo to download dependencies dramatically increases supply chain security risk. > Currently the best solution is to not use programming language package managers, but GNOME’s Rust code depends heavily on Cargo.
That's what an ostrich would say. How is your manual alternative to manage supply chain any better than this explicit one where transparency is standardised?
> I don’t want to downplay the severity of security issues either.
That's exactly what you're doing
> Security vulnerabilities are not even the biggest digital security threats ... a distant third place
Downplaying the 3rd biggest issue
> Security bugs are just bugs, and they’re not necessarily more important than other bugs.
Downplaying the danger.
What is the "era of ostriches"? Is that a reference to some meme? Would someone explain the meaning?
ostriches hiding their heads in the dirt to escape danger is a common allusion for someone or something irrationally ignoring real looming danger and just denies the existence of the danger instead
in this case it would be organizations refusing to adapt more rigorous quality tooling alongside the rate of release, similar to the footgun allusion
as a fun sidenote, it does look like the ostrich sticking its head in the sand was a mistaken inference by the Romans and in actuality they do that to build and maintain their underground nests
https://www.mcgill.ca/oss/article/did-you-know/ostriches-do-...
I believe they are saying that forbidding AI-generated bugs means you don’t find out about security bugs, but they’re still out there.
Producing correct code is insanely difficult. It's hard to convey this to junior or even mid-level engineers.
In fact, for many complex projects, it's essentially impossible, even with AI.
Eventually, you get to a point when you have every feature you could possibly want but the list of tradeoffs is long and yet not worth trimming.
I am quite a seasoned dev myself, and “insanely difficult” is not what I consider writing code to be. Perhaps if you have a crazy coupled system that is very hard to reason about, or you’re going about things in a very cowboy fashion. Or perhaps you’re writing under very challenging constraints.
Care to explain the circumstances/context that you mean?
I work with distributed systems. It gets difficult when you have to deal with table sharding, replication, cache, realtime updates (targeted/efficient), distributed processing, streaming in batches without missing any rows while the data is being updated live...
When I worked with blockchain before, that was another level because each node had to talk with thousands of other nodes; each running different versions of the code and they had to propagate messages throughout the network in a secure and scalable way without missing any nodes or reaching the same node twice (spam vulnerability) so your code is basically talking to different versions of itself which feels a bit like recursion, but harder and with a network between which adds latency and errors; and you can encounter tricky issues like message storms among others where the nodes keep bouncing and replicating a message between themselves. Or if any kind of propagated processing doesn't deduct tokens, then that's a massive spam vulnerability. Also, if the peer-discovery algorithm is structured, then the network is vulnerable to eclipse attacks. Also, most parts of the code had to be fully deterministic and idempotent or else some nodes could fork off the network. Stamping out non-deterministic, non-idempotent logic is hard work, especially when you have to do it across multiple distinct nodes running on different machines operated by different people! Paradoxically, some parts of the code actually benefited from being non-deterministic like the P2P networking and peer discovery logic since that made it harder to game/carry out eclipse attacks. So you need deep, nuanced knowledge to get it right.
For the kinds of systems I work on, loose coupling + high cohesion is mandatory, but building reliable systems is still difficult and time consuming regardless.
That blockchain project I mentioned wasn't architected well in the beginning and it was a nightmare to work with; it had to be rewritten because it was literally impossible to add new features on top (in a reliable way); nobody could do it, even the people who were there since the beginning couldn't explain how it was working. Making it modular allowed us to make it reliable and extensible but each module was still difficult to work on in the sense that every feature required careful discussion and debate with team members because so many tradeoffs had to be considered.
I mean … trees, what you’re describing is a challenging situation. But also, you don’t have to take that all on at once all the time. You ought to have corners of your code where you have guarantees and invariants you can trust that make your life easier. At least I would hope.
Also you made a general statement about writing correct code being insanely hard. I mean, writing hard code is hard, but many if not most of the things we do in this profession are not in that category. And most of the correctness we need to achieve isn’t insanely hard. Agreed that there are of course areas where the confluence of challenges can be extremely challenging.
My experience is that for a lot of complex systems, there are many exception cases which need to be handled, many interpretations, gaps and sometimes contradictions in the spec. It just takes a lot of effort and a long time to handle all possible cases.
Sometimes even something which sounds really simple, isn't simple at all once you consider all the possible formats, modes of interaction and all the things which could go wrong.
So yes, "for a lot of complex systems" writing some of that code can be hard. Writing code in general, isn't "insanely hard".
You want to write the next Google Spanner - probably challenging. You want to write another instagram - probably mostly straightforward with some intense challenge peppered around.
We all have to deal with exception cases, ambiguity, etc. That's not "insanely hard" - that's just the expectation for this career. No different (easier?) than engineering, etc.
Have you tried having a recent model audit your code for potential security issues recently?
I found that quite humbling. I thought I was a lot better at writing secure code than that.
The statement was about producing correct code. I’m aware of the security situation, but that’s a different issue than the one they were discussing.
Insecure code is incorrect code.
And moving goal posts into the bleachers doesn't make for an enjoyable game.
The statement was about the difficulty of creating _correct_ code. Agreed security is important. So is performance, memory usage, etc - and we're not talking about those either.
Right. "Correct code" needs to be bug-free, secure, performant, and easy to understand and maintain.
Original comment said that "Producing correct code is insanely difficult". I agree with them.
If it truly was "insanely difficult", we would have almost no products. Clearly that's not the case. Of course most products are highly imperfect, but here we are.
And not all code is the same. To a huge degree - most things are pretty straightforward, and the hard stuff is usually a minority of the whole.
Correct code might not be sufficiently tested, it might waste memory, it might do dumb things with the wrong data structures, it might be terribly factored, it might be commented in sanskrit - and yet it can still be "correct". Don't muddy the waters by bringing in all these other factors. Those are not correctness, even though it might be something that you (and I) strongly desire, or things that are necessary to ship with. Correctness is not "done".
And I agree that any code released into the wild should be as secure as you can make it. Though a scientist running a sim on their desktop might not be remotely concerned at how secure their fortran code is.
Imagine a very complex piece of software, now imagine a venn diagram where every feature is a bubble. Now imagine those bubbles overlapping by the number of users who use/have-access-to the feature.
Any of those little junctions between features could very well have <10 users even on multi-million users pieces of software. Now every one of those little possible cross-sections in the venn diagram is another possible state the software can be in and that needs to be tested.
In the software I work currently we have one of such case, a combination of 3 different features that almost no users use in conjunction, but if they do it breaks the system. I am aware of it, my manager is aware, the product owner is aware, the fix is not trivial (in fact it would require rewriting large portions of the system).
It just stays there and we have monitoring and customer-support manually handling it. The product is fundamentally not correct (in fact the correct behavior is not even defined), yet it still works for 99.99% of the users.
Practical example? I have ran multiple times in multiple different products (even ones I worked) where if you login with Google/Apple/Whatever that makes your account completely borked to be used with SAML/OIDC if you get invited into one later. You basically need to call support to ask them to remove your user and be invited again. All those software were, by definition, not correct.
You can definitely engineer situations where you make your life far harder. Combinations of mutually incompatible feature flags is a great example. I get that some orgs just stroll down this road with disregard for the costs, but that's an aside.
Even in the presence of this sub-optimal situation, I would argue you can probably carve out areas where you're able to reason about the logic you're adding. If you can't - then that's a very strong signal your codebase is factored poorly.
This still doesn't counter the opinion that in general getting correctness right is "insanely hard". It certainly can be in some circumstances, like you're alluded to here. I would say step 1 is probably making changes to reduce the complexity you're dealing with. Or perhaps find a different gig!
Write a signup form that takes the following information
1) person's name 2) their address 3) their email address
This form must
1) meet or exceed WCAG AA 2.1 2) handle people from all over the world 3) only allow valid inputs
If you've never done this before you will think it easy. If you have you will know that it's nearly impossible. This is web development btw.
The apostrophe in my last name taught me a lot about how bad the average web form is at names early on.
I've also had registered domains turn the box red with "Please enter a valid email address" as if it needed to end in .(com|org|edu|gov)
I’ve had “please enter a valid email address “ even though my email address is valid and ends in .com. Some people have terrible validation.
3) is not possible given the other two, since there is no worldwide consensus on what is a valid name or address. Often developers over-constrain the inputs without good reason.
"Without good reason" as if the recipient won't call you stupid for letting such an "obviously invalid" name/address through.
The tidal wave of reports will continue, until reporters stand to lose real money from submitting bad reports.
Reporters that submit useful, quality reports, should not only get their money back, but also a dividend on the money taken from low-quality reporters.
why not have AI do more quality control?
I’d posit that well over half of tokens spent should go not just to write new code/software alone, but in review, testing, as well as tooling. Every bit of code an agent writes should at the very least have an adversarial review loop.
I totally agree, and the differential token cost is minimal if they are included during product code generation.
Anyone who is responsible is doing that.
From the tone of the blog post, it sounded like an untenable problem.
Hard to keep up because there's a lot of work.. that's not untenable, that's just a lot of life.
my rebuttal to his point is that AI generated code does not essentially have to be low quality. And it very well mean higher quality code if supervised properly
Because of quality
supervised, of course.
> GNOME is primarily written using unsafe programming languages where simple mistakes in our code lead to devastating consequences for our users, and we make these mistakes all the time. No matter how much we try, GNOME developers will fail write secure code when using unsafe languages like C, C++, or Vala: it’s just too hard for even experienced developers to do properly.
Once I saw that I knew that this article was a ridiculous stack of bullshit. Gnome might have some bugs and shortcomings but now millions desktops are using Gnome based window manager for decade and the world didn't collapse yet.
And let's not forget the ridiculous assumption that you can't handle a software quality without using AI...
But if I may steelman the article a bit:
What was good enough in the past may not be good enough now. In the past these overflow defects were as hard for attackers to find as they were for developers, because they had the same tools available.
Now we have LLMs, and they can apparently find all sorts of problems that, for whatever reason, weren’t being found with manual review, static analysis and fuzzing. We have to assume that hackers will use the technology to find vulnerabilities. If maintainers don’t do the same, then they are ceding an advantage and leaving their users unnecessarily exposed.
I don’t know that I completely agree with the above. (For example, I don’t know how scrupulous GNOME has been in the past about non-AI tools for automated defect discovery, or how well they compare to AI.) But it at least feels like a much more charitable interpretation of the article’s main thrust.
It remains viable as long as frontier models remain subsidized, too. How long will it take before these providers have to raise the prices to such a degree that such attacks would be reduced to only the most determined, financially capable attackers?
And even then there is the risk that the frontier model providers collapse. There’s no indication yet that these companies are going to become profitable. And open source models simply piggy back on frontier ones and are generally not powerful enough for this level of adversarial attacks as far as I know.
And finally are LLMs the only method to hardening software? There is still a lot left on the table that could still allow a project to resist attacks from a frontier model.
Sure, humans are bad at catching this stuff. But in order to drive an LLM you have to be able to catch this stuff. Otherwise your only option is to trust the model and give up.
To the point about LLMs being the only method to harden software - that's why I'm not sure I'm convinced by the argument. The article says the bulk of the defects were integer overflow bugs. This is out of my league a bit, but that feels like the kind of thing that should be detectable with static analysis, possibly both less expensively and more reliably than with LLMs.
For example: https://link.springer.com/article/10.1186/s42400-020-00058-2
Perhaps using static analysis generates false positives in cases where the code can't be proven safe? But when I was working on a project where we used Sonarqube, we ended up deciding as a team that we'd prefer changing the code to eliminate false positives over "wontfix"ing them, and I was happy with that decision. It led to more regular coding practices that ultimately made the codebase easier to read and understand. For largely the same reasons as Dijkstra was getting at in "Go To Statement Considered Harmful."
I think your expectations may be a little out of date. Existing models, including open weight models you can run yourself, are already quite incredible at finding defects. Even if the technology never gets better (it will) we are already at the point were LLM-wielding attackers have a dramatic advantage over non-LLM-wielding defenders.
There is no excuse for not having an LLM look for flaws in your codebase. Your attackers are using them already.
This remind me of OpenBSD's code. Not saying there isn't any bugs there, but the risk is mitigated by writing simple and clean code. They do not rush to add the latest ideas and wishes to the codebase.
Is the world collapse the only scale of issue you can notice?
This is just a rust proselytizing, move along
I didn't have that takeaway.
> Currently the best solution is to not use programming language package managers, but GNOME’s Rust code depends heavily on Cargo. Accordingly, I recommend against using Rust for writing GNOME software.
It didn't seem like the article was really about Rust, honestly.
I must say, I had this thought. While everyone thought AI written code will inevitably lead to slop, bugs and security issues, I had the feeling the exact opposite happens. I can task an AI agent with striving for the quality metrics I want to see, and it will always work along them. No fatigue that leads to errors, almost no oversights even in more complex systems, etc.
This may actually be the time where it becomes feasible to create high quality software with reasonable (human) effort.
What we are seeing with AI generated incident reports causing issues is maybe mostly an impedance mismatch between people who have fully adopted AI and people /projects who haven't.
Hey does that mean they'll use "AI" to allow users to customize the desktop environment again?
You can do this by vibe coding extensions, and it appears many people are doing this. Ironically this probably makes GNOME the easiest DE to customize at this point.
> GNOME the easiest DE to customize at this point.
It's not even false, you do know that KDE exists
KDE cannot be modified by extensions in the same way GNOME can. This is a fact. The problem is the extension needed to be written. They are trivial to vibe now. You can make them do whatever you want.
> KDE cannot be modified by extensions in the same way GNOME can.
I was pretty sure that was false. I did a quick check and found
https://develop.kde.org/docs/plasma/scripting/
https://develop.kde.org/docs/plasma/kwin/
https://develop.kde.org/docs/plasma/krunner/
Yes, you can do some light scripting or create your own plugins for specific apps (krunner). This is not near what you get with gnome extensions, which allow you to essentially execute arbitrary code in the shell’s main process.
The shell got a lot of hate for being written in gjs, but you won’t get that kind of functionality from a shell written in a compiled language.
You can just vibe code changes to the DE, so at this superficial level Gnome remains as hard to customize as before
Not really. That would require re-compiling, ensuring binary compatibility with the rest of the system, etc. GNOME extensions are just scripts injected into the main process.
Agents can't compile? "Essentially arbitrary" injections can't break the rest of the ecosystem or the main process?
I feel like you are being intentionally dense. Show me some examples of customized KDE builds, at the source level. You don’t even have to look to find 100s probably 1000s of gnome extensions. They are not the same.
It's the opposite, I'm at the level of your aspiratons for vibe coding while you're ignoring the basics.
First, you should subtract from those "100s probably 1000s" what's possible via the identical KDE mechanism that you were aware of in the other comment ("some light scripting or create your own plugins").
Then once you get to a less-obviously-wrong number you should think about the all the vibe coding that resulted in nothing useful, also a very common pastime nowadays, and not count those towards achieving the goal of "easiest DE to customize"
Think think about whether there might be other factors besides "ease" that could lead to the difference. Like, maybe the base KDE is already more customizable, so you wouldn't need to vibe code any custom builds to achieve the same.
Basically, just take to heart your own
> They are not the same
...only dig just a bit deeper
No - non-customizability is a design goal of the GNOME desktop, since they want the experience to be identical for everyone.
New quality tools will have to be developed.
[flagged]
[flagged]
Everything coming from GNOME about software quality should be taken with a Strategic Petroleum Reserve of salt.
While other projects rewrite things in memory-safe ways, GNOME's response is to ask a chatbox if there are any memory vulnerabilities.
Say what you like about the random word sequence generation machine, but it does actually seem to be usefully good at generating sequences of random words that correspond to problems in your software. And if you're inclined to write the code by hand, it's probably going to be easier to fix up your existing shit than rewrite it all. (And if you're going to use AI, then you're hardly going to listen to me.)
I'm a KDE guy through and through, don't get me wrong, but statements like this deserve attribution, otherwise it's just FUD.
The purpose of this is to address a practice common in certain open source ideologies of banning all AI contributions - including vulnerability reports. Basically they are choosing to ignore security vulnerabilities because they had to read too much slop last year.
> Basically they are choosing to ignore security vulnerabilities because they had to read too much slop last year.
That's not only an uncharitable take, it's also wrong.
If 999 out of every 1000 "reports" from a specific source is wrong, then it is not irrational to disregard all 1000, especially when they can be generated faster than you can read.
I mean, it's just probabilities, right? If you're okay trusting output from an LLM, you should be okay with using statistics in general as a source for informing decision-making.
The TFA is making the assertion that most vulnerability reports by AI in 2026 are valid. They reference the fact that the curl maintainer agrees. That has been my experience as well. Are you arguing something different?
> The TFA is making the assertion that most vulnerability reports by AI in 2026 are valid. They reference the fact that the curl maintainer agrees. That has been my experience as well. Are you arguing something different?
Right, but that assertion does not contradict what I said: there's a difference between the articles premise (AI reports are mostly valid) and what I said (3rd-party submitted AI-reports are mostly invalid).
See my reply to a sibling poster who also implies I did not read the article.
I think the disagreement here is whether this constitutes a "specific source" or not. I've seen some people produce things with incredibly quality and others produce useless slop all with the same AI tools and models, so defining that as one single source doesn't seem like a very good way of viewing things.
Lets assume your argument is valid, and further assume hat only the high-skill people submit AI-reports.
Out of, say, 40 bugs that SOTA models can find, you're still going to have to sift through all the hopeful wannabes who each submit that same list of 40, but differently worded, differently explained and with different PoC code.
The problem still remains when welcoming AI-reports from the world: you could potentially spend all your time on examining and then discarding these reports without even getting to any new bugs in those reports.
You could make the same argument for rejecting all reports from third-parties in a pre-AI world though. It just seems like you're picking an arbitrary property to extrapolate a trend from when there are plenty of other similarly arbitrary properties you could extrapolate similar trends from. If I noticed that most bug reports that come on Tuesdays are low quality, I don't think it would make sense to have any bugs that get reported on Tuesdays get auto-closed, regardless of the statistical trend.
Projects were already doing this by making you jump through hoops to submit an issue. It filters out the low effort chaff. I think asking for people (instead of their agents) to submit reports is on the same level.
> You could make the same argument for rejecting all reports from third-parties in a pre-AI world though.
No one did though, because the friction involved in finding and submitting bug reports meant that a single individual could not overwhelm a project in spurious reports.
If a single individual overwhelms a project now, it's possible to just reject their reports without mandating no AI help at all. I can't tell if you're claiming that all LLMs (or specific vendors/models) should be treated as a single individual or if you're missing the point I've been trying to make.
If you won't read TFA, source being the RedHat employee paid to triage Gnome vulnerability reports since 2020:
> Have you heard that most AI bug reports are “slop?” Not so in 2026. That was true for most of 2025, but the quality of AI-generated vulnerability reports has drastically improved. That is not to say that we no longer have problems with bad vulnerability reports, but in general, nowadays most of them are pretty good. (Daniel Stenberg reports the same pattern for curl.)
> If you won't read TFA, source being the RedHat employee paid to triage Gnome vulnerability reports since 2020:
I read the article very carefully, including the bit that you quoted. Here's what I read:
> Red Hat’s scan of GLib found 118 vulnerabilities. Or at least, it claimed to. However, due to the way we ran the scans, several of these are actually unnecessary duplicates of each other, which we have not fully deduplicated yet, so the number I report is not entirely trustworthy. Moreover, 46 of these “vulnerabilities” are bugs in gobject-introspection, mostly in the typelib support, which is evidently not very robust. A typelib controls how your program calls libraries; it is effectively calling convention, so it must inherently be fully trusted: a malicious typelib would be able to induce vulnerabilities even without any bugs! I would expect an AI ought to have been able to figure that out, but apparently not. These bugs are still real problems that we ought to fix, but all maintainers agree they are not security vulnerabilities, so let’s count all of them as false positives. That alone creates a 40% false positive rate. Ouch.
And that's with them running the scanner, not with submitted reports by 3rd-parties! When you welcome AI reports, everybody is going to submit the same report, just differently ordered and differently worded.
I mean, he even said:
> I requested that the bug bounty program end because I was overwhelmed with incoming AI-generated issue reports. The final issue was reported on February 23, 2026. Here are the results:
Sure, he attributes it to a financial incentive, but it's clear that submitted AI reports will overwhelm, and the only way they got to a measly 40% real-bugs was by do the scanning themselves.
(Also, I wish all these sibling posters implying that I did not very carefully and thoroughly read the article would, themselves, read the article!)
Yes. They will need to use AI to process the increased load of AI reports.
I hope you understand that software engineering is now going to require the use of AI. In the same way that software engineering requires the use of compilers. Sure, some people refuse... but...
"use the tool to fix issues created by using the tool" is not a valid solution. The solution is to stop using bad tools.
> I hope you understand that software engineering is now going to require the use of AI. In the same way that software engineering requires the use of compilers.
When LLMs actually can reliably do their jobs (which compilers do), then they might be an essential tool. Not before. For now, they are slop machines used by people who care more about going fast than getting things correct.
> When LLMs actually can reliably do their jobs
LLM agents do a fantastic job of finding exploitable bugs in code. MUCH better than humans.
They would also do a fantastic job isolating the duplicate reports as described above.
So what's your issue?
You are out of touch unfortunately. Your logic was correct last year, but things have changed radically and super fast. You need to re-evaluate, and this article by a core GNOME developer specifically doing security work should have made you do that re-evaluation!
The last 1000 times someone has said "nah bro AI was bad last year but this year it's good trust" have been wrong, I am also comfortable being informed by evidence.
> I am also comfortable being informed by evidence.
Then look. If you can't judge, then trust the experts. This article is written by experts.
They did this the last 999 times and always came to the same conclusion: that the AI promoters were talking nonsense. At what point should you stop listening to people who only talk nonsense so far, to avoid getting DoS attacked? Must the villagers look for the wolf every time the boy cries?
No. But when the wolf experts announce that there are a dangerous number of wolves - and you ignore it - that's a problem.
The people writing this article are experts. They cite other experts.
If you can cite real data from the last few months that still claims there are no wolves - and it's not just insane anti-wolf propaganda - I'd love for you to show me.
> The people writing this article are experts. They cite other experts.
"Economists have predicted 18 of the last 2 recessions".
I mean, c'mon! You have never read that?
Besides, when "expert in $FOO" means "familiar with $FOO that's only 6 months old", then it's not unreasonable to be skeptical.
In other fields, an expert is someone who's studied the specific field $FOO for decades. Here we're talking about a skill level that is not distinguishable between "1 weeks experience" and "two years experience".
Your argument boils down to "I'm not trusting that bridge! Have you seen how many mistakes astrologers make!!"
I've found that software engineers are good at analyzing the public reports they receive for their own projects.
Let's not over generalize, shall we?
What if the last 999 times wolf experts announced there were a dangerous number of wolves, no wolves were found?
You're going to need to leave the hyperbole behind and use actual facts if you want to continue.
Cite data from the last few months.
But you get to use hyperbole to defend your side? No, I'm not interested in fighting Brandolini's Law.
Friend, I only used hyperbole to answer yours.
Let's return to actual data: the article we are discussing is experts claiming that AI should be used to report errors in software.
Do you have data to support your side?
EDIT: I did a little research. These projects accept AI contributions: Python, NumPy, SciPy, pandas, scikit-learn, Django, Kubernetes, the Linux kernel, Firefox, Flutter, Homebrew, curl and PyTorch.
Why do you think they do, if it's such a bad idea? Are they all idiots? They have no idea what they're doing? Linus? Really?
[dead]
Yea well.. we've all been there. But after a sufficient round of improvements, things start to actually become good. Just sticking your head in the sand isn't rational when dealing with tech that moves this fast.
You can read how skeptical I was if you dig through my comments if you want. But at some point it's not skepticism, but pigheadedness.
[flagged]
AI is well-suited to the tedious work of testing and QA.
This same statement has been said countless times, replacing “AI” with whatever trend is big at the time. It has also been wrong in every case where that thing is said to replace QA.
just from first principles its really not. given its propensity to just make shit up and cheat, ai is really useful when there is some kind of formal or exhaustive checking as a wall for it to throw crap at. so if you rigorously define success and spend a bunch of tokens, you could easily save time and money. but if you ask the ai 'is this correct' and it says 'yes!', or even 'no!', then you've really learned nothing. this isn't a can you can kick arbitrarily far down the road.
I think writing tests is a great use of ai, but only if the tests themselves are throughly reviewed or are themselves validated by statements in a formal system.
> given its propensity to just make shit up and cheat
That's more-or-less how I define QA work. The goal is not proving overall correctness, it's surfacing individual issues.
I think you could use AI for this if you do it properly as a sort of adversarial coding project. Have it build tests to break the code. Don't give it the job of making a test suite that passes.
I think people higher up are warning against a naive mistake, which is asking one agent to write both the product and the test suite. Here, making things up and cheating becomes a problem of quality theater...
Totally agree. My point is simply that this aligns with existing roles.
The QA role (regardless of whether it's performed by an AI or a human) typically involves breaking tests, not writing them. (This applies more to unit tests, integration tests blur this line.)
For me QA is tasked with making sure that the product functions as intended. that means coming up with clever test suites to explore the spaces that the developers didn't think to, making sure the coverage for operational problems is adequate, and also long term tracking of performance and memory utilization.
this doesn't sound like your model, and I'm unclear what it means to break a test. maybe test automation, in which case, sure that seems fair game for AI, but that not where the real meat is.
> For me QA is tasked with making sure that the product functions as intended. that means coming up with clever test suites to explore the spaces that the developers didn't think to, making sure the coverage for operational problems is adequate, and also long term tracking of performance and memory utilization.
This pretty much. My last job didn't really have QA so I did the next best thing which is writing a bunch of integration tests for the use cases that matters for the product. They were not an indication for correctness, but more like a canary to warn me if I break something while developing. Bugs reported by consumers usually warn me of area not well covered.
QA would play the same whole. They shouldn't need to check for code correctness, their most useful task is to surface bugs that breaks the product requirements (performance, security, business logic,...). And for that, having knowledge of the implementation is unnecessary. In the above example of writing integration tests, I took care of only using the public interface of the modules.
That largely aligns with my view. I think in a large enough codebase (roughly the size QA becomes necessary/relevant) it becomes impossible/infeasible to guarantee correctness. I think the line "clever test suites" highlights the distinction.
In my mind, tests are everyone's responsibility, but the goal differs. A regular developer adds features and should be writing tests to prove their code functions as intended. QA does not add features, so their goal is finding holes in code added by others.
It's the adversarial relationship mentioned by a parent:
> Have [QA] build tests to break the code. Don't give [QA] the job of making a test suite that passes.
"of testing and QA" ... for a certain percentage of "testing and QA". The rest still needs humans.
The article makes a strong point that the slice that needs humans is dwindling quickly. The article seems to suggest our ability to write prose for other humans is our main differentiator.
Even that is not a differentiator. LLMs are perfectly capable of following writing style guides, it's just that their default writing style has tells and clichés, and most people don't care enough to instruct it to deviate from that style with any specificity.
Is this some kind of joke? What more features could Gnome reduce?
They should be using an automated AI agent to validate vulnerability reports. Have it pull up the code base, confirm the bug exists, try to reproduce, then update the ticket. You might even run another AI agent pass to clean up the text before humans look at it. AI writing quality improves a lot with multiple passes.
"Vibe reviewing" is an underrated way of dealing with vibe coded PRs. There's going to be a lot of low-quality noise that's probably better to just close without a human looking at it, but it would be unfortunate to ignore the stuff that might be worthwhile because of that.
So I could just keep spamming you with new PRs and run your ai usage bill up.... got it!
Sounds really expensive as far as the work you're willing to let the public invoke on your project.
> AI writing quality improves a lot with multiple passes.
Or you end up with an AI version of Chinese whispers.