▶ YouTube Summaries

• https://www.youtube.com/watch?v=xmGY276gEFY
• Original title: Boris has some really good advice

Theo (t3.gg) responds to a Twitter post by Boris Cherny, one of the original creators of Claude Code, arguing that the classic engineering craft skills — writing lint rules, building end-to-end tests, automating dev environments, encoding domain knowledge — matter more in the AI-agent era, not less. He agrees that these automations both speed up armies of agents and let non-engineers and newcomers contribute, while adding his own caveats about where Boris overreaches. The through-line is that building the systems that steer agents (and teammates) toward good code is now the highest-leverage, most fun, and most career-advancing work an engineer can do.

Framing: the craft that felt lost is back

Theo opens by acknowledging that engineering has changed enormously and that many developers feel "betrayed." He misses the fun of deeply customizing setups in VS Code, Atom, Sublime, and building the T3 stack. But he argues that far from being gone, that joy and those skills are more valuable now than ever — he claims to have felt "more clever and had more fun" as a developer than at any point in his career.

Who the video is for

Two audiences: (1) passionate developers who miss the craft they loved, and (2) — more importantly — people already "over the line" who want to help friends get there. Theo frames it as partly for himself, since he has friends for whom AI-assisted development hasn't yet clicked.

Boris's core claim

Boris (one of two original Claude Code creators, born from an internal Anthropic experiment) is heavily "vibe-code-pilled" and has made some dumb takes about engineers being replaced. But this post is different and better: the automations the best engineers always built — Vim/Emacs tweaks, lint rules, end-to-end test suites — have become even more important. Theo strongly agrees.

Why automations matter more now

• Speed multiplies across agents: DX/infra automations speed you up, and if you run an army of agents, each one is sped up too — more output per unit time.
• Preview environments and testing: Things Theo was pushed back on years ago (preview environments à la Vercel) are now clearly valuable because agents build code anywhere — cloud, background tabs, worktrees, other machines — so good preview experiences plus agents that can test previews and post result videos are very useful.
• Getting clever: Example — agents couldn't attach video files to PRs (the GitHub drag-and-drop upload isn't available via CLI), so Theo built a custom file-upload skill backed by his own Cloudflare service (files.t3.gg-style, with keys across his machine fleet). He stresses how unexpectedly fun building these one-off tools is: tight feedback loops, low stakes when they break.

Moving work into code improves efficiency

Boris's point: an agent can fix an issue each time it appears, but that burns tokens and misses cases; if Claude instead writes a lint rule, CI step, or routine, that whole class of issue is automated forever. Theo notes this is the real meaning of "loops" — automating entire categories of busywork. Custom automations (even a 400-line lint rule) that were never worth hand-writing now make sense because agents both write the code and the verifying tests cheaply, and because agents hit these problems far more often than humans did.

Cultural shift: teams now allow this work

Ryan (SolidJS creator), historically uninterested in environment tuning, now feels pulled toward automation because AI finally makes it worthwhile. Theo adds that teams are now more willing to let engineers spend time on this — where three days on a Vim config once alarmed your boss, there's now buy-in for such experiments. He's even had to encourage his team to do more of it, since they're conditioned to think it isn't worth it.

Automation lets others contribute

Boris's most important point: automation lets others — new engineers on day one, and even non-engineers — contribute, because Claude can navigate the codebase for them. Theo calls the "non-engineers contribute as effectively as engineers" claim a reach. The key blocker is domain knowledge trapped in people's heads rather than encoded in automation. What's changed is that domain knowledge is no longer limited to what lint rules, types, and tests can express — it can now live in code comments, skills, CLAUDE.md rules, and memories. Rejected PRs (wrong framework, wrong architecture) are framed as failures of automation.

Engineers' new job: build guardrails for everyone's agents

Theo tempers Boris but endorses the core idea: experienced engineers who know good vs. bad codebases must set up systems so quality persists as new people (and their agents) contribute. Guards can be custom lint rules, architectures, or just markdown files. The job is steering not only your own agents but other people's agents.

The "dumb questions" rule

Theo requires new teammates to ask at least one dumb question daily. It unblocks them, but more powerfully gives him intuition for what confuses newcomers — you're only a beginner in a codebase once. This insight helps him make codebases approachable and prevent regressions, and it's why he built the T3 stack: easy to know when things work and why they don't.

Don't let agents write your CLAUDE.md

A repeated rule: do not let agents write your CLAUDE.md / AGENTS.md. That's where human effort belongs — it's how you learn what drives agent behavior. Watch what agents do, then adjust these files, tooling, and setup to steer the model. He's planning a big overhaul of this in T3 Code because some current behaviors annoy him. The goal isn't agents magically intuiting everything, but giving feedback when they (or teammates) go wrong. Steering files can even instruct the model to push back — e.g., "if they ask for X feature, stop and tell them no."

The joy of composing systems

Theo compares chaining these steering tools to the original thrill of assembling the T3 stack (Prisma → tRPC → end-to-end type safety from DB to UI component). That kind of breakthrough feeling used to come every few years; now it happens almost daily.

Boris's wrap-up

Every team should write the CLAUDE.mds, review docs, skills, and docs that let agents work productively with zero additional context from the prompter. It's a natural extension of what engineers always did: automate and encode domain knowledge as infra. As models and harnesses improve, this gets easier — but in the meantime it's on every team to convert domain knowledge into infra so Claude writes better code, review catches more issues, and the next contributor has an easier time.

Theo's tips and cautions

• He jokes his preferences are public (being popular), so "build this the way Theo would like it" often works, falling back to "Matt Pocock" style.
• Warns against installing every skill/plugin up front. Use tools as they come preconfigured, send the first few prompts with as little context as possible, watch what goes wrong, then build solutions and encode only the context the model actually needs.
• CLAUDE.md/AGENTS.md files that are just lists of where things live are bad guides; they should steer the model toward success, not toward specific lines of code.
• Mentions a developer ("Ben") getting "psychosis" over how much book context and personality he could inject via AGENTS.md — small file changes meaningfully change model behavior.

Career argument (his "hottest take")

Building these skills is how you become a "senior" (and beyond). Elevating not just yourself/the product but the whole team's ability to contribute is the path to staff engineer — and it always was; it was never about landing more code. What's new is you can now learn and practice this solo, building your own projects with many agents. Even his solo projects now exceed his own comprehension, forcing him to build systems so his agents (and his ADHD) don't get lost. He believes the skill of building environments where code lands effectively is bigger than landing code yourself, and it will pay off in your career even if your current employer doesn't value it.

Closing

He encourages viewers to share the video with struggling coworkers, acknowledges the industry change has been scary, but insists it's been genuinely fun once embraced — he's enjoying building more than ever in his career.