How software work gets done here at Synesthesia

Most of the work starts in a terminal. There is a checkout, an agent working in it, and usually a browser open beside it. When the agent finishes, someone still has to read the diff and try the thing. A passing build won’t tell you that the button is in the wrong place.

The checkout stays on the work machine when you leave the desk. You can open another terminal on a phone, reconnect to the session, and pick up where you left off.

The terminal end

Ghostty is the local terminal. herdr keeps the agent sessions together and makes their status visible. It helps to distinguish an agent that is still working from one that has been waiting for an answer for twenty minutes.

The coding harness is OMP. pi is the smaller starting point if you want to assemble the setup yourself. Extensions such as autoresearch, sidequest, zen-tui, web-access, and pi-welcome-screen cover more specific needs. You don’t need to install the whole list to edit a file.

Give the agent a bounded job: which behavior needs to change, where it can work, and what would count as finished. If two jobs touch the same files, running them at once tends to turn the review into a merge exercise. Separate checkouts help with independent changes; they don’t resolve disagreements about the interface.

Read what changed

Hunk is the review surface. It lets you annotate a change and send that feedback to the agent. Pointing at the line is less ambiguous than asking for “a cleaner implementation” in a terminal that has already scrolled past it.

Start with the file list. An unrelated configuration change is easy to miss when the patch opens halfway through a component. Then read the behavior: what happens on the second click, what survives a reload, what happens when the request fails. Those questions usually find more than another pass over the variable names.

For a UI change, open the page at the width where it will be used. Try it with the keyboard. A screenshot is useful for spacing; it cannot tell you whether focus comes back after closing a dialog.

There is still an editor. Neovim, with LazyVim if you want that starting configuration, is useful when you already know the exact edit. Opening a file and fixing one line can be quicker than describing the line to an agent.

Leaving the desk

Moshi provides the mobile terminal, and Tailscale connects it to the work machine. From there, herdr gives you access to the agent sessions. The phone becomes another way into the session rather than a second development environment to keep in sync.

That is enough to answer a blocked agent, inspect output, or check a preview. Reading a large diff on a phone is still reading a large diff on a phone. If the change needs a wider view, it can wait.

The host has to remain reachable. A sleeping laptop will not finish a build because the terminal is open on another device. Put long-running work on a machine that can stay awake, and keep previews private unless there is a reason to publish them.

The background process

Hermes handles ongoing assistant work. Its Discord gateway provides a way to reach an agent running on a server for tasks such as research and system administration. That is a separate job from editing a repository through the coding harness.

That separation is useful. A persistent assistant may need context from several days ago. A coding task needs the current repository, a clear scope, and permission to make a particular change. Sharing every credential and conversation between the two would make it harder to tell what either one is allowed to do.

Keep the review notes with the change, including the command or interaction used to check it. If someone reopens the issue next week, they should be able to repeat that check without recovering the terminal conversation first.