Engineers as gardeners: maintaining a codebase for agents
- YT :: https://www.youtube.com/watch?v=GtJKFhztgdM
- Original title :: Coding Isn't About Code Anymore
Theo argues that with AI agents the engineer's role shifts from writing code to gardening: building and maintaining an environment (fast dev server and CI, clear docs and examples, strict but cheap checks, small guiding signals) in which agent-written code grows in the right direction and weeds are removed early. The argument is built on personal history - Twitch product/platform teams, the T3 stack, the Convex migration of T3 Chat - showing that platform work was always the highest-leverage part of engineering and is now ten times more important, because slop grows faster than weeds and slow tooling blocks agents harder than it ever blocked humans. Concrete examples from T3 Code: deleting about half of 11,000 unit tests, and a CI check guarding wire-protocol size. Result: PRs merged per day rose from 2-20 to 400+. Sponsored segment: CodeRabbit (security scanning).
Premise and tone
- Aimed at developers who ship and want to use AI well, not at commenters who say Theo is "not a real engineer". Comments to be ignored.
- Claim: anyone who has not changed the way of coding over the last year because of these tools may not have a job in a year or two. Theo admits having danced around this for years and being wrong.
- Thesis: engineers are not really engineers anymore; the role is gardener. The best thing to do is to maintain a healthy garden.
- The video is meant to be hopeful, not sad: the new problems and building blocks are more fun than before (Theo sometimes goes to bed at 6 a.m. because of it).
Sponsor: CodeRabbit
- AI writes code and exploits well, but the everyday models cannot scan for insecurity and happily write insecure code.
- CodeRabbit's new security product does deep scans of existing code and scans every PR, covering reachability, exploitability and blast radius. Exploits now appear as soon as a patch lands, so code should be secure before shipping. 14 days free.
What engineering is about
- The joy of engineering: finding the right pieces, assembling them, and choosing the size of the building blocks - silicon, assembly, C, runtimes, packages, composable functions and modules.
- Common fear: this tinkering feeling disappears with AI. Theo's experience: after coming through the other side, the problems and tools are more fun than ever.
Twitch: product vs platform
- Theo was at Twitch 2017-2021. 2018-2019 was a bad stretch (team folded, sponsor exec retired, forced into Go on the VOD team) and he almost got fired. A front-end manager steered him to React + TypeScript; hooks clicked thanks to Elixir and functional-programming background, and the feeling of understanding a whole system returned.
- Twitch was moving from Ember + Rails to Go + GraphQL + React TypeScript. Theo joined the rewrite early.
- Team structure: feature "product" teams (chat, creator dashboard, mod tools) own the whole vertical; "platform" teams (browser clients, GraphQL Edge, data, video infrastructure) make sure everything scales and fits together.
- Theo was formally product but attended platform teams' planning meetings (browser clients) because he cared about the platform.
- Formative moment: a colleague (Derek) reacted to Theo's mediocre PR by asking why it was written that way, then within 30 minutes shipped two PRs: removing misleading docs and rewriting the confusing code examples. Lesson: every bad PR is an opportunity to fix the cause, not the symptom; otherwise quality erodes fast.
- Safety tooling team ran a small clone of the main stack with 300 users, which allowed dogfooding ideas and passing the good ones to the browser clients team.
- Code quality is as much a communication and organization problem as an engineer-skill problem; a platform set up well lets an okay and a phenomenal engineer both merge good-enough code. Notably absent from this story: managers, heavy code review, guard rails, coverage.
- Anecdote: a dashboard layout needed a recursive JSON blob; Theo's team believed the GraphQL Edge team would refuse it and designed an elaborate node graph. A direct conversation with the Edge lead (Tony) settled it in one minute - "why not just store the JSON blob" - and led to a lasting friendship. Much friction is one conversation and one small platform change away from not existing.
Solo founder and the T3 stack
- After leaving Twitch (1500 employees to one person), Theo first tried to replicate all the platform teams' work (Elixir GraphQL backends, hand-tuned bundles) and ended up doing everyone's job.
- The T3 stack came from the need for platform confidence without the friction: Next.js, TypeScript, React, Tailwind, Prisma (type safety from database to backend) and tRPC (TypeScript functions callable from the front end, the contract being TypeScript instead of GraphQL or OpenAPI). Nothing in it was new; it was an assembly of existing tools.
- Theo learned tRPC as homework from Tanner Linsley after joining a Twitter Space; tRPC's maintainer Alex is still a friend, and Julius (now behind T3 Code) came from that community.
- While building Ping, T3 tools (now T3 Code and T3 Chat), YouTube, fundraising and Y Combinator, about half of Theo's pull requests did not change anything visible to users - they made the other half easy to land. Swinging like a pendulum between platform and product, and blurring the two roles, levelled him up the most.
Last hand-coded overhaul: T3 Chat to Convex
- Theo's last big hand-written rewrite: moving T3 Chat from a custom sync engine to Convex (now open source and mature), a 25,000+ line PR done over a month, started while ill with COVID and ending with news of a hand reconstruction surgery. Agents were tried and could not do it.
- Reasons: maintenance pain and absurd database costs, but mostly that Theo was the only one who understood the backend and blocked Julius and Mark. Afterwards they landed many more PRs, and iteration continued while Theo could not code for months.
- Users noticed almost nothing except better cross-device sync; such invisible overhauls are the favorite kind of work.
- Theo wrote slop before agents did: the custom sync engine was "Theo sync slop", blocking the team. Reframed: where the slop comes from does not matter; Sonnet 4.5 slop blocks Opus 5.5. Platform work that made the team successful is now ten times more important.
The mindset: mailing the TypeScript team, TS Rust
- Anecdote: Twitch type checks took 15-20 minutes and dev start 3-5 minutes; Theo, aged 21, replied to a TypeScript team member (Daniel Rosenwasser) on Twitter, then brokered a meeting between the Twitch browser clients team and the TypeScript team. Lesson: things are malleable and made by ordinary people.
- Same mindset leads to the current TS Rust work; the TypeScript team reached out and Theo talked with Anders Hejlsberg.
- Cost-benefit has changed: rewriting TypeScript in Go at Twitch for 600-800 front-end engineers was never worth 20 engineers; rewriting it in Rust for a three-person team now is. A Twitch migration from Apollo GraphQL 2 to 3 (thousands of broken files tracked in a shared sheet, around eight people plus helpers for a month-plus) would now be one prompt.
Gardening analogy
- Engineers should not grow the code; they build the environment where it grows in the right direction: nutrients (docs, examples), supports (posts and stakes), monitoring, and quick recovery before a plant becomes a weed.
- Agents are blocked harder than humans by friction: a 5-minute dev server start, 5-minute cache TTLs wasting tokens through missed cache reads, slow or RAM/CPU-hungry CI limiting parallelism, slow or scary releases limiting merges.
- Key point: slop grows faster than weeds. Without constant maintenance the garden becomes mostly weeds. The job is fertilizing, staking and weeding as soon as problems appear.
Examples from T3 Code
- Test purge :: a PR deleting about half of the unit tests (about 250,000 lines of code); useless tests multiply and breed unnecessary edge-case tests. Of 11,000 tests only four were brought back, and no regressions that the deleted tests would have caught. Prevention: guidance for agents, plus asking contributors to find the thread where a bad test was added and ask the agent why, in order to fix the root cause.
- Thread transfer impact check :: a CI action (about 30-45 seconds) that replays real Codex and Claude thread events through a simulated end-to-end pipeline and reports how much data goes over the wire (goal: about 5 KB even for a large thread). It posts the result in every PR with red marks on regressions, where a babysitting agent notices and fixes it. This is the "wooden stake" that guides growth, and it solved repeated small PRs that regressed protocol performance.
- Theo enjoys data representation and protocol work, and keeps checking where agents get stuck, what they trip over, what confuses them.
- Result chart: PRs merged per day since T3 Code started went from roughly 2-20 per day to 60 on a bad weekend day and 400+ on active days.
Closing
- A chat viewer and Lauren (a post Theo reads out) arrived at the same analogy: every team needs a gardener watching the PR stream, noticing smells like lint suppressions creeping like ivy, and tending weeds before slop takes over.
- Theo offers more videos on gardening techniques (some proven, some not yet), says he has never enjoyed work more, and hopes viewers find the same magic despite fear of fast change.