> Because getting the F/LOSS alternative to feature-parity is going to require a multi-million-dollar investment,

That may have been true a year ago, but these days FOSS software can be extended by anyone with a GPU and some imagination, or any proprietary software can be rapidly reverse engineered and clean-roomed as open source. I have added features to most software I use every day.

Adding a giant pile of vibecoded garbage to a questionably-engineered hobby project does not usually tend to result in stable and production-ready software suitable for betting your livelihood on. Besides, those tokens - and especially those GPUs - aren't exactly free either.

If anything, at the bare minimum you're still going to need to pay a domain expert to judge the LLM's design documents. A hands-off "Clone Adobe Premiere Pro, make no mistakes." might eventually result in something vaguely Premiere Pro-shaped, but Good Luck convincing any members of the project's F/LOSS community to play whack-a-mole with your unmaintainable LLM dump to actually make it work.

When experienced software architects use LLMs to produce software they have actually read the code of and iterated on, they can get actually maintainable results and you cannot tell an LLM was involved.

For instance, even if it triples the wall time, you can say "Generate mathematical proofs for every function" and watch it fix a ton of its own bugs.

I have added tons of features to FOSS software I use with my own consumer GPUs and that is only going to get easier and require less hand holding to get correct and maintainable output.

There is indeed a middle ground between yolo one shots in Astra and tools carefully guided by an engineer. I suppose time will prove out the tactics that result in maintainable software.

As a Linux OS maintainer, LLMs have made debugging and fixing obscure bugs 100x faster freeing me up for more time to solve new problems.

[delayed]

Let he who has never committed broken code cast the first stone.