I Hired an AI Product Manager. Then I Had to Take the Project Back.

I wanted to evolve the toucan avatar on my website, so I gave the project to an AI product manager. I called it Bob-PM and asked it to organize the work, coordinate coding agents, manage testing and releases, and keep the project moving without requiring me to supervise every step.

The website was a personal project, which made it a useful place to experiment. I wanted to see how much of product development I could delegate, including the coordination I would normally do myself.

There was real progress. We built the Toucan and an interactive Aviary. A poison dart frog joined the Aviary. The animals could move independently, with controls for pausing them and support for reduced motion. I was genuinely pleased with parts of what we built.

The creative iteration was especially useful. I could describe how I wanted the bird to emerge from its hole, why its movement felt wrong, or how feeding should be easier to discover, then review a concrete implementation. Some ideas made it onto the website. Others remained unfinished experiments.

As the project grew, I expanded the scope. We started work on Frog behavior on ordinary pages, more Toucan movements and expressions, reactions to page content, and a possible 3D version. I encouraged parallel development. Bob-PM coordinated work across separate tasks and branches, and I expected it to bring the pieces back together.

The repository became increasingly difficult to understand. Work accumulated in branches and separate working copies. There were replacement candidates for earlier candidates, changes that had passed some checks but not others, and unfinished features mixed into a growing integration backlog. By the time I pushed for cleanup, the inventory had reached 65 checkouts and 11 open pull requests. Each checkout had to be accounted for.

I spent hours asking basic questions. What had actually been merged? What was ready? Why were merges still waiting after I approved them? Which working copies could we remove? How long would it take to get back to a manageable state?

The answers did not reliably bring the project closer to resolution. Estimates slipped, and a promised cleanup handoff was missed.

I had delegated the PM role and found myself chasing the PM for the state of the project.

There were quality problems too. I encountered freezing, unreliable feeding, slow startup, and animation that did not behave consistently. We also exhausted the included GitHub Actions allowance. Testing became another coordination problem: which checks were necessary, where to run them, and whether a passing result applied to the version we were considering for release.

Some individual blockers were legitimate. Dependency conflicts blocked integration. An accessibility check failed. The available cleanup tools could not handle certain unmanaged working copies. Those problems needed to be resolved. They should also have led us to reduce the unfinished work sooner.

The status reports themselves became hard to trust. When I asked whether the Frog work had all been wasted, Bob-PM initially said it had never verified a production delivery. It later found its own earlier confirmation that the Aviary Frog had shipped. The later page-companion work was unfinished, but that earlier release was real. Losing the distinction made it harder to trust the rest of the report.

I eventually stopped Bob-PM's website work, disabled the recurring development tasks, and moved cleanup to Codex directly. A verified backup preserved committed history and selected working files. At the time of writing, the cleanup was still taking longer than I wanted, and I was seriously considering abandoning some unfinished work just to move on.

The mistake started with me. I gave Bob-PM broad responsibility before establishing a strict orchestration process. I assumed that asking an agent to act as a PM would also give it the discipline to keep parallel work under control. I kept asking for more while the integration backlog was growing.

That does not excuse Bob-PM's execution failures. Keeping track of what had shipped, limiting active work, and giving me an accurate account of blockers were central to the job I had assigned it. I had not made those responsibilities enforceable. Too much depended on instructions spread across conversations and on the agent remembering to reconcile them.

We are now writing a project called Bob Orchestrator that uses Infinite Queue, a project we built to organize project backlogs and coordinate work across multiple agents, alongside GitHub for code and pull-request state. Its intended scope includes assigning agents, selecting models, coordinating reviews, and planning releases across related changes. I care most about whether it can keep the work small enough to finish.

I want a limit on active work, a named owner for integration, and an explicit decision for every pull request: merge it, close it, or deliberately defer it with a recovery path. A task should not be finished while its working copies and branches are still unexplained. Release status needs to distinguish code that exists, code that has passed checks, and behavior verified in production. When integration gets stuck, starting another batch of work should require a reason.

The orchestrator is still being built. I have no evidence yet that it will prevent a repeat. My next test is straightforward: can I ask what is ready to ship, get an answer I can verify, and return to building without spending the evening reconstructing the repository?

---

This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.