At Roadrunner, we are building an AI-native CPQ for companies that want speed and flexibility. We help companies deliver pricing models on their own terms, giving sales teams the freedom and ease to structure any deal, and the business the control to scale with confidence.

Why parallelization?

At Roadrunner we are constantly exploring how we can move faster, smarter, and at scale. In our efforts to improve this we found that parallelization is the single biggest unlock in engineering productivity we can make in the age of AI. As we aimed to parallelize work, this started to exacerbate new problems, but it also opened new opportunities.

Every time you unlock that for one person, they will be 3-5x more productive for the rest of the time they're here. 

DevDash is our evolving answer to how we are both enabling our devs to parallelize and compounding the benefits across our teams. This is the story of how we got here and why we think this is our unfair advantage.

Timeline: fixing one problem at a time

More agents == new problems

As I began to spin up more agents in parallel, a constant pain emerged in my daily workflow. I’d spin up a session, actively work on it for a few hours, and then maybe come back to it a few days later. After a rebase or an unwanted computer reboot, the local infra would go stale.

Naturally, I threw agents at it. They’d get all my tmux sessions in a row and rerun some generation scripts, and I’d spin up another session while I waited. Which eventually gave me another stale environment to come back to. A vicious cycle 🫠.

So while I was “parallelizing” more, the friction of returning to a session and waiting for everything to work again was getting frustrating. Calling an agent with a skill did solve the problem, but it still felt like wasted time on a deterministic problem with a deterministic solution. We knew what tended to break and how to fix it enough.

Thus, just doctor was born

A simple, performant CLI that runs deterministic checks and auto-fixes, completely vibe-coded, with a catchy name 🆒 🧑‍⚕️.

Also, notice the airplane and orange? I love airplanes and the color orange, so I made sure everyone on the team knew it 😆. These devtools and mini projects are a good excuse to have fun. You’re building something that helps you and your teammates move faster, and you get to make it your own. For me, that meant a clean experience with a few visual quirks.

Fast forward a few weeks, and our parallelization had taken new heights. We had proper worktree isolation, with a full stack behind each session: tmux, Docker containers, Git worktrees, and hooks to handle spin-up and teardown. A lot of machinery just to get a session running.

This exposed the next problem: how do I actually see what’s going on across all these sessions? Where are my error logs? How can I see into the database? My local Temporal workers?

Again, I threw an agent at it. Again, I found myself spinning my wheels while it dug around for information. Same smell: a deterministically solvable problem.

At the same time, I’d been wanting to explore GUIs and write something other than Python - we were still on Django at the time 😭. After looking at a few options (mainly Tauri and Electron), I landed on Wails because Go seemed cool, we were starting to migrate parts of our stack to it, and I wanted to learn more. It felt like a good excuse to vibe up a local Mac app.

That brings us to wt-dashboard, a dashboard to easily see all my tmux panes and access my Temporal workers, saving me a lot of time and sanity. As more engineers adopted it, the way we used it changed. It was no longer a personal debugging tool. Other engineers were using it, contributing to it, and depending on it to manage their local dev environments. So, we renamed it DevDash.

Becoming DevDash

The rename reflected a broader shift. We were pulling more of our development tools into one interface such as:

• A stack-aware diff viewer to easily inspect dependent branches against their parents without checking out each branch

• A “My PRs” view that let engineers view all of their PRs with a central view of all CI checks, review status in dependency order

• Quick actions to share entire stacks in PR experience of choice (GitHub, Graphite or Linear)

• Smart stack auto-merge so you don’t have to remember to wait for each PR to go green

The question DevDash was helping answer changed from “What is running in this worktree?” to “Which piece of work needs my attention?”

With less overhead for tracking parallel work, engineers could break larger features into multiple stacks of PRs and build them concurrently. Our load-testing feature is one example. The work crossed two repositories and required several related changes. I was able to divide it into parallel PR stacks across both repositories and shipped the feature in under a day (while shipping other features simultaneously).

Outcomes

Our overall shipping rate increased significantly during the same period. It would be misleading to attribute that increase to DevDash alone. Better coding agents, finer-grained task decomposition, and DevDash all developed together. Agents make parallelization of work easier than ever, worktrees isolate parallel streams of work, and DevDash makes it all manageable.

The way DevDash spread through the team mirrored the way we built it: incrementally, without a formal rollout. Engineers who used it could keep more work in flight with less coordination overhead. Other engineers saw that workflow, adopted it, and eventually contributed features of their own. We never set out to create a general developer platform. We kept solving concrete problems as the team pushed parallel development further.

DevDash quickly evolved from being a side-project for one person's workflow into a core productivity unlock for the entire engineering org. Our hope is that this grows past engineering so the rest of the company gets the same multiplier. Getting to that point means DevDash has to continuously lower the barriers to parallelization. Naturally, the more bottlenecks we unblock, the more we uncover.

What's next?

Cloud agent visibility

Most agent sessions still run inside local worktrees. CPU, memory, Docker capacity, and the lifetime of a developer laptop all impose a ceiling on how much work can run concurrently. We have already started moving beyond that model. We use Claude Tag and Devin to run agent sessions in provider-hosted cloud sandboxes. Those sessions can continue without occupying a developer’s laptop, but they currently sit outside DevDash. Engineers start them in one system, follow their progress in another, and usually encounter the result in a range of disconnected systems like the originating cloud session, opened PRs, notifications in Slack, etc.

That creates a new visibility problem. DevDash can tell us whether a local agent is working, whether its services are healthy, and what it changed. It cannot tell us whether a cloud agent is still running, blocked on a question, failing during setup, or ready for review. Why should there be a divide between local development and cloud-based development? So the next step is not moving execution to the cloud (we already do that to an extent). It is bringing cloud sessions into the same DevDash workflow engineers already use for local work.

Agentic discoverability

DevDash already brings together information engineers use to understand their work: what changed, which checks are failing, whether an environment is healthy, and what is deployed. But agents did not have an equally straightforward way to get that same context. They had to piece it together from separate tools and sources, even when an engineer could see it all in DevDash. We started exposing that information through a new DevDash MCP so agents could access the same view of the work.

Our agents can already access systems like GitHub, Slack, Confluence, and Linear. Giving them access to another source was not particularly difficult. What is harder is knowing what exists and which source to trust. An agent can search the codebase for an endpoint, but it should not need to reconstruct information already captured by an OpenAPI specification. It can find examples of a component, but that does not tell it which implementation is current or who owns it. Slack and Confluence may contain several conflicting answers from different points in time.

Our plan is to build a structured engineering catalog in DevDash and expose it through the MCP. Much of the underlying data already exists: OpenAPI specs define endpoints, oasdiff tracks API changes, import-linter boundaries encode components and dependencies, and ownership and configuration increasingly live in Git.  Together, these sources help an agent understand what a component does, what depends on it, who owns it and where to look before making a change.

We think about the catalog in three groups:

1. DevDash-owned data: golden templates, approved patterns, and its own metadata.

2. Generated data: endpoints, components, versions, and ownership from sources in Git, with CI keeping those records current.

3. Pointers to data: Slack, Confluence, Linear, and live telemetry remain in their existing systems, with enough structure in the catalog to tell an agent where to look.

The distinction matters because we do not want engineers manually maintaining another database. If information can be derived from code or configuration, it should be generated automatically. This complements CLAUDE.md and AGENTS.md files. They set expectations for how an agent should work: coding standards, review requirements and team conventions. The catalog centralized in DevDash would describe the engineering system itself: what exists, who owns it, and where to find authoritative information.

Final thoughts

DevDash has been lots of fun for us to build internally, and the speed + scale improvements have been highly advantageous for us. As you think about how to invest your time and energy as a company, our recommendation is to first focus on the individual. Our journey started from one individual trying to improve their own dev experience, and has now taken life resulting into a more centralized effort to improve dev velocity.

This was enabled by the freedom to work on things you find interesting, a culture that emphasizes sharing, and a team that wants to be at the forefront of maximizing AI for internal dev tooling. We always love to hear about how others are exploring this, so please tell us about your ideas!