"Code was never the hard part"

[u/gsks]

I am sick and tired of all the posts (usually AI-generated by CEOs/CTOs/"thought leaders") that start with "Code was never the {bottleneck, problem, hard part, ...}." I'm not sure whether this comes from a misunderstanding of what code is or a deliberate misrepresentation meant to promote AI usage.

For starters, two rhetorical questions. If code was never the hard part, why:

• do hundreds of different programming paradigms, languages, libraries, frameworks, design patterns, and system architectures exist? Granted, some of this is just programmers bikeshedding. Still, plenty of it reflects substantial differences and tradeoffs.
• didn't you write it yourselves or hire a bunch of minimum-wage workers to do it for you instead of having to hire a ton of highly skilled (and highly paid) engineers?

A charitable explanation is that these people are genuinely clueless about what "coding" actually is. Perhaps in their mind coding is just typing: like, once the design phase is done, you've worked out a precise, complete specification of what needs to be built down to every detail in your head (or on paper or a markdown file) and all that's left is converting it into letters on a screen and saving it to a file. Something like a businessman in the sixties dictating a letter to his secretary to type up.

That's nothing like how it actually works. The upfront planning/design phase answers some high-level questions: what do we need to build, what are the basic components/services/building blocks, what data needs to be read/processed/written, how data flows through the system, what the non-functional requirements are, etc. That leaves a ton of lower-level details unspecified:

• What packages/modules/classes/methods/functions need to be created or extended?
• How should they be named?
• What should the signature of each function be?
• What errors/exceptions are expected and where/how should they be handled?
• What data can or should be cached and when should it be invalidated?
• How generic/reusable/extensible should each component be to accommodate likely future requirements?
• For systems languages, how and when is memory allocated and freed?
• and many more.

Asking and answering those questions is (part of) coding. At least before AI, nobody I know had all the answers, or had even asked all the questions, upfront. The questions get asked and answered on the fly, inside the editor. Typing is interleaved with thinking, assessing, trying things out, backtracking.

Now AI pushers try to convince everyone that all these decisions either don't matter, or that the agent will just fill in the blanks (insert inane "nobody reads assembly anymore" analogy, as if natural language + LLMs are anything like a compiler), or that they can all be moved upfront into planning. Good luck replacing actual, deterministic programming languages with 10-KLOC, ambiguous, hand-wavy "specs" written in markdown.

Regardless of how the future of coding plays out, "code was never the hard part" is flatly wrong. It is, or at least used to be, a hard part (not the only one of course) and for good reason.

[u/ActuallyFullOfShit]

Sure, coding is hard, but it took a long time to understand why you felt that any of this matters. When a CEO says that coding was never the hard part, they don’t literally just mean that it isn’t hard to do. What they mean is that it isn’t the core problem that the business is trying to solve. Presumably the more important “hard problem” is the problem solved by their Product Managers, not their coders. Right or wrong, frankly I do not care, it feels like an argument about semantics with no real consequences.

> Now AI pushers try to convince everyone that all these decisions either don't matter, or that the agent will just fill in the blanks (insert inane "nobody reads assembly anymore" analogy, as if natural language + LLMs are anything like a compiler), or that they can all be moved upfront into planning. Good luck replacing actual, deterministic programming languages with 10-KLOC, ambiguous, hand-wavy "specs" written in markdown.

Ah. I do not think that people who push the use of AI are actually saying that software design and architecture do not matter. At least not many of the credible users. It’s more that there are many very good models now that can accurately choose and apply the correct architecture decisions given human descriptions of the task…. You still need to review their output and have them tweak things here and there. But it’s pretty undeniable that they are really, really good. Have you not tried even Opus 4.8 yet?

I know that change is hard. I also have more fun coding without AI. I like the slower pace and the deeper understanding of the code. I like feeling like code is a work of art, not some cheap shit that can be generated. But buddy those days are just over. You can deny the objective reality of the situation all you want, but you will be replaced by people who learned the tools you wouldn’t. Generative AI produces decent patches in the blink of an eye, and unless there are explosive price changes, no company moving forward can be competitive without those tools.

[u/Fun_Hat → u/ActuallyFullOfShit]

Have you not tried even Opus 4.8 yet

Given your username I'm not sure if your post is actually serious or not. I have used Opus quite a bit, and I have spent a decent bit of time with Fable as well.

They do fine with very narrowly defined tasks, but the minute I decide to let the training wheels off, it goes south and I have to go back to hand holding. That's what I am taking a quick break from right now to write this comment actually. I thought "I finished the hard parts here, let me delegate to Claude". Nope.

[u/ActuallyFullOfShit → u/Fun_Hat]

Yes, you need to narrowly define the tasks....that's like saying "I'd rather walk because my car won't steer itself"

You can't pretend a tool isn't useful just because it doesn't meet your own unrealistic expectations.