Live data from Hacker News

Changing how we develop Ladybird

ladybird.org

481–490 of 602 posts

Re: Changing how we develop Ladybird

#481

The cause of this is that the cost of creating plausible code contributions has gone down, so PR proposals can multiply, but flaws still threaten project security and LLMs can be confidently wrong. So human review is needed right now to maintain the integrity of the project, but it takes time and costs money. Ladybird's developers, and we as a community, can't easily evaluate "this is what we want" vs. "this is not w…

Full visibility of the source code is very different from having full legibility of the system: comprehensibility is the bottleneck.

(Seems I ran out of edit time!)

Re: Changing how we develop Ladybird

#482

Earlier quoted context omitted.

The code just isn’t the main effort of work anymore. Anyone can generate the implementation, so it makes more sense than ever to instead hammer out the what, why, and how that underlies any code change. I see all projects moving this direction. Makes more sense to hash out a plan together.

Code was never the main effort of work, but it was a clear signal that someone has done the main effort, which is understanding the codebase, designing a new feature, or investigating a bug, and have the knowledge to write the code. By the time you get to review, you can expect a knowledgeable person on the other end. It’s the same about published journal article. A lot of them are a few pages. That is mostly one hou…

Right, and all of that is what I consider to be the "code" effort:

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.

Re: Changing how we develop Ladybird

#483
post #480

Very confusing statement. It is definitely true that OSS is on the verge of a crisis because of AI agents, but they clearly said AI is not the reason to reject external contributors: "Whether code was typed by hand is beside the point." If AI is the problem, the solution would be introducing an AI policy, community trust management system or something like that. Definitely not a closed development process.

How would they know for sure if the submitted code was written by a human or AI? If they had a “no-AI” policy, there would be no way to enforce it.

The policy makes sense to me given the security concerns for the project.

Re: Changing how we develop Ladybird

#484

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…

On this topic, "Open-Source Isn't About You": https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...

Re: Changing how we develop Ladybird

#485
post #5

"Gain trust through plausible contributions" is a new angle on AI-produced PRs I haven't seen yet. Though in retrospect we should have seen it. It's been an angle of attack since forever, it only took a lot of effort.

isn't linux-kernel-development operating on exactly the same model since forever ?

Someone mentioned sqlite in a comment. It's a better comparison IMO.

Also, Linux has many more people, many of whom basically just review code.

Re: Changing how we develop Ladybird

#486
post #378

Earlier quoted context omitted.

I’m confused, when has “everything” been a bazaar, and when did that cease to be?

Umm, I missed a negation there, sorry. I meant that the newest generation has only seen a world where there's a giant OSS ecosystem and the bazaar style is the norm for all of your tool and library needs.

Okay that makes way more sense. It seems especially applicable to web frontend, where everything seems to have been developed out in the open.

Re: Changing how we develop Ladybird

#487
post #372

Earlier quoted context omitted.

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

Man, you must hate those handymen who put up YouTube videos showing how to do basic home maintenance. A truly class-conscious handyman would insist that the homeowner hire them to replace a light switch.

There certainly exists a class of electricians who believe that homeowners shouldn't be changing a light switch, and jurisdictions exist where a permit is required to do so.

Re: Changing how we develop Ladybird

#488
post #430

Earlier quoted context omitted.

> 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. I consider this mode of thinking selfish and anti-progress. It’s pretty much exactly what Americans decry about unions.

> It’s pretty much exactly what Americans decry about unions. If you consider a union to be a "bad thing" then we are likely going to talk past each other for eternity.

I support workers being compensated for their value; what I dislike are protectionism and ossification.

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.

Re: Changing how we develop Ladybird

#489

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.

How many people will ask to be a "priest" and will then violate the rules around AI?

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.

Post reply on HN