Every time a new AI coding tool ships, I watch the same thing happen — junior devs get faster, and the gap between them and senior engineers quietly widens.

It’s counterintuitive. The tools are supposed to democratize software development. And in a narrow sense, they do: someone six months into their career can now produce working code at a pace that would’ve seemed impossible a few years ago. But “working code” and “the right code” are different things, and I’ve been thinking about why AI seems to be sharpening that distinction rather than dissolving it.

The Abstraction Is the Hard Part

Here’s the thing most coverage of AI coding tools misses: the hard part of software engineering was never the typing.

It was never remembering the exact syntax for a SQL window function, or knowing which HTTP status code to return, or looking up how to configure a webpack loader. Those are all annoying, but they’re lookup problems. The hard part is deciding what to build — which layer of the system should own which concern, how to draw the lines between modules, what to make configurable versus what to hardcode, when to reach for an abstraction and when to resist one.

AI is genuinely, impressively good at the lookup problems. It’s even good at generating code within a well-scoped problem. But that scoping — the act of deciding what problem you’re actually trying to solve — is still entirely on you.

Compression, Not Elimination

What AI actually does is compress time. And compression changes risk profiles in ways that aren’t immediately obvious.

In the old world, a shaky architectural decision might take months to fully metastasize. You’d make some questionable calls early on, the system would grow, and by the time the load balancer was groaning and the database was locked on a bad join, you’d forgotten the decision that caused it. The feedback loop was slow enough that the connection between cause and effect was murky.

AI tightens that loop. Features get built faster. Codebases grow faster. Which means the consequences of a bad abstraction show up faster, too. A decision that would have taken six months to bite you now takes six weeks.

This is actually good news if you have taste — your good decisions compound faster. It’s bad news if you don’t, because you’ll hit the ceiling sooner, harder, and with more code to untangle.

What “Taste” Actually Means

I want to be precise about what I mean by taste, because it gets thrown around loosely.

In my experience, engineering taste is the accumulated intuition for when complexity is accidental versus essential. Essential complexity is in the problem — you’re building a distributed system, and distributed systems are genuinely hard. Accidental complexity is the stuff you introduced — the overly clever abstraction that made the simple case slightly cleaner but made the edge cases a nightmare, the service boundary you drew in the wrong place because it was convenient at the time.

Senior engineers have usually been burned enough times that they can feel accidental complexity building up before it’s visible in metrics. They’ll look at a design and say something like “this is going to hurt when we need to do X” — and that prediction comes from a library of past mistakes, not from any formal analysis.

AI doesn’t have that library. It has patterns from training data, which is different. It will generate code that looks like the right abstraction because it looks like things that were right in other contexts. Recognizing the difference between a pattern that fits and a pattern that’s been cargo-culted in requires judgment the model doesn’t have.

The Junior Engineer Trap

The risk for junior engineers isn’t that they’ll be replaced by AI. It’s subtler than that: they might get so good at using AI to produce output that they skip the years of getting burned by their own bad abstractions.

Those years are uncomfortable, but they’re how you build the intuition. When you’re the one who drew the line between services in the wrong place, and you’re the one who has to migrate across it eighteen months later, you remember it. The lesson sticks in a way that reading about it doesn’t.

I don’t have a clean answer for how to short-circuit that process. Maybe you can’t, fully. Maybe the right frame is that AI makes the experiments cheaper, so you can run more of them — but only if you’re actually paying attention to what’s failing and why, rather than just asking the model to fix the error message and moving on.

The Ceiling Stays

The abstraction ceiling isn’t going away. If anything, it’s getting more visible, because the floor keeps rising. You can get further faster, which means more engineers are going to hit the ceiling — the point where the system stops cooperating and the only way through is genuine architectural understanding — earlier in the lifecycle of their projects.

The tools are genuinely useful. But I keep coming back to this question: are we using them in ways that build judgment, or in ways that let us avoid ever developing it?

I’m not sure I know the answer yet. I’m not sure anyone does.