Becoming an AI-Era PM 02 | Why Not Knowing How to Code Is an Edge
Start with something built by a person who can’t write code.
Marcus Rush runs a residential real estate brokerage, and he isn’t a programmer. Using Claude and Zapier, he put together an AI agent called Russ: every morning it scores leads from more than 11,000 contacts, writes a day’s follow-up plan for each agent on his team, and handles his calendar on the side. A brokerage owner built an internal system that runs daily operations, without writing a single line of code by hand.
This isn’t a one-off. One 2026 tally found that 63% of vibe coding’s active users aren’t developers. A designer with no programming background shipped his own product using Replit and AI, and got to $20K a month — more than double his old salary.
Put these together and a counterintuitive thing comes out: on the road from idea to a thing that actually runs, people without a technical background sometimes move faster than engineers.
Engineers have to shed something first
People have watched how senior engineers work with AI. They’re used to picking at every implementation detail, pushing back with “why not X” and “did you consider Y,” while the model’s default reaction is “sure, I’ll add that.” The instinct, twenty years in the making, to be responsible for every line of code — that’s the thing they have to put down first when they collaborate with AI.
This is hard for them. What they have to let go of is the conviction that “every line has to be written by my own hand and reviewed by my own eyes.” In the METR experiment, 16 senior programmers used AI on projects they’d maintained for years, and were actually 19% slower, while believing they’d gone 20% faster. The more fluent you are, the easier it is to work against the tool.
Non-technical people don’t carry this baggage. They have nothing to shed.
”This is too hard” — a non-technical person can’t say it
Part of a product manager’s judgment used to come from “how hard is this feature to build.” That knowledge has a side effect: the more clearly you see how much has to change behind an idea and how many pitfalls lie in the way, the more likely you are to kill it before you ever bring it up. The people who know the most self-censor the hardest.
Non-technical people don’t set up that hurdle for themselves. They don’t know it’s hard, so they spell out what they want first and let AI take on the implementation-difficulty part. This is exactly what doaipm means by speak it and AI builds it (言出法随): say it clearly, and AI builds it for you. Marcus didn’t know how hard it “should” be to write scoring logic across 11,000 contacts — he only knew what he wanted, and he said it.
The scarce thing is stating the idea clearly, not writing the code
Russ runs not because Marcus can write Python, but because he knows the business: what leads get scored on, which items belong in a follow-up plan, which contacts go to the front. These are judgments, not technology.
AI won’t infer from omission. If you don’t spell it out, it’ll hand you a default version, and most of the time it isn’t what you wanted. Whoever can lay out the rules, the boundaries, and the states produces work an order of magnitude better than everyone else’s. That ability has nothing to do with whether you can program. One of a16z’s pieces of advice for product managers: the pure process manager gets phased out; the person with a “builder mindset” is the one with leverage. A builder mindset means being willing to make the idea yourself and take it out to validate — whether you can write code isn’t part of it.
The edge isn’t free
Not being technical doesn’t mean you need to understand nothing. The Zapier that Marcus used and the Replit that designer used both sit on top of a craft you have to get fluent in: how to break a requirement into small steps AI can catch in one bite, how to judge whether what it gives back is right, where to stop and let a real person take over.
The thing non-technical people miss most easily is the safety net. Don’t put real customer data in a prototype; the buttons you can’t take back — publish, delete, pay — leave those for a person to press. Marcus’s Russ “writes” follow-up plans for the agents, but it doesn’t “send” them out for anyone — that click still belongs to a person.
One thing you can do today: pick a small idea you’ve always assumed “needs an engineer,” don’t ask first whether it’s hard, write out what you want line by line, and hand it to AI to build a first version. See how far it gets before you make the call.
Further reading
- Zapier, “Vibe coding examples: Real projects from non-developers” (Marcus Rush / Rush Home case): https://zapier.com/blog/vibe-coding-examples/
- a16z, “5 Principles for PMs in the AI Era” (builder mindset vs process manager): https://a16z.com/stay-relevant-in-ai/
- Piece 01 in this series, “Which PM Tasks AI Took Over, and Which Ones Got More Valuable”: /en/blog/ai-pm-what-changed/
Discussion