Things that used to be features, or even whole products, can now be a prompt or a markdown file. That is Theo Browne's claim on the MEGA podcast with Joel Hooks, premiered October 5. The interesting half is what he does not throw out.
#Own the stack the agent runs in
Theo built T3 Code because he and Julius wanted the Codex app, and then wanted it on their own terms. It is an open-source interface for running Codex, Claude Code, and other coding harnesses. The same sessions run on a computer, in the browser, and in a React Native app already on the App Store for iOS and Android, with a SwiftUI rewrite on TestFlight. His machines sit on a tailnet, so he can reach a session from a different computer without rebuilding the workflow for each one.
The point of opening it is the same point as the old T3 stack. People who want to go deep can read how it is put together. Theo's audience, he says, is the person who has already gone past the tutorial and feels a bit alone. The channel worked because that person wanted the nerdy version.
#They wake up on the first day, every time
Joel asks whether skills survive. Theo's picture of an agent is a talented engineer in the world's worst Groundhog Day. Every task resets the brain. Everything learned last time is gone. Endless first day on the job.
That is why the durable part cannot live only in a chat. Standards you care about go in files the next agent will see: what good looks like, what to check before it claims the work is done. Theo already uses lint, TypeScript, and end-to-end tests to catch errors before they become his problem as the reviewer. The new move is the same shape for taste. Encode what the team cares about in markdown and tell the agent to check it before it gives a thumbs up.
He is also blunt about the other failure. A lot of people use the model to skip understanding. His advice is the opposite: automate the parts you do not like of the work you do care about. If you do not understand the work, you cannot tell a preference from a real defect, and the agent will not either.
#Plan mode was the paper calendar
Theo thinks about iOS 6. Up through that release, Apple made the phone look like the physical objects it was replacing. A wooden bookshelf. A paper calendar that turned pages. A compass on a wooden table. People had to be convinced the glass rectangle could do the job, and Apple did not yet know a better shape than the object they were copying.
Then people grew up without the physical calendar. iOS 7 dropped the costume and designed for the thing the software actually does. You can fit more capability into a flat interface than into a skeuomorphic knob for every feature.
He thinks agent tools are still in the iOS 6 era. We pretend Git has to look the way it has for decades, that a terminal is the only serious interface, that you have to read every line or you do not understand the system. Plan mode was both a map of how we used to work (plan, then do) and an honest reflection of models that needed the plan written down. He has watched it fall off. The replacement is not "stop thinking." It is a loop the model can run: break the work up, review it with a separate pass, test it in a browser. He gets close to that now by telling Codex or Claude to spin up sub-agents, with no new product required.
We're still a little bit in that skeuomorphic era, where we're trying to pretend the way we've used Git for the last three decades matters.
#The gates get more valuable, not less
Joel asks about the old T3 reasons for type safety, lint, tests, and CI. Theo's answer is that he leans on them more, not less, once an agent is allowed to move.
A full-stack TypeScript pipeline that errors on the client when a column is renamed is how he sees the consequence of a change without reading every file. Preview environments are the other half. His favorite Vercel feature is the one that gives every pull request a real preview, idle at no cost when nobody is on it. He had built that kind of CI himself. Having it as a default meant teammates could click, check, and merge, and he could spend the saved time on whether the change solved the user's problem.
Verifying the solution should be as simple as looking at the solution. Anything that makes you pull, build, and wait is time you are not spending on the user.
#A bench that describes the trick
Most frontier models, Theo says, score in the 82 to 88 percent range on Skatebench. One model hits 95. He does not ask it to name the trick. The bench describes the trick by its physics: which way the board is going, which way the skater is going, which axis spins. The interesting part is what a model can judge when the question is a description of motion, not a label from a list it memorized.
That is the same shift as the rest of the conversation. Describe the outcome. Let the model reach it. Keep the type system, the tests, and the preview, because those are how you know it got there.
