The popular narrative goes like this: AI coding is here, the boundary between frontend and backend will dissolve, and everyone will become a full-stack engineer. That story is half right. The boundary is genuinely dissolving. But the destination is not “everyone can do everything” — full-stack is a fine concept, yet being able to do everything is not the same as everything being worth doing. When Meituan’s CLC team formally merged its frontend and backend organizations, and when Boris Cherny, creator of Claude Code, mapped five new role archetypes for his own team, both were pointing at the same thing: AI coding is not just changing how developers write code. It is changing how engineering teams get organized.
This article is not about whether engineers should learn full-stack — that is short-term survival anxiety. The question worth attention is: when AI covers most of the code-execution layer, what logic should teams use to organize people?
Full-Stack Isn’t the Answer, but the End-to-End Loop Is
Meituan’s CLC grocery-retail engineering team (Keemart) completed a structural adjustment: frontend and backend teams formally merged, with frontend staff starting backend training more than a month in advance. In the same period, Ant’s Wangshang Bank pushed its testing roles wholesale into development roles with a six-month transition buffer.
Read superficially, the conclusion looks cynical: companies want cheaper people — one engineer covering both ends beats two specialists on budget. But that explanation collapses on contact with facts. If cost were the goal, outsourcing is cheaper. If layoffs were the goal, a month of cross-training would be pointless. The real driver is structural: when one developer with AI tools can independently complete the full chain from frontend through backend to deployment, the team’s organizational unit shifts from the tech stack to the delivery loop.
Why did engineering organizations split into frontend, backend, and QA in the first place? Because one person could not span the whole pipeline. AI coding tools are removing exactly that constraint. OpenAI’s latest Codex numbers make the trajectory explicit: in the first half of 2026, weekly active users grew more than fivefold, and the share of individual users shipping submissions representing more than eight hours of human work grew nearly tenfold since the start of the year. AI coding is migrating from helping humans complete code to taking tasks off human hands. Once one engineer plus AI covers requirements analysis, implementation, integration, testing, and deployment, the frontend/backend split becomes pure organizational friction — it protects historically formed job boundaries, not delivery efficiency.
So when ByteDance posts an “AI full-stack engineer — video and edge” role under its frontend job family, with responsibilities spanning agent orchestration, multi-platform SDKs, audio-video internals, and cloud platforms, the JD is not sloppy. The organization is emitting a signal: the era of building teams around tech stacks is ending.
Boris Cherny’s Five Archetypes: A Replacement for Stack-Based Divisions
Boris Cherny shared observations from his own team on X: engineering, product, design, and data science are fusing into a new shape of role. Inside the Claude Code team, what he sees is not traditional functional division but five archetypes:
1. The Prototyper — generates genuinely new ideas, rapidly produces volumes of creative output, most of which never ships.
2. The Builder — converts a prototype or idea into production-grade product or infrastructure, fast.
3. The Sweeper — polishes UI, simplifies code and systems, retires unnecessary features, optimizes performance.
4. The Grower — after the product exists, keeps iterating to deepen product-market fit.
5. The Maintainer — runs mature systems for the long haul, keeping them safe, reliable, and efficient as they scale.
The framework’s elegance is what it refuses to do: it does not classify people by which stack they use; it classifies them by what kind of problem they solve — which is precisely the most rational organizing principle for the AI era. In traditional organizations, roles are pinned to stacks: a frontend engineer does not touch backend logic, a backend engineer does not touch frontend experience. With AI leverage, one person spans multiple roles — and Cherny’s team confirms it: members routinely cover two or three archetypes without strict functional binding. A designer may be the prototyper; an engineer may be the sweeper.
More valuable still is the dynamic view of team composition — the mix a product needs changes completely by stage: a new project without product-market fit needs more Prototypers plus Builders plus Sweepers (1+2+3); a growth-stage product that has found PMF needs Builders plus Sweepers plus Growers with a few Maintainers (2+3+4, light on 5); a mature product with strong PMF needs Sweepers plus Growers plus Maintainers with a few Builders (3+4+5, light on 2). This is not a theory paper. It is the configuration logic the Claude Code team runs on.
Several Signals, One Direction
Line up the big-company job postings and the shared pattern becomes obvious. ByteDance’s Commercial AI team advertises a senior frontend role whose scope covers digital humans, AIGC voiceover, video generation, and agent creative tooling productization — that is not frontend; that is an AI product engineering role. Alibaba’s Taotian group posts an AI agent application developer to build LLM-powered price-comparison decision tools for e-commerce, orchestrating multi-domain agents to lift the whole operations chain — the role demands server-side engineering, the LLM application stack, and the ability to weave models, tools, knowledge, and business systems together. Tencent’s frontend posting describes work on “an agent-oriented system of sandboxes, data, debugging, and visualization web products” — from building pages to building agent engineering platforms. Stripe’s latest full-stack opening declines to split frontend from backend at all, asking for design, construction, and maintenance of “user-visible experiences, services, APIs, and systems,” direct collaboration with early-stage founders, and cross-service production debugging.
Together they draw one clear line: major companies are no longer hiring “people who write code better.” They are hiring people who turn models into products, agents into systems, and AI capability into real business loops. Whether you came up through frontend or backend has stopped mattering.
The Framework Travels: Five Roles Beyond Engineering
Cherny’s model was born in an engineering team, but its explanatory reach is wider. Consider a marketing team: it needs idea generators (Prototypers), campaign executors (Builders), channel optimizers (Sweepers), ROI amplifiers (Growers), and people who keep existing channels and brand assets running stably (Maintainers). Consider a product team: an early product hunting for direction is starved for Prototypers and Builders; a mature product defending its market is starved for Sweepers and Growers. Consider any team you know, then ask the only question that matters when you can hire exactly one person: do you want a specialist in a particular stack, or someone who solves the most critical problem of your product’s current stage?
The framework generalizes because it was never about skills — it is about responsibility. And that is exactly what AI is doing to organizations: automating the skill-execution layer until responsibility becomes the only axis along which people are measured.
Three Concrete Moves
If you are an engineer: retire the question “should I learn frontend or backend” — it has already expired. Observe the stage your product is in and identify your natural archetype. You do not have to become omnivalent; Cherny’s team still has pure Builders and pure Maintainers. The point is not covering every role but knowing where your leverage is highest — and being legible to your team as that role.
If you lead a team: stop designing headcount by tech stack. Diagnose the product’s stage first, then hire to the role mix that stage demands. A growth-stage product with PMF needs more Builders and Growers, not a world-class security specialist. The discipline that matters is keeping your team’s role ratio aligned with the product’s actual stage.
If you are a founder: audit your current team against the five-archetype map. The most common early-stage pathology is too many Prototypers — the ideas are great and nobody converts them into deliverables. Cherny’s first iron rule: a product without PMF needs the 1+2+3 mix, and most founding teams have only the 1.
AI coding will not eliminate engineers. It will eliminate the practice of defining engineers by stack boundaries. Cherny’s five archetypes offer a replacement you can apply this week — and the Meituans of the world have already started moving.
Sources: InfoQ; Business Insider’s reporting on Boris Cherny; Cherny’s original posts on X; OpenAI Codex research data; official job postings from ByteDance, Alibaba, Tencent, and Stripe.
