lets consider a common explanation for what professional coders use LLMs for: boiler plate

i often hear coders say "oh yeah, LLMs suck overall, but they're REALLY GOOD for boilerplate"

and this is pretty true!

but, well.. people have been talking about Boilerplate Code since at LEAST 1981, with a popularization happening in 1990

the programming world has known about boilerplate for a while, and had ample opportunity to try to address it. there are even some great ideas!

Go was designed INTENTIONALLY to be feature-sparse because the people who made it wanted to make sure that any schmuck hired by google could write Go without having to learn fancier techniques

so because google's corporate environment was hostile to TRAINING, they made Go

Go is an intentionally feature-sparse language because it needs to be used by people who have low skill levels, because improving people's skills is not a priority

but while it's not Google's priority, it also isn't anyone elses, either

we can't lay the blame at just Google's feet, because you see this across languages, including ones that aren't primarily pushed by large corporations

open source developers, for instance, have a well documented hostility toward helping people learn

and to improving the usability of languages because its good enough like it is and why bother making it better!

in open source, there's low regard for good documentation -- documentation isn't running code so it's a distraction, plus its hard to write b/c no one knows how

and user-friendliness is seen as synonymous with powerless, useless, etc.

so language after language has the most abysmal features, and tools, that are hard to use. and one of those persistent problems is boilerplate

but its not just opensource devs who are to blame here, because the research about this stuff isn't the best either

i mean, there's lots of research on techniques, sure, but academics aren't exactly fantastic at communicating these things in ways average devs understand

the routes into the techniques of PLT are rather limited and sparse

and on top of that, there is also a general tendency for PLT research to avoid the empirically-linked dimensions of theory, such as the issue of boilerplate and similar things

a lot of theoretical work is done on PURELY theory internal things, and so places where theory can touch reality tend to be neglected

more PLT people are probably working on homotopy type theory right now than are working boilerplate

the broad trend here in all of this is that there's a general lower regard for things that make users more capable and more skilled

from the person who isn't a programmer, to the programmer who isn't a language dev, the things that cause them frustrations go ignored

and so lots and lots of things which COULD be done are simply replaced by things that mask over the problem

few people write their own software these days, you just buy a million apps until you find one that suffices

few people make their own websites these days, ...

... you just pay SquareSpace-like companies to get something good enough

few people use skills and tools to augment their programming to get more efficiency, reduce boiler plate, etc. they just ask an LLM to do it

as the support for doing the learning, skill development, and so forth has vanished, people have come more and more to accept tools that completely paper over their lack of skills, and the lack of support

tools which "solve the problem" in a way that make their users worse off

to some degree this is a uniquely software-driven problem, because software is SO powerful and SO capable, that it's capable of supplementing what used to be whole personal skillsets while ALSO being capable of preventing you from leaving the software behind

i mean like, take a completely out of left field example: drafting/CAD

now, CAD is an absolute boon, don't get me wrong!

but no drafter 100 years ago was trained to only use Esterbrook dip pens and stuck using them for all their projects once they used it once

you draw a line on a document using an Esterbrook pen and anyone can read it, and if you need to modify the document later, you can use shitty Bic ballpoint for all anyone cares!

now try doing that with a design made in Fusion 360

or even Freecad

sure you MIGHT technically IN THEORY be able to export files that other programs MIGHT in THEORY be able to make use of

but in practice, you're stuck in that one program unless you want to completely re-implement the design

the most open source un-corporate un-malicious-intent CAD programs out there, like FreeCAD, are VERY convenient but also in a way completely incapable of replicating the end-user-power of pen and paper

and while you might use FreeCAD and then manage to export to some other program successful, you now have to learn that other program

whereas, when you pick up a shitty Bic pen to do your drafting, constructing tangent circles is the same geometry Euclid was using 2500 years ago

software has this tendency to ensnare people with conveniences, even if we don't intend it to, even if we make it very user friendly and end user programmable and provide abundant learning resources

you're still learning _this_ program, or _this_ programming language

which means that it's even MORE important for software folx to emphasize training/skill development, end-user programmability, ease of use, and openness. because those are the only things that currently can reduce the likelihood of people getting trapped