How I ship with T3 Code, tstack and flow mode

Good software development has usually followed a git flow: branch, review, merge. With AI writing the code, it's tempting to skip that and commit straight to main. That works right up until an agent is confidently wrong in a way that passes its own tests. I think the flow matters more now, and it needs more than one reviewer.

Every feature in this monorepo goes through the same steps, with more than one model involved and a PR at the end. Three things make that work without me babysitting it: T3 Code, Theo's tstack skills, and a skill of my own called flow mode.

T3 Code runs the models

T3 Code runs Claude Code and Codex in one app, and for me the part that matters is that they can hand work to each other. A Claude thread can start a review on GPT Sol and get the answer back without me copying anything between windows.

It also knows about PRs. An agent links its PR to the thread and asks to be woken when checks finish or a comment arrives, so nothing sits in a sleep loop burning tokens. That's how I can say "merge when green" and go do something else.

tstack does the PR work

tstack is a set of short skills: file-pr, babysit-pr, sol-loop, modernize, takeover and a few more. They're small on purpose and they push back on scope creep. sol-loop tells the agent to make the most minimal changes it can and not to be scared to disagree with the reviewer.

I reviewed them before installing them and made three edits on my own branch. council stops after three rounds. pr-wait doesn't wait for review bots I don't have. modernize cleans up the worktrees it creates. Read skills before you install them. They're instructions your agent will follow.

Flow mode ties it together

tstack starts when there's a change to review. Flow mode covers the whole feature:

1. Spec, with me. The agent reads the code first, then brings me only the decisions that are mine, as multiple choice with a recommendation. Each decision in the spec is marked as mine or the agent's.
2. Plan. Tasks that name their files and how each one gets checked.
3. A different model reviews the plan against the real code, before any code exists.
4. Implement, one commit per task.
5. Prove it in real use. Not just tests. The cheapest run that actually exercises the change.
6. Sol reviews the diff, through sol-loop.
7. PR, with the description run through poteto's unslop skill to cut the AI tells. Then 8. merge when I say so, after reading every check.
8. Journal. What happened, what was learned, what the agent got wrong. This comes from working with agents.

Production changes, image pushes, new spend and merges stay mine unless I say otherwise.

What it catches

The second model earns its cost. When I added a node graph editor to studio, the review of the design found a real path traversal in our server, which the agent had only listed as something to check. The review of the code found that a filter hiding private file names cleared the list and left the first name sitting one field over, in default. The agent's test passed because it wrote the fixture by hand from what it assumed the data looked like.

Real runs catch what reviews can't. Building a lease server for our GPU box, the first real run found that Docker there prints error: no such object in lower case, which left a stale lease. No mock would have had that.

And sometimes everything misses it. One fix passed its spec and got approved by Sol, then CI failed, because it broke a 2 second spacing rule that only the full test suite checks. The agent had run a subset. So the rule now is to run tests the way CI runs them.

Where I still matter

The flow doesn't replace paying attention. A review agent once looped for 67 minutes because it could only see its last 24 screenshots, and I'm the one who asked if it was stuck.

This week I got a billing warning that looked wrong. One idle machine's heartbeat was reading 32 KB every 15 seconds to update a timestamp. The agent proposed moving the data to its own table. I asked if we should stop storing the full list at all, and that question got us to a better fix: keep only the entries we use, which took the read down to 2 KB. None of the reviews had flagged it, because none of them had been asked about the bill.

So that's the split. The models write, review and argue with each other. I decide what's worth building, approve what touches production, and keep asking questions. If you want to try it, start with tstack and take flow mode as a template. Your version should name your own checks. Mine are about my GPU box, and yours won't be.