Choose Boring Technology, Revisited
Ten years ago, I wrote about Dan McKinley’s classic blog post Choose Boring Technology and its resonance with my own development philosophy. My conclusion then was simple: when spinning up a new project, I consider whether I’m using it as an excuse to learn something new, or trying to solve a problem. Learn something new? Fine, but limit it to one unknown. Trying to solve a problem? Stick with what you know.
A decade later, my opinion hasn’t changed. If anything, the advent of LLMs and agentic AI coding tools has made this principle even more critical.
McKinley’s core argument was that companies have limited “innovation tokens” and should spend them strategically on established, well-understood technologies rather than exciting but unproven ones. The math is straightforward: boring technologies have known failure modes, well-understood capabilities, and proven operational reliability. When something breaks at 3 AM, you want to be debugging a technology with Stack Overflow answers, not pioneering uncharted territory.
Here’s where things get interesting—and dangerous. Modern AI coding tools are remarkably good at generating plausible-looking code for almost any technology stack you can imagine. Give Claude or Copilot a prompt about implementing microservices with Kubernetes, GraphQL federation, or the latest JavaScript framework, and you’ll get back code that looks professional, follows conventions, and might even run.
