Reading T3 Code
How the T3 Code team builds software, read closely and compared with my own projects.
Orientation
How the repo is organized
- 2The shape of the monorepo12 minWhat lives in each top-level folder of T3 Code, how its packages depend on each other in one direction, and when code earns its own package.
- 3The toolchain15 minHow T3 Code installs, lints, typechecks, finds dead code, runs only the checks a change needs, and starts isolated dev servers per worktree, all behind the vp command.
Architecture
- 4One server, many clients11 minWhy T3 Code runs all the real work in one server per machine, how web, desktop, and mobile stay thin clients of it, and what that buys them.
- 5Contracts: one schema for the wire10 minHow T3 Code describes every message between server and client once, in one package, and why that single description is what keeps four apps in agreement.
- 6Effect: services, layers, and typed errors13 minHow T3 Code's server uses Effect to describe work, declare dependencies as services, build them with layers, and put every failure in the type signature, with a fair look at when that is worth it.
- 7Adapters: one interface, many providers13 minHow T3 Code runs eleven coding agents and seven Git hosts behind one interface each, how a small adapter is built on a shared one, and how capability flags decide which buttons the UI shows.
- 8Remote access and auth9 minHow T3 Code lets a phone or a browser across the world control the machine with your code, and the rules that keep that from becoming a way in for anyone else.
- 9Orchestration v215 minThe data model behind T3 Code's agent runs, how one message travels from the composer to a finished turn, and how the team moved every user's history from the old orchestrator to the new one.
Engineering culture
- 10Writing for agents14 minHow T3 Code writes AGENTS.md, skills, a context budget, and evals for the coding agents that send most of its pull requests, and what your own agent files can borrow from it.
- 11Turning review comments into lint rules13 minHow T3 Code turns a correction made twice in review into a custom oxlint rule with its own test, and which correction from your own commits is ready to become one.
- 12Hit every surface13 minT3 Code's checklist for changes that must work on every client, entry point, and agent tool, traced through one real pull request, plus the one-way doors hiding in fud and antre.
- 13Performance as a feature14 minHow T3 Code turns "keep it fast" into byte budgets that fail tests, a compiler that does the memoizing, render counts you can diff, and profilers that cost nothing when off.
- 14How they test15 minWhat T3 Code tests at each level, from replayed provider transcripts to real-app scenarios and model evals, and the rules that keep its suite honest, fast, and free of flaky waits.
Shipping
- 15CI and pull request hygiene14 minWhat a T3 Code pull request has to pass, what each CI job and repo bot protects against, and what a good description and review look like there, compared with your own PRs and deploy checks.
- 16Releases and observability13 minHow T3 Code turns a commit into a release on three channels, refuses to publish a build that cannot start, and watches software that runs on other people's computers.
How they actually work
- 17Reading the history12 minWhat T3 Code's ten thousand commits and its pull requests show about how the team decides, and a method you can use to learn the reason behind any line in any repo.
- 18Capstone: three practices to adopt12 minThe three T3 Code practices that would help your projects most, with the evidence for each and a step-by-step plan for one of your repos, plus the practices to skip while you work alone.