---
title: "Choose Boring Technology and the LLM as an innovation token"
description: "Dan McKinley's Choose Boring Technology gave every company a few innovation tokens, and a coding model looks like it hands out more but it spends one too."
url: "https://michael.zazon.us/notes/choose-boring-technology-and-the-llm-as-an-innovation-token"
published: "2026-09-02T12:00:00-04:00"
kind: "book-notes"
subject: "architecture"
tags: ["ai-coding"]
---
It's kind of like the LLM ate all the easy parts of the job, but all of those hard parts are still there. But because we now just have more bandwidth, the question is, have we just kind of all bought ourselves more innovation tokens? I'm inclined to say to a degree, yes.

This question comes from [Choose Boring Technology](https://mcfunley.com/choose-boring-technology), a great essay by Dan McKinley from 2015. The core idea in that essay is that every company gets like 3 innovation tokens. You should spend your innovation tokens on the stuff that differentiates your company, and use boring tools for everything else because you understand the failure modes of boring tools.

I actually think the introduction of large language models themselves is a form of innovation token usage.

Now, two things can be true at once. The model can free up your time to focus on the hard parts, but it's also a new piece of technology that your team needs to learn and trust, which means it costs a token when it comes in the door. The [talk version](https://boringtechnology.club/) of this essay talks about how you need to account for the total cost of a piece of technology (maintenance costs vs velocity benefits) across the entire company.

I think a lot of large language models are oversold and that the maintenance costs, whether it's cognitive load, whether it's training, whether it's the cost of, is the foundation model going to get banned by the US government, those maintenance costs can be quite high, and that if you're not getting the velocity benefit out of it, you've now introduced a new thing that's actually a net drag on your company.

I think that might be the thing, is some of this boring technology in a world of LLMs is how many innovation tokens of cognitive load do I have to take on because I'm choosing something that's not in the training corpus of large language models.

The old meaning of boring was "we understand the failure modes". The new added meaning of boring is "the model has been trained on a huge number of similar examples". If your team starts choosing a framework largely because it's what the coding agent deals with well, you get a quiet drift of everything towards the most common stack. The upside is you get known failure modes. The downside is maybe the better tool is the less common one.

I like this idea that you really need to justify what feels like a shiny new thing. Is it in the core capability? Is this something that your team's willing to own for the next 10 years? If you make this decision and you can't switch off of it, are you comfortable with it for the next 10 years?

The model is a dependency like any other, with vendor, price, and policy risk. Who on your team is going to own it for the next ten years?