The Five Archetypes of Future Talent: What Claude Code’s Creator Says About Tomorrow’s Workplace
Core question this article answers: Boris Cherny, creator of Claude Code, has identified five distinct talent archetypes that will define how teams work as AI reshapes traditional roles. What are these archetypes, and how can understanding them help you build better teams and plan your own career?
Image source: Unsplash — Modern collaborative workspace
1. Why Traditional Job Boundaries Are Disappearing
Summary: AI-powered tools are eroding the rigid walls between engineering, product management, design, and data science. The future belongs to people whose capabilities span multiple disciplines rather than those who stay within a single lane.
Core question: Why are the traditional boundaries between engineering, product, design, and data science becoming less relevant?
The answer is straightforward: the tools have become powerful enough that one person can now do what previously required an entire team. Boris Cherny, who leads the Claude Code team at Anthropic, has observed something that many of us have felt but struggled to articulate — the job titles we use to organize companies are becoming less useful than the actual ways people solve problems.
Think about what happens in a typical product cycle today. A designer who knows how to prompt an AI coding assistant can go from wireframe to working prototype without ever opening a ticket for an engineer. A product manager who understands basic data pipelines can run their own analytics instead of waiting for a data scientist’s sprint allocation. The “handoff culture” — where work moves sequentially from one specialist to the next like an assembly line — is giving way to something more fluid and integrated.
This isn’t about everyone becoming a full-stack generalist overnight. It’s about capability expansion at the edges. The designer doesn’t need to become a senior backend engineer, but they do need to understand enough about how software gets built to create prototypes that are actually useful for user testing. The product manager doesn’t need to write production-grade machine learning models, but they need to know enough about data to ask the right questions and interpret preliminary results.
Author’s reflection: I’ve watched this shift happen across multiple teams over the past few years. The most effective people I’ve worked with aren’t necessarily the ones with the deepest expertise in a single domain — they’re the ones who can move comfortably across the boundary between “thinking about the problem” and “building the solution.” The irony is that this was always valuable, but it used to require years of cross-training. AI tools have collapsed that timeline. What used to take six months of learning Python basics now takes a motivated product manager a few weekends of experimentation. The barrier isn’t technical anymore; it’s willingness to step outside your labeled role.
2. The Five Talent Archetypes Explained
Summary: Boris Cherny proposes five archetypes — Prototyper, Builder, Polisher, Grower, and Maintainer — that describe how people contribute value across a product’s lifecycle. These are not job titles; they are modes of working that can coexist within the same person.
Core question: What are the five talent archetypes, and what does each one actually do?
Cherny distilled these patterns from observing his own team at Anthropic. What’s important is that these are not five separate jobs you hire for. They are five ways of creating value that can exist in different combinations within individuals. Here’s how they break down:
2.1 The Prototyper (原型探索者)
What they do: Prototypers are the idea generators. They constantly experiment with new concepts, test hypotheses, and explore directions that may or may not lead anywhere concrete. Their output volume is high, but their hit rate is relatively low — and that’s by design.
Where they create value: Early-stage product development, when the team doesn’t yet know what will work. Prototypers help map the possibility space before the organization commits significant resources to a single direction.
Real-world scenario: Imagine a team at Anthropic trying to figure out how Claude Code could help scientists. A Prototyper might spend two weeks building five different experimental interfaces — one for literature search, one for code generation, one for data visualization, one for collaborative editing, and one that combines all of the above. Four of these might get shelved, but the fifth might reveal an interaction pattern that becomes central to the final product.
2.2 The Builder (建造者)
What they do: Once a Prototyper has identified a promising direction, the Builder takes that rough concept and turns it into something functional and stable. Builders are execution machines — they thrive on the challenge of making ideas real.
Where they create value: The critical transition from “we think this might work” to “we have something people can actually use.” Builders aren’t necessarily the most creative thinkers, but they’re indispensable for momentum.
Real-world scenario: After the Prototyper’s experiments, the Builder steps in to construct the actual Claude Science application. They set up the architecture, integrate the 60+ scientific database connectors, build the multi-agent coordination system, and ensure the whole thing doesn’t fall over when a researcher submits a large genomics job. The Builder makes the vision concrete.
2.3 The Polisher (清道夫)
What they do: Products that come out of the Builder’s hands work, but they rarely feel finished. The Polisher refines the rough edges: improving UI interactions, cleaning up code, removing unnecessary features, optimizing performance, and elevating the overall quality from “functional” to “delightful.”
Where they create value: The gap between “it works” and “it works well.” This is where user retention often gets decided — a product that technically solves a problem but feels clunky will lose users to a more polished alternative.
Real-world scenario: In Claude Science, a Builder might ship a feature that renders 3D protein structures. It works, but the rotation controls are awkward, the color scheme is hard to interpret, and loading large structures causes noticeable lag. The Polisher redesigns the interaction model, adjusts the default visual parameters, and implements level-of-detail rendering so that even massive structures load smoothly. The feature goes from “technically present” to “actually useful.”
2.4 The Grower (增长者)
What they do: Once a product is solid, someone needs to figure out how to get it into the hands of the right users and ensure it actually solves their problems. The Grower runs iterative experiments to improve product-market fit, measures user behavior, and drives adoption through continuous small improvements.
Where they create value: The transition from “we built something good” to “people are actually using it and getting value.” Without Growers, excellent products can languish in obscurity.
Real-world scenario: After Claude Science launches in beta, the Grower analyzes which scientific domains show the highest engagement. They discover that single-cell RNA sequencing researchers are power users, but protein structure prediction users are dropping off after the first session. The Grower works with the team to add better onboarding for structural biology workflows, creates template analyses for common PDB queries, and writes case studies featuring successful protein folding projects. Adoption in that segment doubles over the next quarter.
2.5 The Maintainer (维护者)
What they do: When a product reaches maturity with a large user base, the Maintainer becomes essential. They ensure the system remains secure, stable, and efficient as scale increases. This role isn’t glamorous, but without it, even the best products collapse under their own success.
Where they create value: The long-term health of a product. Maintainers prevent technical debt from accumulating, monitor for security vulnerabilities, optimize infrastructure costs, and keep the lights on so everyone else can do their jobs.
Real-world scenario: Claude Science starts handling genomics pipelines that run across hundreds of GPUs. The Maintainer implements better queue management to prevent resource starvation, adds circuit breakers for failing database connections, refactors the agent coordination layer to handle higher concurrency, and establishes runbooks for on-call engineers. Users never notice these changes — and that’s exactly the point. The product keeps working even as usage scales 10x.
Author’s reflection: I’ve noticed that organizations consistently undervalue Maintainers until something breaks catastrophically. There’s a cultural bias toward “builders” and “innovators” that treats maintenance as janitorial work. But Cherny’s framework makes something explicit that I’ve long suspected: maintenance is a distinct and valuable skill set, not a punishment for people who couldn’t get “promoted” to building new things. The best engineering organizations I’ve seen are the ones where senior Maintainers are respected as peers to senior Architects. When Anthropic’s Claude Code team talks about this archetype with the same weight as the others, that signals a maturity in how they think about team construction.
3. Why Archetypes Beat Job Titles
Summary: The same job title can house completely different archetypes. What matters isn’t whether someone is called an engineer or a designer — it’s whether they naturally operate as a Prototyper, Builder, Polisher, Grower, or Maintainer.
Core question: Why should teams think in terms of archetypes rather than traditional job titles when hiring and organizing work?
Cherny makes a point that sounds obvious once you hear it but is rarely acted upon: your job title doesn’t determine your archetype. Within Anthropic, some designers are natural Prototypers who constantly churn out experimental concepts. Other designers are Polishers who excel at refining existing interfaces to perfection. Some engineers are Builders who love starting from zero; others are Maintainers who find deep satisfaction in keeping complex systems healthy. Data scientists follow the same pattern — some want to explore new datasets and find unexpected patterns (Prototypers), while others want to productionize and monitor models in the wild (Maintainers).
This observation has practical implications for how teams should think about staffing:
Traditional approach: “We need a frontend engineer, a backend engineer, a designer, and a product manager for this project.”
Archetype approach: “We need someone who can quickly explore multiple directions (Prototyper), someone who can build the chosen direction into a working product (Builder), and someone who can refine the user experience until it feels polished (Polisher).”
The archetype approach forces you to think about what the project actually needs at its current stage rather than filling a roster based on org-chart conventions.
Real-world scenario: Imagine you’re staffing the initial development of Claude Science. The traditional approach might lead you to hire a full-stack engineer, a bioinformatics specialist, a UI designer, and a technical writer. The archetype approach would ask different questions: Do we need someone who can rapidly prototype different scientific workflow integrations to see what resonates? (Prototyper) Do we need someone who can take the most promising prototype and build a robust system around it? (Builder) Do we need someone who understands how scientists actually work and can refine the interface until it fits their mental model? (Polisher)
You might end up hiring the same people, but the framing changes how you evaluate candidates and how you assign work once they’re on the team.
4. Matching Archetypes to Product Stages
Summary: Different stages of a product’s lifecycle require different archetype combinations. Knowing which archetypes to emphasize at each stage can prevent costly misalignment between team composition and actual needs.
Core question: How should teams balance these five archetypes depending on where their product is in its lifecycle?
Cherny provides a practical framework for archetype allocation across three product stages. This isn’t just theory — it’s a staffing heuristic that can save teams from painful mismatches.
4.1 Early-Stage Products: Exploration Mode
Archetype mix: Prototyper + Builder + Polisher (with minimal Grower and Maintainer presence)
Why this mix: At this stage, the fundamental question is “does anyone want this?” You need people who can generate lots of ideas (Prototyper), quickly build testable versions (Builder), and refine the most promising ones enough to get genuine user feedback (Polisher). You don’t need Growers yet because you don’t have product-market fit to optimize. You don’t need Maintainers yet because the system isn’t under real load.
Real-world scenario: When Anthropic first started exploring AI applications for life sciences, the team needed to figure out whether researchers would actually use an AI-powered workbench. They didn’t need infrastructure engineers optimizing for million-user scale. They needed a small team of Prototypers and Builders who could rapidly test different interaction models — maybe a chat-based interface, maybe a notebook integration, maybe a plugin for existing tools. The Polisher made sure the demos were compelling enough to get honest feedback from beta scientists.
4.2 Growth-Stage Products: Scaling Mode
Archetype mix: Builder + Polisher + Grower (with some Maintainer support)
Why this mix: The product has found its direction. Now the priority is making it better, getting it to more users, and ensuring the system doesn’t collapse under growth. Builders add new features that users are asking for. Polishers improve the experience to reduce churn. Growers run experiments to optimize acquisition and engagement. Maintainers keep the infrastructure from falling over as usage increases.
Real-world scenario: After Claude Science’s beta launch showed strong traction with genomics researchers, the team shifted into scaling mode. Builders added support for proteomics and cheminformatics workflows. Polishers refined the 3D molecule viewer based on user feedback. Growers identified that academic labs were the highest-value segment and created targeted onboarding flows for that audience. Maintainers ensured the system could handle the surge in concurrent users without degrading performance.
4.3 Mature Products: Optimization Mode
Archetype mix: Polisher + Grower + Maintainer (with minimal Builder presence)
Why this mix: At maturity, the product’s core value proposition is established. Big innovations are rare and risky. The focus shifts to incremental improvements, operational excellence, and extracting maximum value from the existing user base. Polishers continuously improve the experience. Growers optimize monetization and retention. Maintainers ensure reliability and security at scale. Builders are kept in reserve for genuinely new opportunities, not routine feature work.
Real-world scenario: Imagine Claude Science five years from now, with hundreds of thousands of active researchers across multiple scientific disciplines. The team isn’t trying to reinvent the product — they’re making sure it stays the best tool in its category. Polishers work on micro-interactions that save researchers seconds on every analysis. Growers experiment with premium tiers for enterprise labs. Maintainers monitor the infrastructure across multiple cloud regions and ensure compliance with institutional data policies. A small Builder team works on speculative features — maybe AI-powered grant writing assistance — but most resources go to making the core product better, not bigger.
Author’s reflection: I’ve seen teams get this wrong in both directions. Early-stage startups that hire too many Maintainers end up building robust infrastructure for a product nobody wants — they’re optimizing for scale that may never come. On the flip side, mature products that keep stuffing the team with Prototypers and Builders end up with feature bloat, technical debt, and a deteriorating user experience because nobody is focused on refinement and stability. Cherny’s framework is valuable because it gives you language to diagnose these mismatches. When your mature product keeps shipping half-baked new features while core workflows degrade, you don’t have an innovation problem — you have an archetype balance problem.
5. What This Means for Your Career
Summary: Understanding your own archetype tendencies helps you choose roles where you’ll thrive, identify skills worth developing, and avoid situations where your natural strengths are mismatched to organizational needs.
Core question: How can individuals use this archetype framework to make better career decisions?
The framework isn’t just for managers building teams — it’s equally useful for individuals navigating their own professional development. Here’s how to apply it:
5.1 Know Your Natural Tendencies
Ask yourself honest questions:
-
Do you get energized by blank-slate exploration, or do you prefer working within established constraints? -
Do you feel most alive when you’re starting something new, or when you’re making something good into something great? -
Do you find satisfaction in user growth metrics, or in system uptime dashboards? -
Do you enjoy the chaos of early-stage ambiguity, or the predictability of well-defined processes?
Most people have a primary archetype and one or two secondary archetypes. You might be primarily a Builder with strong Polisher tendencies, or a Grower who can also Prototype when needed. That’s normal — people are complex.
Real-world scenario: If you’re a data scientist who loves exploring new datasets and finding unexpected patterns (Prototyper primary), but you also enjoy the process of productionizing models and monitoring their performance in production (Maintainer secondary), you might thrive in a research-heavy environment that also values operational rigor. A pure research lab might frustrate you because your work never sees real users. A pure engineering team might bore you because there’s no exploration phase. A team working on applied research — like Anthropic’s life sciences group — might be the perfect fit.
5.2 Match Your Archetype to the Company’s Stage
This is where the framework becomes genuinely career-protective:
If you’re a Prototyper and you join a mature company with rigid processes and quarterly planning cycles, you will likely feel suffocated. Your natural impulse to experiment will be seen as disruptive or unfocused. You need an environment where exploration is valued — early-stage startups, research labs, or innovation teams within larger organizations.
If you’re a Maintainer and you join a pre-revenue startup that’s pivoting every month, you will likely feel anxious and undervalued. Your instinct to build robust systems will be seen as premature optimization. You need an environment where stability and reliability are genuinely valued — mature products, infrastructure teams, or platform engineering groups.
If you’re a Polisher and you join a team that’s purely focused on shipping features as fast as possible, your attention to detail will be seen as slowing things down. You need a team that understands the competitive advantage of quality — consumer products where user experience is a differentiator, or enterprise tools where polish signals reliability.
If you’re a Grower and you join a team that doesn’t yet have product-market fit, you’ll be optimizing metrics for a product that fundamentally doesn’t work. You need a product that’s already solving a real problem for real users, so your growth experiments have a solid foundation to build on.
If you’re a Builder you’re relatively versatile — Builders are needed at every stage. But even Builders have preferences. Some love the zero-to-one phase where they’re creating something from nothing. Others prefer the one-to-ten phase where they’re expanding an existing system. Know which type you are.
5.3 Develop Complementary Skills
Once you know your primary archetype, you can intentionally develop adjacent capabilities:
-
Prototypers often struggle with follow-through. If this is you, deliberately practice Builder skills — learn to take one of your ideas and see it through to a working implementation, even if it’s not perfect. -
Builders sometimes lack creativity. If this is you, give yourself structured exploration time — set aside a few hours a week to experiment with new technologies or approaches without a deliverable. -
Polishers can get stuck in infinite refinement. If this is you, practice shipping things that are “good enough” and moving on. -
Growers sometimes lose touch with the product itself. If this is you, spend time doing customer support or using the product yourself to reconnect with the user experience. -
Maintainers can become overly risk-averse. If this is you, occasionally take on a project that’s outside your comfort zone to keep your skills broad.
Author’s reflection: I’ve spent most of my career oscillating between Builder and Polisher modes, with occasional forays into Prototyper territory. What I’ve learned — and what Cherny’s framework helps formalize — is that these aren’t fixed identities. They’re skills you can develop. Early in my career, I was purely a Builder — I loved starting projects but lost interest once the initial architecture was done. I had to deliberately train myself to enjoy the refinement phase, to find satisfaction in shaving milliseconds off response times or simplifying a complex UI flow. That transition wasn’t natural for me, but it made me significantly more valuable as a team member. The archetype framework gives you a map for this kind of intentional skill development.
6. Practical Action Checklist
Use this checklist to apply the archetype framework in your own context:
For Team Leads and Managers:
-
[ ] Map your current team members to their primary and secondary archetypes -
[ ] Identify which archetypes are overrepresented or underrepresented -
[ ] Compare your team’s archetype mix to your product’s current lifecycle stage -
[ ] Adjust hiring priorities based on archetype gaps rather than job-title gaps -
[ ] Have explicit conversations with team members about their archetype preferences
For Individual Contributors:
-
[ ] Honestly assess your primary and secondary archetypes -
[ ] Evaluate whether your current role aligns with your natural tendencies -
[ ] Identify one adjacent archetype skill to deliberately develop over the next quarter -
[ ] When considering new opportunities, ask about the team’s archetype balance and the product’s stage -
[ ] Frame your strengths in archetype terms during performance reviews and job interviews
For Entrepreneurs and Founders:
-
[ ] Be explicit about which archetypes you need for your current stage -
[ ] Avoid the temptation to hire “senior generalists” — get specific about which archetype capabilities you need -
[ ] Recognize that your own archetype preferences will shape company culture; compensate for blind spots -
[ ] Plan for archetype transitions as the company matures
7. One-Page Overview
What are the five talent archetypes?
-
Prototyper: Explores ideas rapidly, high volume of experiments, low hit rate by design -
Builder: Transforms rough concepts into functional, stable products -
Polisher: Refines products from “works” to “works well” through attention to detail -
Grower: Drives adoption and product-market fit through iterative optimization -
Maintainer: Ensures long-term stability, security, and performance at scale
Why archetypes matter more than job titles:
The same job title can contain completely different archetypes. A “designer” might be a Prototyper or a Polisher. An “engineer” might be a Builder or a Maintainer. What matters is what the person actually does, not what their business card says.
How to match archetypes to product stages:
-
Early stage: Prototyper + Builder + Polisher (exploration and validation) -
Growth stage: Builder + Polisher + Grower + some Maintainer (scaling and optimization) -
Mature stage: Polisher + Grower + Maintainer (incremental improvement and operational excellence)
Key career insight:
Understand your natural archetype tendencies, choose environments that value those tendencies, and deliberately develop adjacent archetype skills to increase your versatility.
8. Frequently Asked Questions
Q1: Can one person embody multiple archetypes?
Yes, and most people do. Cherny explicitly notes that many individuals possess two or three archetype traits simultaneously. You might be a strong Builder who also has Polisher tendencies, or a Grower who can Prototype when needed. The framework describes tendencies, not rigid categories.
Q2: Are these archetypes specific to tech companies?
While Cherny derived these from observing the Claude Code team at Anthropic, the underlying patterns apply to any product development context. Whether you’re building software, hardware, or services, products go through similar lifecycle stages that require different types of contributions.
Q3: How do I determine my primary archetype?
Pay attention to what energizes you versus what drains you. Do you feel most alive when exploring new ideas (Prototyper), building working systems (Builder), refining details (Polisher), driving metrics (Grower), or ensuring stability (Maintainer)? Your energy levels are usually more honest than your self-perception.
Q4: Should teams aim for equal representation of all five archetypes?
No — the ideal mix depends entirely on the product’s stage and the organization’s goals. A research lab might need mostly Prototypers and Builders. A mature SaaS company might need mostly Polishers, Growers, and Maintainers. The goal is alignment, not balance.
Q5: Can someone’s archetype change over time?
Absolutely. People develop new capabilities through deliberate practice, and their preferences can shift based on experience and context. Someone who starts as a pure Builder might develop strong Polisher skills over time. The framework is descriptive of current tendencies, not prescriptive of fixed destiny.
Q6: What if my archetype doesn’t match my current job description?
This is common and addressable. If you’re a natural Prototyper stuck in a Maintainer role, you have three options: find ways to incorporate more exploration into your current role, negotiate a transition to a more suitable team, or seek opportunities elsewhere that better match your strengths. The first step is recognizing the mismatch.
Q7: How does this framework relate to existing personality assessments like Myers-Briggs or StrengthsFinder?
Those tools focus on personality traits and general strengths. Cherny’s archetypes focus specifically on how people create value in product development contexts. They’re more actionable for team construction and career planning because they’re tied to observable work behaviors rather than abstract psychological profiles.
Q8: Is there a “best” archetype to have?
No. Each archetype is essential at the right time and place. A team of all Prototypers would generate brilliant ideas but ship nothing. A team of all Maintainers would keep an empty system running perfectly. The value of an archetype is contextual — it depends on what the product needs at that moment.
Closing thought: The most important message in Cherny’s framework is that the future of work isn’t about what your diploma says or what your job title claims — it’s about where in the product lifecycle you create the most value. As AI tools continue to dissolve traditional skill boundaries, this way of thinking about talent will only become more relevant. The organizations and individuals who internalize this shift early will have a significant advantage in building effective teams and fulfilling careers.