The post pushes back on a now-common AI-era line that “code was never the hard part,” arguing that it erases the real skill in programming and understates why software work has long been hard, costly, and prestigious. The author’s case is that if coding were truly trivial, the industry would not have built whole careers, interview systems, textbooks, and identities around it, and software would not be as fragile and bug-prone as it is. The core complaint is less about semantics than status. Reducing programming to mere transcription makes it sound like the only remaining valuable work is product judgment or management.
Most of the high-signal reaction landed on a narrower distinction. A lot of people agreed the slogan is badly phrased, but still thought it points at something real. In ordinary business software, the expensive failure modes are often not “can someone type valid code” but “do we know what to build, can we align people around it, can we fit it into an existing system, and can we keep it correct as requirements and context change.” Several commenters said the phrase only makes sense if “code” means the final act of expressing a solution, not the whole chain of design, tradeoffs, debugging, and maintenance. Once “coding” gets stretched to include architecture and problem solving, the slogan collapses into a word game.
A second strong theme was that the answer depends heavily on domain.
CRUD web backends, internal enterprise apps, and integration-heavy business software were repeatedly cited as places where requirements, coordination, and process dominate. Embedded work, compilers, databases, high-performance computing, trading systems, control systems, kernel work, and safety-critical software were the standard counterexamples where implementation itself is deeply technical and mistakes are expensive. That split made the broad claim feel false to many people. It describes a lot of software jobs, but not software as such.
The comments also tied the argument directly to LLMs. Even people sympathetic to AI coding tools said the tools mainly remove the typing and boilerplate layer, not the need for taste, architecture, domain knowledge, deployment judgment, or long-horizon maintenance. Several described their current work as managing code-generating agents, reviewing low-quality output, or translating vague organizational demands into something testable. That makes software development look less like disappearing labor and more like a shift in where the bottleneck sits. The consensus was not “AI changes nothing.” It was that AI helps most where the work was already repetitive, and makes sloppy organizations sloppier unless someone strong is still steering.
blog.senko.net