# How We Ship Roadbook with an Agent Team

An experiment in agent-driven development — four pipelines, a product owner that preps the backlog, and a workflow that gets better every time we run it.

Date: 2026-05-20
Author: Patrick Heneise
Source: https://zentered-studios.com/blog/agent-driven-development-roadbook

---

We're building [Roadbook](https://roadbook.us) — a social road trip planner with AI enrichment — as a solo founder. This is an experiment: how far can you get with a small agent team running on Claude Code instead of a traditional engineering team? Every day we're improving both the product and the pipeline. Sometimes it works well. Many times it doesn't. But it's getting better.

Here's how the workflow runs in practice.

![Winding mountain highway through aspen forest at golden hour](/blog/agent-driven-development/road.png)

## The Four Pipelines

**Product discovery.** I walk through the app from a user's perspective. A team of specialist agents reads that transcript in parallel: one looking for UX friction, one auditing the code paths implied by what went wrong, one hunting for test gaps. A product owner agent synthesizes their notes, anchors every finding to a specific moment in the transcript, and files GitHub issues. Nothing gets filed that isn't grounded in what actually happened. The result is a backlog that reflects real friction, not guesses.

**Backlog preparation.** A product owner agent works through the backlog, classifies issues by type, priority and effort, and moves them to the Ready column in GitHub Projects when they're fully specced. This is the bridge between a raw issue and something the implementation pipeline can act on without ambiguity.

**Implementation.** Give it an issue number (or a list, or nothing and it pulls from the Ready column). It handles the rest: a spec if the work is substantial, a plan, implementation in an isolated git worktree, tests, code review from multiple angles, and a final merge gate. Bug or feature, the pipeline adapts. For straightforward issues the agent drives it directly; for more complex work it brings in specialists.

**Verification.** Regressions are one of the hardest problems in a fast-moving solo codebase. After every PR merges, this pipeline doesn't just re-read the code — it runs the product. It checks the acceptance criteria, executes the changed flows in a real browser session, and writes regression tests for anything that isn't covered. If something is broken it files a new issue automatically. If everything passes, the PR gets labeled verified. The label is the state. No separate tracker, no manual QA step.

## What Actually Changes

The bottleneck moves. Writing code stops being the slow part. Figuring out what to build next, keeping the backlog grounded in real user behavior, making sure merged code actually works as intended — those were always the hard parts. The pipelines make them repeatable.

The other shift is that GitHub Issues and GitHub Projects become genuinely useful as a management layer. Because every issue is prepared before it reaches the implementation pipeline, issues don't sit in backlog ambiguity. They're ready to ship, or they're not.

And because the pipeline itself is just code — skills defined as commands — it gets better every time we run it. Today's retro feeds into tomorrow's implementation run.

![Multiple monitors glowing in a dark workspace](/blog/agent-driven-development/workspace.png)

## You Can Do This Too

Claude Code lets you define your own pipelines as commands with custom agent teams. If you have a workflow that repeats — product reviews, bug triage, spec-to-merge — you can encode it once and invoke it like any other command. Start small: one pipeline, one repeating workflow. The leverage compounds.

---

Roadbook is what this pipeline builds every week. If you're planning a road trip, [give it a try](https://roadbook.us) — early access is open. The best way to see what agent-driven development produces in the wild is to use the product.

*[Join Roadbook at roadbook.us](https://roadbook.us) — free early access.*