← all posts

AI Didn't Eliminate Engineering, It Changed the Bottleneck

For most of my career the slow part of building software was building it. That part is mostly solved now, so the bottleneck moved to the question nobody could automate: should we build it this way?

AI didn't eliminate engineering.

It moved the bottleneck.

That distinction matters, because most of the anxiety about AI and most of the hype about AI are both aimed at the wrong place. The machine didn't take the job. It took one specific part of the job, the part that was never actually the constraint, and in doing so it made the real constraint impossible to ignore.

For years, building was the slow part

For most of my career, the slow part of shipping software was producing it.

Typing the code. Wiring the services together. Fighting the framework until it did the obvious thing. Translating a clear idea in someone's head into syntax a compiler would accept. That translation tax was real, and it dominated the schedule. When you estimated a project, you were mostly estimating how long the typing would take.

That part is mostly solved now. AI writes the function. It scaffolds the service. It fills in the boilerplate faster than any human can, and it rarely fumbles the parts that used to eat whole afternoons. The cost of going from "I know what I want" to "here is a working implementation" is collapsing toward zero, the same way AI made buildability cheap everywhere else.

So if production of code was the bottleneck, you'd expect everything to get dramatically faster. And some things did. But the projects that were going to fail are still failing, just earlier and more cheaply, which tells you the bottleneck was somewhere else the whole time.

The constraint moved, it didn't disappear

When you remove the slowest step in a process, you don't get a process with no slowest step. You get a new one. The constraint moves to whatever was quietly second in line.

The bottleneck is no longer "can we build it."

The bottleneck is "should we build it this way."

Producing code got cheap. Deciding what code to produce did not.

Those decisions were always there. They just hid behind the typing. When implementation took three weeks, the day you spent arguing about the data model looked like a rounding error. Now that implementation takes three hours, that same day of architecture is suddenly the expensive part, sitting in plain view, unautomated and unavoidable.

The questions that are still yours

Strip away the typing and look at what's left. None of it is a syntax problem:

  • Is this the right boundary? A clean abstraction around the wrong seam is still the wrong seam, now with tests.
  • Is this the right owner? Code with no clear owner is a future outage with a delayed fuse, no matter how well it's written.
  • Is this the right data model? The model you pick today is the migration you dread in six months.
  • Does this hold up when it succeeds? Architecture is what happens after success, and AI does not ask whether your design survives the load it earns.
  • How does this fail, and who gets paged? Recovery is the system, and nobody downloads a recovery posture from a model.

Every one of those is a judgment call. The machine can give you a hundred implementations of each answer. It cannot tell you which answer is right for your team, your data, your operational reality, because that requires context it doesn't have and consequences it doesn't bear.

Why this is good news, mostly

If you defined your value by how fast you could produce a working implementation, this is a genuinely uncomfortable moment, and pretending otherwise helps no one. That skill is being commoditized in real time.

But if you ever suspected that the typing was the least interesting part of the work, this is the best thing that's happened to the craft in a decade. The boring tax is being lifted. What's left is the part that was always the actual job: figuring out what should exist, where its seams go, and how it behaves when reality leans on it.

The engineers who matter now aren't the fastest typists. They're the ones who know which question to ask before a single line gets written, and who can tell a confident wrong answer from a correct one when the machine hands them both.

This is the same shift I keep seeing from the review side, where the review moved up the stack from "is this code correct" to "is this the right thing at all." Same force, different vantage point. The cheap part got automated. The expensive part got more expensive, relatively, and a lot more visible.

The one-line version

AI didn't take engineering. It took the typing, which was never the bottleneck, and left you holding the part that always was: deciding what to build before anyone builds it.