▶ YouTube Summaries

• https://www.youtube.com/watch?v=GcNu6wrLTJc
• Original title: Delete your CLAUDE.md (and your AGENT.md too)

Theo argues that Cursor, Claude Code, and Codex are all buggy and inconsistent not because the underlying models are weak, but because the tools themselves were built too early by "vibe coding" with immature models (Sonnet 3.5/3.7), and codebases that start out sloppy never recover. He lays out why this happened, why it's structurally hard to fix, and a set of concrete practices for keeping a codebase (human- or agent-maintained) from decaying the same way.

The core claim: dogfooding backfired

Normally, dogfooding your own tool (writing a C compiler in C) is good practice. But Cursor, Claude Code, and Codex all committed to writing themselves with AI models far too early - back when Sonnet 3.5/3.7 was state of the art and "impressive" but not capable of serious, reliable engineering. Anthropic's own blog bragged about using Claude Code internally on Sonnet 3.7 in February last year (2025); Theo says you simply cannot build a serious application on that model. The result: these tools' own codebases were slopified from month one, and it shows in daily use - broken UI toggles in Cursor (the agent/editor mode switch was removed for no good reason and never replaced), Claude Code's non-deterministic input handling (dropped/duplicated pasted images, stuck compaction, dead threads after hitting context limits), and sluggish, laggy CLIs (Claude Code and OpenCode both fail to register early keystrokes).

Codebase inertia: the 6-month rule

Every codebase reaches a quality plateau roughly 3-6 months into focused work, and that plateau is essentially the best it will ever be - things only get worse from there unless you deliberately intervene. Patterns established early get copied constantly ("the easiest pattern to find is the one that gets reused," rarely the good one), so bad code compounds exponentially while good code only grows linearly. AI agents accelerate this dramatically: a coding agent will happily copy whatever pattern already exists in the repo because "it's in the codebase, so it must be fine." If a codebase's 6-month mark was already full of slop written with weak, early models, no amount of later effort - or better models - will save it, because newer models are much better at extending good patterns than at cleaning up bad ones.

Why Cursor and Claude Code specifically are stuck

Cursor inherited the extreme complexity of a VS Code fork nobody on the team had originally built, making it hard to reconcile upstream changes; Theo suggests it may be time for them to start over. Claude Code has no such excuse - it was greenfield - but because Anthropic insists on writing effectively all of its code with Claude Code itself, the slop has compounded to the point that buying Bun's creator/team (to rewrite the JS runtime in Zig) looks like a workaround for performance problems the tool caused for itself, rather than fixing the actual code.

How to avoid the same fate

• Optimize for ease, clarity, and speed: small changes should touch few files, big changes should touch many - not the reverse. Fewer services/abstractions to touch per change (why Tailwind feels good, why GraphQL often feels bad).
• Tolerate nothing: bad patterns multiply faster than good ones because bad code is usually the convenient code. Don't accept "we'll fix it later" - later means never. If something smells, remove it immediately regardless of deadlines.
• Watch how long agents take to explain or complete things: if an agent can't explain a feature well in under ~3 minutes, or a simple task takes it too long, that's a signal the code around it is bad and should be thrown out.
• Don't be afraid of the agent, and don't be afraid to delete code: since agents make big rewrites cheap, sledgehammer-style replacement (deleting and rebuilding a broken area from scratch) is now viable in hours instead of the 50+ days it used to take a human team. Spend real time in planning mode with the model, write and actually read the plan, then have it execute.
• Use the best available model, don't stay on outdated ones for cost/approval reasons.
• Keep unrelated things out of the main codebase: features that only serve a handful of internal users (his Twitch "permaban button" story) should live in their own service/repo rather than bloating the primary codebase. It's now trivial to spin up new services, so there's no excuse to keep piling one-off features into a shared codebase.
• Interrogate the agent's choices: ask why it did something, and trace the answer back - either to a bad pattern in the codebase (delete it) or to instructions in CLAUDE.md/AGENTS.md (fix those).

The two-codebase idea

Theo floats a model borrowed from Vampire Survivors' development: the creator prototypes and iterates freely in a "slop" JavaScript/Phaser version in the browser, then a separate team ports validated ideas into the polished, reliable C++ production version. He suggests AI-native teams (including his own, building "T3 code") may want to formalize this: use fast, disposable "vibe coded" branches/PRs to test ideas and UX, then have a smaller set of people or a second pass turn validated ideas into the actual maintained codebase - "file twice, merge once" instead of merging everything cheap code produces.

Takeaway

Theo isn't anti-AI-coding - he thinks skilled engineers matter more than ever, because agents are extremely good at amplifying whatever patterns (good or bad) already exist. The tools people rely on today (Cursor, Claude Code) are themselves case studies in what happens when you let agents write everything without enough diligence early on, and he doesn't expect their existing codebases to get better - only for the products built on top of them (through eventual rewrites) to improve.