In the last week, I’ve seen an uptick in ‘AI is good for boilerplate’ posts. It is 2026. Metaprogramming is over 50 years old. Why are we writing boilerplate at all, much less creating expensive tools that let us write more of it faster?
Discussion
Loading...
@david_chisnall because quite often the source of boilerplate isn't mine, e.g. terraform or fitting into an existing project. I wish my life was just the interesting parts!
@david_chisnall @simon because you see if we had people with expertise in metaprogramming they would demand to be paid like experts and it’s much easier to have some opex to a third party than to have expensive humans do the work. Bonus if labour costs lessen as a result.
The thing is, most of these projects are using some framework. And so the number of people who need to have that expertise is quite small: it's the folks who write the framework. But very few popular frameworks seem to put much effort into this.
@david_chisnall I agree with you, but I wonder if metaprogramming deserves more attention from programming language designers than it’s been getting. A couple of years ago my colleagues and I used Scala’s new, revised macro system to write a library that generated validating newtypes for arbitrary types. We wanted constants to be validated at compile time, so it was impossible to construct an invalid instance. This was surprisingly hard (but possible) to implement. Maybe widespread use of LLMs for boilerplate could motivate language designers to design more powerful, more ergonomic macro systems?
I think it's worth separating compile-time and run-time metaprogramming. Smalltalk and Lisp did a lot with the latter to remove boilerplate. Higher-order abstractions that let you just write code for the things where you're deviating from some template are very easy in these languages. Python inherits this ability, but it seems to be used a bit less. JavaScript also inherits it and uses it even less.
Compile-time metaprogramming features are often less flexible but have two additional benefits: better performance (code specialisation at compile time, versus additional dynamic dispatch indirection at run time) and the opportunity to do better error reporting. The latter is the killer feature for me of C++ and Rust over C in systems programming: I can write APIs that will fail to compile if you use them wrongly. That's incredibly valuable, but it doesn't necessarily reduce the amount of code that you need to write.
Features like key-value coding and key-value observing in Objective-C didn't do anything at compile time but massively reduced the amount of code that you needed for GUI apps by allowing the frameworks to ship 100% generic controller classes that just needed to be parameterised on key names.
@david_chisnall @benjamingeer Lisp (CL, at least) also does good things with compile-time metaprogramming.
@david_chisnall “it doesn't necessarily reduce the amount of code that you need to write” but I’ll happily write more code to make it less likely that I’ll get woken up in the middle of the night to deal with an incident in production.
@david_chisnall I got this argument two years ago from various colleagues, as "look, LLM is very good at generating boilerplate for front-end tests, back-end api functions...".
my immediate reply was *why do we need those boilerplates? why don't we create an abstraction layer that does all of those and call that every time we need it?*
they usually just answered with dismissal and vaguely explaining it would be too much work - so instead of reducing complexity, we added more via "AI" agents 🫠
@david_chisnall I love metaprogramming but you may as well ask why we even still have to write code at all in 2026, given that surely every problem in the field of computer programming has already been solved decades ago
I write new code to solve new problems. I write boilerplate to solve the same problem in a different place. I have no problem with the former.
@david_chisnall From time to time, I use it to reduce boilerplate. I don't respect, say, bash enough to truly desire to learn more about it. Enough has been said about their limitations elsewhere. I have better things to do than code-golfing bash, but I want the result - my bash to be terse.
Never point LLMs at things you love. I don't love nix the language or C++17 and I never will
@david_chisnall Many people I've worked with were excited about the possibility "AI" would make mash-ups of apps so much easier. You just get an "agent" to go through the UI of apps in the background, and complete tasks for you, instead of having to figure out how to drive each of these APIs.
But this is software engineering *failure*. The problem is shitty APIs, and if you go down this path, you're never writing good APIs—only documentation for your shitty "agents" to infer actions from.
@david_chisnall The exact meaning of "boilerplate" in these discussions is unclear to me.
Are we talking about the sort of common cross-project tasks that libraries (our own or other people's) can be brought in to solve? E.g. reading and validating a config file, handling HTTP requests, playing audio.
Or, is it the sort of smaller utility functions we all end up writing/copying into every project? Formatting a duration, pluralising some text.
Is it both, or something else entirely? Are these in fact the same?
@david_chisnall I've had this conversation so many times with people and it has confused me since day one. Isn't the point of boiler plate to write once and use those same pieces forever? I suspect this actually means that it creates scaffolding when they don't know how to start a project, which to me is more of an indictment on project setup and layout tooling than anything else.
@david_chisnall Boilerplate is a strong indicator that the API is badly designed. "Wizards" even moreso.
@david_chisnall
Agendas...
I suspect somebody is desperate to drown out bad publicity, and/or make their IPO seam better.
@david_chisnall and me here has been generating boilerplate for decades using small shell scripts, templates and hotkeys. not an unsolved problem. but newbs be newbs...