There is a claim making the rounds that LLMs may be good at coding, but coding was never the hard part; the hard part is figuring out what to build. It is a satisfying line, and it is half true. The trouble is that the untrue half is exactly where the difficulty, and the money, have always been.

Two very different jobs wear the same word

Most of what gets called programming is daily work: a new dashboard widget, a form, a CRUD screen, the hundredth variation of a component. For that kind of task the claim basically holds. Once you know what to build, a competent developer, or now an AI, can produce it quickly, and the genuinely hard part was deciding it was worth doing. But there is a second kind of work that shares the word and shares almost nothing else: building a real-time video system from a low-level library, architecting something to survive ten thousand concurrent users, untangling a production bug nobody can reproduce. There the idea is cheap and the implementation carries the weight. Get the implementation wrong and it does not matter how good the idea was, because nobody uses a product that lags.

Where AI actually lands

Drop an LLM onto the first kind of work and it shines, which is why the claim feels true right now. Drop it onto the second and the cracks show. It will happily start building a video-conferencing system from scratch and never once stop to tell you that is a terrible idea you should almost never attempt. It does not weigh the decision; it just complies, ships something half-broken, and leaves you to discover the gap in production. The judgment to say “do not build this” is the expensive part, and it is precisely the part the model does not have. This is the same split we keep returning to: the model gives you the average unless a person supplies the judgment.

The noise is the opportunity

Here is the part worth internalizing. As churning out code gets easy, more people do it, and the volume of vibe-coded, only-the-author-uses-it software explodes. That noise does not devalue deep skill; it does the opposite. The moment any of that software has to be shared, scaled, or debugged by someone who did not write it, the gaps appear, and whoever actually understands systems becomes the scarce, valuable person in the room. The right move is to be that person before the wave of people who skipped the fundamentals hits the wall. An orchestrated AI stack is powerful, but someone still has to know when the architecture is wrong and make the radical call the model never will.

What it means for a business

If you are hiring or building, stop treating “can produce code” as the bar; the machine cleared it. The bar is judgment: knowing what not to build, spotting when a system needs to be simplified rather than extended, owning the decision when the output is wrong. That is the whole basis of how we scope our solutions. Coding was never the only hard part, and it was never the easy one either. The word just hid two different jobs, and AI made the difference between them impossible to ignore.

Prompted by a video essay reacting to the article “Coding was never the hard part” (2026). Credit to the original; the read here is ours.