AI Engineering · Product · Hiring
When AI makes prototyping free, who ships to production?
AI made prototyping nearly free. Boris Cherny’s five product roles show why the scarce work — and the value — moved to whoever ships to production.
AI made prototyping almost free. That didn't make software teams obsolete — it moved the scarce, valuable work downstream, to whoever can take a prototype and make it survive production. Boris Cherny, who created Claude Code, put language to the shift: as engineering, product, and design melt together, teams organize less around job titles and more around five roles — Prototyper, Builder, Sweeper, Grower, and Maintainer. The role that just got cheap is the Prototyper. The ones that got more valuable are the rest.
The five roles of an AI-era product team
In his framework, Cherny argues these roles aren't tied to a job function. A designer can be a Builder; an engineer can be a Maintainer. What matters is the work someone does, not the title on their profile:
- Prototyper — generates brand-new ideas and churns out many of them, most of which never ship.
- Builder — turns a promising prototype into a real, production system.
- Sweeper — simplifies and hardens the code, the UI, and the systems around it.
- Grower — iterates on a shipped product to improve product-market fit.
- Maintainer — keeps it secure, reliable, and efficient as it scales.
The insight underneath: a healthy team needs a different mix of these roles depending on where the product is in its life. Early products need idea generation and construction. Later ones need refinement, growth, and stewardship.
What AI actually changed
AI is a Prototyper's dream. Anyone can go from an idea to a working demo in an afternoon — no team, no sprint, no permission. The role that used to be scarce senior work is now abundant.
Abundance kills leverage. When everyone can prototype, prototyping stops being the bottleneck. The constraint moves downstream, to the roles that turn a demo into something a business can depend on: Builder, Sweeper, Maintainer. That is the work AI has made more valuable, not less — because there is far more raw output now demanding to be made correct, secure, and durable.
Prototype is not product
A demo that works on the founder's laptop and a system that holds up with real users, real data, and real load are different artifacts separated by a long, unglamorous last mile. Authentication that survives contact with attackers. A data model that doesn't corrupt under concurrency. Architecture that survives the next 10x. Costs that don't balloon.
That last mile is exactly where most AI-built software stalls. The Prototyper got you 80% of the way in a weekend; the remaining 20% — the Builder-to-Maintainer stretch — is now the expensive part, and the part that decides whether the product launches or quietly dies in staging. It's the work we do at SV Dev: taking AI-built and early-stage software the rest of the way to production.
How to staff by product stage
The framework is most useful as a staffing lens. Match the mix of roles to where the product actually is:
| Stage | Roles to weight | Why |
|---|---|---|
| Pre-PMF | Prototyper + Builder | Find an idea worth shipping and get one version into real users' hands. |
| Growth | Grower + Sweeper | Iterate toward fit while simplifying the mess that fast growth creates. |
| Scale | Maintainer + Sweeper | Security, reliability, and cost become non-negotiable. |
The common failure is a team stuck in Prototyper mode: a graveyard of impressive demos and nothing in production. AI makes that failure easier to reach, because it makes prototypes so cheap to produce.
Roles are capabilities, not headcount
Cherny's sharpest point is that these are capabilities, not job titles — and one person can play several. That is precisely what AI unlocks: a small team can now cover more of the spectrum, because the model handles a large share of the Prototyper and Builder work. But no model yet covers a Maintainer's judgment about what will break at 3 a.m., or a Sweeper's taste for what to delete.
This is why we think about teams the way we do — we build products by building people. You don't hire finished Maintainers; you develop people into the roles the product needs as it matures. The titles are dissolving. The capabilities are what you actually staff for.
Key takeaways
- AI made the Prototyper role abundant, so the scarce value moved to Builder, Sweeper, and Maintainer — the roles that ship and sustain production software.
- "Prototype" and "product" are different artifacts. The last mile between them is where most AI-built software stalls.
- Staff to the product's stage: prototyping and building early, growing and sweeping in the middle, maintaining at scale.
- Roles are capabilities, not titles — build people into the ones your product needs next.
FAQ
What are the five AI-era product roles?
Per Boris Cherny, creator of Claude Code: Prototyper (new ideas), Builder (prototype to production), Sweeper (simplify and harden), Grower (iterate toward product-market fit), and Maintainer (security, reliability, and efficiency at scale).
Did AI make software engineers obsolete?
No. AI made the prototyping part of the job abundant and cheap. It increased the value of the downstream roles — turning prototypes into secure, reliable, production systems — because there is now far more raw output that needs to be made trustworthy.
Which role is hardest to automate?
The Maintainer. Keeping a system secure, reliable, and efficient at scale depends on judgment about failure modes, trade-offs, and context that models don't reliably hold yet.
How should an early-stage startup use this?
Weight your team toward Prototyper and Builder to get a real product into users' hands, but don't skip the Builder-to-Maintainer work before launch — that last mile is what turns a demo into a business.