My precious attention
Beagle SCM
My precious attention
M.C.Escher - Balcony
Some say intelligence is a commodity now. We have intelligence on tap. What is the bottleneck then? Tokens? Lately, my work has been token-constrained more often. Given some context and hints, LLMs can endlessly reproduce known engineering practices and tricks. Then we get some legit-looking codebase that works most of the time. Still, to get beyond that prototype-quality code (slop), we likely need more than tokens. Doing original work takes vision, taste and tons of feedback. My main difficulty so far has been keeping track of things. That means my attention is the bottleneck for everything.
I can give Claude the context, the general direction of work and any objective criteria I have. Still, the resulting work has to be gated. Some work gets merged at once, some needs one more pass, and some is nuked from orbit, just to be safe. Quite often an LLM creates more problems than it solves. Crams in an extra abstraction, plants a code landmine, and so forth. Until we have superintelligence, that will be an issue. People do all of that too. That is the reason we have pull requests in the first place!
If I run LLM single-threaded, that most often devolves into slow but tiresome chat ping-ponging and ends in late-night swearing. That is exactly how an LLM makes you 10% slower. The way to make LLMs pay off is to set the rules and goals, let a bunch of them run free, then gate the results.
A not so unexpected discovery: I have my context window too. Switching between numerous threads of thought wears me down, makes me dizzy or indifferent. I end up okaying stuff, and then (yes) swearing when I finally see the result.
As an engineer working on an SCM system, I looked for an engineering solution. With agents, we collaborate even when working locally. We set goals and policies, accumulate knowledge banks, review PRs. That is relatively high-level work. git is a much lower-level tool. In fact, the original workflow was git plus the mailing list. For the general public, that became git+GitHub. But GitHub is an intermittently available proprietary service and it is absurd to collaborate with your local agents through GitHub. Like many others, I use a bunch of Markdown files to steer the agents. Keeping that local and greppable is a plus, while storing it on GitHub is an obvious hindrance.
My objective was clear at this point: keep track of tickets and agents locally, review their work and merge it back, with minimum friction. Once you start second-guessing "merge or rebase" or trying to remember "what else did I have cooking", that is your workflow failing. These things must be self-evident, in-your-face obvious. (Today, it is difficult for me not to make 10 commits a day - so it worked.)
The foundation for the build was Beagle the git-compatible SCM I work on. Beagle itself is a very low-ceremony revision control system with 6 verbs (get, post, put, delete, patch, head... remember those?) and no options or flags. Its underlying revision control engine is syntax-aware with CRDT merges. Plainly put, it merges at the syntax token level, not the traditional line-level. More precise and much less technical conflicts; that removes a lot of friction. Beagle is also malleable; everything above the engine is JavaScript.
So, how does the system that preserves my precious attention work? Easy as one-two-three.
$ be work
The screen gives a good view of the battlefield. What tickets do we have open? Is there a worktree and what is its state? What are the changes? Is it ahead/behind? Should we merge, redo or nuke it? With two chats on the main screen, multiple workers in each, and another five or six waiting on blockers or decisions, this is the right tool for the job.
In this system, one ticket corresponds to one branch, one worktree and (ideally) one commit. Commit messages and code comments start with their ticket code for the broader context. Tickets have statuses, also-see references, parents, blockers and so on. Each ticket line has three status/control panels. Each panel has a number of clickable buttons.
worktree state<br>i the status view (light blue)
~12 changed files (blue-ish)
+3 new files (green-ish)
-1 deleted files (reddish)
∞ run CI (grey/green/red)
commit state<br>≡ commit log
1⇄2 divergence (blueish)
+1 ahead of the upstream (greenish)
-1 behind (reddish)
✓ commit (greenish)
decision<br>✓ close with DONE
✗ close with DONT
All button statuses (visible/not, clickable/not) get updated in real time based on the state of the worktrees. In this system, the happy path is click-click-click. The buttons are 2-3 characters wide, with a good mouse (Logi MX Anywhere) browsing and acting is effectively instant. One day I will add keyboard shortcuts. Think of the overheads of doing that through GitHub. In theory, this workflow can be built on top of git. In fact, it might be difficult to make these things work instantly, as git is not...