“Code Was Never the Hard Part” Is a Lie — And AI Is Proving It

“Code was never the hard part.” You’ve heard it. Maybe from a VC explaining why your team is being cut in half. Maybe from a product manager who just discovered Claude Code. Maybe from a founder who hasn’t written production software since 2019. The claim has become a rhetorical weapon in 2026 — a convenient frame for 80,000 tech layoffs that attributes the cuts to inevitability rather than choice.

This week, Senko Rašić published a direct rebuttal that hit Hacker News with 243 points and 170 comments. He’s right. But he only got half the argument. The other half is sharper: AI — the very tool supposedly proving that code is easy — is failing at exactly the things that make coding genuinely hard. That’s not a coincidence. It’s the point.

What the Claim Actually Says (and What It’s Being Used to Say)

There’s a defensible version of “code was never the hard part”: understanding what to build, who will use it, and why it matters are undervalued skills. Product thinking matters. Requirements are legitimately complex. Good engineers who can’t communicate or understand users are less useful than the combination suggests they should be.

That version is mostly true. But it’s not the version circulating in board meetings and headcount reviews. The version getting used goes like this: AI handles the code, so we need fewer engineers. The “hard part” — the human part — is the product vision and the business logic. Writing code? That’s commodity work now.

Rašić has a simple counter: if coding is so easy, why has it commanded six-figure salaries for decades? Why do top companies run grueling technical interviews? Why do programmers like John Carmack achieve something close to folk hero status among their peers? “If coding is easy,” he writes, “why is software so damn buggy?”

The answer is that good code — at scale, over time, in systems that evolve — is genuinely difficult. Architecture, debugging, system coherence, knowing when to refactor and when to hold: none of that is easy. Calling it easy is not a compliment to product managers. It’s just wrong.

The Irony: AI Is Failing at the Hard Parts

Here’s the argument Rašić didn’t make, and it’s the one that ends the debate.

If code were truly the easy part, AI would have solved it by now. Instead, AI coding tools are failing precisely where coding gets hard. A JetBrains survey of over 600 developers found that “lack of context” and “limited understanding of complex code” beat even hallucinations as the top failure mode. AI tools can generate functions. They cannot reason about what happens when ten microservices call each other in sequence with shared state and a stale cache.

Bito AI’s research on large codebases documented the failure pattern: AI tools misuse internal APIs that no longer exist, follow patterns that used to be correct but have since changed, and miss upstream data shape mismatches. Worse, the failures compound. Hundreds of individually plausible AI edits can gradually make a codebase unrecognizable. Untangling architectural drift of that kind takes quarters, not sprints.

Boris Cherny at Anthropic put it plainly: “You can absolutely vibe code with AI models, but it’s not the thing you want to do all the time. These tools remain not great at coding in production systems.”

That’s not a criticism of Anthropic’s models. It’s a description of what coding actually is. The parts AI handles well — boilerplate, scaffolding, greenfield features — are the easy parts. The parts AI fails at — debugging novel failures, maintaining architectural coherence, reasoning about system history — are the hard parts. The evidence is right there in the tools themselves.

The Data Is Unambiguous

AI-generated code contains 1.7 times more major issues than human-written code. Forty-five percent of AI-generated samples contain OWASP Top-10 vulnerabilities. Code churn is up 41 percent; code duplication has quadrupled. Sixty-three percent of developers who used AI-generated code report spending more time debugging it than writing the equivalent themselves would have taken.

A comprehensive analysis of vibe coding adoption found one data point that cuts through the noise: senior engineers with ten or more years of experience show 81 percent productivity gains from AI tools. Junior developers show much smaller gains. Why? Because the senior engineers know what to catch. They can evaluate AI output because they can write the equivalent themselves. Their coding expertise — the supposedly easy part — is exactly what makes AI coding usable at all.

What Developers Should Actually Do

Ignore the dismissal. The engineers who come out of this period intact are the ones who understand code deeply enough to catch what AI gets wrong, think architecturally, and can debug production failures without a model holding their hand.

The “code is easy” framing does the most damage to junior developers. They’re the ones being told not to bother learning fundamentals because AI will handle it. Then they ship vulnerabilities they can’t identify, build architectures they can’t explain, and maintain systems they don’t understand. Enrichlead — an indie developer who built an entire SaaS with Cursor and couldn’t sustain it when users hit real edge cases — is a preview of what that looks like at scale.

Code was always the hard part. It was hard before AI, it’s hard with AI assistance, and the tools that were supposed to prove otherwise keep getting stuck on the same things that have always required judgment, expertise, and deep system knowledge. That’s not a coincidence. That’s the definition of “hard.”