AI-Native Methodology

The Builder Role Is Real. The Solo Part Is the Trap.

Bill Cava/

There's a prediction worth taking seriously, and it comes from someone worth listening to. Marc Andreessen, who co-wrote one of the first widely used web browsers and is now one of Silicon Valley's most influential startup investors, laid it out in an Instagram Reel that's been making the rounds: the three historically separate jobs of software, programmer, product manager, designer, are collapsing into a single role. The framing is a three-way standoff: each role has realized it no longer needs the other two, because AI now lets any of them generate the code, write the spec, and do the design. The conclusion lands clean. They're all right, the job has changed, and the new job is "builder." You get on the builder track from any of the old roles, or from customer service, or from anywhere. In ten or twenty years, the prediction goes, "coder" as a standalone job is mostly gone, replaced by an enormous number of builders shipping complete products, each one super-empowered by AI filling in everything outside their background.

Marc Andreessen in a video clip beside an on-screen transcript stating that software's three separate jobs (programmer, product manager, designer) are collapsing, because each role thinks AI now lets it do the other two.
Andreessen's case, in his words. He's right that the three jobs are merging. The trap is the solo builder the prediction quietly assumes.

I think that's mostly right. I also think the picture quietly underneath it is the trap.

Are the three software jobs really merging?

Yes, and it's worth saying so plainly before complicating it. When the person closest to the problem is no longer blocked by a technical barrier, the old division of labor stops making sense. A domain expert with AI can prototype. A designer can ship working software. A product manager can build the thing instead of writing a ticket about it. The on-ramp really does come from any direction, and the "builder" really is a single role where three used to stand.

We've been arguing a version of this for a while. It's the same shift behind ideas being the new bottleneck: once execution stops being the constraint, the lines drawn around who executes what stop mattering. So this isn't a prediction we want to fight. It's one we've been making.

But notice the assumption riding along with it: that the builder is a solo act. One person, one AI, a complete product. That image is where it goes wrong, and it goes wrong for a structural reason, not a sentimental one.

So why is the solo builder a trap? No domain expert in the room.

Because "solo" is the wrong unit. A builder working alone, however good, is building apart from the two things that decide whether a product is worth building: the person who knows the problem cold, and the user it's for.

The usual fixes both miss. A better builder who finally does all three jobs is still a soloist. Adding review gates is just a slower way to find out you built the wrong thing. What good looks like is a builder and a domain expert in the work together, pointed at the user and the real problem from day one. Not a stakeholder who reviews the output, but someone in the work, shaping what gets built while the builder makes it real. That is co-creation: building together, not apart.

Without it, you ship something polished that solves a problem nobody has, because no one who lived the problem was ever in the room. The craft is real. The aim is wrong. AI amplifies your direction, right or wrong, so a wrong aim ships faster, not wiser. That's the real ceiling on the solo builder. Not that one person can't do enough, one person can do an astonishing amount now, but that a builder working apart from the problem is amplifying a single point of view.

So who does the builder build with?

The answer was never "no one, they do it all now." The perspectives the work needs were always going to come from more than one person. Merging the job titles doesn't change that. It just changes where you go to get them.

What good looks like is a builder and a domain expert in the work together, the person closest to the problem shaping what gets built while the builder makes it real, both anchored to the user. That is Human and Agentic Collaboration, and it draws on two sources. Other humans: the partner who knows the market, the operator who has lived the problem, the person closest to the problem. And AI agents treated as collaborators you interrogate, not delegates you accept.

This is why the builder role is the strongest argument for co-creation, not against it. The convergence doesn't remove the need to build with people who know the problem. It removes the excuse, because you can no longer tell yourself that's some other team's job.

What does a builder's job actually become?

Not "do all three jobs." Build the right thing, with the people closest to the problem and with agents, aimed at a real user. The builder's value was never holding every discipline in one head. It's judgment: knowing what to build, who to build it with, and whether the thing in front of them solves the actual problem or just looks like it does.

The seductive version of the builder is one person who no longer needs anyone. The durable version is a person whose reach now spans all three domains and who deliberately builds with the people and agents who keep the work honest about the problem and the user. The first hits a wall fast. The second is what ships products people actually want.

The builder is real. The solo builder is the ceiling. The collaboration is the part you have to choose.

Which builders win?

The prediction is probably right that in ten or twenty years "coder" as a standalone job is largely gone, replaced by a huge population of builders shipping complete products. The question it doesn't ask is which builders win. Here's the bet: not the lone operators who mistook "I can do all three jobs" for "I can build it alone." The builders who win treat the convergence as a reason to build with the people closest to the problem, not a license to work apart from them. The proximity an org chart used to enforce now has to be chosen.

Ideas are the new bottleneck, not execution. Judgment is the new scarce skill, not typing. The builder role makes both more true. When anyone can generate the code, the spec, and the design, the differentiator stops being which of the three jobs you trained in. It becomes how good your aim is, and how honestly you let people and agents challenge it.

The builder is real. The solo part is the trap. The collaboration is the part you have to choose.

Frequently asked

Are the three software jobs really merging into one?
Largely, yes. When AI lets any one person generate the code, write the spec, and produce the design, the old division of labor between programmer, product manager, and designer stops being a hard boundary.
Largely, yes. When AI lets any one person generate the code, write the spec, and produce the design, the old division of labor between programmer, product manager, and designer stops being a hard boundary. The job is converging into a single 'builder' role, and you can reach it from any of the old roles. That part of the prediction is right.
Can one person build a whole product with AI now?
They can produce one. Whether it's the right one is the question.
They can produce one. Whether it's the right one is the question. Building solo means building apart from the person who knows the problem and the user it's for, and that is what decides whether a product is any good. The answer isn't a better soloist, and it isn't a review gate bolted on after. It's a builder co-creating with a domain expert, aimed at the real problem from the start.
Why does building solo with AI hit a ceiling?
Because AI amplifies your direction, right or wrong, and a solo builder is aiming alone.
Because AI amplifies your direction, right or wrong, and a solo builder is aiming alone. The failure mode of a one-person product is something polished that solves the wrong problem, because no one who lives the problem was in the work. The ceiling isn't capability. It's distance from the problem and the user.
What does a builder's job actually become?
Building the right thing with the people closest to the problem and with AI agents, aimed at a real user.
Building the right thing with the people closest to the problem and with AI agents, aimed at a real user. Not personally holding every discipline, and not approving work behind a gate. The builder's value is judgment: knowing what to build, who to build it with, and whether the thing in front of them solves the actual problem or just looks like it does.
Subscribe

Considered takes, in your inbox.

We write when we learn something worth sharing. No schedule, no marketing digests. Built for engineers and product owners shipping with agents.

~1 email/wk · Unsubscribe anytime