"Code was never the hard part" is an insult to all programmers
The Fallacy of "Code is Easy": A Defense of the Programmer
By Senko Rašić (Rewritten) Date: August 8, 2026
The software engineering landscape is currently experiencing a seismic shift. While the ultimate destination of the AI revolution remains a mystery, it is undeniable that the nature of our work—and the act of programming itself—is being fundamentally altered.
Recently, a specific narrative has gained traction: the idea that LLMs are merely automating the "easy" part. You've likely heard it: “LLMs might be great at writing code, but the code was never the hard part,” or “Coding is trivial; the real challenge is figuring out what to build.”
To me, these statements are nothing short of a gross insult to the global community of programmers.
The "Easy" Paradox
If the act of coding is truly so simple, we are left with a series of glaring contradictions. Consider the following evidence:
| The Claim | The Reality |
|---|---|
| "Coding is easy" | Programmers have commanded massive salaries and high demand for decades (long before the ZIRP era). |
| "It's a trivial task" | The industry has been plagued by chronic stress, overwork, and burnout long before AI started generating 5,000-line Pull Requests. |
| "Anyone can do it" | Companies obsess over "10x ninjas" and put candidates through grueling LeetCode gauntlets. If it were easy, a fresh graduate could do it all. |
| "No skill required" | We have massive "doorstopper" books like Clean Code and The Pragmatic Programmer to guide the craft. |
Furthermore, if coding is a breeze:
- Why do we have specialized bootcamps and four-year university degrees?
- Was John Carmack simply "lucky" with his timing?
- Why is there such visceral anger when AI models train on stolen code?
- Why do developers feel as though their very identity and professional purpose are being erased?
The Myth of the "Hard Part"
The counter-argument suggests that defining the product is the actual challenge. But if that were true, the corporate hierarchy would look very different:
"If deciding what to build is the primary difficulty, why are so many Product Managers seemingly clueless?"
If "understanding the customer" were the peak of the mountain:
- Market researchers would be the "rockstars" of the company.
- Usability experts would be the highest-paid employees.
- Customer Success managers would be the most revered.
- Business analysts wouldn't be dismissed as mere "pencil pushers."
Moreover, if implementation is the easy part and finding demand is the struggle, programmers should be thrilled when a salesperson promises a feature to close a deal. After all, the salesperson has done the "hard part"—they found a paying customer! Instead, developers are usually furious.
If coding were truly effortless, the market would be flooded with people launching ten different versions of every idea just to see which one sticks.
The Fragmented Developer Identity
There is a common cliché that software development is mostly about stakeholder management and priority alignment. In reality, most programmers I've known avoid stakeholders and customers like the plague (unless they are founders or freelancers). For many, "clarity on priorities" is just a polite way of saying: Please tell me exactly what to do and stop changing your mind every 48 hours.
We often see a strange dichotomy in developer personas:
While some rare individuals manage to balance deep technical craft with genuine customer empathy, they are the exception.
Navigating the Tectonic Shift
I believe that solving a user's problem and maintaining stakeholder alignment is critical. However, I also believe that writing high-quality code is a craft requiring wisdom, patience, and precision. It will remain relevant.
The goal should be a synthesis:
We must avoid the two extremes:
This isn't a call to blindly join the LLM hype train or to become a "manager of AI agents." Nor is it a call to dismiss AI code as "stolen slop" and hope the bubble bursts. It is a call to recognize that we are in a period of industry-wide transformation.
What Changes vs. What Stays the Same
| Constant (Never Changes) | Variable (Changes) |
|---|---|
| Software requires maintenance (Bit-rot is inevitable). | Specific languages and frameworks. |
| Hardware and software will continue to evolve. | The "Tech du jour" (e.g., the VR cycle). |
| Clients will struggle to articulate their needs. | The tools we use to manage memory. |
| Tension between Business needs vs. User needs. | The specific syntax of a PR. |
Programmers have always disrupted their own industry. The decades spent fighting memory leaks in C or C++ are largely irrelevant in the era of Rust, Go, Python, and JavaScript. I remember the days of mysql_real_escape_string() in PHP4—knowledge that is now completely useless.
I barely missed the era of dBase and HyperCard, yet I still see those systems running in old cafes on beige golden-brown midi-towers (probably without any backups).
The bottom line: There is immense hype surrounding us. Our job is to discriminate between the noise and the signal.