You write a prompt, AI generates the code, you push it, and go to lunch. But reality is a little different. And at times, quite unpleasant.
Gergely Orosz, author of The Pragmatic Engineer newsletter, noticed something that annoyed him every day: on Claude.ai, text would regularly disappear as he was writing a prompt. The page would load, the text field would reset, and the first few words would vanish. A basic bug that would not pass muster even in a prototype. Yet millions of Anthropic's paying customers experience it every day. No one noticed until Orosz posted about it on social media.
The paradox? Anthropic generates more than 80% of its production code using Claude. In other words, using its own tool. And yet a bug like this still made it into production.
Speed at Any Cost
Anthropic is not alone. Amazon experienced a series of outages directly linked to its Kiro AI agent. One of them lasted 13 hours and occurred because the agent was given too much freedom and decided to delete and recreate the entire environment. The result? An outage of a less frequently used AWS service and an internal meeting where Vice President Dave Treadwell told employees verbatim: "Web and infrastructure availability has not been good lately."
Amazon subsequently introduced a new rule: junior and mid-level developers must have AI-assisted changes approved by a senior developer. A step back to prevent further damage.
And Meta? It tracks AI token usage when evaluating employee performance. Low token usage by a developer with average performance? A clear sign that they are "obviously a weak performer." The pressure to use AI is thus no longer a recommendation but a matter of career survival.
Experienced Developers Are Slower with AI. Really.
The METR research organization measured it: experienced developers working on familiar codebases were 19% slower with AI tools than without them. A figure that surprised many. How is that possible? AI is supposed to make things faster.
Marco Martinez of Coder explains it simply. The developer is no longer just a creator but has become a reviewer. The code arrives instantly, but determining whether it is any good takes time. And that is precisely where time is lost. The code looks functional but fails in production. Or it works, but is so bloated and difficult to maintain that six months later no one even wants to open it.
Yet none of this is new. Version control systems, automated tests, CI/CD pipelines. All of them initially slowed developers down. They had to stop, learn a new way of working, and overcome the friction. AI is just another turn on the same merry-go-round.
The Trust Gap
A 2025 Stack Overflow survey revealed an interesting figure: 84% of developers use AI tools, but only 33% trust them. That is an enormous gap. Developers trust compilers because they are predictable. An AI model is probabilistic. One time it writes perfect code; the next, it silently introduces a bug that does not surface until a month later.
This trust cannot be bought through marketing. It is built through repetition. Teams that put AI-generated code through the same review processes as any other code gradually found that small changes began to pass without causing anxiety. But it took time. And it required patience that not every company has.
Dax Raad, founder of the open-source AI agent OpenCode, warns that AI tools lower the bar for what makes it into production at all, discourage refactoring, and ultimately do not make teams faster. Sentry's CTO and other startup founders are observing the same thing: AI removes the barrier to getting started, but produces bloated, difficult-to-maintain code that hampers long-term development.
Those Who Survive Will Be Faster. But They Have to Persevere.
So what should we do? Give up on AI tools? That would be the wrong conclusion. Coder.com sums it up well: teams that took the time to establish the right habits and were willing to be slower for a while are now moving faster and making fewer mistakes. Their documentation is better, problems are identified faster, and test coverage has improved. But it took months, not days.
Developers with a solid grasp of architecture are becoming more valuable than ever. Not because they do not use AI, but because they know when to trust it and when not to. They can recognize when a model is "confidently getting it wrong."
Orosz suggests returning to some old principles: formal validation, stronger QA processes, and senior oversight of AI-assisted changes. Nothing revolutionary. Just common sense applied to a new tool.
