Boring tech on purpose: choosing an AI-predictable stack
Why I deliberately picked a boring, conventional stack for this site — and how "predictable to an AI agent" became a real, defensible selection criterion.
The takeaway up front: I chose the most boring, conventional stack I could for this site, and one of my selection criteria was explicitly “how predictably can an AI coding agent work in this?” That’s a new axis for choosing tools, and I think it’s a real one — not a gimmick.
What does “boring” actually buy you?
Boring technology is technology whose failure modes are already known. Someone has hit every sharp edge before you, written it up, and the answer is one search away. You trade the thrill of the new for a property that compounds over years: predictability. You can estimate work accurately, onboard people quickly, and debug at 2am without discovering a novel category of problem.
Dan McKinley framed this as a budget of “innovation tokens” — you get a small number, and you should spend them on the things that are actually your competitive edge, not on your build tooling or your markdown pipeline. For a personal site, my edge is the writing and the systems I’m showing off. So the correct number of innovation tokens to spend on the stack is roughly zero.
Why is “AI-predictable” a real criterion now?
Because a large share of the code on a project like this is written with an agent, and agents are far more reliable in well-trodden territory. The mechanism is simple: a conventional Astro-plus-Tailwind-plus-Markdown setup appears thousands of times in the training data and in public examples, with consistent conventions. An agent working in that space makes fewer wrong guesses, invents fewer non-existent APIs, and recovers from mistakes faster.
Push into a bespoke framework, a fashionable-but-thin library, or a clever abstraction I invented, and the agent has nothing to pattern-match against. It hallucinates method names, mixes incompatible versions, and I spend my time correcting it instead of building. Novelty in the stack taxes every future interaction with the tools that now help build it. That tax is new, and it points the same direction boring-tech already did: toward the conventional choice.
Doesn’t this just mean “never use anything new”?
No — and this is the part worth being precise about. The rule isn’t “old is good.” It’s spend novelty where it pays for itself, and be relentlessly conventional everywhere else.
For this site the split is clean: the content and the R&D projects are where any originality lives; the delivery mechanism is deliberately generic. Static output, typed content collections, a zero-JS baseline, one well-worn CSS framework. If I later need something genuinely novel — say, a rendering technique that’s core to a project I’m demonstrating — that’s exactly where a token should go. The stack around it stays boring so that the interesting thing stands out and stays maintainable.
The test I actually use
When I’m tempted by a shinier option, I ask three questions:
- If this breaks at the worst possible time, is the fix a search away or an expedition?
- Six months from now, will a new contributor — human or agent — recognize this, or have to reverse-engineer it?
- Is the novelty here load-bearing for what I’m trying to prove, or is it just novelty?
If the honest answers are “expedition,” “reverse-engineer,” and “just novelty,” I pick the boring thing. It’s not a lack of ambition. It’s putting the ambition where it counts.