they can vibe-code their own browser, there's no need for the public to access every single open-source project anymore, you need to find people you can actually trust
Changing how we develop Ladybird
411–420 of 602 posts
Re: Changing how we develop Ladybird
#412As far as I can tell, architecture, i.e. sound, precise definitions of exactly what a software artifact must do, is now critical. And with LLMs, it's now feasible to begin implementing such things, though many brownfield projects may be intrinsically unsound in ways that their creators are unaware of. In such a world, contributions simply require a modified proof that the software does what it must do, with perhaps additional claims that the maintainers provide.
Re: Changing how we develop Ladybird
#413I can understand where they come from. If most of the pull-requests were AI-coded, well, the maintainers are equally capable of prompting Claude Code themselves. 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.
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).
Re: Changing how we develop Ladybird
#414I am old enough to remember what happened to GCC. It was also developed by a closed group of maintainers, because "it couldn't work" as a bazaar-style development. Then EGCS fork happened and became more successful. 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…
Re: Changing how we develop Ladybird
#415Earlier quoted context omitted.
The pre-ai reaction was also unwarranted: committing a massive amount of potentially unmaintainable handwritten code isn't a necessarily positive contribution and any decent engineer (or person tbh) would understand that & not expect gratitude, no matter how concerted their effort. 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…
> 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 is hard for me to imagine another engineering discipline that would be totally fine accepting work from those who don't…
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?
Re: Changing how we develop Ladybird
#416Earlier quoted context omitted.
Come on, are you really going to strawman "engineering should be inherently disqualifying" into "so people shouldn't DIY in their own home"? Please try a little bit harder.
I’m not strawmanning anything. I’m pointing out what I believe to be ridiculous gatekeeping. Software engineering isn’t some holy magic that must be kept from the masses. 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…
Re: Changing how we develop Ladybird
#417"A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds." I believe this is the key point the article makes and it's valid for most projects out there
Re: Changing how we develop Ladybird
#418"A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds." I believe this is the key point the article makes and it's valid for most projects out there
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.
Re: Changing how we develop Ladybird
#419Goodhart's law, again. 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…
There is, it’s being able to tell bullshit from actual cosplayers. 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.
How do you do that efficiently so it can scale?
Re: Changing how we develop Ladybird
#420On the one hand, if you grew up in the baazzar, moving to the cathedral might feel like the "death of open source" even if it is really just a return to an earlier way of working. 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.
Open source development has become more and more superficial aligning with modern social network characteristics. It's more important to have an contribution, a active commit history, a few stars as a proof of pixel fame than the intrinsic value of the contributions or projects. Before the rise of github, open source projects were heavily walled gardens. Little clubs that gave you a stare when you entered the room. G…
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.