The archetypes split by time, not by person

Boris Cherny, who leads Claude Code, posted a map of his team that I have not stopped thinking about. Looking at the people around him, he saw five execution archetypes:

Archetype	What they do
Prototyper	Generates new ideas; most never ship
Builder	Turns a prototype into production-grade product and infrastructure
Sweeper	Cleans up the UI, simplifies the system, unships
Grower	Iterates a shipped product toward product-market fit
Maintainer	Keeps a mature system secure, reliable, and fast as it scales

His sharpest point was that none of these are job titles. Some designers are Prototypers, some engineers are Sweepers. The old walls between engineering, product, design, and data science are melting, and the archetype is what sits underneath.

But that map assumes a team. Five archetypes describes how a group divides one body of work, one person leaning Prototyper while another holds Maintainer. I run four products and nine repositories alone. There is no one to divide the five across. So the split has to land on two different axes, and that is where it gets interesting.

The short version: a solo operator splits the five archetypes across time and across agents, not across people. You wear them in sequence, and you push the low-judgment ones down into deterministic machinery so they run without you. And exactly one of the five resists both moves. It cannot be time-sliced away and it cannot be automated, and naming it is the most useful result of running the whole exercise on myself.

Two axes a team never needs#

On a team, the five run in parallel because five people run them. Alone, they cannot. They redistribute along two axes instead.

The first is time. I am a Prototyper on Monday and a Maintainer on Thursday, and the skill is not doing all five at once but knowing which one the hour calls for and refusing the other four while it lasts.

The second is machinery. Some archetypes are mostly judgment, and judgment stays with me. Others are mostly detection and enforcement, and those drop down into scripts, hooks, scheduled jobs, and a few agents that run whether or not I show up. I sort each one with the same question from leverage by subtraction: how much of this is open-ended judgment, and how much is discipline a machine holds better than I do?

The answer sorts the five cleanly.

One stays fully in my hands, two are split with machinery, one falls almost entirely to machinery, and one refuses to move at all. That last one is the point, so I will build up to it.

Prototyper: gate everything by default#

The Prototyper is the archetype I lean on hardest, and I run it under one rule: gate by default. Its defining trait, in Cherny's framing, is that most ideas never ship, which sounds like waste until you ask when it actually costs you. It only costs you if a half-formed idea can leak into production. So the discipline that makes heavy prototyping safe is the gate. Every new idea is built behind a flag, dark by default, going live only when something deliberate flips it.

My fleet is a stable of experiments, most of them gated on purpose: a pricing-engine track, a set of interactive visualizations, a local-only language-model platform, a market-prediction edge experiment. A large share sit dark or local-only behind a release check or an owner gate, precisely so I can keep generating without each one becoming a liability the moment it exists. The gate is what turns Cherny's "most of which never ship" from a confession into a method. Churn is cheap when nothing reaches a user until I say so.

This archetype does not delegate. A model will build anything I describe, but deciding what is worth describing is the one input it does not supply. The Prototyper stays fully in my hands.

Builder: spec before code#

The Builder takes a prototype and makes it hold, under the discipline this blog keeps circling: spec before code. The failure mode is familiar to anyone who has shipped a prototype. It was held together by context that lived only in your head, and the production version inherits none of it. Writing the spec first, then building to it, is what carries that context across. I made the case in SDD is context management and watched it save me in when the spec was wrong.

One arc makes the seam concrete. An idea that started as a rough visualization was promoted only once it had a spec, a parity check against a reference implementation, and a solver carried down to compiled code. The Prototyper made the sketch; the Builder refused to ship it until it was specified and verified. I cross that seam several times a week.

The Builder is the clearest split of the five. The mechanical half, the stacked pull requests, the wiring, the test scaffolding, runs as agents against the spec all day. The judgment half, deciding what the spec should require, stays with me, because a model builds faithfully to a spec but cannot tell me the spec is wrong. Hands automated, architecture not.

Sweeper: subtraction keeps churn from becoming debt#

Running the exercise on myself corrected my own ranking here. I expected the Sweeper to place last, a tidy-up after the real work. It belongs near the top, because it is the direct counterweight to the Prototyper, and on a team of one those two share a body. Generate like a heavy Prototyper, skip the Sweeper, and the churn compounds quietly into debt until the fleet seizes.

I run the Sweeper as subtraction passes, a method I have written down twice: the determinism test in leverage by subtraction, which routes most work toward scripts and hooks instead of agents, and the plainer habit of unshipping and simplifying instead of only adding. The Sweeper asks of every tool, route, and agent whether the fleet would be healthier without it. Solo, that is not housekeeping. It is survival, because no one else will notice the rot.

It delegates, but only the detection. A pass that flags dead code, drifting config pairs, or unswept branches runs fine as a scheduled job. The call to actually cut, to accept the small risk of unshipping, stays mine. Machine finds, human cuts.

Maintainer: maintenance is machinery, not a role I occupy#

The Maintainer is the first archetype to leave my hands almost entirely, under the label maintenance as machinery. Cherny's version owns a mature system and keeps it secure, reliable, and fast, which on a team is a standing assignment. Treating it as a role I personally occupy would be a mistake, because maintenance is mostly rules that must always hold, and a rule a human has to remember to enforce is already broken.

So it went down into infrastructure: a scheduled security baseline (a one-day security baseline for a solo fleet), standardized monitoring across the fleet (how I standardized infrastructure monitoring), nightly audits, deploy guards, drift detectors, a branch-hygiene sweep, and hooks that refuse a bad deploy before it lands. The Maintainer is not a hat I wear; it is a layer I built once and now supervise. It is the cleanest instance of Cherny's own point that the work shifts from doing to orchestrating: I do not maintain the fleet so much as maintain the agents that do. Converting this archetype into machinery is what frees the calendar for the Prototyper and Builder hours that actually need me.

Grower: the one that resists both axes#

That leaves the Grower, and the Grower is the point, because neither axis touches it. I cannot time-slice into it the way I switch into Maintainer on a Thursday, and I cannot push it into machinery the way I automated maintenance. It iterates a shipped product toward product-market fit, and fit needs users to iterate against. An operator who has optimized hard for building has usually starved the one archetype that depends on people he does not have yet.

This is my honest gap, and I will not dress it up: a fleet that is feature-complete in places, an audience thin everywhere. The reason it resists automation is the reason it matters. Growth's raw material is other people, and you cannot script your way to an audience the way you script a security scan. Every other archetype here bends to engineering. The Grower bends to attention, and attention is earned. Naming the missing archetype as a human-facing one, not a technical one, is the most useful result of the whole exercise, because it points straight at the constraint I keep avoiding instead of the ones I enjoy solving.

Where the five landed#

Sorted by judgment instead of by person:

Archetype	My label	Who holds it	What carries it
Prototyper	gate by default	me, full time	judgment only, nothing to delegate
Builder	spec before code	split	agents build to the spec; I write the spec
Sweeper	subtraction passes	split	jobs detect rot; I make the cut
Maintainer	maintenance as machinery	machinery	hooks, CI, scheduled audits
Grower	the gap	nobody yet	an audience, not tooling

Cherny's five describe a team dividing labor across people. A solo operator divides the same five across two axes a team never needs: across time, wearing them in sequence, and across agents, pushing the enforcement-heavy ones down into scripts, hooks, and scheduled jobs that run without supervision. Except one. The Grower cannot be time-sliced and cannot be automated, because its raw material is an audience, and that is a human problem no amount of tooling solves. The archetypes I am best at are the ones that bend to engineering; the one I am weakest at is the one that does not, which is exactly the one I should stop avoiding.

---

Related:

• Leverage by subtraction, the determinism test that powers the Sweeper
• Autonomy is mostly knowing when to stop, the same operator running the loop
• A one-day security baseline for a solo fleet, the Maintainer converted into machinery