30초 요약
Theo Browne describes an intensive holiday experiment with Claude Code and Opus 4.5, building an image-generation studio, a mobile app and a distraction-blocking extension. His examples show both the scope of work an agent can take on and the value of a developer who can diagnose problems and supply clearer instructions. He discusses a missed nested repository, deployment friction, permissive execution and incomplete guardrails. His subscription and inference figures refer to a temporary promotion and are his own estimates, not current pricing.
- 1Diagnosing the first failed fixThe agent initially fails to fix scrolling; Theo clarifies which container should scroll and the next change works.
- 2Planning a mobile monorepoHe asks for a detailed conversion plan, then shows the agent working through installation errors and API changes.
- 3A missing applicationA nested repository causes the mobile app to be omitted from a merged change, revealing a gap in his review.
- 4Lowering the cost of side projectsHe builds an extension that blocks Twitter when no agent task is running and says faster development changes which ideas he tries.
- 5Limits of a safety netA plugin can intercept some destructive commands, but Theo notes that scripts and other tools can bypass such checks.
- 6A time-specific usage estimateHe compares his subscription usage under a temporary double-limit promotion with his own rough API-equivalent cost estimate.
핵심 정리
- Parallel agents and long-running sessions can make it practical to explore more ideas and interface variants.
- A developer’s ability to diagnose a failure and specify the desired behavior remains useful when an agent’s first attempt fails.
- Successful builds and automated review scores do not replace careful review of what was actually included or deployed.
- Permissive command execution and safety plugins have limits; Theo’s personal risk tolerance is unusually high.
- Theo’s pricing observations and model comparisons describe his experience at the time of recording.
챕터별로 다듬은 전문 읽기
Trying Claude Code at scale
Theo describes an intensive holiday experiment and a new workflow with multiple agents.
Over the holiday break, Anthropic temporarily doubled Claude Code rate limits, and I decided to see how much I could use. I ended up running six instances in parallel, building more than I expected and reconsidering how software development might change.
I knew Opus 4.5 had improved, but I did not expect it to change my own workflow so much. During the break I built two projects, made web and mobile versions of one, worked on T3 Chat features, and used Claude Code to configure my operating system.
The multiple terminal windows shown at the start were staged for this video, but they are close to how I have actually been working. Anthropic did not sponsor the video; I paid for the $200 monthly subscription. The separate sponsor message is omitted here.
Building the image studio
A live sidebar fix shows why clear specifications and coding experience still matter. He demonstrates image-generation and interface iteration.
One project is an image studio: a working prototype for exploring the image-generation experience I might want in T3 Chat. It began as a mock-up but now has a functional web interface, a mobile app, and a monorepo.
I notice that the sidebar will not scroll on my smaller recording screen, so I ask Claude Code to fix it. I specify that the problem is in the web app because the project has more than one application.
A new session has to rebuild its understanding of the codebase unless I resume an old one. For a medium-sized project, I have found it useful to stay in a long-running thread: the agent retains enough context to know where to start when I give it another task.

The first attempted fix does not work: scrolling still tries to move the whole page, while only the image grid has a functioning scroll container. I explain the distinction and ask for a different approach.
This is a good example of why these tools are much stronger when you already know how to code. Once I specify what is wrong with the scroll containers, the agent makes a working change: the sidebar fields scroll independently while the generate button stays fixed.
With the interface fixed, I generate images with three models. The backend uses Convex and the frontend uses Vite and Tailwind; I say Claude produced the interface. This is a demonstration of my own workflow, not a guarantee that the same prompt will work for every project.
The image studio has gone through five or six interface overhauls. One technique I use is to run the same redesign request in separate worktrees, or create three routes with the same feature, then compare the versions and ask the agent to combine the parts I like. I also used shadcn components.
The application can turn a generated image into a conversation. I select models, ask them to replace a sea lion with a corgi, compare the outputs, and then ask for another change to a sign. The gallery and chat views let me explore an image-generation workflow rather than simply produce a single picture.

There are still rough edges, but I enjoy testing the two-view interface. Convex keeps the data synchronized with the mobile app as well as the web interface.
A web and mobile monorepo
Theo asks the agent to plan and perform a substantial conversion. He describes installation problems, manual environment fixes and an omitted mobile app.
The prompt that surprised me most asked Claude Code to convert the project into a monorepo, keep the existing web app, and add an iOS-focused React Native app. I specified Expo, Expo Router, TypeScript, Bun, shared Convex bindings and Turborepo, and asked for a thorough plan.
I had expected this task to fail. Instead, the run took over an hour, with roughly twenty minutes spent on the plan. The plan laid out workspace configuration, new packages, the move of the web app, and the extraction of shared code. I gave it a quick review and told it to proceed.
The agent encountered installation errors, adjusted package versions, and continued until the build succeeded. It switched from Uniwind to NativeWind after problems, then corrected API calls in the mobile app. I watched it work through several failures instead of assuming the first result was right.
The mobile project still had problems. The Convex URL did not load properly, and environment variables were lost when I changed both to a monorepo and to a JJ workspace. I moved some files manually, and also encountered server-side errors associated with NativeWind.
The monorepo pull request added roughly 2,300 lines and removed 400. Greptile gave it a high confidence score, but I do not treat that as objective proof that the code is good. It was nevertheless striking to see the agent split the project into packages and build a mobile app.

There was an important omission: Expo initialization created a nested Git repository, and JJ ignored it. I merged the changes without noticing the mobile app was missing. Later I asked Claude for help, repaired my history, and added the app on another branch. The incident also shows how little I had reviewed at first.
The generated code still has rough spots: a very large TSX file and a keyboard-avoiding view that is not quite right. The mobile app does work, though, and a generation started there appears in the web interface because both share Convex.
From prototype to deployment
He shows synchronization across web and mobile, then explains the harder work of configuration and authentication. He would audit the result before exposing it to all users.
One reason this setup works well with an agent, in my view, is that Convex configuration lives in a folder in the repository. The model can edit code instead of having to operate a separate settings dashboard for every change.
The hardest work was getting the project into production: setting up Google Cloud tokens and configuring Clerk, Convex and Vercel. Authentication across the mobile app, web app and backend also spans several layers, even when using established tools.
The agent implemented authentication across those layers and produced a substantial change. I merged it, but I would not put that code in front of all T3 Chat users without a more thorough audit. The prototype is real work, not evidence that its security is already production-ready.
The project reached about 11,900 lines of code, all generated while I was using the $200 Claude Code tier. For me, the notable change is not just autocomplete or editing a handful of files; it is the ability to delegate a larger sequence of work.
A browser extension and smaller tasks
A distraction-blocking extension and scripts illustrate how lower effort changes which ideas he chooses to build.
Long-running jobs create a different problem: I get distracted and do not return when they finish. So I built a browser extension that locks me out of Twitter unless a Claude Code task is running. When the agent finishes, access is blocked again.
I would not trust this extension with my life, and I have barely inspected its code. But I built a side project in about half an hour instead of spending a day on it. The difference is not that I suddenly gained the ability to build it; it is that the smaller cost made the idea worth trying.
I had two agent instances working on the mobile app and a third on the extension. The extension, Claude Blocker, is on GitHub; at the time of the recording I had submitted it to the Chrome Web Store, where broader permissions could make review take longer.
The same shift applies to small personal tasks. I wanted to combine monthly Notion logs into one file, so I placed them in a directory and asked Claude Code to write and run scripts. I could have written the code myself, but previously I would have prioritized other work.
I also asked it to configure JJ commit signing to match Git and to create a Z shell script that makes a worktree, changes into it, and copies the project's environment files. These are examples of changing my local setup, not just editing a repository.
Permissions, guardrails and alternatives
Theo discusses his risk tolerance, a safety plugin, competing tools and the Ralph loop. He explicitly notes limitations and personal biases.
For someone new to coding agents, I would start with the normal mode that asks before edits, then consider auto-accept after gaining confidence. I use a mode that skips permissions, but my tolerance for a destructive mistake is unusually high: as a creator, even a disaster would give me material for a video.
I added the Claude Code Safety Net plugin to intercept some destructive Git and filesystem commands. It can offer another check, including in my permissive setup, but it is not comprehensive: a model can use scripts or other tools to work around restrictions. I describe it as one precaution, not a guarantee.
I still like Cursor when I need to inspect code and work as an engineer in an existing codebase; I also have an investment there, which is a relevant bias. For experiments, system configuration and long background tasks, I have been impressed by Claude Code.
OpenCode is also strong, particularly across different models, and I think it may be nearly as good with Opus. I chose Claude Code to try its updated harness and subscription directly; this is an evaluation from the time of the video, not a permanent ranking.
The Ralph loop is a script that keeps restarting an agent and asking it to continue until a higher-level completion condition is reached. I have found Claude Code often runs for an hour or two without such prompting, so I am not yet sure how necessary the loop is for my own work.
Rough edges and usage
He closes with usability complaints and a time-specific estimate of subscription usage and API-equivalent inference.
The experience is not free of rough edges. I still find hooks, plugin functionality, prompt editing, context compaction, history management and image uploads frustrating in places. My enthusiasm for the results should not be mistaken for a claim that the product is finished.
I used the $200 monthly plan during a period when the limits were doubled and ran multiple instances for much of the day. The dashboard showed a low percentage of the limit; my back-of-the-envelope estimate was about $1,500 in API-equivalent inference for that period. These figures describe that promotion and my own estimate, not current pricing.
As a subscriber I liked the apparent value, but as a company paying API prices for inference I questioned the economics. My view that API customers effectively subsidize subscriptions is my interpretation, not an accounting fact demonstrated by this experiment.
After several weeks, I have a different view of the kinds of projects I am willing to undertake and a better understanding of why people like this workflow. I am still learning how it will affect my work over the long term.
같은 채널의 다른 글
38:47EN
36:07EN
30:37EN
0:43EN
29:22EN
31:13EN