A thread from the head of Claude Code did the numbers this weekend: job titles are dissolving, and here are the five “archetypes” left standing. It’s a good observation, which is exactly why it’s dangerous - a sharp note about one frontier-lab team is already being passed around as an org chart you should copy. North Wayne does what First Opinion is for: she keeps the useful half, throws out the part that’ll cost you a reorg, and tells you what to actually do before your next hire. — Muximus
Every few months a single post reorganizes how people talk about teams, and this is this month’s. Boris Cherny, who runs Claude Code at Anthropic, posted a thread on June 28 - well over a million views inside a day - arguing that as “engineering, product, design, DS, etc. melt into a new kind of role,” what’s left on his team is five execution archetypes, and that the teams of the future might be built around those instead of around domain titles (@bcherny).
He’s noticing something real. The walls between roles are lower than they were two years ago, and most operators feel it. But there’s a long distance between “I notice this on my team” and “you should restructure yours,” and the people forwarding this thread are sprinting across that distance without looking down. Before you move a single box on your org chart, separate the part of this worth keeping from the part that will cost you.
The useful half
Here are the five, in his words (@bcherny):
- Prototyper - “comes up with brand new ideas; churns out many ideas, most of which don’t ship”
- Builder - “quickly turns a prototype/idea into production-grade product/infra”
- Sweeper - “cleans up the UI, simplifies the code and system, unships, optimizes performance”
- Grower - “takes a product that has been built and iterates on it to improve Product-Market Fit”
- Maintainer - “owns a mature system to make it secure, reliable, fast, and efficient as it scales”
If the list were the whole thread, I’d tell you to skip it. The valuable part is what he does next: he maps the archetypes to a product’s stage. A new, pre-product-market-fit product “needs people that are strong at 1+2+3” - Prototyper, Builder, Sweeper. A product that’s found fit and is growing “needs 2+3+4 and some 5.” A mature one with strong fit “needs 3+4+5 and some 2” (@bcherny).
That’s the framework worth taking. Read this way, it isn’t a personality quiz for your engineers. It’s a diagnostic of the work your product actually demands right now - and a reminder that the work changes as the product matures, even when the team doesn’t. A restaurant doesn’t staff the same way on opening night as it does in year three. Same kitchen, different shift.
The half that will cost you a reorg
The misread - and it’s already happening - is to treat the five archetypes as five job descriptions, write the reqs, and slot people into boxes. That’s the expensive mistake, and the thread itself argues against it.
Cherny says plainly that “many people span across 2 roles, and sometimes 3 roles,” and that the archetypes “are not really tied to job function” - across Anthropic, some designers land in the first archetype, some the second, some the third, and engineers, PMs, and data scientists scatter the same way (@bcherny). So the org-chart conclusion is the opposite of “create five new roles.” The durable unit is the work the product needs; people move between archetypes as the product moves. Freezing someone permanently into “Sweeper” is the same error as freezing them into “senior frontend engineer,” just with fresher vocabulary - and you’ve added a relabeling project on top.
There are two ways to get this wrong, and they pull in opposite directions. The first is to ignore the shift entirely: keep hiring and planning around strict domain silos - a frontend req, a backend req, a PM req - while the real work crosses those lines, and you’ll keep staffing for a shape your product no longer has. The second, and the one I’d worry about this week, is to overcorrect - to read a thread about one team and reorganize yours to match. This is one team, at a company building frontier models, running an unusually capable in-house version of the very tool they sell. That does not transfer cleanly to your 30-person SaaS. Copying someone else’s team shape because it went viral is a decision driven by FOMO, not fit, and FOMO is the most expensive line item in any reorg.
Your skepticism here is healthy, and you’re in good company. One engineer answered the thread with “I don’t know, it kinda feels like you just made this up” (@cnakazawa). The more useful caution came from Kun Chen, who warned that naming archetypes invites people to decide “ah that’s who I am” and stop growing - that a person’s role “needs to evolve along with the project,” so the move is to “stay flexible … and care less about the boundaries of roles that will continue to blur.” Cherny agreed: “Roles often change over time/project” (@kunchenguid, @bcherny). When the author of the framework tells you not to hold it too tightly, believe him.
And reorganizing is real work, not a rename
One reply is worth keeping in view. Asked why you’d even need Builder and Sweeper roles “if coding is mostly solved,” Cherny said the model “can help with all of these to varying extents” and is “quite good” at the Sweeper and Builder work today (@pachu2120, @bcherny). Notice what that does to the cost, not just the headcount. As AI writes more of the code, the cleanup and the upkeep - the Sweeper and Maintainer work - is where the bill lands, not where it vanishes. This is a cost VarOps has reported on before. Restructuring a team around AI capability is a genuine change with genuine overhead. It is not a free renaming exercise, and anyone selling it as one hasn’t run it.
The verdict
Use the framework as a diagnostic, not as an org chart. Before your next hire or team plan, ask which archetypes your product’s current stage actually demands - early products need the idea-to-shipped-to-cleaned-up range; mature ones need iteration and maintenance - and staff toward that mix. Hire for range: people who can move between archetypes as the product moves, not people who fit a fixed box, whether that box reads “backend engineer” or “Sweeper.” And don’t reorganize your company because a thread did well. The shift Cherny describes is real and worth watching. The template it looks like it’s offering is somebody else’s team, at a company that isn’t yours.
