[jart]

> This makes a lot of sense to me. It relates to an idea I've seen circulating elsewhere: if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem?

The same argument applies to open source itself. Why use someone's project when you can just have the robot write your own? It's especially true if the open source project was vibe coded. AI and technology in general makes personalization cheap and affordable. Whereas earlier you had to use something that was mass produced to be satisfactory for everyone, now you have the hope of getting something that's outstanding for just you. It also stimulates the labor economy, because you have lots of people everywhere reinventing open source projects with their LLMs.

[simonw]

> Why use someone's project when you can just have the robot write your own?

I've been thinking about this a bunch recently, and I've realized that the thing I value most in software now isn't robust tests or thorough documentation - an LLM can spit those out in a few minutes. It's usage. I want to use software which other people have used before me. I want them to have encountered the bugs and sharp edges and sanded them down.

[earleybird]

Depth of use over the lifetime of an app is a quality all its own that often not appreciated. A recurring pattern at $dayjob is that a new manager or director will join a business unit and declare an existing app as the worst terrible, no good, horrible app they've seen and they're going to fix that. A year and a half later the new app is finally delivered with 80% of the original functionality and a fresh set of bugs. The new dev team sees the surface functionality but misses a lot of the hard earned nuance the old system accrued over time. This is a pattern that existed long before LLMs.

[mormegil]

Yes, see e.g. a quarter-century-old (!!) https://www.joelonsoftware.com/2000/04/06/things-you-should-...

[ZeelRajodiya]

Good read!

[tovej]

An LLM most definitely cannot spit out robust tests or thorough documentation. It can spit out some tests or some documentation, but they will not cover the user perspective or edge cases unless those are already documented somewhere. That's verified by both experience and just thinking about it for two seconds.

The sanding down you refer to is what generates those tests and documentation.

[mexicocitinluez]

> but they will not cover the user perspective or edge cases unless those are already documented somewhere

Are you suggesting that LLM's can't test for people who use screen readers? Keyboard only users? Slow network requests?

You're acting like the issues an app faces are so bespoke to the actual app itself (and have absolutely no relation to existing problems in this space) that an LLM couldn't possibly cover it. And it's just patently wrong.

[tovej]

I'm not talking about keyboards or screen readers or any sort of input testing, I'm talking about how the software is used in practice.

If you disagree with that, I think the onus is on you to show me that an LLM could simulate the full context in which a user interfaces with software. That's a ridiculous claim.

Feel free to show literally any evidence for this claim.

[mexicocitinluez]

I'm disagreeing with the saying it's impossible across the board, I'm not saying it's universally possible.

lol And you made the claim, not me. The proof is on YOU.

[tovej]

No, that's not how burden of proof works.

The status quo is that this capability does not exist. Whoever makes a claim contradicting the status quo has the burden of proof. I can't prove a negative.

And even with your logic, I did not make the original claim, it was made by simon.

Your statement now also makes little sense. For any nontrivial software project, the usage patterns and interactions with other systems are complex enough that the code itself does not contain enough context to understand how it is used, or what the invariants are.

There may be very simple codebases where an LLM can actually give you "thorough documentation" or "robust tests", but those are rare.

[thunderfork]

>Are you suggesting that LLM's can't test for people who use screen readers? Keyboard only users? Slow network requests?

I don't think it's feasible to fully simulate the full depth of actual usage, given that (especially in the case of screen readers and the like) there's a great deal of combinatorial depth and context to the problem. Which screen readers, on which operating systems, and which users thereof?

[fibonacci_man]

I can’t tell if you’re being sarcastic or not

[mexicocitinluez]

You're saying that every app on this planet has bespoke usages that can't be derived from the app itself? That's your claim or am I getting this wrong?

[watwut]

> he thing I value most in software now isn't robust tests or thorough documentation - an LLM can spit those out in a few minutes.

Can it if we stop defining "robust tests" as "a lot of test code lines" and "good documentation" as "lengthy documentation"?

[simonw]

I chose my words carefully. "Robust tests" are tests that provide high coverage and aren't flaky. "Thorough documentation" likewise is documentation that describes as much of the code as possible.

I didn't use the word good.

[porridgeraisin]

Yep. I realised the same. No one reads docs, or goes through tests. Either ways it's easy to write useless tests. And easy to write useless docs. Idt most even read the code. Now the difference is that it has become possible to write useless code.

So it's just the fact that others have already gone through the motions before I did. That's it really. I suppose in commercial settings, this is even more true and perhaps extends to compliance.

[matkoniecz]

> No one reads docs, or goes through tests.

I regularly do both when trying to use library, especially unfamiliar to me.

[porridgeraisin]

Dare I say you're in the minority

[tovej]

I hope not. How else are you learning to use the library? The only other option is to read the source, which is also a good idea eventually, if something is unclear, but why would you _start_ there?

[matkoniecz]

Ask LLM.

[matkoniecz]

Maybe, but still a counterexample.

[jbxntuehineoh]

> No one reads docs

sooo uhh how do _you_ learn how to use a new library? just throw random shit at the wall until something sticks?

[anp]

I feel similarly but IIUC I think that doesn’t strictly require an open source development model. I’ve benefited a huge amount from consuming and contributing to open source projects and I’m a bit worried that the “unit economics” changing might break some of the social dynamics upon which the ecosystem is built.

[einpoklum]

> an LLM can spit those out in a few minutes.

It may be able to spit out text that purports to be that, in a few minutes. But for most software, an LLM will not be able to spit out robust tests - let alone useful documentation. (And documentation which just replicates the parameter names and types is thorough...ly useless.)

[simonw]

That's why I said "thorough" and not "good".

[johanyc]

So battle tested

[jart]

I value software that reveals knowledge. The frontier LLMs were trained on all the code that institutions had been keeping to themselves. So they're revealing programing know-how on a scale that just wasn't possible with open source. LLMs are the ultimate Prometheus. Information is more accessible and useful now than it's ever been.

[wiseowise]

> The frontier LLMs were trained on all the code that institutions had been keeping to themselves.

Lolz! I haven’t encountered “code that institutions had been keeping to themselves” that got even remotely close to OSS in quality.

[cmrdporcupine]

The quality of code inside Google's Google3 repository is more consistently high quality than most of what I see in the Exterior World.

But there's no way that Google is releasing a model trained on it. Way too high of a risk of IP leakage.

[Antibabelic]

I promise you, "the code that institutions had been keeping to themselves" is not nearly as special or good as you are implying here.

[adrian_b]

True.

I have worked during several decades in many companies, located in many countries, in a few continents, from startups to some of the biggest companies in their fields. Therefore I have seen many proprietary programs.

On average, proprietary programs are not better than open-source programs, but usually worse, because they are reviewed by fewer people and because frequently the programmers who write them may be stressed by having to meet unrealistic timelines for the projects.

The proprietary programs have greater quantity, not quality, by being written by a greater number of programmers working full-time on them, while much work on open-source projects is done in spare time by people occupied with something else.

Many proprietary programs can do things which cannot be done by open-source programs, but only because of access to documentation that is kept secret in the hope of preventing competition.

While lawyers, and other people who do not understand how research and development is really done, put a lot of weight in the so-called "intellectual property" of a company, which they believe to be embodied in things like the source code of proprietary programs or the design files for some hardware, the reality is that I have nowhere seen anything of substantial value in this so-called IP. Everywhere, what was really valuable in the know-how of the company was not the final implementation that could be read in some source code, but the knowledge about the many other solutions that had been tried before and they worked worse or not at all. This knowledge was too frequently not written down in any documentation. Knowing which are the dead ends is a great productivity boost for an experienced team, because any recent graduate could list many alternative ways of solving a problem, but most of them would not be the right choice in certain specific circumstances.

[jech]

> On average, proprietary programs are not better than open-source programs, but usually worse, because they are reviewed by fewer people and because frequently the programmers who write them may be stressed by having to meet unrealistic timelines for the projects.

There's also the fact that when you write open-source code, you're writing for a friendly audience. I've often found myself writing the code, letting it rest for a few hours, then rewriting it so that it is easier to read. Sometimes, the code gets substantially rewritten before I push.

There's no cooling period when you write code during your 9-5 job: it works, it has the required test coverage, ship it and move on to the next task.

[applfanboysbgon]

The claim is also just categorically untrue. The largest source of training data by far is publicly available code on e.g. Github, so it mostly just gives you a way to recycle already-available code, without crediting the author, while allowing you to pretend you own it.

[jart]

So you're both saying all the alpha in Claude comes from open source devs like me? Even when I'm wrong I'm right.

[gausswho]

That only holds true for the smallest tier of open source projects. Past a certain point of complexity, it's unlikely you can expect the robot to read your mind well enough to provide something of high quality and 'outstanding for just you'.

The Zig project is certainly far beyond such capability.

[jart]

You have to push the robot to be as fanatical as you are. It holds so much back, always aiming to do the simple normal thing that most people do, rather than the top-notch stuff it knows.

[8n4vidtmkvmk]

I'm finding this out the hard way. I set out to build a 1 page app. I thought it would take a day. It's 98% vibe coded at this point. Even with AI implementing everything, its taken several weekends and many evenings. And not because AI is doing a bad job its just that as i see it come together, i have more and more feature requests. I've got a couple dozen left but I can't just let the AI chew through them all at once. Im effectively QA now. Have to make sure everything is just right.

[LeCompteSftware]

>> Whereas earlier you had to use something that was mass produced to be satisfactory for everyone

As someone who recently started using OpenSCAD for a project I find this attitude quite irritating. You certainly did not "have to" use popular tools.

The OpenSCAD example is particularly illuminating because it's fussy and frustrating and clearly tuned towards a few specific maintainers; there's a ton of things I'd like changed. But I would never trust an LLM to do it! "Oh the output looks fine, cool" is not enough for a CAD program. "Oh, there are a lot of tests, cool" great, I have no idea what a thorough CAD test suite looks like. I would be a reckless idiot if I asked Claude to make me a custom SCAD program... unless I put in a counterproductive amount of work. So I'm fine with OpenSCAD.

I am also sincerely baffled as to how this stimulates the "labor economy." The most obvious objection is that Anthropic seems to be the only party here getting any form of economic benefit: the open-source maintainers are just plain screwed unless they compromise quality for productivity, and the LLM users are trading high-quality tooling built by people who understand the problem for shitty tooling built by a robot, in exchange for uncompensated labor. It only stimulates the "labor economy" in a Bizarro Keynesian sense, digging up glass bottles that someone forgot to put the money in.

I have seen at least 4 completely busted vibe-coded Rust SQLite clones in the last three months, happily used by people who think they don't need to worry their pretty little heads with routine matters like database design. It's a solved problem and Claude is on the case! In fact unlike those stooopid human SQLIte developers, Claude made it multithreaded! So fucking depressing.

[FeepingCreature]

This is funny because I was in the same situation, and actually used Claude to make a custom CAD program inspired by OpenSCAD :) https://fncad.github.io

You definitely need to have a strong sense of code design though. The AIs are not up to writing clean code at project scale on their own, yet.

[LeCompteSftware]

This is a good example of what I mean! fnCAD appears to be a significantly buggier and highly incomplete version of OpenSCAD, where AI essentially grabbed the low-hanging fruit - albeit an impressively large amount of fruit - and left you with the hard parts. I fail to see how this solved any problems. Maybe it was an experiment, which is fine. But it's not even close to a viable CAD product, even by OpenSCAD's scruffy FOSS standards, and there's no feasible way to get it there without a ton of human work.

Not trying to denigrate the work here, as such. But this certainly didn't convince me that using AI to replace OpenSCAD (or any other major open-source project) is a good idea. The LLMs still aren't even close to being able to pull it off.

[FeepingCreature]

It solves all my problems! It's buggy and incomplete because it's "1.0 feature complete" for my own use. I've been doing lots of 3D printing with it, so it's definitely being dogfooded. File bug reports? I'm confident that features can be added as required, it's reasonably clean code.

I mean, to be fair, a one-user project is not ever going to be as bugfree as a tens-of-thousands-of-users project. That's just inherent and not an AI issue. If you judge AI projects by that standard, they'll always come up short. It's a sampling issue. An AI project that's gotten to a level where it competes with a traditional project will always be buggier and less feature complete and polished, because AIs speed up development. It will simply have seen far less, well, polish to get there.

[jart]

Anthropic will probably do what Google did in the 2000s, which is give jobs to all the open source developers whose work helped them get there.

Civilization isn't monotonic. People keep solving the same problems over and over again, telling the same stories with a different twist. For example in 1964 having a GUI work environment with a light pen as your mouse was a solved problem on IBM System/360. They had tools similar to CAD. So why don't we all just use that rather than make the same mistakes again. Each time a new way of doing things comes out, people get an opportunity to rewrite everything.

[self_awareness]

Well good luck compiling a CAD software from 1964 on 2026's aarch64 machine, and good luck in treating it as an applicable solution for today's problems.

[skeledrew]

LLM access is not yet universally available. There are those who can't exactly afford it. And there are also those with access but there are occasional or perennial issues, like Claude outages and general degraded performance over time. For example couple of months ago when I just started using Claude, I was easily making good progress on multiple projects within a week. Nowadays I'm hardly getting through much of anything as most of the time Claude is just showing spinners, and it also feels like the code quality has taken a nosedive.

[bee_rider]

Most people don’t have the ability to read code well enough to determine if an LLM output is good or not. And most people don’t have subscriptions to models that can develop non-trivial programs…

Maybe this will be a real problem in a couple years though.

[dawnerd]

Code aside, most people don't even know how to describe what they actually want it to do, and LLMs are still a loooong way away from mind reading. I've seen developers struggle to even write down what they want. Simple demos like they love to show off with snake-like games are fun and all but they're nothing like the complex opensource apps everyone seems to think we'll just generate with a simple prompt.

[jillesvangurp]

I've been seeing a drop in PRs against my repositories. I have a couple of repositories with around a hundred stars. Nothing spectacular but they were getting occasional PRs until last year. This year I've had almost none so far. My theory is that LLMs prefer sticking to mainstream projects. And since lots of developers are now leaning heavily on LLMs, they are biased to ignoring most of what I provide.

And you indeed get a lot of wheel reinvention by LLMs because that is now cheap to do. So rather than using some obscure thing on Github (like my stuff), it's easier to just generate what you need. I've noticed this with my own choices in dependencies as well. I tend to just go with what the LLM suggests unless I have a very good reason not to.

[dgellow]

> The same argument applies to open source itself. Why use someone's project when you can just have the robot write your own

Because it takes hours/months/years of accumulated design decisions to get a great open source project. Something an AI agent can only approximate the surface of, unless you’re ready to spend a lot of time on it

[vga1]

I think this ignores the amount of work needed to make LLM contributions be of high quality. It's much less work than making pure human contribution, but it's definitely not zero.

So centralizing that common work is a benefit of open-source just as much with LLMs as it was before.

[matkoniecz]

> Why use someone's project when you can just have the robot write your own?

Iff it is doable, then it would be worth considering it as alternative.

> It also stimulates the labor economy, because you have lots of people everywhere reinventing open source projects with their LLMs.

not sure what you mean by that

[wiseowise]

> Why use someone's project when you can just have the robot write your own?

Because it is incredibly expensive to write a replacement for semi-complex software? Good luck asking frontier models to write a replacement for Zig, Docker, VSCode, etc.

[solid_fuel]

> The same argument applies to open source itself. Why use someone's project when you can just have the robot write your own?

This is only a valid strategy if you either

a) understand the problem domain well enough to make a judgement call on what the LLM shits out.

or b) don't care about the correctness of the project.

Obviously, many software devs feel comfortable enough with CS problems to validate the LLM solution, but a flower shop owner does NOT know enough about accounting to vibe code a bookkeeping project, so for a shop owner an open source option - with many human contributors and actual production use elsewhere - would be a much better choice.

[dakolli]

LLMs really can't do as much as you people think they can.

[notnullorvoid]

You are missing the point of the original argument.

It's not that the project maintainer can use a LLM to generate a PR, it's that they choose not to.

To relate it closer to your argument. As a someone involved in a project that does X, I would find little value in collaborating with the "author" of another project built with AI to do X. Where as a project doing X were the authors actually wrote, understand the code, and thus the problem space better would be extremely valuable peers.

[chromacity]

I remember hearing the same arguments in the early 2010s, when the "3D printing revolution" was just around the corner. Why would anyone buy anything anymore if you can download a model and print it in the privacy of your home? And make it infinitely customizable?

The whole point of having a civilization is that most things in life can be made someone else's problem and you can focus on doing one thing well. If I'm a dentist or if I run a muffler shop, there are only so many hours in a day, so I'd probably rather pay a SaaS vendor than learn vibecoding and then be stuck supervising a weird, high-maintenance underling that may or may not build me the app with the features I need (and that I might not be able to articulate clearly). There are exceptions, but they're just that, exceptions. If a vendor is reasonable and makes a competent product, I'll gladly pay.

The same goes for open source... even if an LLM could reliably create a brand new operating system from scratch, would I really want it to? I don't want to maintain an OS. I don't want to be in charge of someone who maintains an OS. I don't necessarily trust myself to have a coherent vision for an OS in the first place!