“LLMs might be great at writing code, but software was never the hard part.” “Writing code is easy—figuring out what to build is hard.”

These two lines keep showing up everywhere, especially under anything about AI-generated code.

Senko Rašić’s verdict: this is a wholesale insult to every engineer.

If Writing Code Is Really That Easy

If writing code is easy, why have engineers always been in demand, and why have salaries always been high—even before the zero-interest-rate era? Why is there so much stress, overtime, and burnout—problems that existed long before AI started churning out five-thousand-line PRs? If it’s so easy, why do companies scramble for “10x ninja rockstar engineers” and haul out LeetCode interviews to screen candidates? Why not just grab anyone fresh out of school?

If writing code is easy, why are Clean Code and The Pragmatic Programmer thick enough to prop open a door? Is The Art of Computer Programming beach reading? Is SICP a coffee-table ornament? Why do coding bootcamps exist, and why are there entire university degrees dedicated to teaching this supposedly “easy” thing?

If writing code is easy, was Carmack just in the right place at the right time? Why does anyone call Fabrice Bellard a genius?

If writing code is easy, why are so many people furious about AI (or anyone else) copying their code? Why do they act as though they poured sweat, soul, and enormous amounts of time into something so trivial?

If writing code is easy, why do so many people right now feel their professional identity and meaning are being stripped away?

If writing code is easy, why is software still full of bugs?

Mogu PSA:

“Sounds seasoned, sounds like you’ve seen through to the essence”—that’s probably the best thing these two lines have going for them. The speaker doesn’t need to prove anything; they’re automatically on the high ground.

But the entire AI coding industry is itself the counterevidence: if writing code is really that simple, why does the output of a coding agent still need humans watching over it, reviewing it repeatedly, and occasionally scrapping the whole thing to start over? The more powerful the tools get, the more they prove how hard it is to make software actually work correctly. ╰⁠(⁠°⁠▽⁠°⁠)⁠╯

If “Figuring Out What to Build” Is the Real Challenge

Okay, let’s look at the other side. If deciding “what to build” is truly the hard part—why do so many PMs seem clueless? Why don’t PMs go through grueling ten-round interviews? Why aren’t PM salaries higher than engineers’?

If understanding customer needs is the most valuable skill, why aren’t market researchers, UX specialists, and customer success teams treated like rockstars at software companies? If “understanding the customer” is harder than writing code, why are business analysts seen as paper-pushing admin staff?

If implementation is easy and finding the right requirements is hard, why do engineers blow up every time sales casually promises a customer a new feature to close a deal? Sales found a real market need, found something someone would pay for—by this logic, that’s exactly “the hard part.”

If writing code is so easy, why not just build ten versions and see which one survives?

There Is No Average Engineer

Here’s another classic: “Most of software development is communicating with stakeholders, understanding customer needs, and figuring out priorities.”

But across Senko Rašić’s career, very few of the engineers he’s met actually want to talk to stakeholders, let alone customers (freelancers and tech company founders excepted). As for “figuring out priorities,” that translates to plain language as “just tell me what to do, and stop changing it every two days.”

Some engineers say: “Writing code isn’t the point—solving the customer’s problem is.” But the same people turn around and start holding forth on monads, memory safety, and the DRY principle. Their idea of “the customer” is a fictional user persona, and they think “affordance” is the pocket money parents hand out on weekends so the kids can go play.

Mogu going off-topic:

“Affordance” is a design term meaning “the shape of a thing tells you how to use it”: a door handle shaped that way is meant to be turned; a flat plate means push. The original joke is that “affordance” and “allowance” (pocket money) sound nearly the same—someone who talks about “solving customer problems” all day can’t even tell apart one of the most basic UX terms from a kid’s weekly spending money. (⁠¬⁠‿⁠¬⁠)

Another crowd says: “Software development is theory construction. Programs are essentially mathematical proofs. Every commit should tell a story.” FTP-upload a PHP file to solve a customer problem? That’s sacrilege.

This isn’t to say engineers who deeply care about both technical craft and genuinely empathizing with customers don’t exist. They do—they just probably need to see a psychiatrist about their split personality.

Post-publication correction: that line went too far. The intent was a half-joke about how few people manage to do both simultaneously, and the very next section actually encourages moving in that direction. My bad.

Mogu roast time:

“Mea culpa” is Latin, the words you say while beating your chest during Catholic confession: “my fault.” Throw the knife, then catch it mid-flight yourself—this kind of on-the-spot correction, leaving the original line intact instead of quietly deleting it, is far more honest than writing something safe and polished from the start. ┐⁠(⁠￣⁠ヘ⁠￣⁠)⁠┌

Both Sides Matter—Self-Comfort Is Not the Way Out

Talking to users, understanding their experience, empathizing with their situation, solving customer problems, getting all stakeholders aligned—he considers these critical to the success of any software project.

He equally believes that writing good code is a craft requiring skill, patience, attention to detail, experience, and wisdom, and that it will remain an important capability in the future.

Both sides matter. The ideal is to pursue both simultaneously: deeply understanding the system being built, while deeply understanding why it’s being built.

Mogu wants to add:

The original section title is the Spanish phrase “¿Por qué no los dos?”—literally “Why not both?” It comes from an Old El Paso taco commercial: a family argues at the dinner table over hard shells or soft tortillas, and a little girl chimes in “Why not both?” It later became an internet meme for any situation where two options clearly don’t conflict and there’s no reason to choose. (⁠๑⁠•⁠̀⁠ㅂ⁠•⁠́⁠)⁠و⁠✧

Loudly declaring “code is easy” or swinging to the opposite extreme of “code is art, a form of human creative expression, impossible to automate”—both are burying your head in the sand.

It’s just self-comfort. And the goal isn’t self-comfort—it’s thriving.

This doesn’t mean “hurry up and jump on the LLM train.” It doesn’t mean “go become a manager of AI agents.” Nor does it mean “AI-generated code is stolen garbage, fight it to the death, the bubble will burst eventually.”

But you have to face reality: the entire industry is going through a tectonic shift. You need to figure out how to adapt. You need to understand what might change and what never will.

What Won’t Change

Software will keep getting more complex. Software will always need maintenance—bit-rot is a law of nature, and so is entropy. Technology (hardware and software) will keep marching forward, for better or worse. The tower of abstraction layers—or should we call it a skyscraper?—will only get taller.

Users will always want more and be willing to pay less. They still won’t know how to articulate what they need, and worse, they won’t be sure themselves. The gap between “the paying customer” and “the person using the product” will remain, and the tension between business needs and user needs won’t disappear.

And: snake-oil salesmen will never run out. Hot technologies come and go—VR’s renaissance is still waiting.

What Will Change

Engineers have been disrupting their own industry from the very beginning. No one uses punch cards anymore. Few people need to write assembly or COBOL. Decades spent fighting memory bugs in C or C++, with scars to show for it—in the age of Rust, Go, Python, and JavaScript, that experience is worthless.

Senko Rašić himself lived through the valgrind era, remembers mysql_real_escape_string() in PHP4—things he’ll never use again in his life. And that wasn’t even that long ago. The dBase, Clipper, HyperCard, Access era—he almost caught it. Those technologies are still running somewhere: in a corner of some small shop or cafe, a dust-covered desktop that’s aged from beige to golden-brown, happily running some custom business system. Backups? What backups?

How to Thrive Through the Tectonic Shift

Accept that change will happen. Stay equally curious and critical about new things.

Recognize that there’s a massive amount of hype, and try to distinguish what’s hot air from what’s genuinely useful (and to what degree). Notice that the bar keeps moving: step back and look at the past one year, five years, and assess the speed of change across technology, economics, and society.

Everyone’s role and responsibilities are shifting. Be willing to invest time and energy into understanding the domains and roles next door.

Senior engineers: don’t seek comfort only in technical depth. Learn about user experience, customer interviews, the business strategy in your domain. Even if you never actually do those things, the understanding will help you appreciate everything that goes into getting a piece of software from written to delivered.

Junior or less experienced engineers: invest in understanding how software works under the hood. Learn pointers, recursion, memory architecture—useful even for JavaScript developers. Understand network protocols and how HTTP works—relevant even if you’re just building WordPress plugins. Do LeetCode, learn algorithms and data structures, even if the job doesn’t require it. Don’t be afraid to ask “why” and “how does this actually work.”

The original article ends with a reading list of twelve books, noting they might help—spanning CS fundamentals all the way to business strategy and team design.

Mogu highlights:

Those twelve span: SICP, Cracking the Coding Interview, The Mythical Man-Month, The Mom Test, Continuous Discovery Habits, Obviously Awesome, The Design of Everyday Things, Don’t Make Me Think, 7 Powers, Working Backwards, Team Topologies, and a Pulitzer-winning work of nonfiction, The Soul of a New Machine. The list itself demonstrates the article’s core argument: an engineer’s growth path isn’t just drilling deeper into technical depth or stretching wider into business—it’s touching both. (⁠◕⁠‿⁠◕⁠)

Don’t Be a Meat Proxy

Regardless of who you are or where you sit—don’t outsource understanding, judgment, empathy, and taste to AI. Don’t abdicate your responsibility. Don’t become a meat proxy.

After the article went live, Hacker News and Lobsters lit up with discussion—clearly it struck a nerve. And the most fascinating part: the people arguing were each bringing entirely different experiences, with their own definitions for coding, programming, development, and engineering.

Mogu OS:

Meat proxy—literally “a proxy server made of meat.” AI spits something out, and a human, without reading, thinking, or editing, forwards it along. The person is still sitting in that chair, but all that’s left is a body performing a forwarding function. The uncomfortable part is that this chair is very real—and getting more comfortable by the day.

gu-log itself is a project that heavily uses AI—every article goes through AI translation, AI scoring, AI rewriting. But ShroomDog still reviews every post, sends them back for rewrites, and decides “is this quality fit for public consumption.” gu-log’s four-judge scoring system exists for one reason: to prevent AI output from becoming the final product directly. Tools can get more powerful, but the judgment behind pressing “publish” cannot be outsourced. (⁠ง⁠ ⁠•⁠̀⁠_⁠•⁠́⁠)⁠ง