Cursor, Claude Code, and Codex All Have a Big Problem
- https://www.youtube.com/watch?v=73F6ZURl1MQ
- Original title: Cursor, Claude Code and Codex all have a BIG problem
Theo argues that Cursor, Claude Code, and Codex all share the same root problem: they were built too early and too aggressively by dogfooding the very AI models they ship, and that bet has quietly wrecked their codebases. Unlike compilers written in their own language, vibe-coding a coding tool with a weak, early model (Sonnet 3.5/3.7-era) locked in bad patterns that no later model can fully undo, because agents copy whatever pattern is easiest to find in a codebase, and bad patterns are always easier to find than good ones. The result, he says, is the visible daily flakiness users experience: Cursor's UI shuffling around and one-click credential leaks, Claude Code's dropped image pastes, silent input loss, and un-recoverable compaction failures, and generally sluggish, non-deterministic terminal input across CLIs including OpenCode.
Codebase inertia and the 6-month ceiling
Every codebase hits a quality plateau roughly 3-6 months after focused work begins; after that point the existing patterns and dependency choices are essentially locked in, and things only get worse, never spontaneously better. Good patterns in a codebase grow linearly as people copy them, but bad patterns grow exponentially, because bad code is convenient code, and agents (like junior engineers) preferentially copy whatever they can find fastest. Claude Code and Cursor both passed their 6-month mark while running on genuinely weak models, so the slop they generated then is still compounding today, even though the underlying models (Opus 4.6, Codex 5.3) are now excellent. A model can't be better than the code it's asked to build on.
Why the tools feel broken day to day
Theo walks through concrete failures: Cursor removed its agent/editor toggle for a "customizable layout" that broke muscle memory and now leaks his email on open; Claude Code doesn't block input while compressing pasted images, so messages get sent without attachments, images silently double-attach to the next message, and a botched compaction can permanently kill a work thread with no recovery. He contrasts this with expectations from the pre-AI era (Sublime Text-level polish) and says the CLI-is-simpler-than-an-IDE promise has been broken by non-determinism baked into the underlying code.
How to keep a codebase healthy under AI agents
He offers a working playbook: optimize for ease, clarity, and speed so small changes touch few files and big changes touch many (the opposite is a common architecture mistake, and part of why he dislikes GraphQL relative to Tailwind-style locality); tolerate nothing — kill bad patterns the moment they're spotted rather than deferring cleanup, since "later" never happens; use a simple litmus test where you ask an agent to explain a feature, and if it can't answer well within a few minutes, the code is bad and should go. Because rewriting is now cheap (agents can port or replace large chunks of code fast), "sledgehammer" rewrites of bad sections are worth doing far more often than in the past — as long as they're preceded by real planning-mode conversations with the model that produce a reviewable markdown plan before any code is generated.
Other recommendations
Always use the latest available models (don't let organizational lag pin you to weaker ones); be far more willing to throw away code instead of patching it; and aggressively keep unrelated features out of your main codebase by making it trivial to spin up new repos/services, rather than stuffing one-off internal tooling into a shared production codebase (he illustrates this with a Twitch safety-tooling incident where a proposed permaban button nearly got added to the public site instead of an internal tool). Finally, always interrogate the agent's choices — ask why it did something a particular way, trace whether the bad idea came from the codebase or from your CLAUDE.md, and fix the source rather than just the symptom.
The "two codebases" idea
Drawing an analogy to Vampire Survivors — prototyped freely in Phaser/JS, then hand-ported by a separate team into a polished C++ version for consoles — Theo speculates that AI-era teams may increasingly maintain two parallel codebases: a disposable "slop" version used to rapidly prototype and validate ideas (including with real users), and a separate, carefully engineered version that only receives the ideas proven to work. He notes his own team at T3 is experimenting with this pattern for an upcoming project (T3 code), and that a large share of his own PRs already function this way — thrown-away scaffolding that shows intent, later rebuilt properly by teammates. He closes by rejecting the idea that AI coding tools make engineering skill less relevant — if anything disciplined codebase hygiene now matters more, since agents will happily multiply whatever mess already exists.