The pitch lands as a threat dressed up as liberation. A non-technical product manager opens Claude Code, points it at a repo, describes a feature in plain English, and ships it to production — no engineer in the loop. The framing that travels with these demos is "building products without engineers," and if you write software for a living it reads like the first slide of your own redundancy deck. The natural defensive move is to keep PMs out of the repo. Guard the gate. Make the codebase the one room where the non-technical can't break anything.
That instinct is wrong, and it's wrong in a way that costs the engineers who follow it the most. PMs in the repo isn't a threat to engineering. It's a promotion — for the engineers smart enough to see what the job becomes.
The repo work is product work
Start with what's really on the screen in these demos, because "without engineers" oversells it badly. Watch Rekhi work and you don't see a PM writing a lock-free data structure. You see a PM running a skill that critiques a product strategy against his own written standards for what good looks like. You see one that drives a browser across competitor pricing pages and assembles an accurate teardown. You see customer interviews transcribed and synthesized against a template, and a release note generated from a commit the PM was too lazy to describe well. This is product work. It always was product work. The only thing that changed is the room it happens in — it now happens close enough to the artifact to touch it.
That's the part the threat-framing misses. The repo was never where engineering value lived; it was where product intent went to wait in a queue. A PM committing a strategy critique or a release note isn't doing your job badly. They're doing their job in a place where it finally produces something instead of a Jira ticket. Rekhi's own bar for shipping is telling: "is it good enough to put my name on it?" He says he built two or three dozen skills and threw most of them away because the output was junk. That is not the posture of someone trying to replace engineers. It's the posture of someone who just discovered how hard the standard is.
The slop is real — and it's the engineer's opening
Here's where the engineers defending the gate misread their own position. The genuine risk in all of this is slop: a non-technical contributor, armed with a confident model, generating plausible code that's subtly wrong, over-complex, or unsafe. The fear is legitimate. But look at how the practitioners themselves answer it, because they hand you the argument.
Albuquerque, who is not technical, is blunt about it. The thing that makes a non-technical commit to a production repo acceptable is not the committer's skill. It's the gate the code has to pass through on the way in — the checks, the review, the infra and security discipline that catch the slop before users do. He reaches for the exact analogy that should reassure you: a non-technical PM with an AI is a junior engineer fresh out of school, and every org already knows how to absorb one of those. A senior engineer reviews the work, sets the guardrails, and owns the standard that keeps production safe. "It doesn't matter if that person is not technical anymore," he says, "because the infra or security person is doing a great job at protecting the repository."
Read that again as an engineer. The non-technical contributor is the junior. You are the senior. The work that gates them — the CI, the verification, the architecture they have to conform to, the standard they get measured against — is the highest-leverage work in the building, and it's yours. Keeping PMs out of the repo doesn't protect that work. It prevents you from ever being asked to do it.
Fix the machine, not the feature
The most important idea in either of these demos isn't a tool. It's a discipline Albuquerque states almost in passing: when a build comes out wrong, don't fix the feature — fix the machine that produced it. Change the agent, the skill, the rules the model works under, then re-run the pipeline. He claims AI-native teams spend roughly half their time improving that machine rather than tweaking individual features.
Sit with what that means for who's valuable. If half the work is building and maintaining the system that turns product intent into safe, shipped code — the agents, the skills, the acceptance checks, the verification harness — then the scarce, durable, compounding job is engineering the machine, not hand-crafting each feature. That is engineering in its most leveraged form. The PM in the repo is the user of that machine. The engineer who builds and owns it sets the ceiling on what every PM, designer, and fellow engineer can safely produce. An engineer fighting to keep PMs out of the repo is defending the part of the job that automation is actually coming for — the hand-built feature — while ignoring the part that's becoming the whole game.
The window, and what it costs to defend the gate
There's a clock on this. Orgs that wire PMs into the repo behind a strong gate get a velocity most teams can't match — product judgment touching the artifact directly, with engineers owning the harness that keeps it honest. Orgs that keep the repo a closed room keep their engineers busy translating tickets into commits, the lowest-leverage version of the role, right up until a competitor's smaller team out-ships them. The engineer who wins the argument to keep PMs out wins a worse job, more slowly, on a team that's losing.
So the move, if you write software and you want the leverage, is to invite them in on your terms. Build the gate first — the checks, the review path, the verification that makes a non-expert commit safe — because that gate is now your highest-value artifact, not a chore. Own the machine — the shared agents, skills, and standards Albuquerque keeps in a team repo are engineering deliverables; whoever maintains them sets the quality floor for everyone. Give PMs a low-risk on-ramp — his own Monday-morning version is to add a PM as a collaborator on a throwaway repo and let them take the oldest, deadest item in the backlog. Nothing reaches production it shouldn't, and you find out fast which PMs sharpen the work and which generate noise. Stop translating tickets by hand and move up to designing the system that makes translation unnecessary.
PMs in the repo isn't the end of engineering. It's the moment engineering stops being measured by features shipped and starts being measured by the machine that ships them safely. The engineers who want PMs out are guarding the wrong door — and the ones who open it, behind a gate they built, are the ones who'll still be indispensable when the demos stop being novel.
Source. Sachin Rekhi (founder, Notejoy; former product executive at LinkedIn and Microsoft), "Claude Code for Product Managers with Sachin Rekhi," Reforge, YouTube, published March 4, 2026: youtube.com/watch?v=zsAAaY8a63Q. Andre Albuquerque (founder, Builderscamp), interviewed by Aakash Gupta on Grow Product, "The Claude Code Setup for Non-Technical PMs That Nobody Shows You," YouTube, published May 18, 2026: youtube.com/watch?v=bYiXxeinhbg. All characterizations of their remarks are drawn from these episodes; quotations are transcribed from them and lightly punctuated for readability. I have no relationship with Notejoy, Builderscamp, Reforge, Grow Product, or any of the individuals named.