Boring technology is not a nostalgia play. Aaron Brethorst argues that AI coding tools make the old “choose boring technology” rule more useful, because generated code is easier to trust when your team can actually review it. The uncomfortable part is simple: AI can write code for stacks you do not understand, but it cannot give your team the judgment it skipped.
Table of Contents
The short version
- Brethorst revisits Dan McKinley’s 2015 “Choose Boring Technology” essay and applies it to Claude, Copilot, and agentic coding tools.
- The risk is not that AI writes bad code. The risk is that it writes plausible code in unfamiliar stacks, where teams have weak review instincts.
- Boring technology works well with AI because known tools have known failure modes, docs, operational patterns, and people who can spot odd suggestions.
- The useful question for a new stack is: if AI generated this implementation, could the team review it without guessing?
What happened
Brethorst’s post starts from McKinley’s idea of “innovation tokens”: teams can afford only a limited number of new, risky technical choices before their ability to operate the system gets worse. A new language, a new framework, and a new infrastructure model in the same project may feel exciting, but every unknown adds review cost.
AI coding assistants change the feel of that tradeoff. Claude or Copilot can produce professional-looking code for Kubernetes, GraphQL federation, Rails, JavaScript, or a framework the team barely knows. That makes the unfamiliar stack look cheaper than it is. The generated code may run. It may follow naming conventions. It may include error handling. None of that proves the design is safe, maintainable, or idiomatic.
Brethorst’s practical rule is blunt: use AI as a multiplier for stacks you already understand. If the team knows Rails, AI-generated Rails code is easier to check. If the team knows JavaScript, Copilot’s suggestions can be reviewed against real language knowledge. In a stack nobody understands, the tool becomes a confidence machine.
Why this is worth watching
Boring technology has a different meaning in the AI coding era. It does not mean old for the sake of old. It means the team knows how it fails, where to find answers, which APIs are deprecated, how performance problems usually show up, and what production pain looks like at 3 a.m.
That matters because AI-generated code has become tidy enough to hide its own problems. Bad code used to look suspicious. Now the risky version may look clean, because the model has learned the surface shape of good code. The reviewer still needs taste, context, and memory of prior failures.
For more software and AI briefings, the IT & AI archive tracks similar stories about developer tools, AI infrastructure, and product engineering choices.
What Hacker News readers are arguing about
The Hacker News thread is tiny, so there is no broad community verdict to report. The one useful comment points to Django as an example of boring technology that still makes a developer more productive.
That small reaction fits the essay better than a noisy debate would. The point is not that every team should pick Django, Rails, Postgres, or any other specific default. The point is that mature tools often pair better with AI coding assistants because the human reviewer has a sharper baseline. The discussion does not prove the argument, but it shows the kind of practical response the essay invites: name the stack you know well enough to trust yourself around.
The practical read for boring technology
A team evaluating AI coding tools should separate two decisions that often get mixed together. One decision is whether AI can speed up the work. The other is whether the team can review the output.
If a project already uses a familiar stack, AI can help with boilerplate, tests, migrations, refactors, and repetitive glue code. If the project also introduces a new framework or infrastructure pattern, slow down. Build a small internal test first. Ask someone to review the generated code without running to the docs every two minutes. If that review is mostly vibes, the stack is not ready for core production work.
Boring technology is a review strategy. It gives AI less room to fool the team and gives humans more chances to catch the mistake before customers do.