Rašić argues that if code truly weren't hard, then type systems, code review, testing pyramids, refactoring, and design patterns — the entire body of engineering practice built up over decades — would be a collective mass delusion. He notes the people repeating the slogan are overwhelmingly executives who never shipped production code or founders selling code-generation tools, neither of whom bear the long-term maintenance cost.
Commenters cited Sourcegraph and GitClear data from late 2025 showing churn on AI-authored code running roughly 2x hand-written baselines within two weeks. They pointed to the Replit database wipe, Cursor auth-token leaks, and other rm -rf-adjacent incidents as evidence that agents produce syntactically valid code no one on the team actually understands.
The editorial argues that the rhetoric isn't merely annoying — it's a pricing strategy. AI-coding vendors bill on keystrokes saved rather than defects introduced, incidents caused, or the six-month rewrite that follows, and accepting the premise that coding is the bottleneck distorts how engineering teams are staffed and evaluated.
A blog post from developer Senko Rašić titled *"Code was never the hard part" is an insult to all programmers* hit 823 points on Hacker News over the weekend, with a comment thread that read less like a debate and more like a support group. The piece is a direct swing at a rhetorical move that's become inescapable in 2026: every AI coding vendor, every LinkedIn thought-leader, every VC deck now opens with some variant of *"code was never the hard part — the hard part was thinking, and now the AI does that too."*
Rašić's argument is short and unfashionably blunt. If code was never the hard part, then the last thirty years of engineering discipline — type systems, code review, testing pyramids, refactoring, design patterns, the entire body of practice we built precisely because code is hard — was collective mass delusion. The people saying it, he notes, tend to fall into two camps: executives who never shipped production code, and founders selling a tool that generates code. Neither has skin in the maintenance game.
The HN thread piled on with specifics. Commenters cited the Sourcegraph and GitClear data from late 2025 showing churn rates on AI-authored code running roughly 2x hand-written baselines within the first two weeks. Others pointed at the growing pile of postmortems — the Replit database wipe, the Cursor auth-token leaks, the parade of `rm -rf`-adjacent incidents — where the common thread is an agent that generated syntactically valid code that no one on the team actually understood.
The "code is easy" framing isn't just rhetorically annoying. It's load-bearing for a specific business model, and it's starting to distort how teams are staffed and evaluated.
The dirty secret of the AI-coding pitch is that it prices the work by keystrokes saved, not by defects introduced, incidents caused, or the six-month rewrite that follows. If you accept the premise that coding is the bottleneck, then a tool that 10x's coding output is worth paying for regardless of what happens downstream. If you reject it — if you believe, as most senior engineers do, that typing was maybe 20% of the job on a good day — then the ROI math looks very different. You're not buying leverage. You're buying a firehose of plausible-looking code that your seniors now have to review, own, and eventually rewrite.
The post lands harder because the counter-evidence is now visible in the wild. Stripe's engineering blog spent much of Q1 2026 documenting how they walked back agent-driven changes to their payment pipeline after a series of near-misses. GitHub's own internal telemetry, leaked in the summer, showed Copilot adoption plateauing among staff engineers even as it climbed among juniors — a pattern that reads less like "the seniors are dinosaurs" and more like "the seniors have seen this movie before." And Dan Luu's much-cited 2025 essay on maintenance costs put a number on the folk wisdom: roughly 70% of the total cost of any non-trivial system is incurred after the initial ship, and code that no human on the team can explain compounds that number, not reduces it.
The deeper problem the post gestures at, without quite naming, is that the industry has confused two very different activities. Writing code is the mechanical act of translating an idea into syntax. Programming is the ongoing negotiation between what the business thinks it wants, what the existing system will actually tolerate, what your teammates will be able to reason about in six months, and what will still be true after the next platform migration. AI is genuinely useful for the first. It is, in the current generation, actively harmful to the second when deployed without adult supervision — because it produces confident output in a domain where confidence without context is the failure mode.
There's also a labor politics reading here that the HN thread flirted with but didn't fully commit to. "Code was never the hard part" is a convenient thing to believe if you're trying to justify a hiring freeze, a layoff round, or a shift from full-time engineers to contract prompt operators. The framing does work that the underlying tools cannot yet actually do. That's a gap worth being suspicious of.
A few concrete things to take away, especially if you're the person in the room being told to "just let the AI handle it."
First, when someone pitches you an AI coding tool, ask for the numbers past the demo. Not lines-of-code-generated. Not tickets-closed. Ask for defect rates at 30 and 90 days, ask for the ratio of agent-generated PRs that survive without human rewrite, and ask for incident counts attributable to under-reviewed AI output. If the vendor doesn't have those numbers, that itself is the answer. The good tools — Cursor, Cody, Aider in agent mode — will now furnish them if you push. The bad ones will pivot to velocity metrics.
Second, treat generated code the way you already treat code from a new hire on day one: useful, potentially correct, and requiring the same review rigor. The teams that are actually getting value from agents in 2026 aren't the ones that gave up review — they're the ones that tightened it. Smaller diffs. Mandatory human explanation of what the change does before merge. Automated tests that the human, not the agent, wrote. The teams that skipped that step are the ones showing up in the postmortem feeds.
Third, and this is the one Rašić's post keeps circling: defend your understanding of your own system. The single most valuable thing a senior engineer owns is not their ability to write code — it's the map in their head of how the system actually behaves under load, under partial failure, under the specific weird thing that customer in Frankfurt does every third Tuesday. That map does not get built by reviewing agent output. It gets built by writing the code, breaking the code, and being on-call when the code breaks. Outsource that acquisition and you'll have a team full of people who can prompt but can't debug, which is exactly the composition of the teams currently generating the loudest incident reports.
The "code is easy" line will keep getting repeated, because it's useful to the people repeating it. But the counter-argument is now backed by two years of production data, and the trendline in senior-engineer sentiment — as visible in this HN thread, in the Stack Overflow 2026 survey, and in the growing crop of "we rolled back our AI coding pilot" writeups — is unmistakable. The next twelve months will separate the teams treating AI as a very fast, very confident junior from the teams that bought the vendor pitch wholesale. The bill for the second group is coming due in maintenance costs, and it's going to be an expensive lesson.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.