I hear a lot of people talk about LLMs writing the "boilerplate" and wonder why they haven't abstracted that away in the first place.
Maybe my brain has been permanently altered by hacking Lisp.
Maybe my brain has been permanently altered by hacking Lisp.
It’s nontrivial to structure your entire AST so that the parts you abstract away are the parts you’re not going to need direct access to three months later. And I never really figured out, or saw anyone else figure out, how to do that in a way which establishes a clear pattern for the rest of your team to follow.
Especially when it comes to that last part, I’ve found pragmatic OOP with functional elements, like Ruby, or task-specific FP, like Elm, to be more useful than Clojure at work or various Lisps for hobby projects. Because patterns for identifying boilerplate are built in. Personal opinion, of course.
I remember years ago, when I worked at a large PC OEM, I had a conversation with one of our quality managers -- if an updated business process consumes half the resources, but fails twice as often, have you improved your efficiency, or just broken even?
"Qualitatively insufficient, but gets you there" sounds like a contradiction in terms, assuming "there" is a well-defined end state you're trying to achieve within equally well-defined control limits.
The way to to use AI is to get help writing that generation logic, not to just get it to crank out boilerplate.
You're not winning just because AI is taking the manual work out of cranking out primary boilerplate.