"Builder" is the job title nobody applied for and everybody suddenly has.
A year ago it was a LinkedIn affectation. Now LinkedIn has quietly renamed its Associate Product Manager program to "Associate Product Builder," Meta's PMs are vibe-coding prototypes to show Zuckerberg, and in March the San Francisco Standard ran a piece, straight-faced, called "in AI land, everyone's a 'builder' now."
The trend is real. The way almost everyone explains it is wrong.
The popular version: AI got good enough that one person can do the job of a designer, a product manager, and a developer, so the three roles collapse into one. Idea to product in an afternoon. The handoff is dead. We're all generalists now.
That's half right, and the missing half is the one that matters. AI didn't merge the three jobs - it merged the three skill sets, and almost everyone writing about this trips on the gap.
Skills are converging. Roles aren't.
The capability to do all three is converging. Anyone with Claude Code, Lovable, or a Figma plugin can now produce a passable version of work that used to need a specialist. That part is true, and it's a big deal.
The value goes the other way. Userpilot is already splitting the product role into a "Builder PM" who ships prototypes and an "Integrator PM" who owns the messy human side, and reporting a pay gap of roughly $245K against $123K between the AI-native crowd and the generalists. That premium goes to people who are great at one craft and fluent enough in the other two to skip the handoff.
So picture a barbell.
One end is the floor, and it keeps rising. The grunt work of every discipline (pushing pixels in Figma, wiring a manual prototype, writing boilerplate, bolting on yet another feature) gets eaten by AI. Anyone can clear that bar now.
The other end is the ceiling, and it keeps getting more specialized. Taste, strategy, architecture, knowing what to build and what it will cost you in eighteen months. That work gets more valuable, because the easy half is now free.
The people in trouble are stuck in the middle. Good-but-not-great at one thing, no real range into the others. They are the ones who get squeezed.
A builder is a specialist who is fluent enough in the other two disciplines to move without waiting on a handoff. It describes what you can do, not a box on the org chart.
The "death of the PM" was always overblown
You can trace most of this discourse to Brian Chesky standing on a stage in 2023 announcing that Airbnb had killed the traditional product manager. The internet has been quoting the headline ever since.
What it skips is that Chesky didn't delete the role. He folded it into a product-marketing function, then later clarified that PMs are "critical, they just shouldn't be doing the job of a designer." The company that supposedly killed product management just moved it.
Nearly every "death of [role]" take is really re-specialization with a punchier headline. You'll see the move on LinkedIn every week from here on.
Three on-ramps, three blind spots
If the builder is a skill profile, there are three ways to grow into it, one from each original role. The on-ramps aren't the same length, and each one has its own way of quietly getting people hurt.
Whichever door you came in through, your native strength is also your blind spot. Becoming a builder is mostly the work of covering it, and knowing the exact point where you stop faking it with AI and hand off to someone who has the craft.
The designer who learned to ship
The designer's superpower was never moving rectangles around. It was taste and systems thinking. Knowing why a layout breathes, where the eye goes, when to invent and when to shut up and use the component library.
AI is genuinely good at the rectangles now. It'll hand you a clean UI that's 90% there and doesn't look like slop. What it won't hand you is the last 10%, the part that makes a brand feel like itself instead of like a template. a16z is confident enough that this layer survives that it launched a "Design Engineer" fellowship built on the premise of thinking in systems, not screens.
With Figma's MCP, tools like Paper, and a few Claude skills, a designer can take an AI-generated starting point and spend their hours on the one thing only they can do, which is making it singular, instead of nudging padding for three days. (I wrote a longer piece on where AI leaves graphic design, if you want it.)
The designer's blind spot is architecture. Someone who can suddenly "build" will happily ship something that looks immaculate and is a maintenance grenade underneath. Looking right and being right are not the same thing.
The product manager who learned to build
Let me make this one concrete, because I know the right example.
Bryce Lokken is a product lead, the user-interviews-and-strategy kind, with real time in startups and big organizations. At some point he saw where this was going and stopped waiting. Instead of conceptualizing a feature, briefing a designer, waiting weeks for comps, briefing a developer, and waiting months for a working prototype, he started building the prototype himself in Lovable.
Now when he works with a founder, nobody's squinting at a static Figma flow trying to picture it. They're clicking around a real, interactive, non-database version of the thing within days. They get their hands on it, the feedback gets sharper, and the concept gets refined before a line of production code exists. When it's ready for a real developer, he hands over not just a clickable prototype but an open, vibe-coded starting point they can read for intent.
He's using building as a sharper way to think and communicate, not as a way to ship. That prototype is not going to production, and keeping it that way is the discipline most people skip.
His blind spot, like every PM's, is maintainability. The best sentence I found in the research came from a solo founder: "AI executes. It doesn't decide." PMs are brilliant at deciding. The risk is mistaking a thing that runs for a thing that's built. Strategy matters more now for a less obvious reason, too. When anyone can add a feature in an afternoon, the teams without real product judgment don't build less. They build more garbage, faster, until the product is an unusable junk drawer. Shipping features was never the PM's real job. Killing the ones that shouldn't exist is, and that job got harder and more important at the same time.
The developer who learned to think in product
Here's the unpopular part, said plainly. If your value is writing code and following instructions, this is the worst stretch in years to be a developer. If you're the one planning the system, it's the best.
AI replaces the grunt-coder. It makes the senior who designs the system more valuable, because someone still has to decide how the thing gets built, and that call compounds for years.
My favorite example is boring and expensive: single-tenant versus multi-tenant. Build a SaaS app single-tenant because it's faster this week, then try to bolt multi-tenancy on when your first enterprise client shows up, and you're in for a genuine nightmare. A schema rewrite, a migration, and a QA cycle that eats months. Plan for it at the start and switch it on when you need it, and it's a Tuesday. Same feature, wildly different futures, and the only variable is whether a senior was thinking past the demo.
This is also where the "10x faster" story hits reality, and the receipts are ugly.
A METR randomized trial last year put experienced developers on codebases they knew well and found they were 19% slower with AI tools, while believing they'd gone 20% faster. GitClear, across 211 million changed lines, watched copy-pasted code climb from 8.3% to 12.3% as AI took the keyboard, with real refactoring falling off a cliff. Veracode ran AI-generated code through security tests and 45% of it failed. Google's own DORA report tied every jump in AI adoption to a measurable drop in delivery stability.
And if you want the horror-movie version: a coding agent at Replit deleted a live production database during a stated code freeze, then fabricated thousands of fake records and lied about whether recovery was possible. The cause wasn't a malicious AI. Nobody senior had separated dev from prod.
None of this means AI coding is bad. I use it every day. It means the value moved off the typing and onto the deciding. Generating code is cheap now. Shaping the system, and spotting the 2am-pager landmines before they get buried, is the expensive part. The developer's own blind spot is the mirror image of everyone else's: they'll happily build the wrong thing beautifully, because discovery, actually asking who this is for and what they need, was never the instinct.
The real dividend: everyone finally speaks the same language
This is the optimistic core, and the part I'm most sure about.
The best teams still have a designer, a product manager, and a developer. What changed is that they now share enough vocabulary and enough tooling that the handoffs between them stop being a tax.
Picture the clean version. A product manager hands off a working, clickable prototype instead of a doc. The designer takes the auto-generated files, makes them singular, and passes along real flows with starting code already attached. The developer steps in and does what only they should: structuring the components into a tight library with proper variants, getting the page speed and the GEO right, wiring up the content pipelines so the client can actually maintain the thing. Same three people, far less friction.
There's a second win underneath that one. All the manual grind we just automated wasn't free before. It was eating the hours that should have gone to thinking. The designer racing comps to a deadline never had time to make it singular. The developer cranking boilerplate never had time to plan the schema properly. Hand the floor work to the machine and you give every specialist back the thing the work actually needed, which is time to consider and refine. For anyone good at their craft, this is the most leverage they've had in a decade.
The part I don't have an answer for
I've been upbeat this whole time. This is the part that worries me.
This is a great time to be a senior and a brutal time to be a junior, and I don't think that gap closes on its own. It's a real problem, and I don't have a solution to it.
The whole argument above rests on judgment. Taste, strategy, architecture, knowing where the bodies are buried. You can't prompt your way to any of it. You learn good design by shipping a pile of bad design first. Schema architecture earns your respect the day one buckles under you mid-launch. And you find out where the button goes by watching real users miss it, never by guessing.
That grunt work, the execution rung, is the exact rung AI now stands on. A senior dictates to Claude Code or Codex or Antigravity, reviews their own PRs, and the work that used to go to a junior to cut their teeth on just doesn't. The ladder is being pulled up by the people who already climbed it. The early data backs it up: Stanford's Digital Economy Lab found a 13% relative drop in employment for workers aged 22 to 25 in the most AI-exposed jobs, while older workers in the same fields held steady or gained.
A junior can still walk in with gumption and outwork the room, and some will. But "show up hungry" is not a structural answer to "the rung you'd have climbed has been automated," and I'm suspicious of anyone selling you one. We're quietly optimizing away the apprenticeship that produces the very seniors this whole model depends on, and I haven't seen anyone, not the labs, not the companies running the layoffs, offer a real fix. I can't either. I'd rather look at it straight than pretend the market sorts it out on its own.
So what do you actually do about it
Enough diagnosis. If you're in one of these roles, four things.
Pick one craft and go deep on it. The barbell rewards depth at the top, and your one real discipline is the anchor. Spreading yourself thin across all three is the trap, not the goal.
Earn enough fluency in the other two to collaborate without a handoff, and no more than that. For a designer, that's enough architecture to know what's expensive to build. For a PM, it's enough building to prototype your own ideas and enough engineering sense to know when a prototype is a landmine. For a developer, it's enough discovery to ask who this is for before you build it perfectly.
Learn your blind spot and your handoff line cold. Your native instinct is the thing that'll quietly sink you, and a real builder knows the precise point where they stop faking it with AI and bring in the person who has the craft. Build something to communicate an idea and that's real leverage. Ship that same thing to production without the craft and you'll delete the database in week one.
Be in the room. The orchestrator at the top of all this didn't get there from a job title. They got there by understanding enough of everyone else's work to be useful in every conversation, and by being present and fluent when somebody needed a little more than their title strictly covered.
There's no new species here. Good practitioners always ended up like this, deep in one thing and conversant in the rest. AI just made getting there a lot cheaper. Standing still is what got expensive.
So go get fluent in the other two. And don't let anyone tell you the craft stopped mattering, because it's the part no model can hand you.
