Two seams, one worth closing

A seam is the boring gap between two things that should be continuous: between deciding to pick up a ticket and having somewhere to write the code, or between a change being ready to look at and actually looking at it. Nobody tracks time spent in a seam, which is exactly why they persist.

I built bridges across two of them. Comparing what they cost to build with what they turned out to be worth is more useful than either tool.

The button

A userscript adds a button to ticket pages in the browser. Clicking it navigates to a custom URL protocol registered on my machine, which fires a hidden launcher — no console flash — that works out which repository the ticket belongs to, prepares or reuses a git worktree for it, and opens a terminal already sitting in that worktree with an agent briefed on the ticket.

Two details I would keep in anything similar. A custom URL protocol is an open door: anything on the machine can navigate to it, so the payload is validated down to digits before it reaches a shell. And the small agent call that resolves the repository runs under an explicit turn and budget cap, because a step that only exists to save me typing should never be able to cost more than the typing would have.

The hook

The second is four lines of configuration rather than a program. When an agent finishes work and shares a link to the pull request it opened, a hook catches the link and opens it in the browser immediately. That is the entire feature.

The button replaced typing one command with a ticket number after it. That is about ten seconds. I use it occasionally, for simple tickets, and if it stopped working tomorrow it would be a while before I noticed. It is the most unusual mechanism I have built — browser to operating system to worktree to agent — and it has the smallest payoff of anything on this site.

The hook is the opposite. It removes no measurable time at all; opening a link is one click. What it removes is a decision — do I go and look now, or finish this thought first? — and that decision was the actual cost. The pull request is simply in front of me, at the moment it exists, and I review it then rather than at some later point I have to remember to schedule.

The lesson I took is that the cost of a seam has nothing to do with how complicated the bridge across it looks. I assumed the expensive gap was the one requiring a protocol handler, and it was not. Ten seconds of typing is not friction; it is just typing. An open decision is friction, even when it costs one click, because it stays in your head until you resolve it.

I would build the hook again immediately. I would probably not build the button — and knowing which is which is only possible after measuring, which is why this is written down instead of quietly deleted.

Developer experience work is unusually prone to this. The satisfying projects are the ones with interesting mechanisms, and the friction that actually costs a team is usually somewhere dull: a decision left open, a context that has to be rebuilt, a thing nobody is sure is their job. Before building the bridge, time the crossing. If the answer is ten seconds, the seam was not the problem.