For forty years, the engineering career ladder has looked like this:

Junior → Mid-level → Senior → Staff/Principal → Architect

It’s a smooth progression. You write more code, then you write less code but influence the shape of it, then you write almost no code and mostly make decisions about how things are built.

This ladder is becoming obsolete. Not in five years. Now.

The problem is not the ladder itself. The problem is that AI has already done something the ladder never anticipated: it’s collapsed the middle rungs by automating the step where you learn to execute well.

What the Ladder Actually Was

Let me be honest about what this progression meant:

  • Junior: Can implement a well-specified task without supervision. Can’t decide what tasks matter.
  • Mid-level: Can implement a semi-specified task with minimal guidance. Is starting to develop taste about solutions.
  • Senior: Can take a loosely specified problem, clarify it, and implement it. Can teach others how to think about problems.
  • Staff/Principal: Can take ambiguous business problems, translate them into technical problems, and ensure they’re solved well. Can influence technical direction across teams.
  • Architect: Can take strategic questions (“Should we rebuild this?” “How do we scale to the next level?”) and ensure the technical decisions reflect the constraints.

Each rung up meant two things: more autonomy, and more responsibility for thinking rather than executing.

The rung up was worth it because the thinking was hard to learn. You learned it by executing thousands of times, developing intuition about what works and what doesn’t. The progression was necessary; you couldn’t jump straight to architect without building the intuition first.

What AI Changed

But here’s what happened: AI is really good at execution. It’s not good at thinking about what to execute.

A junior engineer had to do thousands of implementations to develop intuition about good code. An AI can generate good code instantly, without intuition. But it has no taste. It can’t look at a problem and smell the architectural risk. It can’t see that this solution works today but will fail in six months. It can’t integrate the invisible constraints.

This creates a gap: there are now people who can execute perfectly (AI) but can’t think about architecture. And there are people (architects) who can think about architecture but are relying on junior engineers to turn that thinking into code.

The middle rungs—mid-level and senior engineers—were the translation layer. They were learning to think better while still executing well. They were the place where intuition developed.

But if execution is automated, what do they translate?

The New Split

I think we’re moving toward a clearer, more honest split:

Architects decide what to build and why.

Builders turn architectural decisions into specifications and ensure they’re correct.

Systems (AI) implement the specifications.

This is a much harder hierarchy because there are only two human levels, and the gap between them is enormous.

An architect needs to:

  • Understand the business deeply (what are we trying to optimize for?)
  • Understand the constraints thoroughly (scale, latency, reliability, team capacity, deployment model)
  • Make trade-off decisions (fast but fragile, or slow but reliable?)
  • Have taste about solutions (this is the pattern I’d use, and here’s why)
  • Be right more often than wrong (and own it when you’re wrong)

A builder needs to:

  • Take an architectural direction and turn it into testable, unambiguous specifications
  • Understand the architecture deeply enough to catch when something doesn’t make sense
  • Have enough domain knowledge to push back (“that architecture assumes X, but actually Y”)
  • Know the edge cases, the performance characteristics, the failure modes
  • Be able to hand a spec to AI or a junior engineer and have it implemented correctly

Notice what’s missing: “write good code.” Both roles might write code, but code-writing is not the primary skill. The architect writes code when thinking through a complex problem. The builder writes code to clarify specification or to test edge cases.

But neither role exists to write code.

Why This Is Harder

This is not a natural progression. You can’t be a good builder without being a good architect first, but there’s no ladder to help you become one.

I know excellent architects who were never junior engineers. They came from other fields (finance, operations, product) and jumped straight into architectural thinking. The code execution thing was never their strength.

I also know builders who could never be architects. They’re brilliant at clarity and specification and testing edge cases, but they don’t have the taste for architectural judgment. They wouldn’t be happy making those calls anyway.

These are different skills, and they don’t necessarily build on each other.

This is the hard truth: in a world where AI can execute, we need fewer people who can execute. We need more people who can think about what to execute. But we can’t get there by having everyone climb the same ladder—junior, mid, senior, architect.

We have to explicitly teach both paths:

  • The architectural path: how to develop taste, how to make trade-off decisions, how to integrate multiple constraints, how to be accountable for big calls.
  • The builder path: how to turn ambiguous requirements into precise specifications, how to catch architectural misalignment early, how to have enough domain knowledge to be dangerous.

What This Means for Career

If you’re a junior engineer in 2026, the traditional ladder is still a trap. You can climb it to mid-level. But somewhere in the mid-to-senior transition, something changes.

If you want to be an architect, you need to start thinking about architecture now. It’s not something you learn by writing more good code. It’s something you learn by making decisions and living with them. Every project, you should be asking: “What are the trade-offs here? What are we optimizing for? What’s the hidden risk?”

If you want to be a builder, you need to start thinking about clarity and specification. You need to be the person who catches when the architect’s vision doesn’t match reality. You need to develop a feel for where an implementation will break, and why.

If you don’t want to do either of these things—if you just want to write good code and have someone else decide what to write—that’s fine. But you need to know what you’re optimizing for. Because AI is very good at writing good code. You need to offer something else.

The Uncomfortable Inversion

Here’s what’s really happening:

In the industrial era, the ladder made sense: you got better at your craft by practicing it. The best craftspeople rose to leadership.

In the information era, we copied that model, even though it didn’t quite fit. The best code-writers became architects, even though code-writing and architectural thinking are different skills.

AI has made the mismatch impossible to ignore. You can be brilliant at one and terrible at the other.

So we’re inverting back. In 2026, the architect is not the person who used to write the most code. The architect is the person who thought about the right problem. The builder is not the person who couldn’t rise to architect; the builder is the person who has chosen to solve a different, equally important problem: how do you take a brilliant idea and ensure it’s specified clearly enough that it can be implemented without degradation?

Both roles are necessary. Both roles are skilled. But they’re not a ladder anymore. They’re a fork in the road, and you need to choose which path matches your strengths.

The ladder was a convenient lie. AI has made it impossible to keep lying.