跪拜 Guibai
← Back to the summary

Your Job Title Is a Liability: The 5 Roles That Replace 'Full-Stack'

Stop saying 'full-stack' — in the AI era, teams only recognize these 5 types of people

Author: Bionic Lion Tags: Frontend, Backend, Artificial Intelligence

The article is compiled from a weekly meeting presentation, polished by AI. The original PPT is below.

https://lionad-morotar.github.io/ppt/boris-five-roles-in-ai-native-teams

When engineering, product, and design melt together into a new role in front of AI, what roles really exist within a team?

The answer from Boris Cherny, the father of Claude Code, is five work archetypes: Prototyper, Builder, Sweeper, Grower, and Maintainer.

Starting from his observations, this article discusses the compression of titles and the rearrangement of division-of-labor patterns in AI-native teams.

How many years of shelf life does your position have left?

In the last month, organizational adjustment signals in the product and R&D circle have been so dense they're impossible to ignore.

Meituan's CLC grocery retail Keemart R&D team completed a structural adjustment, officially merging frontend and backend. The new structure is already in effect, and relevant frontend colleagues began receiving backend training more than a month in advance[^infoq]. Ant Webank announced it is pushing testing roles to transition entirely to R&D roles, with a six-month buffer period. Once the transition period ends, former testing colleagues will become full-stack engineers[^infoq]. In the hiring market, job descriptions for full-stack engineers are also noticeably increasing.

Even more exciting, and perhaps more worrying, is that AI digital employees have really started 'onboarding.'

Shopify has an internal AI colleague named River. It is a real 'colleague' — living in the company's public Slack channels, reading code, running tests, submitting PRs, and occasionally publicly objecting when a proposal has issues. According to Shopify's own disclosures, now for every 8 PRs merged into the main branch company-wide, 1 is completed in collaboration with River[^river]. Digital employees are already directly participating in production-level software development.

When you go to work one day and find an Agent sitting at the desk across from you, will you wonder — how much shelf life does your own position have left?

Can the waterfall still hold up?

Let's put this question aside for a moment. To answer how long a position can last, it's worth looking back at how today's positions were carved out in the first place.

Collaboration within enterprises relies on specialized division of labor. Eight years ago, when I first started as a frontend developer, I consulted colleagues who entered the industry earlier. The way they worked in the earliest domestic frontend teams back then was almost exactly the same as everything I take for granted today: specialties were divided by function, requirements came from the market, handed to product for refinement, reviewed by design for UI/UX, then handed to frontend and backend development, and finally supported by the data team for analytics or operational capabilities.

This Waterfall-style assembly line works very well and has been running smoothly for over a decade. But in the face of AI, more and more people are beginning to question: can this division of labor cut by function still hold up?

The source of the viewpoint: Boris Cherny, father of Claude Code

Answering the question 'how should the team formation change,' Boris Cherny's observations come directly from the Claude Code team itself — he is the creator of this product.

Within Anthropic, there is a lab mechanism similar to an incubator. Boris and a few colleagues formed a very small project-based team and, in a short period, created Claude Code, CC Desktop, and the Model Context Protocol (MCP), among other things, after which the team disbanded. This project-based way of working deeply influenced how he views product and engineering. He is also one of the proposers of the recently hot topic of Loop Engineering — he has mentioned in multiple interviews that Claude Code has been moving in the direction of 'using loops as the core execution harness,' with the goal of running more agents at lower cost and higher efficiency.

Those who have used Claude Code will notice that the core assumption of his viewpoint is: traditional process-oriented work will be reconstructed through Shift Left. Work is moved as early as possible, people are liberated from technical process nodes, and more tasks are handed over to Agents for automated completion.

At the end of June 2026, he wrote a widely reposted passage on X. He first asked: when functions like engineering, product, design, and data science melt into a new role, what will future roles look like? He then gave his own answer — observing the Claude Code team, he saw five archetypes[^five].

Five archetypes, five modes of working

The five archetypes Boris gave are: Prototyper, Builder, Sweeper, Grower, and Maintainer.

They describe modes of working; multiple archetypes can appear simultaneously under the same job title. In the Claude Code team, some designers behave like Prototypers, some like Sweepers, and the same goes for engineers, PMs, and data scientists[^five] — this is also the reason why most people within Anthropic share the single title of Member of Technical Staff.

Prototyper: 'I have an idea'

A Prototyper is someone who can produce a large number of entirely new ideas. Most ideas will naturally die out, and that's fine.

Boris has a public judgment: coding is already a solved problem[^lenny]. If coding is already solved, then a person who, with the help of AI, can turn a vague thought into something that can be touched, clicked, and played with directly within a few hours or a day — that person is a Prototyper.

Suppose you have a week to make 7 prototypes, throw away 6 of them, and hand the remaining one to the Builder in the next stage to quickly land as a product — that is the Prototyper's work rhythm.

Builder: 'Build it'

The Builder takes over prototypes and ideas and truly lands them in a production environment as something that can run.

Programmers seem naturally suited to be Builders, but the truly critical quality is the ability to land — a product only truly enters the loop once it reaches the production environment and gets data feedback.

A Builder's work can also start from a non-zero starting point. Suppose a designer uses AI to generate an entire design language and successfully gets it into a production environment within some codebase — at that moment, she is a Builder. The key point is that a Builder is someone who can get things running, which usually requires some engineering intuition.

Sweeper: 'Make it better'

According to Boris's own disclosure, so far this year he has added 400,000 lines of code and deleted another 250,000 lines. A significant portion of those 250,000 deleted lines was just clearing out useless things — and this corresponds exactly to the third archetype: the Sweeper.

Sweepers continuously clean up and simplify systems. In Boris's original words, their work includes cleaning up UI, simplifying code and systems, un-shipping features, and optimizing performance[^five]. Taking useless systems offline and making products and platforms cleaner requires a strong product sense and engineering taste.

Grower: 'Let it grow'

Growth is still growth in the traditional sense. The Grower takes over an already-built product, iterates continuously, and raises the Product-Market Fit (PMF).

What are they doing? New requirements, new experiments, new ad placements, looking at data, adjusting conversions, running A/B tests, finding the thing that truly impacts user metrics.

If the Builder is responsible for getting something live, the Grower is the one who truly puts the product into the 'hypothesis → validation → adjustment' data loop and makes it run faster and faster.

Maintainer: 'Let it run steadily'

Finally, the Maintainer. They are an expert group, with solid theoretical knowledge and practical operational experience, guarding mature systems to make them expand safely, reliably, and efficiently.

AI can help Maintainers locate problems faster, but areas like system boundaries, data risks, architectural trade-offs, and business correctness still require senior engineers to backstop — they are the people who know a particular system best. And the intuition to judge 'what must not be touched' is something that, at least for now, AI does not have.

Team formation: staffing by product stage

Boris didn't just give role archetypes; he also gave a way of thinking about team configuration. He divided products into three stages based on their maturity in the market[^five]:

The pattern is: Sweepers are a rigid necessity from day one of the product, while Maintainers join on the path to product maturity.

The difference from 'Full-Stack Engineer'

Boris also mentioned that the mapping between a specific person and a role archetype is dynamic — a person's capability model changes with phases, interests, and project needs.

What's easy to confuse here is: what exactly is the difference between these cross-functional role archetypes and a Full-Stack Engineer?

The entry points of the two are different. This goes back to Boris's judgment — coding is already a solved problem. He believes that engineers spend a large amount of time outside of coding: communicating with customers, colliding ideas with product and design, making technical decisions, planning tasks, observing data, writing documentation, and preparing for Iteration 0[^lenny]. These upstream and downstream chores of coding are difficult for current programming agents to take over directly.

Boris's role archetypes are a capability model that starts from a product perspective, about 'how to create and operate a product.' The classic Full-Stack Engineer is technology-stack-oriented: understanding how to design beautiful pages, create APIs, understand database structures, and know how to deploy at scale and operate data — focusing on end-to-end delivery capability.

One answers 'with what posture to create value,' the other answers 'with what technology stack to deliver value.' These are two independent dimensions of the problem.

Back to the beginning: how much shelf life does a position have left?

Circling back to the initial question.

My conclusion is: The real problem AI-native teams must face is the rearrangement of division-of-labor patterns — from cutting by function to staffing by archetype.

First, when AI enters a team, what changes first is efficiency; deeper down, it's the division-of-labor patterns between people and between people and AI.

Second, archetypes were never tied to functions in the first place. The same archetype can be exhibited whether you are a designer, engineer, or PM. The stories often heard online about PMs getting their hands dirty and modifying code are a flip side of this — once a PM gets hands-on and succeeds, they become a Prototyper, or even a Builder.

Job title labels still influence positioning on the field. In my own years doing frontend, my title alone has changed several rounds — H5 Frontend, Web Frontend, Frontend Engineer — reflecting how different companies' understanding of the function is changing. But the descriptive power of a fixed label like 'Web Frontend' is disintegrating: it can neither measure a person's real influence within an organization nor keep up with their dynamically changing role.

So, which role are you?

From Boris's perspective, a healthy team doesn't need everyone to be all-rounders, but rather to staff the archetypes according to the product stage — just like a good football team doesn't need eleven Messis.

It's worth observing yourself and the colleagues around you: what kind of posture do people adopt when doing things? Perhaps you'll find that in a certain moment, you are polishing an idea to the point of landing, your eyes lighting up — that might be your dominant archetype emerging.

Following this line of thought, the commonly anxiety-inducing question 'Will I be replaced by AI?' can also be reframed:

Which role are you, and which role do you want to become? This concerns the way you create value.

[^infoq]: Frontend and Backend Disappearing Together: AI Coding is Rewriting the Division of Labor for Big Tech Engineers: InfoQ, Chu Xingjuan, 2026-07-01, reporting on the organizational adjustments of Meituan Keemart's frontend-backend merger and Ant Webank's testing-to-R&D role transition [^river]: Under the River: Shopify Engineering Official Blog, 2026, disclosing River's working mechanism and the data point that '1 out of every 8 merged PRs is completed in collaboration with it' [^five]: Boris Cherny's original X post on the five role archetypes: Published at the end of June 2026, proposing the five archetypes of Prototyper / Builder / Sweeper / Grower / Maintainer and the idea of configuring teams by product stage [^lenny]: Head of Claude Code: What happens after coding is solved: Lenny's Podcast interview with Boris Cherny, discussing the judgment that 'coding is solved' and the real allocation of engineers' time