Theo: AI coding makes maintaining the development environment the job

I've been talking to engineers beyond my San Francisco circle about coding with AI and what an engineer's job means. I think the work has changed deeply. My analogy is that we are gardeners: we maintain an environment in which useful code can grow.

I love engineering because we find pieces and assemble them into something meaningful. Software offers building blocks at many levels, from chips and assembly to languages, packages and modules. I worried that using AI would take away that joy of tinkering.

On the other side of that transition I have found different building blocks and problems that I enjoy even more. I know I was fortunate: software development was not my only source of identity or income, which made the change less frightening.

I worked at Twitch from 2017 to 2021. After a difficult period on a video-on-demand team, my manager encouraged me to try React and TypeScript. React Hooks clicked with my functional programming experience, and I joined the effort to rebuild Twitch's web product.

For the first time I felt I understood a system well enough to predict the effects of a change. At Twitch, product teams owned a user-facing area end to end: chat, moderation tools or the creator dashboard, for example.

Separate platform teams supported these products. Browser clients maintained shared web repositories, the GraphQL edge connected clients to services, and other teams operated databases and video infrastructure. Product teams could not each build all that infrastructure themselves.

Although I was on product teams, I spent time with the browser clients team. Early on I submitted a poor change based on misleading documentation and examples. A colleague asked why I had written it that way, then fixed both the documentation and the confusing code.

That showed me a bad pull request can expose an opportunity to remove its underlying cause. If misleading examples remain, the next person is likely to repeat the mistake. I also tested ideas in a smaller internal safety-tools repository before proposing the useful ones for Twitch's main site.

I loved building products people used, and I loved platform work when it made those products better. The relationship goes both ways: products give the platform feedback, while a good platform helps the products grow.

Code quality is partly a communication and organizational problem. Ideally, the environment should help engineers with different levels of experience contribute changes that do not degrade the codebase. I am talking about that feedback relationship, not simply adding management or measuring test coverage.

When I left Twitch and started Ping, I went from a company with many specialists to working on my own. My first instinct was to recreate the complex systems those teams had maintained. I ended up doing several people's jobs and needed a simpler way to work.

The T3 Stack grew out of that need for the confidence of a platform without the same maintenance burden. I combined existing tools, including Next.js, TypeScript, Prisma and tRPC, to connect the frontend and backend with shared types. I did not invent those individual tools.

While building Ping and handling other company and channel work, I had limited coding time. I estimate roughly half my changes improved the platform rather than directly changing the product. Those invisible changes made the other half easier to deliver.

I learned to move back and forth: when a feature becomes harder than it should be, improve the platform, then return to the product. At Twitch, crossing the boundary between product and platform also let me solve problems that had become tangled in assumptions about what another team would allow.

For one dashboard, my team believed the GraphQL team would reject a simple JSON representation and proposed a complicated alternative. I described the problem to the platform lead without suggesting a solution; he independently recommended the JSON approach. A conversation removed friction that had consumed more time than building the dashboard.

My last major hand-coded overhaul was moving T3 Chat from my own synchronization engine to Convex. I had been skeptical of it, but came to see it as a more mature backend, database and synchronization platform. Agents could not yet perform the migration for me.

The change involved more than 25,000 lines and about a month of work. Users would mainly notice more reliable synchronization between devices. We found unusual edge cases as a large customer, which Convex addressed, but the bigger reason for the migration was the team.

I was the only person who understood the old database synchronization code, so I repeatedly blocked my colleagues. Moving to Convex let them keep shipping even while I could not code for several months after hand surgery. The platform improvement made product work easier.

My earlier code was itself a source of low-quality work and friction for the team. It does not matter whether that friction comes from a person or an agent: it can block whoever works on the system next.

At Twitch, TypeScript checks had reached 15–20 minutes and starting the development server took three to five minutes. I contacted a TypeScript team member and helped arrange a discussion with Twitch's browser clients team. That experience showed me that the tools around us are made by people and can be changed.

I call this work gardening: build an environment that steers code in the right direction, supports it and catches problems early. The TypeScript work served the same purpose by letting people check and change code more confidently.

More recently, type checking T3 Code consumed substantial CPU even after TypeScript's Go rewrite. In the past rewriting a tool would have been difficult to justify, even for hundreds of Twitch engineers. I am now rewriting TypeScript in Rust to help a three-person team move faster.

At Twitch an Apollo GraphQL client upgrade broke thousands of files. We put the files in a shared spreadsheet, assigned them to volunteers and manually fixed and tested them. About eight people plus helpers spent more than a month on it. I think agents can now carry out this kind of migration far more cheaply.

Slow development servers, checks and releases also block agents. A five-minute startup delays their feedback and can waste cached context; slow checks consume resources and constrain how many tasks can run in parallel. Maintaining the platform is more important when agents encounter that friction repeatedly.

Poor code and unnecessary tests can accumulate quickly, so someone has to remove them and address their causes. In T3 Code I deleted roughly half the unit tests: about 11,000 tests and 250,000 lines. I say we saw no regression those deleted tests would have caught, and restored four tests.

Deletion alone was not the whole answer. We changed guidance for agents and watched for poor tests returning. When one appeared, we asked the contributor to inspect the agent's thread and ask why the test was added, then used that explanation to find the underlying cause.

I also kept seeing regressions in how much data our thread synchronization protocol transferred. I built an automated pull-request check using real event data and a simulated end-to-end path. It reports transfer sizes and flags meaningful regressions for reviewers and agents.

The check tells an agent that transfer size is something we care about and should optimize. It runs in under about 45 seconds, I estimate. I see it as a stake that guides the plant, rather than leaving quality to chance.

Much of my work on T3 Chat became unblocking teammates by improving the platform. I now do the same for agents: watch where they get stuck and improve the codebase and checks around them. For me this is still engineering, and it is work I enjoy.

I showed a chart of T3 Code pull requests merged per day. I say the project moved from roughly 2–20 a day to around 60 on slow days and more than 400 on active days, which I attribute to the work environment. Others use the same gardener analogy for watching changes and removing recurring problems.

There is more to learn about which maintenance techniques work. The pace of change can be frightening, but I hope people can also find enjoyment in building with these new tools.