Stop Calling Coding "The Hard Part" — You're Insulting Every Engineer
In this article
> **Bottom line:** A post titled "Code Was Never the Hard Part" hit the top of Hacker News this month, and I decided to test the claim instead of just arguing about it.
I logged every minute of a 10-day, 46-hour side project built with heavy AI assistance (Claude 4.6 and ChatGPT 5) and found that literally typing or generating code took up just **12% of total time** — while reading, verifying, and fixing that code ate **41%**.
The "hard part" people dismiss as trivial — requirements, architecture, taste — accounted for 30%.
The remaining 16% was debugging a real production-style bug that AI code introduced.
The takeaway: the part everyone's calling "not the hard part" is actually the majority of the job, and it's the part that still requires knowing how to code.
I've seen this phrase everywhere since AI coding tools got good: "coding was never the hard part." You've probably seen it too — on X, in product demos, in some founder's LinkedIn post about how their non-technical cofounder shipped a whole app in a weekend.
It sounds humble. It sounds wise, even. And it is, quietly, one of the most insulting things you can say to a working engineer.
So instead of writing another take, I ran an experiment.
I tracked every single minute of a real 10-day project, built with AI doing most of the actual code generation, to find out how much of engineering is really "just coding" — and how much is everything people claim is the "real" hard part.
The Setup
The project: a webhook retry system with exponential backoff for a small SaaS tool I run on the side. Real feature, real production stakes, nothing contrived.
I used **Claude 4.6** for the bulk of code generation and **ChatGPT 5** as a second opinion on trickier logic, which is roughly how I already work day to day.
I logged everything in Toggl, broken into four buckets: writing/generating code, reading and verifying code, requirements and architecture decisions, and debugging.
No fudging the categories after the fact — I picked the bucket before I started each task block, not after I saw how it made my argument look.
Ten working days. **46 hours total.** Here's how they broke down.
Round 1 — The Part Everyone Talks About
The first two days felt like the hype videos.
I described the feature, Claude 4.6 spat out a retry queue with exponential backoff, a dead-letter table, and reasonable-looking tests in about four minutes.
I was smug about it. This was the "coding isn't the hard part" moment people keep posting about.
Then I actually read the code.
The backoff math was fine.
The idempotency handling was not — the generated retry logic had no idempotency key on the webhook delivery, which meant a slow endpoint could get the same event delivered three or four times during a retry storm.
That's not a nitpick. That's a bug that would've silently double-charged customers in a billing webhook.
**Nobody prompted me to check for that.** I checked because I've built retry systems before and knew where the bodies are usually buried. That knowledge didn't come from AI.
It came from years of getting paged at 2 a.m.
Round 2 — Where the Real Time Went
This is where the numbers stopped being cute and started being uncomfortable.
Writing/generating code: 5.5 hours (12%)
This is the part everyone's talking about when they say "coding was never the hard part." And on its own, they're not wrong — generating syntactically correct, reasonably-structured code is fast now.
**Genuinely fast.** I'm not going to pretend otherwise.
Reading, verifying, and fixing generated code: 19 hours (41%)
This is the part that quietly ate the whole project.
Every function Claude or ChatGPT produced needed a human who could actually read code fluently to check it against edge cases, security assumptions, and how it would behave under load.
I caught three bugs that would've shipped straight to production if I'd just skimmed and merged.
Catching those bugs wasn't a "vibes" skill. It required the exact same technical depth that "coding was never the hard part" implies you no longer need.
Requirements and architecture: 14 hours (30%)
This is the bucket the HN post was defending as the *real* hard part — deciding what to build, how it should behave, what "done" means. I don't dispute that this is hard. It is.
But it's not hard in a way that's separate from coding; it's hard in a way that requires understanding what code *can* and *can't* do cleanly.
Debugging: 7.5 hours (16%)
The idempotency bug alone took most of this.
Finding it wasn't a five-minute fix — it required tracing through async retry timing, understanding at-least-once delivery semantics, and rewriting the queue logic with a proper dedupe key.
**That's a distributed-systems problem.** You don't solve that by being "not a coder, but a great product thinker."
The Results
Add it up and the "hard part isn't coding" crowd gets the framing exactly backward.
- **Writing code: 12%** of total time - **Verifying and fixing code: 41%** of total time - **Requirements/architecture: 30%** of total time - **Debugging: 16%** of total time
That means **57% of the total project** — verifying/fixing plus debugging — was work that's still fundamentally *coding skill*. Not typing speed. Not syntax memorization.
The actual craft of knowing what correct, safe, maintainable code looks like and being able to spot when it isn't.
The 12% that shrank is the part that was always the least valuable anyway — the typing. What didn't shrink, and arguably grew, is the judgment required to know whether the typing was any good.
What This Means for You
If you're an engineer reading "coding was never the hard part" and feeling your jaw tighten, you're not being precious.
You're responding correctly to a claim that's quietly redefining your entire skill set as clerical work.
If you're a founder or product person who's shipped something real with AI assistance, good — genuinely, that's a great use of these tools. But be honest about what you're leaning on.
If you can't independently spot an idempotency bug, a race condition, or a security hole in generated code, **you're not doing the hard part either — you're trusting someone else's judgment and not naming it.** Usually that someone is an engineer on your team, or the pattern-matching in the model itself, trained on decades of code written by people doing the hard part the old-fashioned way.
And if you manage engineers: the skill that's becoming *more* valuable right now isn't typing code faster. It's the 41% — the reading, verifying, and catching-what-AI-missed.
That's not a junior task you can hand off. It's often the most senior thing on the team.
The Twist
Here's what actually surprised me. I expected the "hard part" — requirements and architecture — to dominate the clock. It didn't. **Verification did, by a wide margin.**
The uncomfortable implication is that AI hasn't eliminated the hard part of coding.
It's shifted it sideways, from *writing* code to *judging* code — and judging code well requires everything a good engineer already had.
The phrase should probably be flipped entirely: coding was never *just* typing.
It was always the judgment. That part didn't get easier. It just got busier.
Have you tracked your own time since leaning on AI for code generation? I'd bet your "verification" bucket is bigger than you think — try logging it for a week and see where you land.
---
