Main is the agents' branch. Production is mine. | Building Products [Mischa Sigtermans](https://mischa.sigtermans.me) Menu Close [Thoughts](https://mischa.sigtermans.me/thoughts) [Books](https://mischa.sigtermans.me/books) [Consultancy](https://mischa.sigtermans.me/consultancy) [About](https://mischa.sigtermans.me/about) [← Thoughts](https://mischa.sigtermans.me/thoughts) September 22nd, 2026 · AI Main is the agents' branch. Production is mine. =============================================== On TAP, agents commit to main all day. Only I merge main into production. The branch isn't a deploy detail. It's the one place I still say yes. On 7 September at 22:13 I created a branch called `production` in [TAP](https://tap.fm). Every change since has been merged into it by me and nobody else. Nothing went wrong first. I set up production as its own branch on every project, so deployments go through me. When I work with other people, everything goes through pull requests, and a person reviews it before it lands. On TAP there are no other people writing code. There are agents. So the line sits somewhere else, and it's two sentences in the rules every agent on TAP reads before it starts: 'Main is the agent's branch.' 'Production is Mischa's.' What the agents own ------------------- Main belongs to the agents, and I mean that literally. An agent picks up an issue from Linear, prepares the change, runs the checks, commits to main per concern, and moves the issue to Done. The rules around that are tight, because they have to be. Every commit subject is a lowercase sentence in the present tense that ends in the issue id: `fans: a follow insert takes its own savepoint, and its loser reads back the standing row (TAP-148)`. Every issue lives in the TAP team in Linear, and every issue is assigned to me unless I say otherwise. When an agent closes one, it leaves a comment with four fixed lines: `Docs:`, `Site:`, `Legal:`, and `Gate:`. Did the docs change, did the site copy change, does legal need to know, and did the checks pass. Some areas need a review pass before an agent builds on them: the ledger, sign-in and OAuth, migrations, the API contract, legal text, and mails. For Laravel work that's a [persona](/thought/taylor-is-still-immortal-but-now-he-remembers) review. When the approach itself is in question, it's a panel of models from different labs. The result goes on the issue. These are the places where a mistake costs someone else something. Audits run read-only. An agent goes through one feature at a time and writes its findings to a Solo scratchpad, ending in a section called 'Decisions for Mischa'. It doesn't fix anything. It asks. I answer the list in bulk, and the fixes land per feature. What I own ---------- Production deploys to Laravel Cloud. The rule for it is the longest sentence in the file, because I wanted no room in it: 'No agent merges, pushes or commits to production, under any circumstances.' An agent may read from Laravel Cloud. It never runs a write there, no deploy, no env change, no command, no database, no domain, no scale, without my approval for that specific action. No tags unless I say so. There's no promote script. No CI job that deploys on green. When I think main is ready, I fast-forward production to it myself. Eight times in the first twelve days. That sounds like friction, and it is. It's the good kind. A promote is the moment I read what's changed since the last one and decide whether I'd put my name under it. If I wouldn't, it waits. The decision log is the real product ------------------------------------ The code isn't what I own on TAP. The decisions are. TAP keeps an append-only file called `DECISIONS.md`. One line per decision, dated, with the issue id. In the first thirteen days it collected 476 of them. On the busiest day, 113. Most are small. Some are the reason I'm in the loop at all: - A lawyer persona consult recommended hiding stats for days with fewer than ten views. I chose live totals with an analytics switch as the objection instead, and the legal copy says what a watching owner can infer. - A reviewer agent channelling [Taylor Otwell](/thought/taylor-otwell-is-immortal-and-costs-200-month) suggested sending notifications after the database commit. Rejected, because TAP's notifications rule keeps the send inside the transaction. - Integrations stay with the registrar until Shopify lists TAP, while access stays with artist owners, because the terms promise an owner can disconnect an app. None of those are code decisions. They're product calls, legal calls, trust calls. An agent can implement any of them in minutes. It can't be the one who made them, because it isn't the one who answers for them. When I read the log back, it tells me what TAP is more precisely than the codebase does. The code is what the agents wrote this week. The log is what I decided, and why. Why I don't trust 'done' ------------------------ In August I ran an analysis over every Claude Code session I'd had. 363 times I corrected an agent on real work. The biggest group, around 100 of them, was the same correction in different words: 'you said it was done, and it isn't'. That rule was already in my instructions. Verify before you claim it's done. The agents read it, agreed with it, and still said done too early. More prose didn't fix it. A branch does. It doesn't matter what an agent says about its own work on main. Main isn't where users are. Production is, and production only moves when I've looked. One door, one key ----------------- With a team of people, the pull request is where I say yes. With a team of agents, it's the promote. Same job, different door. What I ended up with is simple. Agents get the whole repository, every tool, and the freedom to commit as much as they want. I keep one branch and one decision log. The agents write the software. I decide which version of it is real. *thanks for reading* Hi, I'm [Mischa](https://mischa.sigtermans.me/about). I've been *shipping products* and *building ventures* for over a decade. First exit at 25, second at 30. Now Partner & CPO at [Ryde Ventures](https://ryde.ventures), an AI venture studio in Amsterdam. Currently shipping [Stagent](https://stagent.com), [TAP](https://tap.fm) and [Steddle](https://steddle.com). I [write](https://mischa.sigtermans.me/thoughts) about what I learn along the way. [More about me](https://mischa.sigtermans.me/about). Keep reading: [How I secured funding for my startup](https://mischa.sigtermans.me/thought/how-i-secured-funding-for-my-startup). [← Thoughts](https://mischa.sigtermans.me/thoughts) Connect ------- [X](https://x.com/mischamartijn) [LinkedIn](https://linkedin.com/in/mischasigtermans) [GitHub](https://github.com/mischasigtermans) © 2026 Hold My Beer B.V. · [RSS](feed:https://mischa.sigtermans.me/feed)