Two Months of Beats

I made myself a promise in February: stop building, start using. The tool needs to prove itself in daily use before I know what’s actually missing.

It’s been two months. I’ve been using Beats across every project at KUY.io: client work, internal tools, and something new that’s been consuming my thinking since March.

What survived

The CLI is the right interface for agents. Every coding agent I work with (Claude Code, Cursor, Copilot) can drive Beats through the command line without any special integration. They create issues, update statuses, add comments, all through shell commands. No plugins needed. That simplicity matters.

Append-only is still the right call. Two months of daily use across multiple projects and I haven’t lost data once. The event log just grows. When I need to understand a decision, I walk the history. When something looks wrong, I can trace exactly how it got there. This confidence in the data layer is worth everything.

Opinionated defaults work. Not a single project needed custom issue types or custom workflows. Task, Bug, Epic, Story. Backlog, Todo, In Progress, Review, Done. Every project fit. The constraint that seemed limiting turns out to be liberating. Nobody wastes time configuring the tool.

Need to look at

The board is too passive. The backlog view is fine for seeing the shape of work, but you can’t do anything from it. No drag-and-drop. No inline editing. No keyboard shortcuts. I keep switching back to the CLI for actual work because the board is read-only in practice. A board you can only look at is a dashboard, not a workspace.

The CLI needs a TUI. Dynamic column widths help, but there’s a limit to how much information you can show in a terminal table. Once you have 50+ issues with labels, estimates, assignees, and relationships, the terminal output becomes a wall of text.

No way to plan across projects. Each project has its own .beats/ directory, its own issue space. But real work crosses project boundaries.

Decomposition belongs in the issue tracker

In March I started building the Ai Software Engineering (AiSE) Kit, a spec-driven process for working with AI coding agents. The core idea: before the agent builds anything, you co-author a specification together with the AI agent that captures the decisions that matter. The agent proposes, the developer disposes. Guard rails where they add value, intuition everywhere else.

Building AiSE with Beats drove home something I’d been circling since February: the issue tracker isn’t just where you list tasks. It’s where problem decomposition happens. Epics break into stories, stories get specs, specs constrain the agent’s implementation. The planning track in AiSE, from product brief to epics to stories, inherently belongs inside an issue tracker operation.

Then it dawned on me: AiSE was doing all its planning in markdown files. The AiSE Kit itself started as a directory of markdown templates that you copy into a project. CLAUDE.md described the process. Slash commands defined each step. Specs, decisions, and learnings were markdown files in an .aise/ directory. It worked. But it wasn’t flexible. Static files and directories meant that changing the decomposition would require updates to file paths and references across the kit and made pivoting once you had an initial plan incredibly painful.

AiSE Kit’s planning track is the issue tracker. Problem decomposition, story sequencing, dependency mapping. All of it belongs in Beats, not in markdown files alongside it. The markdown files are the same crutch I identified in February, just wearing a different hat.

This means Beats needs to grow. It’s not enough to track issues. It needs to be the place where planning and execution meet. The board needs to become a real workspace. And the agent needs more than CLI access. It needs structured, typed access to the entire issue graph.

I’ve been thinking about this as “making the tool better.” I’m starting to realize it’s something bigger.