A programmer named Senko Rašić published an angry post this week. He is angry at a slogan going around: “code was never the hard part.” He calls it an insult to programmers. The post hit Hacker News and Lobsters and drew more than five hundred comments.
Reading the comments, I noticed one thing over and over. They argue about what the word “coding” means. Some people say it is the easy part and always was. Others say it is the whole job and always was. They are not disagreeing about difficulty. They are using one word for two different things: producing code, and building something that holds.
I have a stake in this. I write that execution has gotten cheap and coherence is the hard thing now. Skim that fast and you might file me under the same slogan.
The hard part was always building well
Producing code that runs is one thing. Building something that holds is another: the design that survives real data, the structure that stays coherent as the system grows, the choices that still make sense a year later when the author is gone. That second thing was always the hard part, and it was always the job.
Before AI, doing it well was expensive, because it took a skilled person and their time. Doing it badly was possible, but it was slow and the result was bad. Nothing about producing software was cheap.
Cheap is what AI added. A model writes a working function or a working page in the time it takes to describe it. Someone with no training can now get running code out of a sentence. That is new, and I will not soften it. Execution got cheap.
Cheap is not the same as bad
AI writes good code in places, and the commenters who said so are right. The quality is uneven, and the unevenness has a shape. The models are strong where they had the most to imitate, the patterns written out in public a million times: CRUD, forms, glue code, the endpoint that reads the database and returns JSON. They are weaker where the examples run out, on scientific computing, embedded work, anything performance-critical. One commenter put it well: AI kills it on problems with a thousand forum posts, and you do not point it at the ten-billion-dollar machine headed to Mars.
There is a reason coding is where AI advanced fastest. Code is checkable. It runs or it does not, the tests pass or they do not, and my book argues that AI improves fastest exactly where the work can be checked. The checkable parts of building will keep getting cheaper and better. What stays hard is the judgment no test can catch.
That was never the job
I wrote recently about a delete button from a data engineering thread. An engineer built a button to remove a record. It took the record off the screen. It left behind the three related records the original had created when it was made. The screen looked right. The data underneath was orphaned.
Producing that button is the cheap part. A model does it now. Knowing it had to clean up three records you cannot see is the judgment. That was the hard part, and that was the job.
The comparison people keep reaching for
Watching the threads, I noticed people reaching for the same analogy – writing. Anyone can put words into sentences that flow and reach a point. A model does it fluently. That was never what made someone a writer. What makes a writer is the choice of words and their order. The same point can land or die on those choices. One commenter compared it to a novel, where clean sentences were never the hard part.
AI did not invent bad prose but made fluent-looking prose free and endless. “Code was never the hard part” runs the same move as saying words were never the hard part of writing. About spelling, it is a shrug. About writing, it is an insult. The slogan gets both out of the same words by letting you hear the first while it means the second.
The swap, named
The slogan is true about producing code and false about building well. It earns its credibility on the first and spends it on the second, where the conclusion is that coders are now optional. One commenter worried the line would harden into a truism for business leaders. That is the reader I have in mind.
If someone read me as saying coders no longer matter, they would be making the same swap. The thing I say got cheap is producing code. The thing I call hard is building something that holds. Those did not both get cheaper. Anyone worried about systems built fast and badly is saying that building them well is still hard. You cannot write about that problem and also believe the work is trivial.
The right version of the slogan is my argument
Some people say the line and do mean something reasonable. On Lobsters, a commenter called lcamtuf said Senko was reading it uncharitably, and that the real meaning is that producing lines of code was never the bottleneck. That is true. If coding was fifteen percent of an engineer’s week, automating all of it buys back about a sixth of the week. You aimed the speedup at the fastest part of the job. Another commenter reached for Amdahl’s Law to make the same point with a number.
Then lcamtuf added the part that matters most to me. Some friction, he said, was good, because it stopped people from building software that was unnecessary or unmaintainable. That friction was a filter. It did not stop people from producing code. It stopped building-without-judgment from becoming load-bearing, because getting anything shipped had to pass through people whose time was scarce. That filter is the thing AI removed. The difficulty of building well did not leave. It stopped being enforced.
The same thing, at two heights
Building well has a name once you zoom out. Making each part fit a whole you cannot see all of at once is coherence.
The delete button is a coherence failure inside one function. The record fit the screen and broke the data underneath. Agentic slop is the same failure across a company. Each workflow works on its own, and the enterprise stops making sense. Senko is defending coherence in one program. I am after it across an organization.
The slogan is backwards. The hard part of code was never the typing. It was always the judgment, and here is the part that lasts. Where a design was already worked out a thousand times in public, the model has something to copy, and it copies well. Where the design is new to your system, there is nothing to copy and no test to guide it. That judgment stays human, because it is both uncheckable and unwritten.
Producing code got cheap. That judgment never did. It used to get paid up front, in salaries and review and the time of people who knew what they were doing, where you could see the cost. Now it shows up late, in the corners, with no owner.
This argument runs through my book, Coherence, arriving this Fall. If you want to follow the thinking as it develops, join the list at coherise.com. The one-page decision tool from the book is the first thing I send.