Boris Cherny, who created Claude Code at Anthropic, posted something recently that has been doing the rounds. His argument is that engineering, product, design and data science are melting into a new kind of role, and that on his team he sees five archetypes rather than job titles:
- Prototyper: comes up with lots of new ideas, most of which never ship
- Builder: turns a prototype into a production-grade product or piece of infrastructure
- Sweeper: cleans up the UI, simplifies the code, unships things and improves performance
- Grower: iterates on a built product to improve product-market fit
- Maintainer: owns a mature system and keeps it secure, reliable and efficient as it scales
He maps them to the stage a product is at. Pre-PMF needs Prototypers, Builders and Sweepers. A growing product needs Builders, Sweepers, Growers and some Maintainers. A product with strong PMF needs Sweepers, Growers, Maintainers and some Builders. He also notes that the archetypes cut across job functions: some designers are Prototypers, some engineers are Sweepers.
I use Claude Code every day, and working solo I recognise all five in my own week. I have also spent a lot of time inside enterprise teams, and that is where the model starts to strain.
What is new and what is not
The stage mapping is not new. Simon Wardley described Pioneers, Settlers and Town Planners back in 2015, and Kent Beck's Explore, Expand, Extract covers similar ground. Boris adds the Sweeper, which I like. Nobody gets promoted for deleting things, and every mature product needs someone who does.
What is new is the claim that functions are collapsing into dispositions. I think that part is broadly right. When a designer can ship working code and an engineer can produce a decent interface, what you are really paying for is temperament and judgement. The craft boundaries matter less than they did.
The sample is unusual
This was observed on the Claude Code team: well funded, AI-native, and building a tool its own people use all day. Most organisations I work with look nothing like that. An enterprise that has built software the same way for fifteen years will not reorganise around archetypes because a good post went round LinkedIn, and many could not hire that way if they wanted to. Their career ladders, pay bands and HR processes are all built around function.
AI's leverage is lopsided
It would be easy to say the model only applies to innovation work. That is not quite fair, because Boris says outright that a mature product needs Sweepers, Growers and Maintainers. The better criticism is that AI helps each archetype by very different amounts.
For prototyping, the gain is enormous. I can get a new idea to something demonstrable in about the time it would take to write the business case for exploring it, and a working demo usually makes a better case anyway.
For maintaining a large, established product, the gain is much smaller. Those codebases carry years of technical debt. Every change has to be reviewed and committed in a state that does not add risk to something customers depend on. The teams I see doing this well do use AI, but carefully, and their bottleneck was never typing speed. It is comprehension, review and risk.
I would also push back on the idea that prototyping is now close to free. Tokens cost money and usage limits are real. Next to a salary that cost is small, though. The bigger hidden cost is the human attention spent reviewing everything that gets generated.
That has a consequence I do not see discussed much. If Prototypers and Builders can now produce far more, Sweepers and Maintainers become scarcer relative to the output they have to absorb. AI-generated code creates entropy faster than most teams can clear it.
More people, more code, more collisions
Solo, taking on several archetypes is easy. I am the Prototyper in the morning and the Sweeper after lunch, and the only person I have to agree with is me.
Teams are different. Several people committing to the same codebase has always been hard, and AI makes it harder because there is more code arriving from more sources into the same place. I wrote recently about two developers getting completely different AI output from the same codebase. That problem grows with every person you add.
So are we heading towards one developer owning an entire codebase? For small products, possibly. For anything sizeable I doubt it. The constraint is context: there is only so much of a system one person can hold in their head, and the bus factor on a one-person codebase is not something I would want to explain to a board. The likelier outcome is smaller teams with harder ownership boundaries, where each person or pair owns a bounded context and AI output from different people rarely lands in the same place. That puts more weight on architecture, not less.
User stories were never meant to be the spec
Scrum already collapsed a lot of roles into a handful, and put more of the responsibility for ways of working on the developers. When I did Scrum training years ago, the room agreed on something that has stuck with me: the best product owners have a technical background, because they can turn business need into requirements a team can actually build.
That matters more with AI in the loop. A well-refined user story is good at expressing user value. It is much weaker as an instruction for implementation. By the time you reach development and QA, it is hard to trace the resulting code back to the value the story described, because the wording leaves room for interpretation that a specification would not.
That was always by design. Ron Jeffries described a story as a card, a conversation and a confirmation. The card was a placeholder and the real detail lived in the conversation between people. An AI agent cannot have that conversation with your product owner, so the conversation has to be written down. Once you write it down properly, you have a specification.
I can see product owners moving further into the business and owning the why, while developers take user requirements and break them into specifications that get implemented against the product. Executable acceptance criteria are probably the bridge between the two. A product owner can read them, and the build fails when the implementation drifts.
Architects are well placed, with a caveat
If AI takes on more of the implementation, the valuable part of the process moves upstream: turning business requirements into technical ones and keeping the whole system coherent. That is what architects already do. Solution architects in particular spend their days translating business intent into technical direction and guiding teams through it.
The caveat is that not every architect is well placed. Architects who have drifted away from code will struggle, because a specification an AI can implement has to be precise and testable. That is closer to the work of a hands-on tech lead than to someone producing diagrams. There is also a risk that spec-driven development slides back into big upfront design, which we spent twenty years learning to avoid.
The counterweight is the prototype. When building a working version is cheap, the prototype can be the spec. Build it, put it in front of people, then formalise what survives. I have written before about why a no-throwaway prototype works when you define the contract first, and the same thinking applies here.
The role that is missing
Going back to Boris's list, the gap I keep returning to is the person who holds coherence across all those builders. Someone who decides what not to build, keeps the boundaries clean, and makes sure five fast-moving people are building one system rather than five. In a traditional team that was split between the architect, the tech lead and the product owner. In an AI-heavy team, I think it is the role everything else depends on.
If you are working out how your team should be shaped as AI takes on more of the delivery, I am happy to compare notes. No pitch, just a conversation if it is useful.
