Context
Agents write the code, open the PRs, and sometimes merge them. Keeping up with what ships gets close to impossible, and the easy way out is to stop reading and just trust them. I wanted to stay the one who decides what ships.
The Git clients we have were built before agents. They are good at helping you write a commit. They can't tell you what happened while you were on a coffee break.
Since starts from that gap. The main screen is a live commit graph you work on directly, every change to your repository can be undone, and everything is one key away. On top of that sits a layer for the person who merges: what landed since you last looked, which pull requests need you, which are stuck, and in which order they can go in.
Your job went from writing code to deciding what ships.
It was also an experiment in the other direction. If agents are going to write most of the code, what does it take to run them like a product team, and keep the quality bar where I would put it myself? Since is the answer to both questions: the product, and the way it was made.
The Team
Seven agents, one human. The agents wrote the code. I wrote the rules, made the calls, and reviewed what came out.
Every agent ran on Claude Opus through Multica, each with its own role, instructions and skills. They worked in their own git worktrees, one issue per run.
- Mika, chief of staff. Turns my goals into issues, splits larger work into staged sub-issues, drives them to done.
- Engineer. Implements one issue per run and opens one pull request, ending with a review brief: risky spots, tests, what was not tested.
- Reviewer. Reviews at three depths, runs the test suite locally, fixes small findings itself, and squash-merges or sends the work back once.
- Designer. Front-end changes I ask for in chat, with screenshots as evidence.
- Web. The website.
- Strategist and Marketing. Thinking partners. Neither writes product code.
There was no standing process to start with. Each rule was added the day something went wrong, and logged in the project as a dated decision.
The Loop
An idea in chat becomes an issue, a pull request, a review, and a release. The only step that always needs me is deciding.
- Idea. I talk it through with the Strategist, the Designer or Mika. If it is a decision, it gets written into the project brief or a skill.
- Issue. Mika writes the spec, often as staged sub-issues that start themselves once the previous stage is done.
- Build. An engineer agent picks it up, works in a fresh worktree, and opens one pull request with a Conventional Commits title and a review brief.
- Review. The Reviewer pulls it locally, runs the tests and gives a verdict that starts with a count:
0 Important · 2 Nits · 1 Pre-existing. Features and anything critical come to me. - Follow-ups. Findings in new code get fixed in the same PR. Only problems that were already there become follow-ups, filed into topic buckets.
- Triage and batches. Follow-ups are re-checked against
main. I pick which ones ship, and they go out together as one "Batch" pull request. - Release. Mika collects merged PRs, groups them by theme, and I make an in or out call on each group. The notes ship as a PR I merge with the build.
Rules as Code
Agents repeat whatever you let slide. When the same kind of mistake shows up in three pull requests, it stops being a review comment and becomes a rule.
Two files in the repository do most of the work. CLAUDE.md tells every agent how to build;
REVIEW.md tells the Reviewer what counts as a failure. A few of the lines:
- "Show evidence, don't claim success: paste the test result. Say plainly what wasn't tested and why."
- A failure is "data loss, or a change that ⌘Z can't undo exactly", or a keyboard trap.
- "Nits are capped at 3. No style-only findings." At most one fix round.
- "No instructional or teaching copy in the UI: labels, values, status, errors and short warnings about irreversible actions only."
- A diff to
CLAUDE.mdorREVIEW.mditself blocks the merge, because agent runtimes write their own copy into worktrees.
Repeated work became skills: how to add an undoable Git operation, how to add a shortcut, how to style UI, how to hand a pull request to review, how to file follow-ups, how to write release notes. Each one encodes calls I had already made once, so I wouldn't have to make them again.
Where I stepped in
My part was the judgement calls: 94 comments across 60 issues, and 122 review gates assigned to me. Most of them were visual review with screenshots. Once, a change I wanted to test got merged before I could. That became a rule the same day: a pull request with an open review checklist stays unmerged until I close the review.
The Little Big Details
The product is a Git client first. Agents wrote the code, but every one of these decisions is a design decision.
Undo for everything. Every ref change, stash and config edit goes into a journal. Objects are
pinned under their own refs so git gc can't collect them, and older entries are paged to disk so
memory stays flat. There is no cap on history.
Stashes by identity, not position. A stash is tracked by its SHA, never by stash@{n}, so undo
can't restore the wrong one after the list shifts.
The trunk stays on the left. The first-parent chain of HEAD is one straight line down the left edge, and every other branch fans out to the right. Layout runs incrementally while the log streams in. The graph at the top of this page is that layout.
Fast on huge repositories. No commit cap. On an M1 Pro, the Linux kernel, 1,485,146 commits, shows its first rows 0.3 s after the window loads and scrolls at 120 fps. The performance notes ask that the machine stays next to any number, and that 0.54 s is never rounded down to "instant".
The merge order before you merge. The merge plan picks the pull requests that are ready, flags the ones that are behind their base, and shows the order they can land in before anything is merged.
Blocked actions offer a fix, not an error. A rejected push offers rebase and push, merge and push, or force push with lease. A dirty working tree offers to stash and continue, as a single undo step. Disabled menu items say why.
One keymap. Shortcuts, menu accelerators, the ⌘K palette and the shortcuts page on the website all read from the same file. Every action gets a palette entry. A shortcut needs a stated reason, and 0.1.0 removed some.
Tokens with tests. One token file feeds the app and the website. A test checks WCAG AA contrast and that branch colours in the graph stay distinguishable, including under simulated colour-vision deficiencies.
Facts, not scores. Since notices agent work from branch prefixes and co-author trailers, and shows plain facts about a change. No risk score and no policy: the reader decides what it means. It never launches or controls an agent.
Local first. No accounts and no telemetry. Every network call is listed with its trigger and destination, and tests fail if the app gains a runtime dependency or a network module it shouldn't have.
Landing previews from real markup. The previews on the website are the app's own markup at real size, drawn with the same tokens and icons. They only animate while on screen, and screen readers see them as a picture. The vignettes on this page are built the same way.
The Result
Under three weeks from first commit to 0.1.1. The numbers below come from the repository and the issue tracker.
- 5 releases: Beta 1 on 16 October, Beta 2, Beta 3, 0.1.0, and 0.1.1 on 1 November.
- 324 commits on
main, 308 of them merged pull requests. 311 carry a Claude co-author trailer. - 655 issues in the project, 580 done. Mika and the Designer opened most of them; I opened three.
- Reviewer verdicts: 113 approve, 94 approve with nits, 19 request changes.
- 13 follow-up batches, shipped as single pull requests.
- 81 unit test files with about 730 tests, and 21 end-to-end specs that open real windows.
Download it at gitsince.com or read the code on GitHub.
What I took from Since
Agents are fast, and they are confident. Speed was never the problem; keeping my own bar was. What worked was treating every mistake as a missing rule and writing it down where the next agent would read it. By the end I spent my time on the parts I care about most: what the product does, how it feels, and what ships.