Small Tools, Sharp Edges

Every project I’ve regretted started the same way: with a framework chosen before the problem was understood. Every project I’ve enjoyed started with a single file.

A small tool has an unfair advantage. You can hold the whole thing in your head. When it breaks, you know where to look, and when it needs to change, the change is obvious because there’s nowhere else for it to go.

The pull toward more

Big systems don’t arrive all at once. They accumulate. A config option here, an abstraction “for later” there, a dependency that saved an afternoon and will cost a weekend. None of these decisions is wrong on its own. Together they add up to software nobody fully understands, including the person who wrote it.

The discipline isn’t refusing to grow. It’s making each addition earn its place:

• Does this solve a problem I have today?
• Could the platform already do this for me?
• Will I understand this in six months without reading it twice?

If the answer to any of those is no, the smaller version wins.

Where AI changes the math

Code is cheaper to write than it has ever been. A model will happily generate a thousand lines before you’ve finished describing the problem.¹ That makes restraint more important, not less. The bottleneck was never typing. It was understanding, and every generated line is one more thing to understand.

So I’ve started using models the opposite way: not to write more, but to ask what can I delete? The best suggestion is often the shortest diff.

Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.

— Antoine de Saint-Exupéry

Sharp edges are a feature

Small tools have sharp edges. They don’t handle every case, and they say so plainly. I’ll take that over a smooth surface hiding a maze.

This site is built the same way: static pages, one stylesheet, no server code. If it ever needs more, it’ll get more, once the need is real.