Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Changing how we develop Ladybird

ladybird.org

Post reply on HN
Print view View original

431–440 of 602 posts

Re: Changing how we develop Ladybird

#431

Post by jakolaptu »

lucideer wrote: post #87
Fraterkes wrote: post #66

I've been looking a lot at Godot (another big open source project) PRs lately, and there's been kind of a surge of wholy ai-generated PRs (both code and description). This is agains project-policy, so people creating these PRs usually get mildly told off. What's surprising is that while many submitters take that fairly well, some people get really indignant, essentially calling the maintainers ungrateful. It's kinda…

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…

But your company employs said individual, whereas arbitrary drive-by patches from randos on open source projects with no consequence of submitting a mountain of garbage.

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.

Re: Changing how we develop Ladybird

#432

Post by thewebguyd »

CodeCompost wrote: post #278
cpcallen wrote: post #42

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

> it more difficult to identify who to invite to join the priesthood. 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.

I think whats more likely to happen is patches & forks stop being shared. If AI continues to improve, I see a world where people are mostly no longer making software for others, but purely for themselves.

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.

Re: Changing how we develop Ladybird

#433

Post by rurban »

losvedir wrote: post #407
rurban wrote: post #333

Earlier quoted context omitted.

[flagged]

This thread is in the context of community PRs in open source projects. So it's not about AI or not, it's about maintainers using AI vs random contributors using AI. My point is that with AI, where the actual code generation is easy, there's little value in community PR contributions anymore.

Hmm. I've read that differently. Maybe you are right. So he is going the GNU/FSF direction avoiding the minefield of external contributions

Re: Changing how we develop Ladybird

#434

Post by dofm »

zkry wrote: post #216
Fraterkes wrote: post #66

I've been looking a lot at Godot (another big open source project) PRs lately, and there's been kind of a surge of wholy ai-generated PRs (both code and description). This is agains project-policy, so people creating these PRs usually get mildly told off. What's surprising is that while many submitters take that fairly well, some people get really indignant, essentially calling the maintainers ungrateful. It's kinda…

I can imagine in these cases the LLM is telling the "contributor" how smart they are and how much the project is loosing out, maybe saying something like: "It's not about maintaining project boundaries, it’s not about ensuring code quality; it’s a gatekeeping mechanism designed by traditionalists who feel threatened by forward-thinking creators like you who truly master the efficiency of AI."

Whether or not they are, I agree it is entirely possible to imagine them doing that, given what we know about how AI chat has reinforced people doing much worse to themselves and others.

(And the whole "miffed AI wrote a shitpost" thing)

Re: Changing how we develop Ladybird

#435

Post by sph »

tgv wrote: post #83
domenicd wrote: post #80

Fascinating to see that Chromium/Gecko/WebKit are now more "open" browser engines than Ladybird, at least in one important respect. (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 cre…

Chrome is Google's loss leader.

It sure is, but it’s a bit weird to call loss leader the cornerstone of their trillion dollar monopoly.

Re: Changing how we develop Ladybird

#436

Post by LeFantome »

kjksf wrote: post #409
js8 wrote: post #376

I 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…

You're extrapolating from an exception. 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…

I think 8 full-time people at this point.

Re: Changing how we develop Ladybird

#437

Post by jeremyjh »

nh2 wrote: post #371
jeremyjh wrote: post #226

Earlier quoted context omitted.

> 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. You state these things as if they are facts, but they are completely contrary to the liv…

> Would you mind sharing a link to one of the open source project you've been maintaining and reviewing contributions on for years 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 o…

Thanks for your work on nixpkgs but I think that shapes your perspective quite a lot - its a very different project from Ladybird. Not to belittle your contributions there but the majority of commits there are a few lines of code and much of it is declarative. I'm sure a lot goes into review of entirely new packages and there are some complex interactions between dependencies to consider on some changes but not in a program structure or logic sense. Vibe slop may not be so much an issue there.

Re: Changing how we develop Ladybird

#438

Post by dofm »

rurban wrote: post #333
losvedir wrote: post #321

Earlier quoted context omitted.

It's interesting to see this perspective in the wild. In the age of AI I wonder what "massive value" your PR is bringing to the maintainer. $1 worth of tokens?

[flagged]

> Only stoneagers would say that they are better than a good AI.

I am only a bit above average and I clearly still write better code than a good AI.

The only question left in my mind, alas, is whether that is enough to earn a living.

I mean: it is clear that in every domain except for programming, a talented XYZer can do better than an appropriate LLM trained to do XYZ (except perhaps in some absolutely exhausting pattern recognition tasks).

So I am not sure why we see our own field as different. A sort of inverted Gell-Mann amnesia?

Re: Changing how we develop Ladybird

#439

Post by pianopatrick »

torben-friis wrote: post #391
pianopatrick wrote: post #352

Earlier quoted context omitted.

I can believe that the difference between the slowest programmer in the world and the fastest AI aided programmer in the world is now 100x in terms of lines of code output. Like I can imagine a programmer writing 250 lines of code per week by hand and I can imagine an AI powered person writing 25,000 lines of code per week.

>and I can imagine an AI powered person writing 25,000 lines of code per week. 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?

Well, as a thought experiment, I'd say that depends on if the measure is "1.3M lines of production code" or "1.3M lines of code (test code, comments and production code combined)".

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.

Re: Changing how we develop Ladybird

#440

Post by sdsdffsddfs »

elgertam wrote: post #412

Having read the blog post and then the comments here, I'm rather astonished. Do we understand our craft so little that our only realistic option is to ban LLMs (so-called AI)? Has everyone forgotten we've been in a software crisis for almost sixty years?[0] Have we so internalized the sweat-of-the-brow we've accumulated for decades that it's now part of the identity of being a programmer, and the only reliable signal…

I believe the development world has a few cultural issues that make it hard to focus on the issues at hand. As a group we tend to not see the forest for the trees which causes us to worry about microscopic details while ignoring overwhelmingly more important realities, like, say, economics, lack of proper communication, team alignment, power hierarchies, etc. Being male-dominated has also not helped us for as far as I can tell the field, like many others, is dominated by power play, ego and identity issues. Everyone is trying to prove to everyone else how clever they are instead of cooperating properly. I can count on one hand the programmers I met that are actually humble and not just humble bragging. I myself am guilty of this arrogance.

If we were at all competent we would have focused on the issues you mentioned. Architecture, intent, definitions, validation, actual proof that our work does what it needs to do. We didn't care because we were too busy showing ourselves and the people we look down on - the "suits" and other programmers using different styles/languages/frameworks - how superior we are and how clever we are that we can internalize and navigate Rust's syntax and C++'s foot-guns.

Unfortunately, or perhaps fortunately depending on your perspective, I think that strategy is dying. It might be best for us to keep the eyes on the ball. What does the system need to do and how do we validate that it in fact does what it says on the tin? All the rest is noise and that includes "code". If a million monkeys on typewriters get the job done within acceptable parameters so be it.

Post reply on HN