From Builder to Orchestrator: The Identity Crisis Nobody's Ready For

You became an engineer because you like building things.

The dopamine hit of shipping code. The satisfaction of debugging a gnarly problem at 2 AM. The craft of turning a messy idea into working software. It’s not just what you do. It’s who you are.

Now the industry is asking you to stop building and start managing.

Boris Cherny, head of Claude Code at Anthropic, recently told Fortune he hasn’t written code in over two months. He’s shipping 22-27 pull requests per day, all AI-generated. An OpenAI researcher named Roon said the same thing: “100%, I don’t write code anymore.”

Let that sink in. The people building the most advanced AI coding tools on the planet have stopped coding. They’ve become orchestrators.

(Which is either inspiring or terrifying, depending on how much you enjoyed your job this morning.)

If you’re an engineer who’s been doing this for 10, 15, 20 years, you might be feeling something you can’t quite name. Something that sits between excitement and grief.

That feeling is an identity crisis. And nobody’s talking about it.

The shift happening now

Meta executives report that AI coding tools are enabling individual engineers to do work that previously required entire teams. The language they use is revealing: engineers are moving toward “higher-level problem-solving, architectural decisions, and creative feature design.”

Translation: less building, more directing. Your new job title is Fancy Reviewer Who Approves Robot Work.

An analysis from Aviator captured this bluntly. We’re moving from “conductor” mode, interactive pair programming with one AI, to “orchestrator” mode, where you manage fleets of agents working in parallel. Their assessment of how engineers will feel about this transition?

“We became engineers because we like building things with our hands.”

That’s the quiet part, said out loud.

There’s a reason ThePrimeagen’s “99” plugin hit #1 on GitHub trending last week. It’s a Neovim AI agent explicitly designed for “people without skill issues,” a deliberate shot at tools that assume developers need their hands held. The viral adoption isn’t about the plugin itself. It’s a signal. Skilled engineers are pushing back against the premise that their job is to become obsolete.

But pushback doesn’t stop the wave. It just means the wave is real.

Why this is harder than learning a new framework

When React replaced jQuery, you adapted. You learned the new thing. It was annoying, maybe, but it didn’t challenge who you were. You were still an engineer. Still building.

This is different.

The transition from builder to orchestrator isn’t a skill change. It’s a role change. And role changes mess with identity in ways that skill changes don’t.

Think about what made you good at your job. The ability to hold a complex system in your head. The intuition for where bugs hide. The satisfaction of writing code that’s not just functional but elegant. Years of pattern recognition, hard-won through debugging sessions and production incidents.

Now imagine a world where most of that happens inside a black box, and your job is to review the output.

You’re not building the house anymore. You’re inspecting the house that the robots built, signing off on it, maybe asking them to move a wall. Congratulations on your promotion to Building Inspector.

Some people will thrive in that role. Others will hate it. But almost everyone will feel the dissonance: the gap between the identity they built over years and the role the industry is handing them now.

The skill erosion nobody wants to discuss

Here’s the part that makes this harder than a simple mindset shift: there’s evidence that using AI tools actually degrades the skills you built.

A recent study found that AI-assisted coders scored 17% lower on mastery quizzes compared to those who coded by hand. Nearly two letter grades. The speed gains? Not statistically significant.

Read that again. AI makes you feel faster while potentially eroding the competency that makes you valuable. It’s the coding equivalent of GPS slowly killing your sense of direction. Sure, you got there. But could you do it without the robot?

This creates a vicious cycle. The more you rely on AI, the less you trust your own judgment. The less you trust your judgment, the more you rely on AI. Eventually, you’re an orchestrator who couldn’t build the thing yourself if the agents went down.

Some people are fine with that trade. “I don’t need to know how the engine works. I just need to drive the car.”

But there’s a reason senior engineers command high salaries. It’s not because they type faster. It’s because they have judgment: the ability to know when the code is wrong, even when it compiles, when the architecture will scale, and when it won’t. That judgment comes from years of building things yourself.

If AI erodes that judgment, what exactly are you orchestrating with?

What I’m seeing in the field

I want to be honest about the range of responses I’m seeing from engineering leaders navigating this shift.

Some are thriving. They’ve embraced the “architect who directs AI builders” role and find it genuinely exciting. Less tedium, more high-level thinking. They describe feeling “unshackled” from the grunt work. Good for them. Genuinely.

Some are grieving. They miss the craft. They describe the new workflow as “hollow,” reviewing code they didn’t write, merging PRs they don’t fully understand. The productivity gains are real, but something has been lost.

Some are in denial. They’re sure this is a temporary hype cycle. They point to previous AI winters, to the gap between demos and production. They’re not wrong about the limitations. But they might be wrong about the trajectory.

And some are splitting the difference. Using AI for boilerplate and context-gathering while deliberately preserving hands-on coding time for the work that matters to them. This seems like the healthiest approach I’ve seen, but it requires intentional boundary-setting in environments that reward pure output.

A framework for navigating this

I don’t have a clean answer. Anyone selling you a “5-step guide to thriving as an AI orchestrator” is guessing. (Or selling a course. Possibly both.) But here’s a framework that might help.

Name the feeling. If you’re experiencing dissonance, resistance, or grief about where engineering is headed, that’s not weakness. It’s an appropriate response to a real identity shift. The people who push through without acknowledging it tend to burn out or become cynical.

Separate skill questions from identity questions. “Can I learn to be an effective orchestrator?” is different from “Do I want to be an orchestrator?” Both questions deserve honest answers. Being capable of something doesn’t obligate you to do it.

Preserve the craft deliberately. If hands-on building is core to who you are, make space for it, even if it’s less “efficient” by current metrics. Side projects. Open source. The 20% of your job where you code manually, because it keeps your skills sharp. Efficiency isn’t everything. Meaning matters.

Watch for skill erosion honestly. Notice if you’re losing confidence in your own judgment. Notice if you can’t debug without AI assistance anymore. Notice if your architectural intuition is getting fuzzy. These are signals worth attending to.

Accept that this might not be your era. Some people thrived in the mainframe era. Some thrived in web, mobile, and cloud. Every era favors certain dispositions. If orchestration genuinely doesn’t fit how you’re wired, that’s information about where to focus, not an indictment of your worth.

The question underneath

I keep coming back to something an engineering friend said to me last month. He’s been coding for 25 years. He’s excellent at it. He’s using AI tools now, and he’s productive as hell.

But he told me: “I’m shipping more than ever, and I’ve never enjoyed my job less.”

That’s the identity crisis in one sentence.

The industry is optimizing for output. But engineers aren’t output functions. They’re people who got into this work because they loved a particular kind of problem-solving, a particular relationship with machines, a particular way of thinking.

When the nature of the work changes that fast, some people will love the new version. Some will adapt because they have to. And some will realize that the thing they loved doesn’t really exist anymore —at least not in the form they fell in love with.

I don’t know which camp I’ll end up in.

But I know that pretending this is just another tool upgrade is dishonest. It’s bigger than that.

And the first step to navigating it well is admitting that it’s happening at all.