Ten Days That Changed Everything

I sat down about two weeks ago to “improve the board.” Ten days later, I’d rebuilt it from scratch and Beats had become a different product.

The plan was modest: better drag-and-drop, some keyboard shortcuts, maybe a command palette. But once I started pulling the thread, the whole thing unraveled. The board wasn’t a feature of a CLI tool. The board was a core part of the product. The CLI is an interface for agents. The board is the interface for humans. The command central and nervous system.

The sprint

Day 1-2: Board redesign from the ground up. Better layout, proper save flow with auto-commit, fundamental bug fixes. The board went from “you can look at your issues” to “you can work with your issues.”

Day 3: Command palette (Cmd+K) and global keyboard shortcuts. The board started to feel like a real application, not a web page.

Day 4: Manual sorting, drag-and-drop in the backlog, proper parent-child rendering. This was the day the board stopped being a view and became a workspace. I could feel the shift. I stopped opening the terminal to manage issues and started using the board for everything.

Day 5: Labels, assignees, and relationships in the web UI. Feature parity between the two interfaces.

Day 6-7: Multi-project support with linked sidebars. Dashboard with velocity charts and burnup graphs.

Day 8: The MCP server. More on this below, because it turned out to be the most important day of the ten.

Day 9-10: Kanban boards with drag-and-drop between columns, cleaner activity feed, paying down the debt from building fast.

The MCP unlock

If I had to pick the single most important thing from these ten days, it’s the MCP server. Not because it’s technically impressive. It’s a thin wrapper over the same business logic the CLI uses. But because it changes the agent’s relationship to the tool.

With the CLI, agents can use the issue tracker. With MCP, agents can inhabit it. They discover the available tools, understand the schema, and interact with issues as structured data. When the AiSE process tells an agent to “update the story status to In Progress,” the agent doesn’t have to parse CLI help text. It calls a typed tool with a typed payload and gets a typed response.

This is the thing I was groping toward in February when I wrote about the issue tracker being where planning happens. The MCP server makes it a shared workspace where humans and agents operate with equal fluency. The human drags a card on the board. The agent calls an MCP tool. Both see the same state, both can make changes, and neither needs to learn the other’s interface.

And it resolved an irony that had been bugging me since April. I’d been building the AiSE Kit’s planning process in markdown files while having an issue tracker that could do the job. The MCP server closed that gap. The planning track now talks to Beats directly: create an epic, decompose it into stories, spec each story. The agent does all of this through MCP calls that create real issues in the real tracker.

That also pushed AiSE Kit to evolve. The spec for a story should be attached to the story’s issue, not buried in a .forge/ directory tree. The issue tracker becomes the single place where the full context of any piece of work lives: the plan, the spec, the decisions, the implementation history, and the outcome.

I didn’t plan this convergence. But looking back, every step pointed here. The markdown file frustration in December. The “decisions should live in the tool” nagging in January. The “planning is issue tracking” insight in February. The “AiSE should use the tracker” realization in April. Each was a piece of the same puzzle, and the MCP server was the piece that made the picture click.

The right architecture

The append-only data model is the reason I could build this fast without breaking things. Every new feature was a new event type and a new projection. The core storage layer didn’t change. The CLI didn’t break. The existing API endpoints didn’t move. I was adding capabilities without rewriting plumbing. That’s the payoff of getting the foundation right in December.

The right process

The architecture explains why nothing broke. It doesn’t explain the velocity.

We’ve been using story points for years. One point is roughly a day of focused work, half a point is a few hours. The numbers aren’t precise, but they’re consistent enough to spot trends. A great week for our five-person team used to land around 30 points total. That meant barely any meetings and a lot of focus time. When Copilot arrived, individual developers started hitting 12 points a week on boilerplate-heavy work, roughly a 2x. When agents came along, that doubled again to the occasional 24.

I’d been tracking this sprint in Beats. When the dashboard came alive on Day 6, I stared at it for a while. My velocity was sitting at around 90 story points for the week.

The velocity came from the process, not from typing faster. The work was properly decomposed. Each story was sized for an agent to complete in one shot. The agents had written the story descriptions themselves as mini specifications they could work against, grounded in the current state of the code. When a story got picked up, it got specced at that moment, so the spec was always current, never stale. The agent read the codebase, understood what existed, wrote a spec for what to add, got approval, and built it. Story after story, each one a clean addition because the agent knew exactly what was already there.

Ninety commits in ten days, and the codebase was more coherent at the end than at the start. That’s not a speed story. That’s a process story. The right decomposition, the right spec timing, and the right architecture underneath it all.

Beats isn’t a CLI issue tracker with a web board anymore. It’s something else. I need a better name.