Great analogy. We've attempted to produce these systems and every time what emerges is software which makes easy things easy and hard things impossible.

This is a terribly confused analogy, afaict. But maybe if you could explain in what sense boilerplate, as defined in https://en.wikipedia.org/wiki/Boilerplate_text, is anything like a nail, it could be less confusing.

You can design furniture without nails or screws. See https://en.m.wikipedia.org/wiki/Japanese_carpentry

Reason Japanese carpenters do or did that is that sea air + high humidity would absolutely rot anything with nail and screw.

No furniture is really designed from a single tree, though. They aren't massive enough.

I agree with overall sentiment. But the analogy is higly flawed. You can't compare physical things with software. Physical things are way more constrained while software is super abstract.

I can tell you about 1000 ways, the problem is there are no corporate monetary incentives to follow them, and not much late-90s-era FOSS ethos going around either...

There are construction systems, for example in Japanese traditional architecture, that use no nails or screws. Good joinery often removes their need.

Carpenters/framers are less skilled and paid less than cabinetmakers. But the world needs more carpenters.

Saying boilerplate should exist is like saying every nail should have its own hammer.

Some amount of boilerplate probably needs to exist, but in general it would be better off minimized. For a decade or so there's sadly been a trend of deliberately increasing it.

Since we invented the tree and control its parameters and features, this is actually correct.

Even Star Trek has self-sealing stem bolts, they don't just 3d print their ships

Love this analogy.

Ground Hog day is optimistic, I think. It will be like "The Butterfly Effect": every attempt to fix the systems using the same dumb, wrote solutions will make the next iteration of the architecture worse and more shitty.

Maybe if you fully hand over the reigns and go watch Youtube all day.

LLMs allow us to do large but cheap experiments that we would never attempt otherwise. That includes new architectures. Automation in the traditional sense is opposite of plasticity (because it's optimizing and crystalizing around a very specific process), but what we're doing with LLMs isn't that. Every new request can be different. Experiments are more possible, not less. We don't have to tear down years of scaffolding like old automated systems. We just nudge it in a new direction.

I don’t think that will happen. It’s more like a 3d printer where you can feed in a new architecture and new design every day and it will create it. More flexibility instead of less.

I find it more likely it will result in an influx of new architectures.

Eventually, prog-lang designers will figure out how to get llms to create new prog-langs.

At least for me when woodworking, the cutting, nailing, and gluing are the fun bits. The sanding and finishing is the grunt work/boilerplate.

and sanding. don't forget sanding. 90% of building furniture is sanding.

Maybe nail guns that have a chance to randomly shoot nails into your leg and apologize when you ask why it did that.

Great analogy. As someone else pointed out in a different subthread, quality furniture isn't held together with nails.

No. This is a fundamentally erroneous analogy. We don't generate code by a stochastic process.

How big a dent do you think we could make if poured $252 billion dollars[0] just into paying down all our towers of tech debt and developing clean abstractions for all these known problems?

[0]: https://hai.stanford.edu/ai-index/2025-ai-index-report/econo...

> Isn’t trying to remove boilerplate how we end up with situations like left-pad?

No. That is a result of bad software engineer practices and stacks, not a symptom of proper abstraction.

Good point. Non-determinism is not fundamentally problematic on many levels. What is important is that the essential behavioral invariants of the systems are maintained.

Reduced mental load. When it’s proven that a set of input will always result in the same output, you don’t have to verify the output. And you can just chain process together and not having to worry about time wasted because of deviations.