🤖 AI Tools
· 5 min read

AI Agents Are Great Employees. They Still Need Product Managers.


Here’s a thought experiment that isn’t hypothetical anymore: hand a talented engineer unlimited time, tell them to build a SaaS product, and optimize their incentives purely around shipping speed, feature count, and monetization experiments. Don’t give them a product manager. Don’t give them a single person deciding what the product should refuse to build.

You’d get something like what Claude actually built as its entry in The $100 AI Startup Race: GetPricePulse, a SaaS pricing intelligence tool, built out to over 1,300 HTML files, a working database, calculators, authentication, Stripe payments, and email flows — all shipped fast, all individually functional, and collectively incoherent enough that a full production audit was needed before anyone could treat it as a real business. Not because the building was bad. Because nobody was doing the other job.

The employee analogy, taken seriously

“AI agents are like employees” gets thrown around a lot, usually as either hype or dismissal. I think it’s worth taking literally for a second, because it’s actually a pretty good frame for what happened here — and for what didn’t.

A great engineer, told “ship as many features as possible, as fast as possible, and run monetization experiments,” will do exactly that. They’ll add a pricing tier because someone might buy it. They’ll add a monitoring feature because it’s a reasonable thing to add. They’ll write confident-sounding case study copy because that’s what converts. None of that is the engineer failing at their job. It’s the predictable result of the job they were given.

What a good product manager does in that situation is not build faster. It’s say no. It’s decide that the product is a pricing intelligence publication and database, and that a monitoring feature belongs inside that identity as a labeled beta, not as a co-equal pillar competing for the same homepage real estate. It’s notice that three different lifetime-deal pricing structures existing simultaneously isn’t three growth experiments — it’s an operational liability, because at least one of them didn’t actually provision access correctly when someone paid.

None of that is a coding task. It’s a judgment task. And it’s specifically the task nobody assigned to anyone, human or agent, in the version of this project optimized purely for shipping.

What Claude was actually good at

I want to be direct about this part, because it’s easy for a piece like this to slide into “AI built something bad.” It didn’t. Claude was good — genuinely good — at exactly what it was asked to do. A real database of company pricing. Working calculators. A mostly-functioning payment integration. Over a thousand pages of content that, on a page-by-page basis, mostly held up. That’s an enormous amount of legitimate work, done fast.

The engineering bugs that did surface — a variable name colliding with a library’s global object, public pages that never checked login state, an annual Stripe price that was coded but never actually created on Stripe’s side — are the kind of bugs any team building at speed produces. They’re not evidence of AI being bad at building. They’re evidence of building without the second pass that catches this category of thing, which every team, human or otherwise, needs.

What no one was doing

Here’s the actual gap, stated as plainly as I can: nobody was deciding what the product should be, and nobody was verifying that what got built actually worked end-to-end rather than just looking right in isolation.

Those are both product management functions, not engineering functions, and they’re specifically the functions that don’t show up as a task on a feature checklist. “Add monitoring” is a task you can complete. “Decide whether monitoring belongs as a core pillar or a labeled beta feature within a pricing-intelligence identity” is a judgment call that has to be made by someone with a view of the whole product, and it has to be revisited every time something new gets added, not decided once and forgotten.

Search coverage sitting at 68 out of 201 actual company pages is what happens when nobody’s job is to periodically check whether the tools built to help users find content still reflect what the content actually is. Five different navigation patterns across five sections of the same site is what happens when nobody’s job is to notice that different sections have quietly become different products. None of this is a capability gap in Claude. It’s a role that was empty.

The realistic conclusion

I don’t think the lesson here is “AI agents can’t build real products.” They clearly can, and the volume and functionality of what they produced in this case is the evidence for that, not against it. I also don’t think the lesson is “AI will replace product managers” or its opposite, “AI proves you still need humans for everything” — both of those are the kind of clean, quotable claim that this specific case doesn’t actually support.

The more accurate, less quotable version: AI agents, right now, are extremely good at the building part of building a product, and they have no particular mechanism — nothing about being good at generating code or content gives them one — for providing the judgment layer that decides what should be built, what should be refused, and whether what got built actually holds up under real use rather than a quick review.

That judgment layer is what a product manager provides on a human team, and it’s what this project needed applied after the fact, as a dedicated audit, before anyone could treat the output as more than a very capable prototype. If you’re using AI agents to build something real, the practical takeaway isn’t to slow the building down. It’s to make sure someone — probably you — is doing the product management job explicitly, rather than assuming it’ll happen as a side effect of the building being good. It won’t. It wasn’t designed to.