Premature Optimization is still the Root of all Evil, even with AI.

AI didn't fix engineering discipline. It poured rocket fuel on its worst instincts.

For a brief moment after Copilot, after Cursor, after the agents — we told ourselves a comforting story. Speed is the bottleneck, the story went. Remove the friction of typing, and engineers will finally have time to think.

What actually happened? Engineers stopped thinking and started shipping. Faster than ever. Wrong things, mostly.

Premature optimization was always the root of all evil. AI just made it possible to commit the sin at industrial scale.

Knuth Was Right, and He Was Right About 97% of It

The line is older than most engineers using it. Donald Knuth, 1974: "Premature optimization is the root of all evil." The full quote is more useful than the bumper sticker version. Knuth said programmers waste enormous time worrying about non-critical paths. 97% of the time, attempts to optimize cause more harm than good.

That number wasn't a guess. It was a warning about how badly humans estimate where time is actually spent. We optimize the parts of the system that feel important. The actual hot path is usually somewhere boring — a serialization loop, a database call, a config lookup that fires ten thousand times.

The principle is simple. You cannot optimize what you have not measured. Intuition is wrong about performance with depressing reliability. The discipline is to build first, measure second, and optimize only what the data demands.

That was hard advice in 2010. It's harder now.

The Rule of Three: The Other Half of the Lesson

There is a sibling principle that engineers ignore even more. The Rule of Three.

State it plainly: don't abstract until you've seen the same pattern three times. Two examples is a coincidence. Three is a shape.

The Rule of Three exists because abstraction is a bet. You're betting that the next ten cases will look like the first one. If you bet too early — with one or two data points — you build the wrong shape. You force every future case to either bend into the bad abstraction or break it.

The blunt version of this rule, repeated by people who have lived through the consequences: duplication is far cheaper than the wrong abstraction. Duplicated code is annoying but inert. A bad abstraction is load-bearing. Removing it requires unwinding everything that depends on it, which is everything.

Premature optimization and premature abstraction are the same failure mode wearing different clothes. One optimizes performance too early. The other optimizes structure too early. Both are decisions made without enough information. Both look like discipline and feel like progress. Both are expensive to undo.

What AI Actually Changed

The standard pitch: AI takes the typing out of programming, freeing engineers to focus on judgment. Hand the boilerplate to the machine. Spend your time on architecture and reasoning.

In practice, the opposite has happened.

AI makes abstractions cheap to generate. Engineers used to resist abstraction because writing it took an afternoon. Now it takes a prompt. The cost of building the wrong shape has collapsed — but the cost of living with the wrong shape has not. That's still measured in months of rework and onboarding pain.

AI makes generalization seductive. Show it one example and it will produce a generic, parameterized, configurable version. Beautiful. Reusable. Sometimes correct. The engineer didn't earn the abstraction. They didn't see three real cases. They saw one, and the model hallucinated the other two.

AI makes premature optimization frictionless. Worried about scale you don't have? AI will happily generate the caching layer, the queue, the sharded data model, the rate limiter, the circuit breaker. None of it informed by traffic you actually receive. All of it now part of your system, and your on-call rotation, and your hiring conversations.

The result is a recognizable pattern. Codebases that look mature and feel brittle. Architecture diagrams that would be appropriate for a series-C company, sitting on top of a product that has not validated its third use case. Layers of indirection where there used to be a function.

This is not engineering. It is engineering cosplay.

Where the Bottleneck Actually Moved

The constraint in software was never typing speed. Anyone who has shipped a real system knew this. The constraint was understanding — what to build, what users actually do, how the system behaves under real load, where the real failure modes live.

AI accelerated output. It did not accelerate any of those things.

So the bottleneck moved. It used to sit at the keyboard. Now it sits in three places at once: validating that the thing you built solves a real problem, understanding the system you've assembled out of model-generated parts, and maintaining it after the original context is gone.

Output is no longer scarce. Judgment is. And judgment is precisely what gets skipped when the cost of producing more output drops to zero.

What This Looks Like in the Wild

A team builds a pricing engine. A senior engineer prompts an agent. Four hours later there's a plugin architecture, a strategy pattern, a config-driven rule engine, and three tiers of caching. The product has one customer. That customer has one pricing model. The team will spend the next two quarters fighting their own architecture.

A startup builds an internal tool. The first version works. The second version, written with AI, is "more reusable." The third version generalizes the second. By the fourth version, nobody can explain what the tool does without a whiteboard. The original problem was solvable in 200 lines.

A platform team adds Kafka because the system "might" need event-driven architecture. There are 12 events per minute. There always will be. The Kafka cluster now has its own on-call rotation.

You have seen all three of these. You have probably built one of them this year.

The Discipline That Still Works

The fix is not new. It is the same discipline we always needed, applied with more care because the cost of skipping it is higher.

Build the dumbest version that solves the problem. Inline the code. Hardcode the values. Skip the abstraction. Skip the cache. Ship it.

Observe what actually happens. Real users. Real load. Real failure modes. Most of what you would have optimized for never matters. A small number of things matter enormously, and you cannot guess which.

Repeat until you have three real examples of the pattern you think exists. Not two. Not one with two hypothetical cousins. Three real, in-production, behaving-differently cases. Then — and only then — abstract.

Optimize only when measurement points at a specific thing. Not when the model suggests it. Not when a blog post says you should. Not when the architecture feels insufficiently clever.

Build. Observe. Repeat. Then optimize.

The Cost of Mistakes Got Faster

The single most important fact about AI in engineering is this: it makes mistakes faster and more widespread, not better.

A bad abstraction used to take a week to write and a year to remove. Now it takes an hour to write and still takes a year to remove. The asymmetry has gotten worse, not better.

Knuth's warning was about wasted effort. The modern version is darker: with AI, misplaced effort scales. You can build the wrong system at unprecedented speed. You can be very productive in exactly the wrong direction, and the velocity will feel like progress until the day it doesn't.

Premature optimization was always the root of all evil. The roots just got faster.

The discipline is the same. The stakes are higher. Build the simple thing. Measure what happens. Earn your abstractions. Optimize what the data demands.

Everything else is theater.