Cursor, Claude Code and Codex all have a BIG problem

AI coding assistants like Cursor, Claude Code/Cloud Code, and Codex are failing in a way that’s easy to miss: they don’t just rely on today’s models—they inherit the same engineering shortcuts, UI churn, and “ship fast” code quality that those models were trained and built around. The result is a growing mismatch between what developers need (stable UX, predictable behavior, maintainable codebases) and what these tools deliver (non-deterministic actions, inconsistent interfaces, and brittle underlying implementations). The practical takeaway is blunt: betting on AI to code early can accelerate sloppiness, and sloppiness compounds.

A major thread runs through the complaints: these tools feel unreliable not only because model outputs vary, but because the surrounding software ecosystem changes constantly and often poorly. Cursor’s interface is used as an example of how product decisions can break workflows—specifically, the removal of an “agent/editor toggle” that users relied on to switch modes quickly. The change layout and sidebar behavior become inconsistent, hotkeys shift, and even basic safety concerns show up, such as an email “leak” button being reachable in the editor. The frustration isn’t just annoyance; it’s workflow disruption—opening the app can trigger UI shifts, and small interaction problems can become recurring hazards.

Claude Code/Cloud Code is framed as worse because the failures are deeper and more chaotic. Image pasting in a terminal/CLI context can involve local compression and asynchronous upload, but input isn’t blocked while attachments process. That leads to messages being submitted without the image, then later attachments appearing in unexpected ways, including race conditions where a still-processing image silently attaches to a later message. In one described sequence, repeated attachment failures and compression errors eventually hit a context limit and kill the entire thread—work gone with no recovery. The pattern is described as a “slot fest”: it doesn’t fail the same way twice, which makes debugging and trust nearly impossible.

Underneath the UX breakdown is a structural claim about codebases over time. Code quality tends to improve early, then hits a plateau around 3–6 months; after that, it’s downhill unless teams actively prevent decay. AI coding tools accelerate both the good and the bad, but the bad expands faster. As codebases grow, the easiest patterns to copy are often the worst ones, and AI systems can replicate those patterns across the repository—especially when they’re encouraged to reference existing code. The speaker argues that no model can outperform the quality of what it starts with, and many of these systems start from “garbage” code written earlier under the same vibe-coding incentives.

The proposed fix is less about better models and more about stricter engineering discipline: optimize for clarity and speed of change so small edits touch few files; tolerate zero bad patterns because bad code multiplies; and treat “smells” as urgent—remove them immediately rather than waiting for deadlines that never arrive. There’s also an operational suggestion: use planning-heavy workflows with agents, read the plan, and upgrade to newer model capabilities. Finally, the most radical idea is to separate prototyping from production—maintain a “slopfest” version for experimentation and a clean, reliable version for shipping, similar to how Vampire Survivors reportedly evolved from browser Phaser.js to a C++ console version while iterating in the easier environment.

In short: these tools aren’t doomed because AI is inherently bad; they’re doomed because AI accelerates the maintenance and quality problems already embedded in the software they’re built on. The path forward is to build codebases that can survive faster iteration—by preventing slop from entering, and by rebuilding when slop has already won.