Note: An LLM was not used in writing this microblog entry.
This entry is part of a microblog series called LLMs
I’m connecting a few areas of thought together in the context of LLMs.
Firstly, some Fred Brooks comments that seem relevant to whether LLMs may fundamentally change sofware development:
I believe the hard part of building software to be the specification, design and testing of this conceptual construct, not the labour of representing it and testing the fidelity of the representation. […] If this is true, building software will always be hard. There is inherently no silver bullet.
More seriously, even perfect program verification can only establish that a program meets its specification. The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.
Separately, commentary by Richard P. Gabriel indicating that this may not matter for industry, and so LLM adoption may be inevitable:
The essay argues simple, hacked-together software that makes it to market first will often outcompete better and more elegant designs.
Gabriel offers the examples of the adoption of C over Lisp, Unix over Lisp machines and VMS, and x86 over reduced instruction set computers as examples of technically worse solutions defeating more elegant ones by arriving to market first.
Finally, a deeper meditation on why this happens generally by Nick Land, which touches on failed collective action, race to the bottom, etc.
Moloch is exactly what the history books say he is. […]
He always and everywhere offers the same deal: throw what you love most into the flames, and I can grant you power.
As long as the offer’s open, it will be irresistible.