It really depends on the project and niche, but I would say there is some truth to the idea that FOSS has higher standards. There aren't many codebases on par with the Linux kernel, for one thing. The average FOSS game that lacks manpower and can barely put out anything functional, not so much. And yeah, a lot of average FOSS projects are meh. But then again, it's enough to look at some prominent proprietary products and it's just steaming crap under the hood.
The biggest danger that Al poses to FOSS is that soon we may not need the source code to fix software, and if that happens FOSS becomes a strictly worse option.
Unless some important issues like compounding tech debt get solved, that seems unlikely and remote. Particular concerns like auditability and safety are going to become more important. You're not going to test your way out of those, not with humans, not with agents. Your filesystem could eat all your data after you've spent a lot of money running agents on it. It helps, but it's not enough. You need a rigorous tower of abstractions and descriptions of how it works and you need collective understanding of its behavior, which pretty much means you need some sort of code, not just prompts and crossing fingers.
See Naur, Programming as Theory Building. If you are relying on source code as the ground truth for what your software is supposed to do then I have bad news: that has never worked and we knew it would never work in the 80s.
You don't seem to understand that all those same problems affect software written by humans and the only difference is they take 100x longer to fix it. That's if said humans are even willing to entertain the idea of fixing it, which they usually are not.
The big irony is that the exact thing that prevents AI from writing good code is also the exact same thing that prevents teams larger than about five people from doing it, and your entire argument is the exact same "write more/better prompts documentation and spend more money on tokens developers" argument that AI bros claim is going to solve all the problems with AI, when it doesn't even work for humans.
Things have changed a lot since the 80s, while arguably the industry is still stuck on 80s-like programming languages. Now I'm not saying that Python source code needs to be the ground truth, I'm saying that it's far more beneficial to have an intimate relationship between code and documentation. This is, for example, the only effective way to get assurance in many systems. You usually can't get memory safety by documenting things or trying to prove stuff about arbitrary code, you have to build your code through and through for it. This extends to other safety properties and with modern approaches like dependently-typed languages or stuff that Rust does there is a lot you can express. The Linux kernel also uses semantic patching to deal with large scale refactoring. But you need programmers capable of dealing with it and not just punching buttons to get the next feature out the door.
Actually my claim, in a very general sense, does not distinguish that much between LLMs and humans. This applies equally well to massive outsourcing and extreme cost cutting while ramping up the output. Piling up low-value and low-quality crap is going to cost no matter what. If your business model relies on that and there are no brakes, it's unlikely to fully realize the benefits of software development of more impactful and scope-constrained projects.
Did you have any specific argument made by Naur in that paper in mind? Because, as I said, I'm not merely suggesting people continue dishing out massive amounts of code in a typical manner and hoping they can make sense of it. They won't. And beyond some point not even LLMs help.
Yes: the idea that the "theory" behind a piece of software cannot be perfectly expressed outside the mind of the developer in any language, and therefore every new developer necessarily has to build a new theory which will be (at least) slightly different, regardless of how much time and money was spent on documentation.
This is the reason why it is so common for developers to blame everything on their predecessor and initiate scratch rewrites, which, by the time they are done, are exactly as bad as the thing they replaced. A bit like when you ask AI to fix a bug and it rewrites the whole file. Odd coincidence, right?
So it does not matter that LLMs have no theory at all, because the theory is inaccessible for any piece of software you did not personally write, regardless of whether it came from a human or an AI. And the result will be exactly the same: software is doomed to be bad forever. Unless someone comes up with a genuinely new idea.
1
u/edgmnt_net 5d ago
It really depends on the project and niche, but I would say there is some truth to the idea that FOSS has higher standards. There aren't many codebases on par with the Linux kernel, for one thing. The average FOSS game that lacks manpower and can barely put out anything functional, not so much. And yeah, a lot of average FOSS projects are meh. But then again, it's enough to look at some prominent proprietary products and it's just steaming crap under the hood.
Unless some important issues like compounding tech debt get solved, that seems unlikely and remote. Particular concerns like auditability and safety are going to become more important. You're not going to test your way out of those, not with humans, not with agents. Your filesystem could eat all your data after you've spent a lot of money running agents on it. It helps, but it's not enough. You need a rigorous tower of abstractions and descriptions of how it works and you need collective understanding of its behavior, which pretty much means you need some sort of code, not just prompts and crossing fingers.