In my last post, I introduced the “five role archetypes” that Boris Cherny presented. After finishing that piece, one thing kept nagging at me, so here’s the follow-up.
How Claude Code Is Reshaping “Job Roles”――Anthropic’s Five Role Archetypes
目次
The Thing That Nagged Me: One Line in the Replies
As I mentioned last time, in the replies to Cherny’s post, someone pointed out that “the sixth archetype, Orchestrator, is missing.” That’s the person who decides which role to deploy when, and how to transition between them.
Cherny’s reply, in short, was this: ideally you design people and incentives so the team self-organizes; the faster things change, the less a central coordinator works; and part of that role can be handled by Claude itself.
I introduced this neutrally in my last post and left it at that, but afterward a question stayed with me. Does self-organization really just happen on its own?
It Never Said “On Its Own”
Reading it again, Cherny never actually says it happens “on its own.” He writes about designing people and incentives. Which means someone is doing the designing. You could read it as: he says Orchestrator isn’t needed, while quietly assuming the work an Orchestrator would do.
There also seem to be two unstated assumptions.
One is hiring. A company at that level, with that kind of applicant ratio, only lets in people who can judge the phase of work themselves and move without being told. Gather people like that, and yes, you get self-organization. But that’s less an achievement of management than an achievement of selection.
The other is shared purpose. In an in-house product, what you’re building and what counts as success are visible to everyone from the start. A group with shared purpose has low coordination costs. In contracted development, by contrast, the purpose sits with the client. The conditions are simply different to begin with.
In other words, coordination cost hasn’t disappeared — it’s been prepaid through upfront design and selection. That’s the framing that makes sense to me. And organizations that can’t prepay have no choice but to pay later. That, I think, is what a manager’s role actually is.
So Should Managers Stay Exactly as They Are?
I don’t think that either. I’m not on board with the “managers are unnecessary” argument, but I also don’t think the role stays unchanged.
A large part of a traditional manager’s job has been relaying information: asking around about who’s doing what, aggregating it, reporting up, passing it down. Progress tracking and workload management are, at bottom, this.
I think this part is going away. Once the development process is written in machine-readable form, deliverables flow through version control, and AI leaves a work log behind, you can see the state of things without relaying it. The relay role existed because the state of things lived only inside people’s heads.
So what stays, and what becomes newly necessary? Let me lay it out.
A Manager’s Work: What Disappears, What Remains
| The work | What happens to it | Why |
|---|---|---|
| Collecting and aggregating progress | Disappears | Once deliverables flow through version control, you can see them without asking around |
| Writing reports for management | Disappears (automated) | Can be generated from logs and diffs. It stops being something you make |
| Passing information down | Disappears | With a machine-readable process, there’s a single source to refer to |
| Estimating and allocating hours | Thins out | The person-month assumption breaks down, though budget negotiation remains |
| Assigning tasks | Thins out | As conditions align, this shifts toward people self-selecting by phase |
| Deciding on undefined items | Remains / grows | AI surfaces more of these; decision authority can’t be delegated away |
| Taking external responsibility | Remains | As long as a human is the party to sign-off and contracts, this doesn’t disappear |
| Absorbing conflict | Remains | Not something that can be made machine-readable |
| Designing the environment and incentives | Becomes central | Self-organization doesn’t just happen — someone has to own this |
| Setting quality standards for AI output | New | How much to accept is a policy decision, not a technical one |
An Engineer’s Work: What Disappears, What Remains
| The work | What happens to it | Why |
|---|---|---|
| Writing code | Thins out | Won’t hit zero; the hardest parts remain |
| Writing routine design docs | Disappears | Once specs are structured, they become generation targets |
| Quietly resolving ambiguity while implementing | Disappears | This judgment call moves upstream |
| Structuring specifications | Becomes central | This is the work of deciding “what to have built” |
| Verifying output | Remains / grows | As volume increases, this becomes the biggest bottleneck |
| Telling spec from AI guesswork | New | You can’t tell from the output alone; a person has to look |
| Small on-the-ground judgment calls | Moves upward | Doesn’t disappear — it moves to the manager’s side |
Laid out side by side, the split is clean. What disappears is work that moves information between people; what remains is judgment that carries responsibility.
The Biggest Effect: The Disappearance of Quietly Resolving Ambiguity
Personally, I think the item with the biggest impact is the one on the engineer’s list: “quietly resolving ambiguity while implementing” disappearing.
Whatever wasn’t written in the spec has, until now, been filled in on the spot by whoever was implementing it — asking around, or deciding from experience. That work was never counted as hours; it’s a cost that’s been absorbed for free.
Bring AI into this and the nature of it changes. AI doesn’t stop for ambiguous input. It fills in whatever wasn’t written using guesswork and produces something that looks plausible. And looking at the output, you can’t tell which parts follow the spec and which were guessed. I think part of what gets called hallucination is less a flaw in the model than an honest response to undefined input.
That’s exactly why a step is needed to explicitly surface what’s undefined. And once you surface it, questions like “this hasn’t been decided yet” start flowing upstream faster, and in much greater volume.
From a manager’s point of view, it will look like introducing AI increased their own workload. In reality, a debt that already existed has simply become visible — but unless that gets explained, the rollout won’t be welcomed. If you sell it as “bringing in AI makes managers’ jobs easier,” you’ll probably end up breaking things on the ground. It’s not that it gets easier — the kind of work changes. From managing progress to processing decisions.
Conclusion
I don’t think self-organization is something that just happens when left alone — it’s a phenomenon that occurs where the conditions are in place. Read closely, even Cherny’s reply assumes the necessity of design. Managers aren’t disappearing; rather, the part of the job that “carries information” disappears, while the parts that “decide” and “set up the environment” remain — and if anything, move to the center.
The name “Orchestrator” also feels slightly off to me once I think about it this way. The word carries a connotation of central control. What actually remains is closer to arranging conditions than exerting control. A gardener might be a better metaphor for what the role actually is.
And one more thing: on the engineering side too, the center of gravity is shifting away from writing code by hand and toward “what to have built” and “whether what came out is correct.” That’s arguably converging on what used to be a manager’s job. Both sides move toward the center, and the boundary dissolves. I take the observation that the five role archetypes aren’t tied to job titles to be pointing at exactly this.