"Code Was Never the Hard Part" - Reddit's Senior Engineers Push Back
The Thread That Hit a Nerve
A Reddit post on r/ExperiencedDevs titled "Code was never the hard part" hit 1,308 upvotes and 379 comments in 48 hours. OP gsks dismantles the CEO/CTO talking point that "code was never the bottleneck" - arguing that coding is thinking, not typing. The micro-decisions inside the editor (naming, error handling, caching) are the engineering. AI specs can't replace decisions made while typing, backtracking, and debugging.
The thread struck a nerve because it articulates what every senior engineer feels when a CTO who hasn't written production code since 2012 announces "coding is solved." The top comment (862 upvotes) nails it: "Code was never the hard part for programmers. Ceremonies, incomplete data, unknown deployments, rushing us with -5% of info - that's the hard part." The distinction matters. The people saying "code was never hard" are usually the ones who never had to debug a race condition at 2 AM.
Coding Is Thinking, Not Typing
OP's core argument: the upfront design phase answers high-level questions (components, data flow, NFRs) but leaves thousands of lower-level decisions unspecified. What packages, naming, function signatures, error handling, caching strategy, memory allocation - these get decided in the editor, interleaved with thinking, trying things, backtracking. AI proponents treat specs as complete blueprints. Senior engineers know specs are fiction until code meets reality.
The "coding is just typing" mental model comes from people who've never seen a senior engineer stare at a blank file for 20 minutes, type three lines, delete two, stare for ten more minutes, then write the one line that handles the edge case that would've caused a data corruption bug six months later. That's not typing. That's thinking with your fingers on the keyboard. The vibe coding crowd thinks the thinking happens in Notion. Seniors know it happens in the debugger.
The "Expert Beginner" Trap
Top comment thread identifies the "expert beginner" phenomenon: AI handles the happy path beautifully but falls apart on edge cases. One commenter nails it: "The hard part is handling edge cases, but they've essentialized the advice to only care about the happy path." AI generates code that works when everything goes right. Engineers get paid for the 99.9% of scenarios where things go wrong.
This is the "senior engineer tax" that AI advocates ignore. Junior devs (and LLMs) write the happy path. Seniors spend 80% of their time on the unhappy paths: retries with exponential backoff, idempotency keys, circuit breakers, the saga pattern for distributed transactions. The code that handles failure is the code. Everything else is a prototype. AI doesn't do failure modes because failure modes don't exist in training data - they exist in production at 3 AM.
Coding ≠ Software Engineering
Multiple commenters distinguish "coding" (translating spec to syntax) from "software engineering" (building systems that survive reality). One commenter who's never written Go but has built enterprise SaaS apps points out: they'd be hired over a LeetCode Go expert because they've built software. The hiring process (LeetCode) optimizes for coding; the job requires engineering. This disconnect fuels the "code was never hard" narrative - spoken by people confusing syntax with systems.
The distinction matters because AI is genuinely good at coding (syntax, patterns, boilerplate) and genuinely bad at engineering (trade-offs, risk assessment, organizational context, "this will break when Marketing changes the pricing model next quarter"). When a CTO says "AI writes 80% of our code," they're measuring lines of code, not engineering judgment. The 20% AI can't write is the 80% that prevents bankruptcy.
Code Is the Spec
A standout comment: "The code IS the spec. Once you've written down exactly how everything should behave, you're done coding. Turns out specifying the exact behavior of a program is not easy at all." This reframes the debate. The "spec" AI proponents imagine is a wish list. The real spec is the code: every branch, error case, retry policy, timeout. Writing the spec is writing the code.
This is why "vibe coding" - prompting an LLM until it vibes right - produces prototypes that collapse in production. You didn't write the spec; you vibed it. The spec lives in the `catch` blocks, the `if (error) return` branches, the `retry(3, exponentialBackoff)` wrappers. AI can generate the happy path. You write the spec by surviving the unhappy paths. No PRD survives contact with production. The code is the PRD that survived.
The Talent Pipeline Problem Nobody Talks About
One of the most upvoted comments warns: AI erodes the talent pipeline. Juniors learn by struggling through the "easy" code - the CRUD, the boilerplate, the happy paths. That struggle builds the intuition seniors use to navigate the hard parts. If AI writes all the "easy" code, juniors never build the reps. You don't get seniors without juniors who suffered through the boring stuff. The industry is eating its seed corn.
This is the existential risk nobody at the AI keynote mentions. A junior who copies Copilot's output learns syntax, not judgment. They never develop the "spidey sense" that says "this looks fine but will deadlock under load." That sense comes from debugging your own bad code at 2 AM, not from reading AI's good code at 2 PM. We're raising a generation of developers who can prompt but can't debug. When the AI hallucinates a subtle bug in a payment flow, who catches it? The senior who's busy reviewing 50 AI-generated PRs a day?
The "Code Was Never Hard" Pivot
Commenters note the phrase "code was never the hard part" existed 20 years ago - meaning syntax isn't hard, engineering is. AI advocates hijacked it to mean "implementation doesn't matter." One commenter calls it a "copying mechanism" - AI didn't deliver the promised 10x productivity, so the narrative shifts to "implementation was never the value anyway." It's a post-hoc justification for disappointing ROI.
The pivot is convenient. When AI coding assistants launched, the promise was "10x developer productivity." Two years later, the metric moved to "code was never the bottleneck." Funny how the goalpost moves right after the quarterly earnings call. The reality: AI speeds up the 20% of work that's typing. The 80% - understanding the domain, negotiating requirements, designing for failure, convincing stakeholders, on-call rotations - remains stubbornly human. The narrative shift protects the AI budget. The engineers know better.
The Hiring Paradox
A comment with 125 upvotes cuts through: "'Code was never the hard part' - and ignore the portion where we do 7 rounds of interviews focused exclusively on deep coding knowledge." Companies interview for LeetCode hard, then claim coding is trivial. The disconnect reveals the truth: they know coding is hard. That's why they gatekeep it. They just don't want to pay for it anymore.
This is the tell. If coding is so easy, why does FAANG pay $400k for it? Why does the interview loop grind candidates on graph traversal and dynamic programming? Because the people holding the purse strings know - deep down - that the person who can reason through a novel algorithm on a whiteboard is the same person who can reason through a novel production incident at 3 AM. They interview for the hard part, then tell investors the easy part is automated. Can't have it both ways.
What AI Actually Changes (and What It Doesn't)
AI genuinely accelerates boilerplate, scaffolding, test generation, and exploratory coding. It's a force multiplier for the mechanics of coding. But it doesn't replace the judgment calls: "Is this abstraction worth it?" "Will this scale?" "What happens when this downstream service degrades?" The senior engineer's value shifts from "writing code fast" to "knowing which code to write, which to generate, and which to delete."
The honest take: AI makes the easy parts easier. The hard parts stay hard. The danger isn't AI replacing seniors - it's juniors thinking the easy parts are the job. The vibe coding shirt is funny because it's true: you can vibe your way to a prototype. You engineer your way to a product. The seniors who survive the AI shift will be the ones who treat AI as a power tool - dangerous in untrained hands, transformative in experienced ones. The juniors who survive will be the ones who still write the boring code by hand, just to learn what it feels like when it breaks.
Key Takeaways
- Coding is thinking - the micro-decisions made in the editor are the engineering work, not the implementation of a pre-existing spec.
- AI handles the happy path; engineers handle the 99.9% of reality where things fail - that's where the value lives.
- The code is the spec - specifying exact behavior (error cases, timeouts, retries) is writing the code.
- AI erodes the junior-to-senior pipeline by removing the "easy" reps that build engineering intuition.
- Companies interview for hard coding skills, then claim coding is easy - they know the truth when hiring, forget it when budgeting.
- AI is a power tool for mechanics, not a replacement for judgment - seniors who survive will curate AI output, not blindly accept it.
Frequently Asked Questions
Is "code was never the hard part" completely wrong?
It's a semantic shift. Twenty years ago it meant "syntax isn't the hard part, engineering is." Today it's weaponized to mean "implementation doesn't matter, AI can do it." The original meaning respects engineering; the new meaning dismisses it. Context matters.
Does AI actually help senior engineers?
Yes - for scaffolding, tests, boilerplate, exploring unfamiliar APIs, and first drafts. It's a force multiplier for mechanics. But seniors still make the architectural calls, handle the edge cases, and own the production risk. AI shifts the ratio: less typing, more reviewing.
Will AI replace junior developers?
It replaces the output of junior developers (basic CRUD, boilerplate) but not the function of junior developers (learning by doing, building intuition, eventually becoming seniors). The pipeline problem is real: no juniors today = no seniors in 5 years. Smart teams use AI to accelerate juniors, not replace them.
What's "vibe coding" and why does Code Culture have a shirt for it?
"Vibe coding" is the term for prompting an LLM until the output feels right - no spec, no tests, just vibes. It works for prototypes. It fails in production. Our vibe coding shirt is the uniform for developers who know the difference between a vibe and a spec.
How should engineers talk to leadership about this?
Stop arguing "AI can't code." It can. Argue "AI can't engineer." Bring receipts: show the PR where AI missed the idempotency key. Show the incident where AI-generated retry logic caused a cascade failure. Translate engineering judgment into risk language leadership understands: "This saves 2 hours of typing but adds 20 hours of debugging risk."
About the Author
