Going Exponential
At the end of the ten-day sprint I knew Beats had become something different from what I originally set out to build, but I didn’t know exactly what. So I did the obvious thing: I shared it with a few people I trusted to be brutally honest.
What landed
The core recipe clicked with everyone who tried it. Decompose a problem into stories sized for an agent to complete in one shot. Let the agent write each story description as a mini specification grounded in the current code. When the agent picks up a story, it specs it, gets approval, and builds it. Story after story, clean additions, no drift.
People who had been frustrated with “vibe coding” producing tangled codebases lit up when they saw this. The tool didn’t just track issues. It structured the work so that agents could actually deliver reliably. That validation mattered more than any feature request.
What needed work
Not all feedback was positive, and that’s exactly what you want from an early-stage tool meeting real users for the first time. Some of the rough edges:
Backlog filtering. I didn’t think this mattered much. I was wrong. It was the first thing every new user looked for. They wanted to slice by label, assignee, status, priority, and see their active filters as chips in the status bar.
Story points vs. issue counts. Some teams estimate, some count. A toggle to switch, and remembering the choice, was a small thing that mattered a lot to people who weren’t me.
Dashboard overhaul. The velocity chart from May was a start. Users wanted cumulative burnup, daily throughput, flow stats, and attention cards highlighting issues that need action. The dashboard went from “interesting data” to “I open this every morning.”
The pattern was clear: features I built based on my own assumptions needed revision, while features driven by watching someone else use the tool landed closer to right the first time.
Going distributed
The biggest thing that became obvious immediately: a local-only tool works for solo developers. It doesn’t work when you have multiple people (or multiple agents) working on the same project from different machines.
So I added a transport interface abstraction, SSH public key authentication, a headless server mode (beats serve), a login command, remote proxy for the web board, Docker packaging, and SSE for real-time updates.
Run beats serve on a machine with the repo, and anyone with an authorized SSH key can connect. The board updates in real-time across all connected clients. Agents running on CI, in the cloud, or on a teammate’s machine can all read and write to the same issue tracker.
Issue locking landed two days later. When an agent starts work on an issue, it takes a file-based git lock so no other agent picks up the same work. This was a real problem: without locking, two agents would occasionally grab the same story and produce conflicting implementations. I only discovered this because other people were actually using the tool. Solo, you never hit it.
Closing the loop
I also added beats review, a unified code review command that shows the diff for an issue’s branch right in the terminal. And beats merge to squash-merge the branch and close the issue in one command. The web UI also got a really nice merge view with file diffs the same day.
This closed a workflow loop that had been open: the full cycle from “pick an issue” to “agent builds it” to “human reviews the diff” to “merge and close” now happens entirely within the tool. No context switching to GitHub for the review step. The tool owns the whole lifecycle.
The same day I did a full UI polish pass: 4px grid alignment across every view, consistent icon sizing, better typography, improved keyboard navigation. The kind of work that doesn’t show up in changelogs but makes the difference between a tool that feels rough and one that feels considered.
Polish is a feature. Not in the “make it pretty” sense. In the “stop making people think about the wrong things” sense. When the filter menu has keyboard navigation that works, people filter. When it doesn’t, they don’t. Every friction point removed is a user experience improved.
This connects back to something I keep coming back to: opinionated over configurable. The tool makes decisions so the user doesn’t have to. Four issue types. Five statuses. One workflow. It’s not that the tool can’t do more. It’s that the tool shouldn’t do more, because every option is a question the user has to answer before they can get to their actual work.
The New Name
By mid-June, “Beats” had outgrown its name. It started as a riff on Yegge’s “Beads” but the tool wasn’t a heartbeat for vibe coding anymore. It was a product engineering platform with a CLI, a web board, an MCP server, distributed multi-user support, and a code review workflow. The tool unlocked a new way of collaboratively building with AI agents leading to unheard of levels of velocity.
I renamed it to Exponential with the xpo executable. The name captures the thesis that’s been forming since I first noticed the compounding effect: every decision logged, every pattern promoted, every learning captured makes the next iteration faster. The knowledge corpus compounds. The improvement is exponential.