Designers can build now. Design teams aren't organized for it.

A few weeks ago I read a post by Boris Cherny, who leads Claude Code at Anthropic. His argument is that engineering, product, design and data science are melting into one kind of role, and that what's left underneath the titles is five archetypes:

• Prototyper: comes up with new ideas, most of which never ship.
• Builder: turns a prototype into production-grade product.
• Sweeper: cleans up the UI, simplifies the system, unships what isn't working.
• Grower: takes something already built and iterates it toward product-market fit.
• Maintainer: owns a mature system and keeps it secure, reliable and fast as it scales.

Then he adds the part that matters: these aren't tied to job function. At Anthropic, some designers match the first archetype, some the second, some the third. Same for engineers and PMs.

I've read a lot of takes on that post about what it means for individual careers. I think the more interesting question is what it means for teams. Because if the archetypes are real, the way we've been building design teams for the last fifteen years stops making sense.

The thing that actually changed

Designers can execute now.

Not "designers can make better prototypes." Execute. I'm seeing designers open pull requests. Designers building functional features, connected to real data, that go to production with review. Designers who spend most of their week in the codebase, cleaning up components nobody maintained. Designers who own the performance and the accessibility of a surface, not the mockup of it.

This isn't a prediction. It's happening now, unevenly, and mostly without anyone updating the job description.

The point isn't that designers became engineers. It's that the barrier that separated proposing from producing is basically gone. And that barrier was the load-bearing wall of how design teams were structured.

What the old model assumed

The design team as most of us know it was built on one assumption: designers can't ship. So the team was organized around handing work to someone who could.

Everything follows from that. Roles differentiated by seniority rather than by type of work, where a senior designer does the same shaped job as a mid designer, just on harder problems. Career ladders that measure scope and craft depth. Rituals built around the handoff: specs, annotations, design review, the QA pass at the end. Success measured by what was designed, not by what held up.

That model worked. It just answered a question that no longer exists.

The archetypes inside a design team

Here's what I think the five look like when you apply them to design specifically. They're not personalities. They're types of work, and most people cover one or two.

The prototyper. Explores in code or in high-fidelity tools, fast, and expects most of it to be thrown away. Their output isn't a file, it's a decision made earlier and cheaper than it would have been in a meeting.

The builder. Takes a validated direction and ships it. Writes production components, opens PRs, works inside constraints instead of proposing them. This is the profile that barely existed in design teams five years ago and is now the most contested hire.

The sweeper. Deletes. Consolidates duplicated patterns, removes features nobody uses, simplifies flows that grew by accretion. In a world where generating interfaces is nearly free, this becomes the most undervalued and most necessary work in the team.

The grower. Owns a live surface and iterates it against real numbers. Lives closer to analytics and experiments than to Figma. This one already existed under other names, usually product designer on a growth pod.

The maintainer. Owns something mature: the design system, a core flow, the accessibility baseline. Their job is that nothing degrades while everything else moves. When they do it well, nobody notices.

Read that list against your current team. My guess is you have four prototypers, one accidental maintainer, and nobody sweeping.

What breaks

Once you see the team this way, a few things stop working.

Hiring. "Senior Product Designer" describes a level, not a type of work. Two candidates with the same title can be useless and essential for the same opening depending on which archetype your product stage needs.

Career ladders. Almost every ladder rewards scope and visible new work. Under that logic, sweeping and maintaining are career suicide. Which is exactly why nobody wants those roles, and exactly why they're about to be the scarcest.

Team composition. Cherny points out that the right mix depends on the product's stage. Early, you need prototypers and builders. Once it's growing, builders and growers. Once it's mature, sweepers and maintainers, with some building. Most design teams are staffed by headcount budget, not by stage.

The handoff. If a designer can ship, the handoff stops being a phase and becomes an option. Half of our documentation rituals exist to compensate for a wall that isn't there anymore.

What I'd change

Three things, in order of difficulty.

Name the archetype, not just the level. In hiring, in team composition, in one-on-ones. It's a cheap change and it immediately explains why some people are struggling: they're doing prototyper work on a mature product, or sweeper work in a team that needs someone to ship.

Staff by product stage. Ask what stage the product is in before asking how many designers you need. A team of prototypers on a mature product will slowly make it worse, and everyone will be busy.

Fix the ladder before you ask for maintainers. This is the hard one. You can't ask people to take on the invisible work while promotion depends on visible launches. If sustaining isn't a legitimate path to seniority, the team will keep optimizing for new things, and the new things will keep breaking.

One consequence for design systems

If designers across a team are shipping directly, the design system stops being a documentation project and becomes the thing that holds the whole model together. It's what lets a prototyper move fast without inventing new patterns, what lets a builder ship without asking, and what gives a sweeper something to consolidate toward.

I'd say it more bluntly: distributed execution only works with shared constraints. Without them, five people building in parallel produce five different products.

Where this lands

The uncomfortable version of Cherny's post isn't "your title is obsolete." Titles have been soft for a while. The uncomfortable version is that the org chart is obsolete too, and the org chart is much harder to change than a title.

We spent years asking for a seat at the table, meaning we wanted designers closer to the decisions. We got something bigger and less comfortable: the ability to make and ship the thing ourselves. The teams that adapt won't be the ones with the best designers. They'll be the ones that stopped organizing people by craft and started organizing them by the kind of work the product needs right now.

References and further reading

• Boris Cherny (Head of Claude Code, Anthropic), post on X, June 28, 2026. x.com
• Same post on Threads, including the replies where Cherny notes that roles shift by project. threads.com
• Business Insider, "The 5 job archetypes of the future, according to Claude Code's creator," June 2026. businessinsider.com
• The AI Daily Brief, episode on agentic work archetypes, July 5, 2026. aidailybrief.ai
• "The Archetype Under the Title," paddo.dev, June 2026, which traces the framework back to earlier taxonomies. paddo.dev
• Robert X. Cringely, Accidental Empires (1992). Commandos, infantry, police.
• Simon Wardley, "Pioneers, Settlers and Town Planners."
• Nathan Curtis, "Team Models for Scaling a Design System" (EightShapes, 2015).