InsideTheStack: What Nobody Tells You Before You Go All-In on Claude Code

I use Claude Code every day. I am building a product with it right now. And I am going to tell you what the viral posts will not.

The internet has decided that Claude Code is the most important developer tool since GitHub Copilot. Maybe since Git itself. Posts about it are pulling millions of views. Engineers from Google, OpenAI, and Anthropic are publicly declaring that software engineering as we know it is over. Non-technical founders are building and shipping apps over a weekend.

Some of this is real. Some of it is not. The problem is that almost nobody is separating the two.

The wave

The Claude Code content explosion started during the 2025 holiday break. Boris Cherny, the Anthropic engineer who created Claude Code, posted his workflow stats: 259 PRs in 30 days, 497 commits, 40,000 lines added. That post hit 4.4 million views. A week later, his setup walkthrough reached 7.9 million views with over 100,000 bookmarks.

Jaana Dogan, a Principal Engineer at Google, tweeted that she gave Claude Code a three-paragraph problem description and it generated what her team had spent a year building. That post hit 8.8 million views. She later clarified it was a toy version, not production code. But the clarification did not travel as far as the original claim.

Andrej Karpathy, former head of AI at Tesla and the person who coined the term "vibe coding," declared a phase shift in software engineering. He said he had moved from 80% manual coding to 80% agent coding in two months.

Bloomberg ran a cover story calling it "The Great Productivity Panic of 2026." Fortune said the excitement was rarely seen since ChatGPT's debut. The New York Times ran "This A.I. Tool Is Going Viral."

This is not a niche tool anymore. It is a cultural moment.

What the viral claims look like

If you scroll through tech Twitter or LinkedIn right now, you will see a consistent pattern.

"Built a SaaS in 11 minutes." "100% of our code is written by Claude Code." "Replaced my engineering team." "A year's work in an hour." "Built a full app and I do not even know how to code."

These posts come with screenshots, screen recordings, and real products you can click on. They are not fabricated. The demos are real.

But a demo is not a product. A prototype is not a production system. And a weekend project is not a business.

What the research actually says

The most important piece of evidence in the entire Claude Code conversation is a study that almost nobody in the content ecosystem has engaged with seriously.

METR, a research organization focused on AI evaluation, ran a randomized controlled trial in mid-2025. They tracked 16 experienced open-source developers across 246 tasks on real, mature codebases averaging over a million lines of code and more than ten years old. These were not toy projects. These were the kind of codebases that real companies actually maintain.

The result: developers using AI tools took 19% longer to complete tasks than developers working without them.

That alone would be noteworthy. But the perception data is what makes this study important. Before the experiment, the developers predicted AI tools would make them 24% faster. After the experiment, having been objectively measured as 19% slower, they still believed AI had helped them. They estimated they had been about 20% faster.

That is a 43-point gap between perceived and actual productivity. The developers genuinely believed they were faster when they were measurably slower.

This is not a one-off finding. Google's DORA 2024 report, which tracks software delivery performance across the industry, found that for every 25% increase in AI tool adoption, delivery stability decreased by 7.2% and throughput dropped by 1.5%. At the same time, 75% of developers reported feeling more productive. Same perception gap, different study, same result.

The code quality problem

Speed is only one dimension. Quality is the other, and it is worse.

CodeRabbit analyzed 470 real GitHub pull requests in December 2025, comparing AI-generated code against human-written code. AI-generated PRs contained roughly 1.7x more issues. The specific breakdowns matter: 2.74x more cross-site scripting vulnerabilities, 2.25x more algorithmic and business logic errors, 2.29x more concurrency control mistakes, and 3x more readability problems.

GitClear's analysis of 211 million changed lines of code from 2020 to 2024 found that copy-pasted code surged from 8.3% to 12.3% while refactored code collapsed from 25% to under 10%. Code churn, meaning lines revised within two weeks of being written, nearly doubled from 3.1% to 5.7%. The code is being written faster. It is also being rewritten faster because the first version was not right.

The Stack Overflow 2025 survey put numbers on developer frustration. 66% said their biggest problem with AI tools is solutions that are "almost right, but not quite." 45% said debugging AI-generated code takes longer than writing it themselves. Only 29% trust AI output accuracy.

And 77% of professional developers said vibe coding is not part of their work. The loudest voices in the Claude Code conversation are, by definition, not representative.

The $13,540 bug

The most instructive failure story I found comes from a developer named Devrim Ozcay.

He had a race condition in a payment processing system. The manual fix would have taken about 12 lines of code and 2 hours of work. He asked Claude to fix it instead.

Claude generated a clean 45-line solution in 8 minutes. The code looked good. It handled edge cases. All tests passed. He deployed it to production.

Over the next three days, 12 new bugs emerged. Deadlocks under concurrent load. A memory leak consuming 420MB in 24 hours. Database connection pool exhaustion. And the original race condition was still there.

The original bug had occurred 3 times and cost nothing. Claude's fix occurred 847 times and cost $13,540 in direct impact.

This is not an argument against using Claude Code. It is an argument for understanding what it is actually good at and what it is not.

Where it actually delivers

I use Claude Code daily for the CarYaar MVP build. Here is where it provides genuine, measurable value.

Understanding large codebases quickly. When you drop into a new project or a section of code you have not touched in weeks, Claude can map the structure, explain the relationships between modules, and give you context in minutes instead of hours. This alone justifies the tool for many developers.

Boilerplate and CRUD tasks. Standard API endpoints, database models, form validation, configuration files. Tasks where the patterns are well-established and the risk of subtle errors is low. Claude handles these reliably and fast.

Rapid prototyping and exploration. When you want to test whether an approach works before committing to it, Claude lets you generate a rough version in minutes. The throw-away prototype is genuinely faster with AI.

Writing tests. Given a function and its intended behavior, Claude produces solid unit tests consistently. It is particularly good at generating edge case coverage that you might skip.

Refactoring with clear constraints. When the scope is well-defined (rename this module, extract this function, convert this callback pattern to async/await), Claude executes cleanly.

Where it quietly fails

Here is where it creates problems that you will not see in any demo video.

Complex multi-file architecture decisions. When a change requires understanding how five different modules interact, Claude tends to solve the local problem while breaking something in a module it is not looking at. The staff engineer at Sanity.io put it well: first attempt will be 95% garbage.

Context retention across long sessions. After an hour of iterative development, Claude starts forgetting decisions made earlier in the conversation. It suggests approaches you already rejected. It duplicates functions it already wrote. This is a fundamental limitation of how context windows work, and no amount of prompting fixes it.

Anything requiring judgment you cannot easily verify. If you do not understand the domain well enough to review Claude's output critically, you cannot catch the subtle errors. The METR study found developers accepted fewer than 44% of AI suggestions. That means more than half the time, the AI's contribution needed to be rejected or modified. If you do not know enough to reject the wrong suggestions, you ship bugs.

Edge cases in business logic. Payment processing, concurrent access patterns, regulatory compliance, security boundaries. The places where getting it 95% right is the same as getting it wrong.

The perception trap

The most important finding across all the research is not about speed or quality. It is about perception.

Developers consistently report feeling more productive while delivering the same or worse results. The bottleneck has moved from writing code to reviewing code, but the time savings on writing creates a powerful psychological illusion.

You feel faster because the typing is faster. But the thinking, the reviewing, the debugging, the integrating, and the deploying still take just as long. Sometimes longer, because you are debugging someone else's approach instead of your own.

This is not a reason to stop using Claude Code. It is a reason to stop lying to yourself about what it is doing for you.

The honest take

Claude Code is a genuine technological breakthrough wrapped in a content bubble.

The underlying capability is real. Opus-tier intelligence at $5 per million input tokens is historically significant. Non-technical people are shipping real products. Experienced developers are getting real leverage on specific task types. The tool has changed the economics of prototyping and exploration in ways that matter.

But the viral content ecosystem has amplified demo results into production promises. Speed runs into strategy. Individual anecdotes into industry truths.

The developers who get the most value from Claude Code are the ones who understand its failure modes as clearly as its strengths. Who know when to trust it and when to override it. Who treat it as a tool with constraints, not a replacement for judgment.

Go all-in if you want. I did. But go in knowing what the 7-million-view posts will not tell you.

InsideTheStack: how real systems actually work.