For twenty years, building software was the expensive part. That’s over. The scarce skill now isn’t writing code. It’s understanding what you’re building well enough to ship it yourself.
Writing code used to be scarce and slow.So we built entire org charts around rationing it.
A manager to decide. A designer to spec. A queue of engineers to implement. Handoffs everywhere, because the bottleneck was always the typing.
The bottleneck moved. Producing correct code got cheap, and the whole relay race stopped making sense. When one person can go from idea to production, implementation stops being the expensive skill. Judgement takes its place: knowing which thing is worth building at all.
Code went from scarce to abundant. The differentiating asset is no longer code, but data and judgement. Pointing in the wrong direction just got more expensive.
A model, a conversational interface, live connections to real systems (MCP), reusable skills, and explicit memory. The whole dev stack, hidden behind a conversation.
What turns individual capability into controlled shipping: version control, governed data access, execution infrastructure, guardrails and observability.
How a team works together when anyone can ship in hours: deciding at the speed of execution, and turning individual learning into collective capital.
What stays irreducibly human: product taste, deep empathy, deciding under uncertainty, and narrative leadership.
All useful. All abstract. None of it answers the question that actually decides whether someone is a Product Builder or just describing one.
There’s a comfortable version of this role going around: you bring the ideas and the taste, and AI handles the messy technical parts. I don’t buy it. You don’t need to be a systems architect, but there’s a floor, and it’s more practical than people think. Call it being your own system engineer.
If the answer is no, you’re not building. You’re commissioning, and hoping. When something breaks in production, the person who understands the system fixes it in an hour. The person who doesn’t files a ticket and waits, which is exactly the handoff the Product Builder was supposed to remove.
Provisioning a server, wiring up a database, setting the security defaults: that’s repetitive, well-defined work, exactly what agents and MCP are about to absorb. Within a couple of years, the manual part of being your own system engineer gets automated. You’ll describe what you want and the system will stand it up.
It’s tempting to read that as «so you won’t need to understand it anymore». That’s the trap. When the plumbing is free, the understanding becomes the entire job. An agent can spin up infrastructure in seconds. It cannot tell you whether that architecture is right, where it will buckle under real load, or which trade-off you’ll regret in six months. It builds what you ask for. Knowing what to ask for is the part that stays with you.
An autonomous travel blog that publishes every day. The AI writes the articles, generates the images, and reviews its own code. I have not read a single line of that code, but I know exactly how it’s deployed, where it can fail, and how it recovers. That’s not a contradiction. That’s the whole point.
You can delegate the building.
You cannot delegate the understanding.
If your organisation is thinking about what this role means in practice, and how to build around it, let’s talk.
Get in touch