Why boring technology is more important in 2026, not less

Dan McKinley wrote "Choose Boring Technology" in 2015. The premise: teams have a limited number of innovation tokens to spend, and spending one on the database means fewer tokens for the product. Pick boring technology: the well-worn option with a large community, answered questions, and documented failure modes. Save the novelty budget for what actually differentiates the product.

In March 2026, Simon Willison made an observation worth taking seriously: when he pointed a capable coding agent at documentation for an unfamiliar tool, it worked. The model read the docs, understood the API, and produced code for technology it had almost certainly not seen in training. The friction of learning a new tool, he noted, no longer requires a human to absorb it.

He's right about that. AI coding tools genuinely compress the time between "I've never used this" and "I have something working." An afternoon with a coding agent and an unfamiliar library's documentation can get you further than two days without it. The adoption cost fell.

What didn't fall is why boring technology was the right call in the first place.

The two costs of adopting a new tool

The McKinley framing had two components. The first is adoption cost: you need to learn the tool, debug unfamiliar errors, fill ecosystem gaps, and bring every new hire up to speed. That cost is real, and it fell in 2026.

But the deeper reason to choose boring technology is different. Boring technology has already failed in every interesting way. When Postgres breaks, someone has already documented it. The GitHub issue has 47 comments and a merged fix. The post-mortem is on a blog somewhere. You are not the first person to hit that wall, and the path back is short.

Novel technology breaks in undocumented ways. When a database you adopted 14 months ago drops connections under a specific combination of WAL checkpoint timing and network load, you file a GitHub issue at 2am. AI helps you write the reproduction case. It cannot fix the bug that doesn't exist in the project's history yet. It cannot generate the Stack Overflow answer that nobody has written.

AI compresses adoption cost: the time to get something working from scratch. It does not compress operations maturity: the accumulated community experience of having hit your specific problem before you did.

Three places where the operations cost showed up

In 2024 and 2025, enough teams made interesting technology choices that the pattern is now visible.

Several teams moved backend services to Bun in 2024, drawn by benchmark numbers and cleaner built-ins. Migrating from Node.js with AI assistance was fast: updated configs, new scripts, working tests within days. Six months later, a portion of those teams found Node.js compatibility gaps that Bun hadn't yet resolved, including specific behavior of certain native modules and memory management under sustained connection load. The bugs were open on GitHub. Fixes were in progress. The teams were in production and waiting.

Cloudflare Workers attracted teams with its execution model: no cold starts, global distribution, and genuinely good performance for appropriate workloads. AI helped write the workers. The execution constraints (no Node.js built-ins, a 128MB memory ceiling, CPU time limits, no persistent file system) are documented but behaviorally surprising at scale. When teams hit those limits, the debugging path was narrower than Lambda, where the failure taxonomy is years deep in forum posts and engineering blogs.

Turso, Neon, and similar distributed SQLite and Postgres-flavored databases attracted teams with pricing and global distribution models. For read-heavy workloads with predictable traffic, many have worked well. For heavier transactional use as data volume grew, teams found themselves past the edge of what the community had mapped. Not broken, but in the 95th percentile of usage where you're often writing the primary source.

None of these tools are bad choices. The question in each case was not whether the technology was good but whether the community had already paid the operations cost at the scale each team needed.

What boring actually means in 2026

Boring technology is not old technology. It isn't the language from your first job or the framework your previous employer used a decade ago. Chronological age is a rough proxy for operational maturity, and it's often the wrong one.

Boring technology is technology where the operations cost has already been paid by the community at the scale you're operating.

Postgres at 100 GB is boring. The vacuuming strategies are documented. The index tuning guides cover most real workloads. Replication configurations are in production at thousands of companies. A novel distributed SQL database at 100 GB may be technically excellent, but boring it is not: the community hasn't paid the operations cost at that scale, and you would be among the first.

Redis for a session store is boring. Valkey, the Redis-compatible fork that AWS, Google, and Oracle backed in 2024, is also boring enough: same protocol, same mental model, large enough community to have accumulated documented answers. AWS Lambda for background jobs is boring. Running your own Kubernetes cluster as a ten-person team is not boring, not because Kubernetes is new but because your specific team has not yet absorbed the operational cost of running it, and most documentation assumes much larger teams with dedicated platform engineers.

The updated rule

McKinley's innovation token model still holds, with one update for 2026.

Old model: each novel technology choice costs an innovation token, teams have a small budget per project, and the tokens should go toward what differentiates the product rather than the infrastructure.

2026 update: AI has partially refunded the adoption portion of each token. You can try more things faster. The operations cost of each token is unchanged.

For experiments, internal tools, and early-stage prototypes, the lower adoption cost is a real benefit. Explore more, stage-gate before committing. Try things in environments where the 2am problem doesn't yet exist, and use what you learn to make better production decisions.

For production systems that engineers will page into at 2am in three years, the gate should be operations maturity, not adoption speed. Before choosing something novel for a production path, ask: how many people have run this at my scale? Where are the post-mortems? Who will I hire to maintain it?

If the answers are good, the tool has probably graduated to boring enough for production, regardless of when it shipped. If the answers aren't there yet, the fact that AI can set it up in an afternoon is not the signal you're looking for.

The adoption cost collapsing is good news. More experimenting, faster feedback loops, and cleaner decisions about what graduates from prototype to production. That's the part worth being excited about: not because it changes the bar for production, but because it makes reaching the bar cheaper to attempt.