Why 'Code Was Never the Hard Part' Sets Programmers Off

There’s a line that shows up in nearly every AI coding tool launch, every VC blog post about the future of software: “Writing code was never the hard part anyway.” Last week, a post pushing back on exactly that sentence climbed Hacker News with 636 points. The technical content wasn’t new. The reaction was. So what is it about that one sentence that lands like a slap?

The line has an honest origin

“Code isn’t the hard part” didn’t start as AI marketing. It started as legitimate software engineering wisdom.

Fred Brooks drew the line in his 1986 paper No Silver Bullet, separating essential complexity from accidental complexity. Accidental complexity is the stuff tooling can eliminate: manual memory management, verbose syntax, build configuration. Essential complexity is understanding the problem and shaping a system around it. Brooks’s argument was that no tool improvement would ever deliver a 10x gain, because the remaining difficulty lives in the essential layer.

Almost every working developer agrees with that. The trouble is what happened to the sentence when it migrated into product marketing. Brooks meant “design is harder than typing.” The 2026 version means “typing is easy, so let the model do it and just describe what you want.” Same words, opposite conclusion.

Code isn’t a record of the design. It is the design.

The rebuttal’s core claim: the premise that writing and designing are separable activities is wrong from the start.

Anyone who has shipped software knows the feeling. The architecture is crystalline in your head. Then you open the editor and it collapses. Where does this function get its data? Who owns this piece of state? Is this error handled here or three layers up? Those questions don’t surface in a design doc. They surface when you type the thing and it doesn’t fit.

So code isn’t where you record a design. It’s where you falsify one. The compiler, the type checker, the test suite — they’re a machine for telling you your reasoning is inconsistent. Skipping that loop doesn’t produce a better design. It produces the same design, with the flaws discovered later, usually in production at an inconvenient hour.

Why the word was “insult”

The rebuttal was titled with the phrase “an insult to all programmers.” That’s not the register of a technical disagreement. That’s a nerve.

The context is decades long. Developers have been told coding is about to be automated roughly once every ten years. Fourth-generation languages in the 1980s. CASE tools. Visual programming. UML round-tripping. Then a decade of no-code and low-code. Every wave promised that non-programmers would simply specify what they wanted. Every wave ended with the same discovery: specifying precisely what you want, in unambiguous terms, with all edge cases resolved, is programming. The syntax changes. The job doesn’t.

There’s a second layer, and it’s sharper. The people who say this loudest tend to be the people furthest from maintaining anything. Building a demo and fixing a race condition in a three-year-old codebase are different jobs that happen to use the same keyboard. “Code is the easy part” is a statement generated entirely by the first experience. One comment in the thread summarized the gap cleanly: generation got dramatically faster, but the time it takes to read code and decide whether you trust it hasn’t moved at all. Every AI-authored pull request still needs a human who understands the system to sign off. That’s now the bottleneck, and it’s a human one.

The other side isn’t wrong either

To be fair, the “code isn’t the hard part” camp has real evidence.

Ask why software projects actually fail. It’s almost never a syntax error or insufficient algorithmic skill. It’s building the wrong thing. It’s two teams with incompatible mental models of the same API. It’s requirements that changed three times before launch. Make code generation ten times faster and the failure rate barely moves — you just arrive at the wrong destination sooner.

The two arguments are describing different altitudes. One is about why organizations ship the wrong product. The other is about how an individual engineer builds understanding of a problem. Both are true. The logic breaks the moment you use the first to argue the second is now optional.

Three layers of difficulty

Strip the argument down and programming difficulty sorts into three tiers.

Syntax and API surface. Which method, what argument order, how to configure the thing. AI has essentially solved this, and nobody is nostalgic for the era of memorizing standard library signatures.

Building structure through code. This is the actual battlefield. When a model emits working code, this layer gets skipped — and the understanding you didn’t build gets invoiced back to you later. Usually during an incident, at 2am, when the person who “wrote” it has no model of why it works.

Deciding what to build at all. AI barely touches this. It’s the layer Brooks was pointing at in 1986, and it’s still where projects live or die.

The question that lingers

The post got 636 points not because it revealed something new, but because it gave precise words to a discomfort a lot of engineers were already carrying. “AI writes good code” and “the experience of writing code is now obsolete” are separate claims. The industry keeps collapsing them into one.

Here’s what I keep coming back to. The instinct that makes a senior engineer look at generated code and say “no, this is wrong” — where does that come from? It comes from having written bad code and lived with the consequences. So what does the next generation, raised on accepted completions, use to build that same instinct? Nobody in this debate has answered that yet, and it’s the only part that actually compounds.