The Orchestrator Identity Shift

There's a conversation happening in engineering circles right now. What does it mean to be a developer when AI writes 80% of the code? Is the craft dying? Is the identity dying with it?

I've been in this conversation. But not for the first time.

About ten years ago, I made one of the hardest decisions of my professional life. I had built a company from the ground up, and it was growing — not despite me being the developer, but in spite of the fact that I was trying to be both developer and CEO simultaneously. The company needed me to lead it. The code needed me to write it. And I was doing both badly.

The choice was stark: leave development as my everyday work and drive the company forward, or stay in the code and accept that the company would become more hobby than business.

I chose the former. And it cost me something real.

I remember the last week I spent truly inside a codebase as my primary work. Not reviewing someone else's PR. Not firefighting a production issue. Actually building — the flow state, the small victories when something finally compiles, the particular satisfaction of a function that does exactly one thing and does it cleanly.

When I stepped back from that, I thought it would be temporary. A year, maybe two, while the company found its footing. It wasn't temporary. The company kept growing, the demands kept compounding, and the gap between me and daily development kept widening.

What followed was a parade of identities — some chosen, most forced on me by circumstance. CEO. Product manager. Tech lead who writes strategy documents instead of code. Account lead who translates client requirements into something developers can use. Tech director who thinks in systems instead of functions.

Each one taught me something I couldn't have learned from inside a codebase. The PM role taught me that the distance between what users say they want and what they actually need is where most product failures are born. The account lead role taught me that the most technically correct solution and the most politically viable solution are almost never the same thing. The tech director role taught me that a team's architecture reflects its communication patterns more than its technical decisions — something Conway's Law describes but only experience makes visceral.

The learning was enormous. I won't pretend otherwise.

But the FOMO was brutal.

I watched frameworks evolve without me. I read changelogs like someone reading letters from a country they'd been exiled from. I sat in developer conversations feeling the particular shame of the person who used to speak the language fluently and now has to ask for someone to slow down.

There was a specific kind of pain in meetings where a junior developer would reference something — a pattern, a tool, a convention — and I'd recognize the word but not quite follow the implication. I knew enough to not embarrass myself. I didn't know enough to contribute meaningfully.

For years, I told myself this was a reasonable trade. The organizational leverage I'd gained was worth more than the technical depth I'd lost. And mathematically, it probably was.

But you can't fully make peace with something you loved by explaining why you were right to leave it.

Then AI happened. Not the way people imagined it would — not as a tool that writes code so developers don't have to, but as something stranger and more interesting. A collaborator that makes the developer role porous in ways it has never been before.

I can now engage with a codebase at a level I haven't sustained in years. Not by pretending the gap doesn't exist — it does, and AI doesn't close it. But AI makes the gap navigable. I can contribute to architecture decisions with actual technical grounding because I can move through code quickly enough to understand what I'm looking at. I can prototype an idea far enough to make the conversation with engineers concrete instead of abstract.

The FOMO didn't disappear. But it stopped being a wound.

Here's what I think is actually happening — to me, and to a much larger cohort of engineers who are watching AI change what it means to be "a developer."

The binary was always false.

The choice I made ten years ago — code or lead, developer or executive — was never about the work itself. It was about where I was directing cognitive energy at scale. Writing code and directing a company both require deep attention. You can't be fully inside both simultaneously.

AI doesn't eliminate that constraint. You still can't be fully inside everything simultaneously. What AI changes is the cost of re-entry. The gap between "someone who used to write code" and "someone who can contribute meaningfully to technical decisions" has collapsed. The identities are more permeable than they've ever been.

This is what I mean by the Orchestrator shift. Not that developers stop writing code — they don't. Not that judgment and craft become irrelevant — they become more valuable. But the identity of "engineer" is expanding to include something it used to exclude: the ability to operate effectively at the intersection of technical, strategic, and organizational without having to permanently leave one to live in another.

The engineers feeling the identity crisis right now are feeling it because they're trying to map a new reality onto an old binary. The question "am I still a real developer if AI writes 80% of my code?" is the wrong question. It's the equivalent of asking whether a conductor is still a real musician because they don't play every instrument.

The Orchestrator is a musician. A different kind.

What I know from having lived the forced version of this transition: the identities you accumulate on the way out of pure development are not consolation prizes. The PM instinct, the systems thinking, the ability to hold organizational complexity and technical complexity simultaneously — these are capabilities that aggregate.

The engineers who will matter most in the next decade are not the ones who resist the Orchestrator identity, nor the ones who abandon technical depth entirely. They're the ones who build both — who remain fluent enough in code to have judgment, while developing the broader operating range that only comes from learning to work across domains.

I had to make that transition under pressure, without the technology that would have made it easier, and without anyone naming what was happening to me.

You have better conditions for it than I did. That's not nothing.

The day I stepped back from daily development was one of the hardest professional days I've had. I didn't know at the time that it was also the beginning of a much larger kind of competence.

I'm not sure I would have believed it if someone had told me.

But I'd have been glad they tried.