The Senior Engineer Is Dead. Long Live the Expert Generalist

A few months ago we had a production outage affecting order preparation in stores. The stock system wasn't updating correctly and pickers were working with stale data. Every minute counted (we're talking about physical stores, real people waiting for products on the shelf).

We had two engineers available to tackle the problem. One was an absolute wizard with the framework we used. He knew every quirk, every configuration, every edge case of the tool. The other didn't know that particular framework deeply, but understood how the stock system worked end to end: the event architecture, the dependencies with other services, the consistency model, and (this is key) why the system was designed that way for the business.

Who do you think found the problem?

The second one. In under an hour. Because the problem wasn't in the framework. It was a race condition between two services the first engineer didn't even know existed.

That experience confirmed something I've been observing across the 100+ engineers I've mentored: the engineer who only knows their stack deeply has a ceiling. And with the arrival of AI, that ceiling keeps getting lower.

The Senior Engineer Trapped in Their Bubble

Does this profile ring a bell? An engineer with years of experience, who dominates their technology like nobody else, who can solve any technical problem within their domain... but who can't explain why their system exists. Who has no idea what business metrics their code moves. Who, when you ask "what impact does this have?", responds with implementation details.

I see it constantly. I manage 7 teams that serve over 25,000 daily orders and more than 1,600 stores. And the pattern repeats: the most valuable engineers aren't the ones who know the most about a technology. They're the ones who understand the full context.

The problem with technical depth without breadth is that it has diminishing returns. Going from "good" to "very good" in a specific framework requires enormous effort. Going from "very good" to "world-class expert" takes years. And when you get there... the framework may have changed, or simply died.

The data backs this up. Erik Bernhardsson analyzed over 26 open-source projects and calculated that code has a half-life of 3.33 years. In frontend, Angular has a half-life of 0.32 years. You're investing thousands of hours mastering something with the life expectancy of a yogurt.

I'm not saying technical depth doesn't matter. Of course it does. But betting all your professional value on it is an increasingly risky strategy.

What an Expert Generalist Is (and Isn't)

When I say "generalist," a lot of people think of the typical jack of all trades, master of none. Someone who knows a little of everything but masters nothing. That's not what I'm proposing.

An expert generalist is something very different. It's an engineer who has real depth (they can design systems, debug complex problems, make architectural decisions with sound judgment) but who also understands the terrain surrounding the code.

In my experience, these engineers share four traits:

They understand the "what for" before the "how." When a requirement comes in, their first question isn't "what framework do I use?" but "what business problem are we solving?" This lets them challenge solutions, propose alternatives, and sometimes kill features before a single line of code is written. That's real influence.

They navigate uncertainty without freezing. They can enter a system they don't know, ask the right questions, and quickly identify the leverage points. They don't need to master the technology to understand the architecture. They don't need to know the business in detail to identify where the risk is.

They connect dots others can't see. When you manage 7 teams, you see a recurring pattern: the most expensive problems are almost never within a single team. They're problems between teams, between systems, between domains. The expert generalist sees them coming because they have peripheral vision. The pure specialist doesn't, because they're only looking at their part.

They communicate technical decisions in business language. This is perhaps the most undervalued skill. An engineer who can explain to a Product Manager why a technical decision will affect time-to-market or operational cost has a power no framework gives you. It's what I call going from "ticket executor" to "strategic partner."

AI as an Accelerator of This Evolution

AI didn't create the need for the expert generalist. But it has accelerated it dramatically.

Think about it this way: if AI commoditizes code writing (and the data says it already generates 41% of the code in many companies), then the engineer's value is no longer primarily in writing. It's in deciding what to write, why, and how it fits into the system.

There's an economic concept that explains this well: the Jevons Paradox. In 1865, when steam engines became more efficient, coal consumption didn't drop. It went up. Because efficiency unlocked new uses that weren't viable before. The exact same thing is happening with AI. The cost of tokens has dropped 10x, but usage has gone up 100x. More code is being generated than ever. And someone has to understand all that code, validate it, integrate it, and make sure it solves the right problem.

That "someone" isn't a prompt engineer. It's an engineer with judgment. An expert generalist.

I live this every day. When a team uses AI to generate code, the problems that appear are rarely syntactic. They're about context: the code doesn't understand the business constraint, doesn't respect the contract with another service, doesn't account for the failure case you only know about if you understand the architecture. The data backs it up (48% of AI-generated code has a high risk of security vulnerabilities). AI generates the code, but the judgment is yours.

As I always say: code is a means, not an end. And AI has made this truer than ever.

How to Build an Expert Generalist

I'm not going to give you a generic list of "learn system design and read Clean Code." You already know that. What I want to share is what I've seen actually work, after mentoring 100+ engineers and living it myself managing systems at scale in retail.

Get involved in decisions that aren't "yours." Next time product is deciding the roadmap, ask to be in the conversation. Not to weigh in on business priorities, but to provide technical context that changes the decision. When you do this a couple of times and your input generates impact, you stop being "the implementation person" and become someone who gets consulted. That's influence, not hierarchy.

When you solve a technical problem, ask yourself what business problem you just solved. Sounds simple. Almost nobody does it. "I optimized the stock query" is not the same as "I reduced in-store preparation time by 15%, which enables 200 more orders per day." The second speaks the language of the people who decide budgets and priorities.

Learn to read systems, not just code. Next time you're assigned to a new project, before opening the IDE, draw the system. What services talk to each other? Where is the state? What are the failure points? What happens if this component goes down? This habit gives you superpowers because you start seeing problems before they exist.

Seek out the problems between teams. The most expensive bugs, the worst outages, the projects that get delayed by months -- they almost always happen at the interfaces between systems and between teams. If you become the person who understands those boundaries, your value multiplies because you're solving problems nobody else can see.

The Invisible Ceiling

Back to the story from the beginning. That day in production, with stores affected and the clock ticking, we didn't need a framework expert. We needed someone who understood the system. The business. The dependencies. The context.

That's an expert generalist. And that's exactly what AI isn't going to replace. Because AI can generate code, but it can't understand why that system exists, who it serves, and what happens when it fails on a Friday at 8 PM with 1,600 stores open.

The classic senior engineer -- the one who bets everything on technical depth in one stack -- has an invisible ceiling. And that ceiling drops a little every day that AI gets better.

The good news is that the transition to expert generalist doesn't require starting from scratch. It requires widening your perspective. Stopping to think only about how to implement and starting to think about why to implement, for whom, and what impact it has.

Code is a means, not an end. And the engineers who understand this are the ones who will lead the next decade.

---

This article stems from a reflection inspired by Milan Milanovic's article on fundamentals vs frameworks, where he touches on the concept of Expert Generalist. I wanted to go further and ground it in my experience managing teams and systems at scale.