I think closing contributions (due) to AI will be looked at in a similar way. Forks open to AI will appear, and take over. And people will return to the open model. I think it needs more proliferation of AI coding and reviewing tools, so that AI contributions can be automatically independently reviewed for quality.
An open-source projects losing the ability to find and mentor new maintainers is so disappointing.
It's kinda surprising to me that even the people who are all in on ai haven't internalized that there's no inherent value in producing a big lump of code. They've massively decreased the work they put in but still expect the same pre-ai reaction/gratitude when submitting a big PR.
"A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds."
On the other hand, while not accepting external code contributions will certainly improve their security posture it will also make it more difficult to identify who to invite to join the priesthood.
Just to make a point: I could throw out SQLite as a project that bans open contributions and is wildly successful.
Also, as others pointed out, Linux is technically open contribution bazaar style by 2000s standards. But if you look at how to actually get involved, there’s way more friction compared to the average GitHub project.
I actually think GCC falls into the same category. Even though it’s technically open contribution these days, it’s not exactly a free for all where any AI agent can open a GitHub pull request and get it reviewed.
You have to mail patches to a mailing list and follow a bunch of super specific and arcane rules set by the grey beards.
EGCS was created because Cygnus, a company whose business was based on GCC, wasn't getting their patches to GCC, maintained by non-company FSF.
Cygnus outcompeted FSF by so much that FSF folded and made EGCS maintainers new maintainers of GCC.
I just don't see average open source project being forked and improved by so much that it eliminates the original.
This requires 3 rare things to happen:
- the project is important enough
- the project is half-dead
- someone is willing to out-compete the original project
That won't happen to e.g. Laydbird. Yes, it's important but it's making rapid progress and they also use ai, so you can't outcompete them just using ai. It's a full-time project for at least one person (Andreas Kling) so unless you manage to find a band of great, unemployed programmers I don't see how you would compete.
Just two months ago ladybird announced that they were leveraging llms to do the rewrite that had been languishing for a year.
Now, "it breaks the social contract." Alright buddy.
This is part of the insane overreaction rippling through various communities.
The folks who figure out how to do it successfully will succeed. Groups that recede into what they know will either be slow to adapt or end up forming modern old order Mennonite groups.
Which, it's fine no judgement. But those groups don't represent technical / human progress. They represent recalcitrance in the face of a changing culture/world/society.
The elephant in the room is so many projects already operate like this without formally announcing it.
If you look at Blender, one of the biggest and most successful OSS projects out there, it's effectively run as source available. Some PRs make it through, but for the most part there have been heavy barriers to entry to get your work into the product. In this example, it's been key to such a large and complex project with millions of users staying afloat. It's an inconvenient truth.
It's one of those unspoken things in open source - the bigger the project the less you can accept or vet contributions. The less able you are to respond to users because there are too many. The amount of code you need to own balloons. The signal to noise to too much. LLMs have massively exacerbated this issue.
Trust is key.
This is probably the best, most succinct explanation of what we're seeing happening in the OS world right now.
Yes, Ladybird is facing a wall of slop... no... A tsunami of slop overwhelms core maintainers. Probably safe to generalize to other popular open source projects.
The project is important and the code is beautiful! I spent many happy hours trying to understand the code, browser-specs and tried to adapt to their coding style. After 18 months I ended up with a few merged PRs. Some were pure joy to write. I got to work directly with most of their core maintainers in the review cycle. They're great!! From the outside, it seems like their responsiveness to submissions slowed down in the last few months... slop.
Of course, it would be great if there was another way, but here we are.
Love <3 to Andreas and the core maintainer group! Keep up the good fight! Maybe we'll meet again.
Of course, if they are also concerned about the quality of external PRs then that does not help.
"green" and "the right artifact exists" drift apart faster than expected with more automation. exit code wasn't enough for us — had to make the output file the thing that proves a run happened.
I would be more sympathetic if they actually spent meaningful time on these contributions and could maybe see an argument for wanting their work to be given due consideration (lots of caveats here), but from what I’ve seen that’s the exception rather than the rule with a lot of these case.
(Servo is arguably in the middle, accepting outside contributions as long as you don't use AI.)
It's understandable that a team without much funding would have to close off contributions to spare on labor costs. But, it makes me feel that people don't give Google/Mozilla/Apple enough credit for the economic resources they put into enabling openness.
(Personal bias/experience alert: I'm currently retired, but formerly worked at Google on Chrome. I saw many of my coworkers nurture outside contributors, and did some of that myself, both informally and through programs like internships.)
I think the whole game of software engineering, open source or not, has completely changed. A lump of code doesn't mean or imply the same thing as it did 2 years ago.
> Outside involvement still matters: clear bug reports
So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.
Instead they have to re-figure it out. The team must be thrilled to re-do work they know was already put in by others, repeatedly.
As a user-and-eveloper, why would I sink time into a project with such rules that put a barrier to improving my life with the software? It seems much easier to use Firefox or Chromium, where my fixes actually meet open ears.
It was very useful for me in the past when a new Chromium version crashed on my product, that I could go and suggest a fix to V8, and it was rolled out in the next Chromium release so my product worked again (https://github.com/v8/v8/commit/4f8a70adca01c). Without this, maybe Chromium developers would have never bothered to fix it because of lack of time to figure it out.
> a pull request no longer tells us as much as it used to about the person submitting it
Nobody should need to know anything about any person submitting a pull request. Hopefully whether code that makes it into Firefox or Chromium was never based on the "effort" or "faith" of the submitter, but based on the correctness of the code in review.
Reviewing code fixes is strictly easier than coming up with them yourself.
This holds true automatically: In any situation where it isn't, you can just write the code yourself and done.
As a project you can always ignore or close a PR you want to write yourself instead. But it seems unwise to bar yourself from the _option_ of reviewing an outside contribution, or using it as input for your own re-write.
Now I see communities being affected. When you kill PRs, you not only kill the code contributions, but also massively impact the other, non-tangible contributions like ideas, eyes on code, etc. That feels way worse.
I'm conflicted, confused and afraid, HN. Look at what I just wrote, yet I use claude and deepseek and all the skills and complex harnesses and MCPs and whatnot... But all now seems like a transition phase. Transition to f-ing what though?
A lot of questions cannot be answered unless we dedicate a meaning to our lives. Human touch? Too late? Also: I liked a song and it was sonos. I unliked it after discovering. I feel so stupid, so often.
Sorry for the unhinged digression.
I love Ladybird (have a sticker on my laptop to prove!), I hope they thrive.
Integrating some kind of proof-of-stake system might be a way forward for open source. Nobody wants to shuffle through a pile of low-quality PRs written by LLM.
Is this a sponsored project where maintainers are just hired?
I feel like 1/10 comment I make on HN are about this.
So merged PR were until LLMs a good proxy for the ability to code and contribute to a software project. Consequently they were used to estimate if a candidate was potentially good for a position. Merged PR on popular project were thus precious credentials one could "trade" for potential work. Since then the desire to provide PR changed from contributing to a project for its own sake, to make the actual project progress, to signalling.
A new proxy must be found to establish the ability to contribute to a project.
We usually call open source software without open collaboration source available software.
This is terrible news, defeating core beliefs people had in Ladybird. Not an open browser I wished for.
Make a better Ladybird successfully to the point the original contributors take notice. If the barriers to doing that are truly lower, then it should be easier.
i feel like there should be a way to trust a PR ID verification or in-person verification at FOSDEM/DEFCON/Chaos Communication Congress,UNI's, for example.
Think about it. Anthropic just reported that their codebase is now improving itself. We're moments away from every open source repo being able to do the same. Think of it like torrenting — you'll be able to open your repo to the public, and have a stream of code flow in from millions of contributors. More code than you could ever write in ten lifetimes, uploaded to your repository in a matter of days.
Ladybird doesn't know it yet, but they just left themselves in the dust.
And then if someone wants to do a larger contribution, they could have a process like making an issue, discussing the approach and then collaborating with a maintainer to get it in.
Blocking public contributions means that they want to have complete control of the project and AI is likely a good excuse to do that.
That way new contributors are forced to start small.
Feature requests are valuable because they tell you what users want.
Error reports are valuable because they tell you under which circumstances the code fails.
But the code that implements those features and fixes those errors can now be written by AI. AI follows all the rules for how code is supposed to be written in your project. Is already producing very high quality code. And soon it will produce a quality that no human can match.
This is the way to go to reduce supply chain vulnerabilities and to reduce time of mainters reviewing LLM slop.
They may, at this point, go ahead and remove "get involved" block from their website https://ladybird.org/, since it's not possible to contribute anymore.
It’s controversial to say, and I may be downvoted, but I’ll share this as a pov: OSS is essentially giving away our work for free. Did that ever really make sense? If it does, why don’t graphic designers give their work away for free? Why don’t authors do that? UX designers?
It’s a very peculiar thing to us nerds.
And the strangest thing is, we may have unwittingly built the data source required to make our skills redundant, as models are trained on the work we gave away for free.
I think this is an interesting narrative.
This is partly due to Ladybird building on low-level system-language primitives that make it harder to identify problems, and while they are porting to Rust it's not fair to say that C++ is single-handedly the cause of this, because regardless of the language, in a complicated interconnected codebase the complexity easily compounds. It's a real shame we don't have the option of a trust-graph filter stop-gap that can filter contributors with a social model of who is trusted for what, purely as a heuristic to reduce the risk of bad contributions (not as solid proof of soundness).
This whole situation shows the way that development has been done isn't nearly as transparent as just having the source code being available.
We haven't been able to say what we want the code to do in a way that can be tested robustly enough to make openly accepting contributions sustainable, and it's unfair to blame the team for that because on top of needing to develop and review their own changes, it's an incredibly difficult problem with only so many hours in the day. I hope we figure out the representation and social trust graph problems, and that people continue to build on their great work.
Bad actors pay good money for vulnerabilities and patient actors are invested in slowly introducing them. Agent loops like Codex or Claude, with Anthropic's Mythos model finding ~271 Firefox 0-days, and helping fix them shows both the problem and the promise.
It's bitter-sweet in a way that Ladybird is great at showing how the incidental complexity of web browsers could be vastly reduced. To protest being gagged, cryptographers made t-shirts with DeCSS DVD or RSA algorithms on them. Alan Kay suggests that t-shirt computing is actually a useful target, and STEPS by his Viewpoints Research Institute managed to really distill some parts of OS-level and desktop publishing software down into minimal, more understandable abstractions that encode the rules of the programs with more appropriate patterns for the problems at hand, that might more plausibly fit on a small wardrobe of t-shirts. Browsers really need this range of t-shirts making.
As a minority browser user (and someone wanting to build on them), I'm excited to see Ladybird get increasingly usable for real browsing, and I am hopeful that in time, the spec representation gaps, and social trust map heuristics are solvable problems that could restore the dream of open-source, or at least stop a trend of closing (with tldraw doing this much earlier, for a less risky but still thorny project).
I don't think that follows. They expect things to improve, they do something about it and might (unreasonably) be frustrated by what they think is a policy that stands in the way of quicker progress. The first part is certain, the second part less so, and the third is just speculation.
It's clear that open source project are struggling to understand what is going on and coming up with plans – like everyone else – but clearly there are better and worse ways to proceed in this new world, if popularity, adoption and progress are things you want to focus on.
We still need some mechanism for determining which humans have enough long-term commitment to become maintainers. Source contributions are no longer a reliable signal for that, and I don't know what future signal we'll use going forward. That's going to be a hard problem.
But, who knows, if AI really does make programmers radically more productive, maybe successful open source projects don't need a large maintainer team.
The point that this announcement is trying to make is, of course, that AI has already made that particular signal approximately worthless for that purpose.
I suspect if you exclude by default but have a manual process for requesting access and permissive standards for granting access, you can eliminate most of the bullshit without really excluding anyone.
In that context, I wouldn't expect an idiot (of which there has always been far too many in this industry) to change their behaviour in a post-ai world. They were always out of line & continue to be.
Fwiw, a non-technical employee in my workplace has begun submitting ai-generated prs to internal repos I maintain & they're of excellent quality, with review feedback graciously received & expediently addressed, so this isn't a matter of the idiots not being technical, it's an attitude problem.
It's 100% an issue with the people with submitting these PRs. So, if someone has a history of having no issue with breaking project rules (let alone being arrogant about it), it should be a massive red flag about the person for any possible employer or future collaborator checking their profile, etc.
Why people are wilfully destroying their own reputation like that is beyond me. It's infinitely better to have no activity at all on your profile than to create a track record of bad behaviour.
It is seen in the way they approach contributions but also in regular language. I created X, insistence that their 'curation' was very influencial to the output, difficulty to mention LLM contribution, attitude of 'I care about building while others lose time in details', refusal to engage with potential flaws, and so on.
It is surprisingly different to what I'm used to from senior devs, which behave like they always suspect their own work is flawed and half assed. Like impostor syndrome was reversed.
(Also, as a sibling comment implied, the archetypal "bazaars", like the Linux kernel project, now appear quite cathedral-like in conparison to the free-for-all GitHub model!)
Before the rise of github, open source projects were heavily walled gardens. Little clubs that gave you a stare when you entered the room. Github commoditized getting in touch and lowered the barrier for how much effort you have to put in or even how much you have to care before you contribute. This is gone now and you have to build trust now before you can contribute to anything.
This isn't the death of open source. It's the death of the global village were everybody can freely roam and it's easy to interact. It's the resurrection of small, social, trusted communities. I hope this spreads to all of the internet.
So I do not see a problem with Ladybirds decision, in contrary, IMHO it strengthens the human aspect of software development and puts the brakes on AI free riders
Why is it surprising that some people who expect results without spending any effort also feel entitled to receiving gratitude without putting in any thought?
How about this. Somebody forks the project and submits their patches to the fork . If the fork is successful (there are users actively using it), upstream can selectively go fish for the patches themselves. The maintainer of the fork eventually gets recognized.
Not ideal, I know, but building a reputation is meant to take time.
Before AI, being open source and having to manage issues and PR's was already a huge task, burning out maintainers left and right. Now with AI, anyone with a terminal and a claude code subscription can open PR's...
I do not think we should be eternally grateful for monopoly building.
A few years ago, if I send a complex PR that compiles and passes tests, that implies a certain amount of time and cognitive investment on my part. It seems likely that I wouldn't invest that if I didn't also understand the codebase, the feature or bug I'm working on, etc.
Now, that understanding is roughly as expensive as before, but AI has vastly reduced the cost of generating the code that compiles and passes tests.
Probably-well-intentioned community members are happy to contribute the cheap thing( Claude Code tokens) but, because it's so cheap, it's not a good indicator they've contributed the expensive thing (human understanding).
Today we’re changing how code enters the Ladybird project.
We will no longer accept public pull requests. From now on, code changes to the Ladybird codebase will only be introduced by project maintainers.
Ladybird is moving into a new phase. As we work toward our first alpha release, the project needs a tighter development process, a clearer security model, and a smaller set of people responsible for the code that enters the browser.
This is not a change we make lightly. Many valuable contributions have come from outside the maintainer group over the years, and we are grateful for them. Many of us also came up through open source by sending patches to projects we cared about.
For decades, code contributions have been how open source projects learned who to trust. People would show up, do the work, take responsibility for their changes, and stick around. Over time, trust emerged from the work itself.
AI tools have changed the economics of this very quickly. We use them ourselves every day, but a pull request no longer tells us as much as it used to about the person submitting it. A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds.
For a browser, this matters. A browser runs untrusted input from the entire internet on the user’s machine, and one well-disguised vulnerability is all an attacker needs. We have already seen patient, well-resourced campaigns in open source to earn maintainer trust and abuse it. What has changed is how much faster and cheaper it has become to produce work that looks like a serious contribution.
At the same time, every change that enters Ladybird becomes our responsibility. It has to fit the architecture, survive future refactoring, interact correctly with the rest of the browser, and be understood by the people maintaining it.
Whether code was typed by hand is beside the point. What matters is who is responsible for it once it enters the browser. Ladybird is becoming a browser for real users. The people introducing changes to it must be the people who decide those changes belong in the project, and who will answer for the consequences.
As part of this change, we will close all currently open public pull requests. We are grateful for the work people put into them, but keeping the existing queue open would keep that contribution path open in practice. There is no perfect time to make this change, so we are making it now. Going forward, pull requests will only be available to project maintainers.
There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks. External code can of course exist under the terms of the license, but we will not treat forks or patch dumps as a review queue for upstream Ladybird.
Ladybird remains open source. The source code will continue to be publicly available under an open source license. Outside involvement still matters: clear bug reports, reductions, website testing, standards discussion, design discussion, security reports, and technical feedback all help move the project forward.
This is the right change for Ladybird now. We are preparing to ship a browser to real users, and our development process has to match that responsibility.
before AI like 1 in 1000 would spend their time fixing something they had no idea about and even then considering how much time you spent and how few of those happened it made sense to review/talk about it.
now every "dev" with claude submits prs having absolutely no idea what they are even doing. most of them would not even be able to create PR without AI in the first place.
and on top of that add slop bots that "fix" issues in the loop and create hundreds of PRs daily
(Seems I ran out of edit time!)
I never trust my own code. And one of the motivations of trying to be fluent with my editor, is to be able to quickly look at it when a bug is reported. I also don’t trust another person with their description of their code. Any surprise, and I’m looking at the source if it’s a available.
(Sorry, accidentally negated my meaning there, what I meant is that they have only seen this current world. Or never seen a world where it isn't the case, to use a confusing double negation.)
Now LLM spam has made it harder, so now there are fewer situations where it makes sense, and projects are switching to a cathedral model.
(And the whole "miffed AI wrote a shitpost" thing)
This is definitely a microcosm of what's happening to the entire Internet.
It was different, to be sure, but it was not worse. We are living through a transition, but people do that all the time and we adjust our behaviour and we find new equilibriums. We will do that with open source too, and if it ends up looking more like open source in the 80s or 90s, it’s gonna be fine.
Maybe some people who got really good at gaming their Github reputation are going to lose out, but that was never the point. Anyone who likes this kind of work and wants to get involved will find a way.
I think assuming a writer had your best intentions in mind has been unwise for quite some time. Murdoch built an empire exploiting this assumption.
I've done it, personally. I've made all kinds of little utilities for myself kind of like a woodworker making their own jigs. While not purely "vibe coded," AI has let me actually finish a ton of personal projects that have been in my "eh, maybe I'll get to that someday" list. Now that there is very low marginal cost to make these tools, they can be highly specific, and they aren't all that useful to others unless someone else has the exact same problem as me, and well if so they can try to vibe code their own tool.
We'll get to a point where most of the open source projects are reserved for large scale infrastructure, as a cathedral not a bazaar, and then the vast majority of end-user level software will be highly personalized, custom utilities that generally aren't shared.
I see this position a bit: the notion that AI-generated code has no value. I think it's easy to generate zero-value code, but I don't agree that all AI-generated code is zero-value. I've been working on my side projects in OpenCode, and I spend quite a bit of time prompting, setting up the right files, descriptions of the product I'm trying to build, and the roadmap for it. I have a tight validation loop that lets me run through a bunch of automated checks after each change, and then I do a bunch of manual testing through edge cases that the generated feature might screw up, and then I iterate. It's a different kind of work, but I can make progress more quickly than I could coding by hand. Validation loops are the main critical component.
My experience doing this over the past months is that using AI to code is a skill, and I learn new techniques and get better at it as I try stuff. But that also suggests that, when done well, it can produce something of value.
All of this is to say: while I take issue with your first sentence, I completely agree with your second sentence. What we've lost is the ability to distinguish easily between something well-thought out and something generated thoughtlessly. Focusing on cheap validation would help here immensely, as well.
I'm 100% on the side of maintainers here, but this is BS. If you could "just prompt Claude yourself" the AI productivity boosts would be in hundreds if not thousands of percent, which is demonstrably and self-evidently not the case (at least as of June 2026).
There might be value in your bugfix, but maybe that value is not greater than the cost of reviewing and accepting it.
> Reviewing code fixes is strictly easier than coming up with them yourself.
This is completely false, for any sufficiently complex project. The fix might be a single line change, but the consequences might be far reaching.
> As a user-and-eveloper, why would I sink time into a project with such rules that put a barrier to improving my life with the software?
Please don't! You don't owe the project anything. The other side of that equation is that the project also doesn't owe you anything. As simple as.
Firefox and Chromium are running much larger teams, let alone the Linux kernel, that other people suggested as a model. Maybe they can afford accepting your contributions.
You're allowed, they'll just ignore it. Same as how sqlite and some other projects operate.
Exactly. You want others to change to fulfill your needs. Their priorities and needs are different. In this case, it was evaluated and found not to be useful (cost > benefits).
As in cheer for the humans because they've been liberated from the drudgery they have lost?
> Whether code was typed by hand is beside the point. What matters is who is responsible for it once it enters the browser. Ladybird is becoming a browser for real users. The people introducing changes to it must be the people who decide those changes belong in the project, and who will answer for the consequences.
Moreover, as these tools become more expensive, people with money to blow on tokens will be able to drown maintainers that don’t have enough token-cash to help them deal with it. People see this as mostly a matter of time and energy, but I reckon it will soon be a financial issue.
The answer: require a written proposal for changes before a patch will even be considered unless it is sufficiently small.
Also fight AI with AI: have a bot auto reject patches unless they can link to a previously approved enhancement document. Folks who commit minimal effort will f*ck right off.
Then the cognitive burden is focused on the ideas, and code authors should have at least conveyed the intent. If they actually care to invest their skin in the game then they need to collaborate and not just drop garbage on the front door.
It is hard for me to imagine another engineering discipline that would be totally fine accepting work from those who don't have the actual engineering background required to do the work.
If I had to push this take to the extreme: software engineers never learned class solidarity and it's now biting the industry in the ass.
There's no other correct fix - why do you care which pen I used to write it?
The original post sums it pretty well, such big output inherently meant big effort, which was a proxy for good faith. Now that's gone.
- Receive a huge vibecoded PR for complicated new feature.
- Complain that this needs some design doc to figure out the right approach first.
- Author says no need for design doc, easier to have vibed implementation and discuss the concrete code instead of abstract document.
- I disagree (obviously), but review the PR with feedback along the lines: this entire approach is flawed, throw this out and start over.
- Author gets defensive, says "but this is already working and ready, let's just merge".
- I tell them there is no chance in hell this is getting merged. They go sulk to their manager that I'm not interested in helping them launch.
It is. Unfortunately, its not happening with open platforms. Communities are migrating to private discord servers, and less is discussed in public/in the open.
I think we should still separate "working in the open" from "allowing or not outside contributions." Outside contributions are fine to be denied, however I think work and discussions should still more or less happen in the open for the benefit of all.
One day discord will cease to be, and there will be years of institutional knowledge and lore lost.
I much prefer the old school forum style. Forums could be locked down to be invite only to contribute, but for the most part were still world readable.
If all relevant open source projects close up their contributions, you can't enter the project anymore from an external point of view.
Almost all open-source public figures started by being interested in a project and submitting PR to it, until eventually either joining the project as core mantainer or creating a separate open source project. The path is now closed, and I don't see a way in, outside of creating a popular open source yourself
I look forward to the book: The Cathedral, The Bazaar and The Junkyard.
My implied argument is not so much that "because llm was used, then llm must be used."
The original argument proposed by the author is essentially distilled into, "because llm could be used, we must no longer accept public contributions."
Which is, in my opinion, a disproportional and misguided overreaction. The llm was apparently good enough to do the byte for byte replica, so we know that it can be used (within the context of ladybird) in a way that's apparently acceptable to the maintainers.
To attempt to get more precise, argument is that "closing the gates" is moving in the wrong direction against progress, and a signals a potentially net negative impact to the ladybird project.
I don't have a fully formed thesis, it's a lot of vibes. It just feels wrong. I'm willing to acknowledge that, much like the overreaction that I'm calling out, I could be experiencing a similar kind of conservative gut reaction to the changing of the open source community that unsettles me.
Well see how it all shakes out. Right now the topic is so charged and we don't have a good suite of tools and heuristics for the new world, that were bound to see the gamut of reactions.
I see all projects moving this direction. Makes more sense to hash out a plan together.
Pin pointing the issue is way more than valuable than code. If you wrote a fix, you have analyzed the bug. The value is there, not in the fix. Sharing your fine analysis is the maximized contribution. Code is an optional bonus at most.
You state these things as if they are facts, but they are completely contrary to the lived experience of open source maintainers - not only my own and the TFA's but quite a large number of others who have shared similar pieces.
Would you mind sharing a link to one of the open source project you've been maintaining and reviewing contributions on for years that forms the basis of your expertise on this matter?
You can still submit a bug report and tell them exactly how you did it.
> Reviewing code fixes is strictly easier than coming up with them yourself.
Unless it's hundreds or thousands of AI slop PRs each pretending "here's a bug I fixed it"
These "contributions", while they did exist in small quantities, mostly were not actually what you've described there.
Instead, those boiled down to unsolicited opinions, hostile takeover attempts, value extraction, general drama and just overall overhead over simply building code.
This was not always the case, but the GitHub model of building FOSS (and removal of all friction) certainly made it the new default.
Said model was always unsustainable, but the burn rate made it sustainable enough so that we could just throw more humans at the problem to replace the burnt-out ones.
AI pushed the burn rate over the replacement rate.
=> We will likely see more projects adapt this or a similar stance I think.
I don't really have anything useful to add here, I think, just that you aren't alone in feeling conflicting feelings here. New things usually are like that, comes with incredible benefits in some areas yet seem to strip humanity away from others, some people use it to produce fluff and crap, others essentially gain new abilities and use those to build even better stuff. I don't think there is any universal truths here, sadly.
It feels like being in the middle of a tornado. But I think it helps to turn off screens, sit in a desk, and calmly remember first principles and consider them slowly.
Quoting obama, "reality has a way of catching up with you".
I see a lot of talk, but iOS is not delivering a decade of features and fixes on each yearly release. Literally no one does, if anything people are complaining that existing functionality is breaking down. So it can't be true that we're at 10x productivity, and this fact will eventually catch up with us.
Let's be human, and remember that many people are emotionally invested. Juniors want this to be a chance to shine in a market that otherwise rejected them. CEOs placed their bet on AI and don't want to walk that back. Seniors want to signal that they are not obsolete. AI companies will poison discourse. But all this smoke will eventually clear.
"Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools"
As the FT summarizes,
> They found an explosive impact at the top of this funnel — coders created or edited almost 300 per cent more files — but that boost was halved to 150 per cent by the time they got to the number of discrete pieces of work submitted for review, and that in turn shrunk fivefold to a roughly 30 per cent uplift in the number of full software releases.
https://www.ft.com/content/8e9ae7a4-7209-4e2c-aa36-f3af77d6c...
So as I wrote, AI vastly improves labor productivity on _coding_, but not nearly as much on code _review_ or other parts of the release pipeline.
And, unfortunately, for many open source projects, it's easy for volunteers to send code for review, but hard for them to volunteer reviewing PRs, managing releases, etc.
Yes, this is the takeaway for me. A PR can no longer be a reasonable proof of work.
It’s MIT licensed, and the maintainers are always grateful for bug reports, but all the code in the project was written by just 3 people.
Not just the changes, you'd push the responsibility, too, for supporting a whole new compilation target. I don't know how big this is, but if it's a big enough hassle to keep maintaining this yourself, then consider that this maintenance work is really what you were hoping to push. So, depeding on which, you might be fine maintaining this, or the maintainers might have rejected the change, anyway.
Any rando armed with an LLM is not a community.
Also they are not changing the licence or preventing forks.
It is a pragmatic solution to a real problem that can really clog down progress on the project. I hope they (and other open source projects) will figure out how to filter in good, responsible contributors but I guess it will take time.
On the other hand, Ladybird is gearing up to become a production-ready browser for real users. Adding fun features for the sake of it, and hand-rolling code to parse PNGs and the like, has become a liability for the project.
I guess they will have to introduce some kind of trust-based system.
Not at all. You are of today’s lucky 10,000 [0]. Open source refers to OSI-compliant licenses, not open to contributions. SQLite is open source but not open to contributions.
1. Free Redistribution
2. Source Code
3. Derived Works
4. Integrity of The Author’s Source Code
5. No Discrimination Against Persons or Groups
6. No Discrimination Against Fields of Endeavor
7. Distribution of License
8. License Must Not Be Specific to a Product
9. License Must Not Restrict Other Software
10. License Must Be Technology-Neutral
Ladybird’s blog post is arguing that it used to be tolerable to spend the amount of time evaluating this for every PR, now it’s just unmaintainable for their effort-time.
This is just the cathedral model to open source, as opposed to the bazaar you clearly prefer, but it's still open source.
it's time for there to be some really nice workflow tooling that people can plug into their GH repos that does this and other things.
1. my company also employs its fair share of folk that would fit into the so-called "idiot" category of my post - I just thought it was of note that I have encountered exceptions to this stereotype
2. I fully support what Ladybird is doing here & find it unfortunate that they have to. I didn't intend my post to criticise their move - my example is definitely the rare exception in a sea of unmaintainable garbage. I do think however that it was already a challenging prospect to manage garbage oss prs in the pre-llm era (see umpteen posts on maintainer burnout) & I wouldn't have faulted any open source project for doing what ladybird is doing even pre-llm.
i think the claim is that more projects are locking up contribution paths ~currently
Is the goal to produce high-quality software, or is the goal to produce an apprenticeship scheme for developers who are interested in the project but not so interested that they are willing to write an email to introduce themself or otherwise engage in normal human social interactions?
Normal people will still be able to get involved if they want to, just like normal people can get jobs. You learn about the organization you’re interested in joining, you try to meet some people and introduce yourself, you gain trust and prove your worth. It can be true that a pull request once embodied some of these tasks, but it is not true that being unable to submit a request means that these tasks are no longer possible to perform. It just means you’ll have to do them differently, just like the rest of humanity does when they want to get involved in an organization.
This seems fair to me: numerous developers would love to put "contributed to the Ladybird project" on their curriculum vitaes, and AI tools can now make this within the reach of a huge number of people.
But the Ladybird project needs more than just working-code, something that AI can easily produce: they need code that is understood and maintainable by the person who submitted it.
Not only does AI-generated code fail to guarantee this understanding and maintenance (to a greater degree than before), but the developers increasingly need to get through an avalanche of AI-generated pull requests rather than, say, code new features.
I would prefer projects to be developed in the open: but when developing in the open makes the code checking exponentially harder, and the chance of the submitters sticking around becomes significantly lower, then I can at least understand.
When the dam starts to overflow, then something needs to be done.
a code owner may choose a very different way of fixing things, even for what looks like a trivial fix.
The real value we get from being open source is high quality bug reports and trust from our customers, not the external contributions. The only reason we welcome external contributors is marketing and generally being welcoming. If LLMs make this cost even higher for us then we might have to stop accepting external PRs.
They probably could do that as part of the hiring process.
Does it? Seems the only sane option. The other being being drowned in AI slop PRs.
Why is it so hard to just accept that AI PRs suck and create an enormous amount of toil?
Ladybird uses AI to code. This is not them banning AI. This is them not wanting to take responsibility for the code WE write with AI. They think outside code contributions are raising their risk and slowing them down.
I dislike this change but it does not track to what you are saying at all.
Like always with Open Source, if you really believe what you are saying, fork the project. Outrun them if you can.
Of course, Ladybird is not production ready yet. Feature-wise, it is getting close. I can use it to do most of the things I want to do with a browser. Speed and reliability are another matter. I has gotten dramatically faster but normal users would still find it slow. But the biggest problem is reliability. I would not use it in its current form for anything that matters.
But for a complicated application that was started from scratch, not being ready yet is not an indictment. They claim it will be ready for regular users to try sometime this year and, from where I type, this seems realistic.
It means they’ll never grow modules or the codebase beyond what the team can reasonably maintain.
However on the other hand.. What does this mean for the existing team, are maintainers now worth considerably more to the project? What does this mean for the codebase, or the momentum of the project?
It’s an approach I would have expected for the likes of curl, or single-purpose libraries. But this is a mammoth decision for a mammoth project.
I guess we’ll just have to see.
You're always going to have to trust some core same-privilege code--a browser renderer is a great example of this: it has to be able to see the entirety of the DOM it's rendering, right?
Higher-level languages can still help code review--for example, memory safety makes it harder to hide a backdoor via unsafe memory operations leading to code injection. But you're still, fundamentally, trusting these community contributions.
I think the real problem (as others noted here) is that:
- writing code is now much, much cheaper than ever
- understanding and designing code is still fairly expensive
So doing the former (in the form of a PR that compiles and passes CI) is not a good "staking mechanism" to prove someone has done the latter.
I wonder if any of you AI boosters have any actual knowledge of how software is written, why bugs exist and how to mitigate tech debt. I wonder if you guys even know what tech debt is.
Somehow it’s always very young accounts which made me wonder if I’m talking to exuberant teenagers or people that have done a one week Python code camp 10 years ago and now think they’re John Carmack with their Claude subscription.
The point of OSS though isn’t that nobody gets paid. It’s that if they charge for contributions, they get paid to release their work as Open Source software. They get paid for the labor of producing the artifact, and not necessarily paid a royalty for future sales of the copies.
It’s been enormously alienating talking to laypeople about the apocalyptic atmosphere in the tech world, while for them ChatGPT is a cool piece of software but the world still hasn’t changed very much. They look at me bug eyed when I tell them how dramatically software engineering has changed in the matter of a couple years. We are in a bubble, or we’re just, as you say, in the eye of the cyclone which still has to hit the rest of the world.
This is insinuating that code was the bottleneck in the first place, or that every line of code is to build a new feature and not fixing existing bugs, or that apple didn't lay off enough engineers and reallocate resources to other departments to make up for the productivity boost.
I do think that companies with poor AI practices will eventually pay the piper in the form of technical debt or debilitating bugs. But let's not equate a productivity boost with a boost in releasing features, because there's plenty of business reasons to not release thousands of new features every year.
I agree with you on the rest of your points. Eventually the smoke will clear. What awaits to be seen is who is left standing when it does? I don't think I like the answer to that question.
I wish I could be so optimistic. Our lives are ruled by distorted, irrational, inefficient, failed markets, and the markets can remain distorted, irrational, inefficient, and failed for longer than we as individuals can remain solvent. "In the long term the market is a weighing machine", for term lengths that include the heat death of the universe.
I think we'll need to revert to artificial barriers such as bonds, e.g., if you want to do a PR to my repository you need to pay a 10 dollar bond. If the PR is good and I want future PRs, you keep your bond. If it's slop and spam, I get 10 dollars for my time.
Well, that's already the case because you cant just call yourself an engineer and start signing off on projects. It's a legally protected title in a lot of places. You need a professional license, and can face legal liability for your decisions.
Software engineering is not engineering. Software craftmanship or even architecture would be a more accurate term. There are no devs that will go to prison if what they produce has, say, a major vulnerability. That alone disqualifies it from being engineering. There's no licensure, there's no liability, so already software development is not gatekept in any way like other engineering disciplines.
I mean, just go into an aerospace engineering office and say you want to move fast and break things, you'll get laughed out of the room.
No idea what you mean by class solidarity. There are only two; the capital owning class, and then everyone else (the working class). Most devs are working class just like everyone else.
Unless you're proposing that software should be gatekept to the level of other engineering disciplines?
Firstly: class solidarity. The apparent death of (or at least notable decline in) class solidarity is popularly lumped upon software engineers because they're relatively highly paid, but it's equally as absent in newly created positions (mainly within the IT sector) at all salary levels. There's been a concerted effort to erode class awareness in the private sector for the past 40+ years & it's been effective across all sectors, mostly in newly created job categories without pre-existing union culture. It's in no way specific to software engineering as a role nor to high salary positions.
Secondly: ai & llms. Currently these technologies are monopolised by corporate entities, with models generally being far too inefficient to democratise, so it's obviously tempting to conflate their very existence with their owners, but if you're singling out ai usage as some kind of affordance to the capitalist class you're missing the woods for the trees. You need to separate ownership from existence/usage.
I think that's probably the key - sounds like you are at a place that rewards "launches" and not long term maintenance and so you are ruining their KPOs or promo packet or whatever.
Boom. Maintainer. Easy.
Why would normal people even want to become an unpaid janitor for someone else's stuff?
Returning to the topic at hand, the challenge for new developers is to earn trust. I bet there are ways to do so aside from the muddy swamp of GitHub's (AI) bazaar.
It’s the same about published journal article. A lot of them are a few pages. That is mostly one hour of typing. But everyone knows that typing it is not the work.
It's not unreasonable to feel conflicted about this, but at the same time, I wonder if they're starting to burn out on code review.
So any project that doesn’t accept AI PRs is really missing out on significant investment
What do you mean you just spent a week implementing something in secret?
AI makes it extra silly because now you can craft up your unsolicited code change in minutes, making it extra obvious that code changes should spawn from real discussion and agreement.
TFA is part of looking for new processes that actually work. Dunno why people are having such rose tinted glasses about pull requests. Open an issue, talk to people. Have an idea? Then get people to cosign it.
Can you? The announcement says "There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks".
So I, as a human, describe in prose which changes I made to e.g. 20 files?
How is that in the spirit of fighting LLM slop?
Also, if I can do that, the LLM slop contributers can also ... do that.
Github is in my profile; I am nixpkgs committer for ~10 years (which is one of the most active projects on Github with 450000 merged PRs).
There is no way I could have possibly written and (pre-tested, to arrive at the eventual code submitted) all the code that I have reviewed.
From the other side, I have spent thousands of hours debugging and writing PRs to over 100 FOSS projects (e.g. glibc, busybox, util-linux, lz4, GHC and tens of Haskell packages, Jenkins, Chromium, GTK, Consul, OpenCV, Signal, many more).
Many of them are small or medium fixes ("drive-by fixes"), where you propose a PR, the owner reviews, says "great, thanks", and the bug gets fixed.
This is a fundamental workflow for open source work. The project gets free contributions and time investment outsourced to "the community" who fix its bugs, the developer-users/community get their problems fixed upstream, permanently.
This not possible for projects that don't have an easy way to submit code with low effort for both sides.
Accepting drive-by fixes is what clears up developer time and helps clear out the countless small issues in software.
If AI slop PRs are a problem, it seems better to establish clear rules and reject contributions that don't follow them with a single click, rather than banning developer contributions altogether. It seems to work acceptably for nixpkgs so far.
I actually am training 2 trainees (Azubi in German) and 1 working student. All three are somewhat anxious about the future but also all are learning in a significantly increased pace, compared to the ones I worked with 1.5 years ago.
They don't have to wait for random senior to answer questions, so they get stuck way less often. They aren't allowed to use AI to generate code though, so not sure how that'd look like learning-wise if we/they went all-in on AI.
I'm also conflicted but take a glass half full approach basing myself on the fact that when I'm feeling like "this time is different" it's probably my ego wanting my lifetime to happen at an interesting time in history, so my brain wants the current events to be the most transformative.
It's quite hard to quantify, but I think it's one shot nature really makes it hard to gauge it's capability
Friends have spoken of good days and bad coding days with me, and I find it odd nodding along, it's a strange new normal
At times it feels like we're just coding with one-armed bandits, trying to carefully line them up for a jackpot and just discarding and retrying if we don't hit
I think about some of the more complex systems I've built and I wonder how well we can build them like this
And over engineering, there seems to be over engineering everywhere, and yet, more fragility to our systems
It's all a little surreal
I don’t disagree with their choice, but it’s not sustainable in the long term.
why would you want this. this sounds terrible
That's not entirely true. It's certainly the case that Ladybird is still under an open-source license, but the whole idea of the "Open Source" label was to move the emphasis away from having a free license to actually being open to patches in practice.
For an open source project that isn't a business, that's really the only way to recruit people
> Source-available software is software released through a source code distribution model that includes arrangements where the source can be viewed, and in some cases modified, but without necessarily meeting the criteria to be called open-source.
https://en.wikipedia.org/wiki/Source-available_software
> Open-source software (OSS) is computer software that is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose. Open-source software may be developed in a collaborative, public manner.
https://en.wikipedia.org/wiki/Open-source_software
And as said here, SQLite was operating like this forever.
But the simple fact is there's massive evidence that in skilled hands 10x or 100x engineers are possible. We're seeing evidence of it across major open source project as well. And definitely behind closed doors across companies.
Reality will catch-up with that too, once the other smoke clears.
What I can imagine though is that
- the value of merged PRs might drop (as it's not a good metric anymore)
- while the cost of submitting them goes up (as price per token is radically changing, e.g. Github announcement just this week)
so maybe it's also only temporary.
Also if all this is correct, including the value of PR on popular repository being more important, then the long tail of projects might not have to worry about this.
How do you do that efficiently so it can scale?
Therefore a maintainer is more likely to steer the AI in a direction that is aligned with the codebase.
1) more reliance on systems to track reputation across projects. I'm sure Microsoft, in the form of GitHub, will love to sell you a partial fix to the same problems it so enthusiastically helped to create. But there are the familiar problems of surveillance, identity theft, office politics, and system-gaming, and it doesn't on its own offer an onramp for new players.
2) in-person coding tests at the same Pearson test centres where people take most of their Cisco (and accounting, and ...) exams today. Not as expensive or inconvenient as you might think, but not the cheapest and easiest, and it certainly has the same concerns re. surveillance and identity theft
The only problem in your theory is that none of those things has anything to do with "engineering".
You're arguing that a surgeon who removes a burst appendix in a hygienic environment isn't "practicing medicine" if they aren't licensed to do that in the jurisdiction where it happens. You'd have to be insane to believe that.
Engineering means solving problems. A license is a license. They're unrelated concepts.
This was part of the implication of my point, yes.
> No idea what you mean by class solidarity. There are only two; the capital owning class, and then everyone else (the working class). Most devs are working class just like everyone else.
Yes, albeit a highly compensated portion of the working class. Software engineers should protect their own field a bit more.
> Unless you're proposing that software should be gatekept to the level of other engineering disciplines?
I do not like or want to use the term "gatekeeping" here, but yes, I think that software engineering should be held to a higher standard. You can't have it both ways.
Obviously, I don't have a crystal ball.
Deep research in the codebase, deciding on the flavor of code to write that matches the project, deciding how you'll model the feature with types, how to architect it so that it's testable, writing the tests, foreseeing cases beyond the obvious path, etc.
What changed is that it can be automated. Or, just grant a world where AI is perfect at implementation.
Now our time/energy/attention is freed up to concentrate the work around planning what to build. And the interesting part is that it becomes the input into the AI implementor.
This is a good thing since we tended to skip the planning stage since it's hard in its own way. Or we start building something and then try to synthesize a high level direction from it, yet now since refactoring is so expensive, we're committed to a solution.
Yes, that is exactly what this announcement is about. That it was too much work for them to tell those two apart.
That is exactly the issue. Projects that are end-user applications - as opposed to libraries or development tools - probably see far more slop than actual work like you've described. The yields are too low for it to make any sense to try to figure out which is which, their time is better spent doing the work.
Would you pay 2000$ for those tokens? If not, the number is meaningless.
That you can still report bugs
> So I, as a human, describe in prose which changes I made to e.g. 20 files?
Rarely does a bug require a description of what needs to be done in 20 files
> Also, if I can do that, the LLM slop contributers can also ... do that.
Yes, they can. Yes, they will. And yes, it's a problem.
The previous barriers worked because they were organically perfectly in line with a contributor's internal incentives. A contributor gains very little benefit from submitting a patch; the likelihood is infinitesimally small they'll ever get any career advancement, financial recompense, or even much community recognition for it. At most, it shifts the burden of maintaining the code they're contributing from themselves to the community / long-term maintainers. The real incentive for a contributor was making the patch, because they get to see the feature or fix they want made for the software. The previous barriers were in making the patch, and contributors would overcome that friction to gain the benefit of having the patch they want. Moving the barrier to merely submitting the patch after it has already been made will simply result in people not bothering, because there is very little incentivizing them to deal with the friction.
Yes, I agree. We are, however, on a site and in a thread that is dedicated to the role of software engineering, so I don't really care about the wider discussion at the moment.
My sole input here is that software engineering has not protected itself as a field, and it will now pay the price for that.
> There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks. External code can of course exist under the terms of the license, but we will not treat forks or patch dumps as a review queue for upstream Ladybird.
This does raise the question on how they are going to get new maintainers. The only thing I can think of is by active outreach to people contributing to adjacent projects that are still open. But that does not seem ideal to me as that will not yield people specifically interested and caring for the project you invite them to.
Social validation. Or, to be slightly more generous, sort of a compulsory way to force someone more experienced to provide some mentorship, by compelling them to review your pull requests.
I think the primary difference is that it removes some of the incentive to status seek because there's no centralized network operator tracking contributions and displaying them on your profile for others to look at.
That said, the linked post explicitly says that Ladybird won't be accepting emailed patches, reviewing changes from downstream forks, or anything else. Hopefully that's not the case since entirely closing off the project would probably be an overreaction as well as jeopardize its future.
Now they can drop a multi thousand line poorly understood PR day 1.
Maybe your legislative feels bought out, that sucks, but that's not the situation nor the feeling everywhere in the world, certainly not where I live, so also doesn't seem to be related although if I assume where you live, I totally understand why you're currently feeling like that.
No. Electricity didn't raise the skill floor all that much. Certainly nowhere near the human skill ceiling.
> the internet would kill all street level businesses
That was never going to happen overnight, if at all. But online retail (and food delivery, etc) does seem to be slowly but surely eating away at local shops so I think it's within the realm of possibility.
Or trying to reduce complexity, increasing readability and coherence of variable names (the opposite of code golf if you will), while staying within a certain limit of performance regression (e.g. "make this code as nice as you can while making it at most 0.5% slower").
Making the stuff millions of people have been using for decades better, in a way that also makes it better for humans when they read the code. Surely that's possible, some people are probably doing it but it doesn't go viral as much, because it's too mundane.
And of course, making new stuff is more exciting. I mean, you could hit on something with a vibe coded thing, and then know it's now worth to make a non-sloppy version, but you won't get much fame for making ffmpeg twice as fast by prompting an LLM. Though on the other hand, it's like a safe investment (if not in "fame", then in "improving the stuff we all have to use daily"), because you know ffmpeg and many many other things will still be around, whereas a vibe coded thing that wasn't special will be 100% forgotten the next day, or have just the one user forever.
This is not helped by everyone using the same LLMs to find the same vulnerabilities and flooding maintainers with duplicate reports to be the first to get that CVE and branded vuln on their resume.
For now this makes sense.
Each of these three sentences are in need of some evidence. I'm not actually seing any signs of software velocity notably increasing anywhere. Except perhaps in the AI-reseller sphere, but that seems mostly due to throwing huge amounts of VC money at it and a lack of quality control.
At my large org (+100 engineers), I'd say it's a mixed bag and the overall impact of AI rollout looks to be slightly negative productivity.
They probably won't say it publicly though.
It's not because some people are more productive with it that all of them are and it certainly doesn't mean that the company itself is more productive either as you have other things than code to take into account.
I do think it is hype as a killer of knowledge work. It can certainly remove a lot of friction in the kind of borderline mechanical work that you'd formerly outsource to the lowest priced denominator, serve as an idea bouncer, remove friction for bug tracing, etc.
Attempts to cross the next line ("no need for architecture discussions, ai plans", "no need to read the code, ai reviews", and so on), nope.
As someone else mentioned, 100x is a couple days producing the outcomes (remember, not output) of a year. Or for a team, iOS delivering in a single year ten times as many features as its entire previous existence. It's not something that doesn't get noticed.
Is this the direct result of a monolithic kernel? And would moving more drivers out-of-tree mitigate this?
Couldn't an agent monitor feature requests and bug reports, reason about them, and then implement and fix the ones it deems important?
I'm picturing something like folding@home, but where people donate their spare tokens to a service, and those tokens get distributed amongst all open source projects on GitHub. You don't think that would be cool? Like, someone might initialise a repo with only a readme and a to do list before they go to sleep, and then wake up to a complete software ecosystem that looks as if it's been in development since before they were born. Like, so much code that no one person could possibly understand it, and it all happened overnight while they were sleeping!
Unfortunately AI tools are breaking the open community dynamics, it has become more and more expensive to run open community oriented projects due to the noise, it’s really a shame. It’s a lot to expect volunteer project members to triage the increasing amount of AI garbage
And submitting a PR is almost wholly dissimilar from a conversation between friends over dinner or drinks. If you want to have a community around an open source project, it always has taken more than just accepting patches.
I've often thought that it would make sense to have a DIY electrician's certificate, proving that you know how to do basic home wiring, such as outlets, switches, ceiling lamps, basic solar (DC and AC), installing new wire, load calculations, and connecting to breakers in a service panel
I have no problems pulling a permit and going through an electrical inspection.
What I don't get, is why these LLM users aren't asking their LLM for how to contribute and how the project prefers to contribute, and how they can make sure it's accepted? Literally, the very same tools they use to code, can be used to make sure their PR follows all guidelines, from discussions to acceptance of the PR itself, it's right there, they literally just have to prompt for it! Such a lazy group of people.
AI just makes it so obvious how bad of a process it is that we can't ignore it anymore, and now we need to finally figure out good processes.
Even little stuff like: I've created issues on the Claude Code github that got agreement and then led to code changes. Why isn't there a default, built-in way for my issues to rise above the zero-effort chaff? If you finally do the work of vetting someone's PR, why isn't there a built-in (hidden) way to +1 someone so we can see that they have some reputation with the project on their future issues/PRs?
I can go on YouTube and get step-by-step instructions on how to safely wire an entire house. In many jurisdictions I would even be allowed to do that.
I can get instructions on how to completely redo a bathroom, down to the studs and up through the waterproofing and tiling. I can get instructions on how to do foundation repair, which might be a bit much for me but can help me ask the right questions to keep the contractor I hired honest.
These are all examples of experts acting as “traitors” to their particular group. In reality, technology enables both specialization and despecialization. Some people try to cling to their specializations and cry “class warfare” when threatened.
& my point in raising that this is not an issue that's unique to software engineering is to argue that the demons you're proposing software engineers protect themselves from are distractions from the root cause. You're proposing software engineers need to protect themselves from something that's specific to their field when the problem is holistic.
Online retail eating away at local shops is a problem with two aspects - one of which is largely ignored and much more pernicious.
Yes, many people are shopping online which reduces footfall in the town centres. If this were a case of all the existing businesses simply shifting away from physical storefronts to virtual ones it would merely be unfortunate.
What's far worse is that the vast majority of the business that shifted away from a diverse collection of bricks-and-mortar stores now goes through one of a very few online retail giants.
Likewise, a couple of food delivery apps are parasitising takeaway food businesses.
And now we're allowing a handful of AI giants to tollbooth software development.
Very easy to say that in hindsight.
Do you expect your government to navigate whatever transition might await us in a manner that works out well for the vast majority of your countrymen? What about the governments of other major world powers? Even if your local government does all the right things, will the world as a whole end up in a good place?
That said, I'm not sure that there's much in the way of actionable options, at least not with clearly defined outcomes.
The EXT4 filesystem driver as an example contains most of the same code whether it is part of the kernel process or is a user process. A virtual filesystem abstraction is needed between the two in either case as well.
The kernel also already has a module system to support loading externally maintained code. You won't necessarily see a benefit from separately maintained drivers that wouldn't already be present.
I still believe that. 250 lines of tight code that solves a specific problem in a way that others can maintain will always be better than 25k lines of code that's difficult to review and consume (and, therefore, becoming a liability).
Reduce your scale: "100x achieves in 1 hour what used to take 1 week."
One year of work could require levels of complexity and human judgement that can't be accelerated past a certain point.
1 week of work can be reduced to an hour and some change.
A year of that is 1.3M code: the size of systemd, or postgres.
Can you imagine a single person writing systemd (not a POC, the current version feature complete and battle tested) from scratch in a year? If so can you point me to any such project?
I have not said it's specific to their field. I've just been specifically commenting on that field.
(The lack of solidarity is perhaps specific to the field)
> I’m pointing out what I believe to be ridiculous gatekeeping.
I am not gatekeeping. I am stating that we collectively exist in a professional caste and that will go away or lose influence if you let it do so. Other professional castes do this exact same brain exercise and that is why they have protections in place.
> Some people try to cling to their specializations and cry “class warfare” when threatened.
I'll be blunt and just state that I am post money and not remotely threatened by this stuff anymore. I am observing that software engineering as a profession is blindly giving away a ridiculous amount of leverage in the world - in the form of dollars and influence, the value of their labor - and more crucially doing it to themselves.
I will be fine whichever way this shakes out, and I don't really have a dog in this fight short of having spent decent time in the OSS space and finding it sad what it is turning in to.
No, but I expect them to do the best they can, with the information they have available, as always, as they just like me, are just humans. Trusting the legislative branch of my government is different from "so you think it'll work out well for everyone then huh?", btw.
> What about the governments of other major world powers?
Why does it matter how much I trust the legislative branch from other countries? They do as they wish, we continue to do as we wish.
> Even if your local government does all the right things, will the world as a whole end up in a good place?
My experience and opinion is that generally the world is getting better almost every day, vast difference even compared to ten years ago, how much better the world is today, for most people. There are some few countries which lately been going in the wrong direction, but for the most part, we (humanity) are getting incrementally better.
Maybe not?
I just got the impression that there are a _lot_ of obscure drivers that have to be carried, and are eventually removed causing annoyance. An ABI for the people who cared about that random driver might localise the maintenance burden.
Besides 1h what used to to take 1 week is basically 40x given a workweek is 40h.
In other words, if you include everything that's required to create useful software then 100x turns out to be a fantasy.
If one week of work can be reduced to an hour, then you should be able to complete a year's worth of work in 50 hours. If you break that into two 25-hour weeks (because a 40x dev earns the right to loaf?), what is that dev doing for the other 50 weeks in the year? What is making them so incredibly unproductive 50 out of 52 weeks in a year?
This is especially bad with new, or quickly improving frameworks, like Android Compose. LLMs use completely outdated, deprecated APIs all the time, when they are not completely supervised. Or at least, I hope so that the framework causes it. Because if that’s not the case, then your products are fucked.
Also even with the best prompts it could never produce more working code in an hour than what I can produce in a day. Regardless of quality, just “working somehow”. Not even with an uninterrupted session. If that’s the case for some, then there is definitely also a developer skill issue. And so would definitely not trust anything coming out of their “supervision” of an LLM.
I don't think you could get to 1.3M lines of production code, but people say AI agents are good at writing tests. I could imagine that if you had an unlimited budget you could set up agents to generate lots and lots of tests and comments, inflating your weekly total. Like, maybe you can set up an agent to loop against a code coverage tool trying to generate more and more tests to hit MC / DC levels of testing.
In the extreme / absurd case, if you could hit the SQLite ratio of 590x lines of test code vs real code then 25,000 lines of code per week could be 43 lines of production code and 24,958 lines of test code.
You'd be a "100x programmer" in terms of lines of code output, but that would not get you to SystemD levels of production code in a year.
I can't point you to a project taking that route, and I don't have the budget to try it, but I can imagine someone hitting 25k lines of code per week with lots of tests and comments padding the numbers.
I am not sure software written that way would be any good though.
I consider this mode of thinking selfish and anti-progress. It’s pretty much exactly what Americans decry about unions.
What is sad about oss? What is it turning into? I will say far before ai came in oss was a few arms deep in the techfluqncer culture where motivations were driven by gh stars and follow counts rather than a genuine interest. Or maybe what was a genuine interest became twisted as the culture changed.
Who claimed that?
That was the context:
"Fwiw, a non-technical employee in my workplace has begun submitting ai-generated prs to internal repos I maintain & they're of excellent quality, "
Yes, but one key reason that a stable ABI isn't provided for drivers is to help encourage companies that ship drivers to make their drivers open source. The idea being, if a driver is mainlined into the Linux kernel, the Linux developers will help maintain support for that driver, in exchange for it being released with an open source licence. There are companies (like NVIDIA) that ship closed source drivers for their devices, but they rely on a kernel-side shim that interacts with the userspace driver, and this is seen as second best compared to mainlining the driver in the kernel.
Agreed, and that was exactly my point. Concern about possible impacts of a technology were expressed and you responded that you trust your government. But that's not the same as thinking that everything is headed in a good direction and doesn't require intervention.
> Why does it matter how much I trust the legislative branch from other countries?
Because in a globalized world if everyone else goes to shit you will probably also experience significant negative effects even if it's not as bad.
> for the most part, we (humanity) are getting incrementally better.
It seems to me that it's prudent to perform a risk assessment rather than assuming that everything will work out just because things seem to have been going well enough so far.
I do care, it's why I commented what I commented. ;P
I already acknowledged that "caste" is an incorrect word choice and I could've done better there, but my core point remains unchanged.
It's not meant to be taken negatively, and is purely a term that I was choosing to represent "hey, you all need to consider better coordinating/representing/holding the line as a group".
If you consider a union to be a "bad thing" then we are likely going to talk past each other for eternity.
I am fortunate that software has paid me well to work on problems I am enthusiastic about solving. I understand that a lot of people on e.g. the Ford assembly line are not there because they want to make excellent cars, they’re there because they need a job. I acknowledge that I have no idea what it’s like to structure one’s life and priorities this way; it is just completely alien to me to align oneself with the task rather than the mission. And I believe that task-identification mindset is why we hear about resistance to electrification because EVs require fewer assembly steps, or Teamsters cutting power cables at trade shows if the vendor dares to plug in a TV themselves.
Software developers should not ossify. Nowhere have I said that LLMs as a tool - used by those in this profession! - should be shunned. I was pointing out that people being totally okay with those outside our profession, those without the necessary skillsets, directly doing our work not only devalues our work.