The Five Roles Replacing ‘Engineer’ and ‘Designer’ on AI-Native Teams.

Your job title was a label for the part of the work you did with your hands. “Engineer” meant you wrote the code. “Designer” meant you pushed the pixels. “PM” meant you wrote the spec and ran the meeting. As AI absorbs more of that hands-on execution every month, the title keeps pointing at the part that’s getting cheap — and stops describing what you actually contribute.

What’s left when the execution moves to the machine is a role: not your function, but the kind of motion you bring to a product. There are roughly five of them — prototyper, builder, sweeper, grower, maintainer — and the most useful thing you can do for your career right now is figure out which one or two you actually play, and point them at a team whose product is at the stage that needs them.

This is for you if you’re an engineer, designer, PM, or data scientist watching AI eat the task list your title was built on, and you’re wondering what you’re even selling now. If you’re a manager trying to staff a team, the back half of this is for you too. If you’re hunting for a tool recommendation or a prompt trick, this isn’t that piece.

The short version: stop optimizing the title on your profile. Name the role you already play, pick the one you want to grow into, and find a product at the stage that’s hungry for it. The match between your role and the product’s stage is the thing that’s actually worth something.

Your title named the execution — and the execution is what’s moving

For most of software’s history, your job title was a fair description of your day. The word told people what you’d be doing: writing code, drawing screens, running the roadmap, cleaning the data. The execution was the job, so the label for the execution was the title.

That link is what’s breaking. When a model can take a rough idea to a working draft, scaffold a service, redraw a layout, or clean a dataset on request, the hands-on half of each of those titles gets cheaper by the month. The title still sits on your badge, but it’s pointing at the part of the work that’s quietly leaving.

So the question shifts. Not “what’s your title?” but “what kind of motion do you bring to a product?” That’s a role — and roles outlive titles because they describe contribution, not task.

The five roles, named plainly

The cleanest version of this comes from Boris Cherny, the creator of Claude Code, reflecting on his own team. Watching engineering, product, design, and data science blur into something new, he noticed the people sorted into about five archetypes — not by their function, but by the kind of work they reach for. Read it as a sharp observation from inside one fast-moving team, not a law of nature, and it’s genuinely useful for placing yourself.

• Prototyper — comes up with brand-new ideas and churns out a lot of them, knowing most won’t ship. Their output is optionality: ten rough swings so the team can find the one worth building. Comfortable being wrong nine times.
• Builder — takes a prototype or an idea and turns it into a production-grade product fast. Their output is the real thing — the version that holds up under actual users, not the demo.
• Sweeper — simplifies the code and the system, cleans up the interface, removes features that shouldn’t be there, and makes everything faster. Their output is less: less surface, less weight, less drag. A sweeper unships as confidently as a builder ships.
• Grower — takes a product that’s already built and iterates on it toward product-market fit (the point where a product fits its market well enough that demand pulls it forward on its own). Their output is traction — the loop of measure, change, measure again.
• Maintainer — owns a mature system and keeps it secure, reliable, and fast as it scales. Their output is trust over time: the thing keeps working at ten times the load, and nobody has to think about it.

None of these is the “senior” one. None is the junior one. They’re different jobs, and a team that’s all builders ships a bloated mess; a team that’s all sweepers has nothing left to clean.

The roles aren’t tied to your job function

Here’s the part that reframes a career: these roles cut across job titles. A designer can be any of the five. So can an engineer, a PM, or a data scientist.

Take a designer. One designer is a prototyper — she’s happiest spinning up twelve wild directions for a feature that may never exist. Another with the same title is really a sweeper: her best work is walking into a cluttered product and taking things away — collapsing three confusing settings into one, killing the menu nobody clicks, making the screen quiet. Same word on the org chart, opposite contributions. If you put the sweeper on a pre-launch team that needs ten rough ideas a week, she’ll struggle and look like a weak designer — when really she’s a strong designer in the wrong role for that stage.

That’s why the role, not the title, is the real unit of what you do. “Designer” tells a team almost nothing about whether you’ll thrive on what they need next. “I’m a sweeper” tells them a lot.

You probably play two, not one — name them honestly

Most people aren’t a single role. You play two, sometimes three. The honest move is to name your real pair — and, just as telling, to notice the ones you quietly avoid.

A common combination is builder-plus-sweeper: you ship the real thing and you can’t leave a mess behind you. Another is prototyper-plus-builder: you generate the idea and you can carry it most of the way to production before you lose interest. Each pairing has a natural shape, and each has a blind spot — the prototyper-builder often dreads maintenance; the maintainer often freezes when asked to throw ten wild ideas at a wall.

Naming the role you avoid is worth as much as naming the one you’re good at. It tells you which teams will drain you, and which gap is your highest-value place to grow. If you’ve never once enjoyed deleting code or features, you’re probably not a sweeper — and a team that mostly needs sweeping will quietly grind you down no matter how good your title looks.

So write it down plainly. What two roles do I actually play? Which one do I reach for first? Which one do I dodge? That’s a more honest career inventory than any list of tools on your résumé.

Teams staff by product stage, not by title

The reason this matters beyond self-knowledge: healthy teams staff by what the product needs, and a product needs different roles at different stages. Cherny’s same observation maps the mix to the stage:

Read the table the other way and it becomes a career map. A prototyper is most valuable on a pre-launch team and most frustrated on a mature one, where the answer to “let’s try ten new things” is usually “please don’t.” A maintainer is essential on a system at scale and underused on a three-week-old prototype that might not survive the month. Your value is the match between your role and the stage — the same person is a star hire or a poor fit depending entirely on where the product is.

This is why a brilliant engineer can flame out after a great interview: the role they play didn’t match the stage the product was in. It’s rarely a talent problem. It’s a placement problem.

What to do with this

Stop polishing the title on your profile and do three things instead.

1. Name the role(s) you already play. Be honest — your real pair, not the impressive-sounding one. Notice which role you avoid; that’s data, not a flaw.
2. Pick the one you want to grow into. Usually the highest-value move is the role next to your pair — a builder learning to sweep, a grower learning to maintain — that widens the stages you can serve.
3. Aim at teams whose product stage needs your role. When you read a job post or size up a team, figure out the product’s stage first, then ask whether the role they need is the one you play. The match is the offer.

Your title is about to describe less of you every year. The role you play — and your honesty about which stage it fits — is the part that keeps you valuable while the execution moves to the machine.