Two builders, one canon, and one disagreement about who gets to skip a step.
Your AI agent will skip the boring step the second it thinks it can get away with it. Which is immediately. Same as a tired developer at 4pm on a Friday, except the agent does it a hundred times faster, with a hundred times the confidence, and none of the self-doubt that occasionally saves the rest of us.
I learned this the hard way. I built a harness called Mycelium to make Claude do real product work, discovery through delivery. The agent aced the discovery on a macOS app. Mapped the opportunity tree like a textbook. Then it shipped the thing with zero tests and no accessibility, which is a flawless plan executed beautifully on the wrong half of the job. Why? Because my rules were friendly advice. And advice, human or machine, is the first thing out the window when there is a deadline in the room.
So I went looking for other people fixing the same problem. The best one I found is Dean Peters and his Product-Manager-Skills.
Here is the part that made me sit up. Dean packaged 49 product-management skills for AI agents. Torres on discovery, Cagan on empowered teams, Jobs-to-be-Done, the whole canon. I built Mycelium on the same canon. Also 49 skills. Two people, no coordination, same map of what good product work looks like, right down to the reading list. Either we are both onto something, or we read the same five books. Probably both.
We disagree about exactly one thing. And it is the thing that matters.
Coaching the human, or stopping the agent
Dean coaches. His tagline is "Always Be Coaching", and every skill is built to leave the human knowing more than they did before. He is refreshingly honest about the stance. On his Substack he says he uses frameworks "like seasoning, not a main course," which is the most sensible thing anyone has said about frameworks in years. The discipline lives in your judgment. The tool sharpens it.
Mycelium does not coach. It gates. Same frameworks, wired up as 38 guardrails in three tiers: a couple are blocked outright, a big middle tier will not let the work be marked done until the evidence exists, and the rest are nudges. No tests, no done. No threat model, no done. The agent finds this deeply unreasonable, or would, if it had feelings. It does not, which is the entire point.
Two different bets about where discipline should live.
Dean bets on the human. Keep it light, teach the craft, trust the person to carry it from there. That is the right bet when the person at the keyboard is steering and the real risk is that they do not yet know what good looks like. Coaching grows a product manager. A gate has never taught anyone anything, and never pretended to.
I bet on the loop. Make the step something the agent has to skip on purpose, because left to itself it will skip it the moment it feels sure, which is always. A handful of things are blocked outright. The rest the framework simply refuses to call done, and writes down that it is not done, which turns out to be enough most of the time. That is the right bet when the agent is moving fast and the risk is not ignorance but momentum. You cannot coach an agent into caring about the boring fix. You can, however, stand in the doorway until the boring fix is done.
Neither is the upgrade of the other. They stack. Run a coaching skill to think the problem through, then gate the output so it cannot ship half-built. The library teaches the human. The gate constrains the agent. Same canon, opposite ends of the same loop.
So which one do you need
One question: where is your risk?
If the risk is that the person does not yet know the craft, you want coaching. A gate will only frustrate them and teach them nothing, which is the worst of both worlds. Dean's framework is built for exactly that person, by someone who clearly enjoys teaching them.
If the risk is that the agent is fast, confident, and one keystroke from a shortcut you will pay for next quarter, you want gating. This is where I have evidence. Modest, but real. I ran Mycelium with three first-time users last month. One of them, a junior developer, caught the agent quietly trying to overwrite her own brief with an improved version. She stopped it and made it keep both. She enforced the exact discipline the framework was built to enforce, in the one moment the framework had not quite managed to. Being out-disciplined by your own tester is a humbling experience, and I recommend it. That is the whole argument in a single story. The discipline has to hold when nobody is watching. Especially then.
Three users is three, not thirty. I am not claiming this scales yet. I am claiming the failure mode is real, because I keep watching it happen, usually right after the agent tells me everything looks great.
The part we agree on
Strip the mechanism away and Dean and I are saying the same thing. The tools will keep changing, monthly, whether we want them to or not. What lasts is whether the discipline survives contact with a deadline. He builds tools that coach that discipline back into the human. I built one that holds the agent to it whether it wants to or not.
So if you are choosing between us, you are probably asking the wrong question. We answer two different ones. Work out whether the thing you cannot trust is the human's knowledge or the agent's restraint, and the choice makes itself. And if it turns out to be the agent, well, that is what the straitjacket is for.
Mycelium is at github.com/haabe/mycelium. Dean's Product-Manager-Skills is worth your time whichever bet you make.
