Boilerplate and plumbing code isn't inherently bad, nor do you improve the codebase by factoring it down to zero with libraries and abstractions.

As I've matured as a developer, I've appreciated certain types of boilerplate more and more because it's code that shows up in your git diffs. You don't need to chase down the code in some version of some library to see how something works.

Of course, not all boilerplate is created equally.

Boilerplate is better than bad abstractions. But good abstractions are far superior.

The best abstraction is no abstraction.

No.

Edit: I'm not going to code asm just to be cool.

asm? Why would anyone use that useless abstraction over byte code?

bytes are abstractions. Only use them if you know upfront how many bits you need.

I agree with you but as I've matured as a programmer, I feel like it's very hard to get abstractions for boilerplate right. Every library I've seen attempt to do it has struggled.

Even Rails went with codegen despite being backed by the language most amenable to abstractions.

I would consider deterministic codegen to be a valid abstraction (or rather a valid implementation of some abstraction). It's not really any different from a regular library wrt ability to test & validate. The problem with any human- and LLM- handwritten code is that even the best coders make mistakes.

Abstractions are like mutations - most of them kill the host =P

"A program is like a poem. You cannot write a poem without writing it." — Dijkstra

You can use niche libraries and still benefit from AI, basically anything I want to code is something that I don't think exists, and to bend API in a way that makes a generic library do just what I want means basically writing the same code, just instead of contributing to library its immediate, because the "piping" around it magically appears. I bet if it keeps improving at a current late for a decade, the occupation "programmer" will morph into "architect".

I'll take boring scaffolding code over libraries that perform undebuggable magic with monkey patches, reflection or dynamic code.

With LLMs, I hope we move towards libraries that make code easier to read, not easier to write.

We won't be eliminating anything until we give up on only ever working directly on plaintext single source of truth code. AI is automating tedium that's otherwise impossible to automate because we're stuck in a 1970s Unix paradigm and can't let go.

But people, especially here on HN, are saying it's the only way to go.

> because it means there's high demand for a reusable library

Every 'modern' project takes bucket loads of (annoying) setup and plumbing. Even in rather trivial 'start' cases, the LLM has to spend quite a bit of time to get a hello world thingy working (almost all of that is because 'modern programmers' have some kind of brain damage concerning backward compatibility; move fast and break things between MINOR versions that have no use or reason for those changes whatsoever but 'they liked it better', so stuff never works as it says on the product page; heaven help you if you need something exotic to be added). It's a terrible timeline for programming, but LLMs do fix at least that annoyance by just changing configs/slabs of code it until it works.