Rašić argues the AI industry's entire business model — SWE-Bench benchmarks, coding-tuned models, IDE agents, Cursor's valuation — is built on generating code, which contradicts the claim that code is trivial. You cannot simultaneously call a task low-value and pour hundreds of billions into automating it; the framing exists to justify replacing programmers, not to describe reality.
Notes that the 'the hard part is X, not Y' framing is always deployed by people trying to sell you a product that does Y. Veterans of previous automation waves point out this exact rhetorical move has played out repeatedly — reclassifying skilled labor as clerical to make its replacement sound like efficiency rather than deskilling.
The editorial argues this is a debate about who gets to describe the industry's own labor. Calling code 'the easy part' reclassifies programmers as clerical workers while positioning PMs, founders, and execs writing prompts as the ones doing the 'real' thinking — the same rhetorical move that devalued professional photographers when cameras got easier to use.
A blog post by Senko Rašić titled "'Code was never the hard part' is an insult to all programmers" hit 324 points on Hacker News this week, sitting near the top of the front page for most of a day. The piece is a direct rebuttal to a talking point that has quietly become the default framing at every AI-tooling keynote of the last eighteen months: that writing code is a mechanical, low-value activity, and that LLMs finally free engineers to do the *real* work of thinking about problems.
Rašić's argument is short and pointed. If code was never the hard part, he asks, why is the entire AI industry organized around generating it? Every major model release is benchmarked on SWE-Bench. Every IDE is scrambling to ship an agent. Cursor's valuation, Copilot's revenue, and Anthropic's coding-tuned Sonnets all sit on the premise that producing code is valuable enough to build a category around. You cannot simultaneously claim that a task is trivial and that automating it is worth a hundred billion dollars.
The HN thread underneath is unusually consensus-driven for HN — over 400 comments, most of them agreeing, several from people who've spent decades watching this exact rhetorical move play out in previous automation waves. The top comment notes that "the hard part" argument is always deployed by people trying to sell you something that does the allegedly-easy part.
This is not a debate about tooling. It's a debate about how the industry describes its own labor, and who gets to set that description.
The "code was never the hard part" framing does real work. It reclassifies programming as clerical, which makes replacing programmers sound like efficiency rather than deskilling. It also conveniently positions the person deploying the LLM — the PM, the founder, the exec — as the one doing the *actual* thinking, because they're the ones writing the prompt. It's the same move that "anyone can be a photographer now" made to working photographers after phone cameras improved, or that "anyone can be a designer" made after Canva shipped. In every case the sentence is technically defensible and practically corrosive to the people whose craft is being flattened.
What Rašić puts his finger on, and what the comment thread reinforces, is that the sentence conflates three genuinely distinct activities: typing code, producing correct code, and producing correct code that solves the right problem in a system you have to maintain for five years. Typing has always been the easy part — every senior engineer has known this since roughly their second job. Producing correct code is medium-hard and gets easier with good tools, LLMs included. Producing correct code that fits a real system is the actual job, and no benchmark measures it because it doesn't fit in a benchmark.
There's a benchmark gap that makes this worse. SWE-Bench Verified numbers look great — recent frontier models score in the 60-70% range on isolated GitHub issues with clean repro steps. But the same models fall off a cliff on tasks that require understanding *why* a system is shaped the way it is, or that require pushing back on a spec that would create tech debt. The parts of the job that resist automation are precisely the parts the industry keeps insisting were never the job in the first place.
There's also a labor-market subtext that's worth naming directly. Junior developer hiring is down sharply in 2025 — some large tech employers are running under half their 2022 new-grad intake. "Code was never the hard part" is a very convenient thing to believe if you're the person deciding whether to open those requisitions. It gives you a story that lets you cut the pipeline without admitting you're cutting the pipeline.
The practical read for a senior engineer is that nothing about your day has actually changed, but the political framing around it has.
Use the tools. Copilot, Cursor, Claude Code, Codex — they genuinely make the typing faster, and the typing was never the bottleneck anyway, so you get back the 15% of your day that was mechanical. Fine. But when someone senior says "code was never the hard part" in a planning meeting, understand what's being set up: the next sentence is usually about headcount, or about shipping faster with a smaller team, or about a junior role that isn't going to get refilled. The phrase is a budget document dressed as a philosophical observation.
The second practical implication is on how you scope AI-generated work. Reviewing LLM output is a distinct skill from writing code, and it's harder than it looks — the failure mode is code that compiles, passes tests, and quietly does the wrong thing in production three weeks later. The teams doing this well are treating generated code with roughly the same suspicion they'd apply to a contractor they've never worked with: high-detail specs upfront, aggressive test coverage, and a review process that assumes the author didn't understand the system.
The third is about your own career surface area. If the industry is going to insist that the valuable work is "understanding the problem" and "making tradeoffs," then that is where you should be visibly operating. Write the design doc. Own the incident postmortem. Push back on the spec in writing. The people who survive automation waves are always the ones whose work product isn't the artifact that got automated.
The interesting thing about Rašić's post isn't that it's correct — most working engineers already believed this — it's that it's finally getting traction. For eighteen months the "code is easy now" framing went essentially unchallenged in tech media, because the people best positioned to challenge it were also the people most worried about looking like Luddites. That's shifting. Expect more posts like this one, expect them to keep hitting the HN front page, and expect the AI-vendor messaging to quietly pivot from "we replace developers" to "we augment developers" over the next two quarters. The economics haven't changed. The pitch is just getting sanded down.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.