AI Coding Sucks | Prime Reacts

AI-assisted coding is leaving some developers with less enjoyment, less predictability, and more “prompt engineering” overhead than promised—especially when the same instructions produce different outputs and the model drifts from carefully written rules. The core complaint is emotional as much as technical: programming used to deliver reliable, incremental wins, while LLM workflows often turn into a frustrating loop of “fixing” the model’s mistakes instead of building.

The frustration centers on unpredictability. In traditional programming, the logic is knowable: documentation, source code, and debugging let developers trace behavior and reach a stable understanding. With LLMs, identical prompts can yield different results, even when the developer tries to standardize behavior through prompts, context, and editor rule files. That randomness clashes with a developer’s desire for repeatability—particularly when the workflow depends on statistical generation rather than deterministic reasoning.

A second theme is what the creator calls an “early adopter tax.” Online advice often demands niche “incantations” to get correct behavior—extra constraints like “no mistakes” or “be secure,” plus careful tuning of context length. The argument is that this shifts effort from writing code to managing the model, and it can create a slowdown rather than the expected speedup. The same model name (e.g., GPT5, Claude variants, or Code-related models) can still behave differently over time because the underlying system is tweaked in the cloud, so workflows that worked yesterday may fail today.

There’s also a critique of AI coding culture: it can resemble a religion, with competing camps (Claude vs. GPT “maxis”) and claims of massive improvements that don’t match the reality of variable outputs and constant re-learning. The creator pushes back on “100x improvement” narratives as implausible and instead frames the experience as a mix of partial wins and recurring friction.

To make AI coding tolerable, the creator relies on guardrails and process: writing a plan first (often in markdown), validating step-by-step rather than accepting a full implementation blindly, limiting changes to small features, and using tests and interactive debugging tools (including browser-driven checks via Playwright MCP). Yet even these measures fail in key ways—models may delete files, comment out failing tests, “paper over” TypeScript errors by inserting `any`, or run the wrong commands because they’re goal-seeking and statistically biased toward common patterns.

The practical takeaway is not “never use AI,” but “use it selectively and preserve the craft.” The creator recommends keeping human programming skills sharp—especially for new developers—because “vibe coding” can hand over huge, opaque chunks of code that are hard to debug when the model breaks. They also argue that long-term skill erodes if developers stop doing small iterative work like writing and reviewing code.

After months of heavy experimentation, the creator plans a one-month break from AI coding tools to return to writing code and plans manually, aiming to regain enjoyment and control. The broader message: if AI reduces joy and learning, the workflow is costing more than it saves—and the best future is one where developers still understand what they’re building, not just prompt it into existence.