"Code was never the hard part" is an insult to all programmers

While there are for sure a lot of programming jobs that don't touch anything "important", like making dime a dozen websites or apps, I think you underestimate the number of things that need some form of higher quality control.

The level of quality needed (or imposed) will vary. It is a wide spectrum from dealing with banking/transactions (money at risk) to brake controllers and auto pilots (human lives at risk). But there is a lot of this, all over the world.

I work somewhere in the middle (rather slow but extremely heavy industrial equipment, where emergency stop is always a safe if costly option). There are domains where emergency stop is not a thing though: some systems on an aircraft in flight, a pacemaker, etc.

My point is though, that there is a ton of code where stakes are higher than "oops, I guess we will fix it next sprint". And while not all of that have regulatory constraints, sometimes a company realises that the financial cost of issues significant enough that it is worth holding themselves to higher standards anyway.

LLMs are surprisingly bad at basic CMake, but i don't see why they should be.

Much of the truly LLM-difficult code is probably hiding in the libraries we import. Database engines, compilers, efficient data parser, control theory, signal processing, protocol implement-ions, or anything with a 12000 page German ISO standard that need to pass a $12.000 certification lab. But this also compose of such a tiny fraction of programmers or code in the world.

A-lot of my work lies in that last one... but that's also where that "code is easy, knowing what to code isn't" is the most true; because industrial standards tend to not spare any expense on the word count, while the implementation is a ~2000 row state machine. I've not yet found an LLM capable of successfully parsing this kind of specification documents, but it's possible they will reach there eventually.

But i do feel online debate do clump the software field a bit too much when AI is discussed. JavaScript compose probably 98% of all code the LLMs are trained on since it's powering every website scraped for training. As such, people in web-development seem to have far more praise to LLM capability than i'm able to give.

My personal AI experience has been very mixed in comparison, regularly making up functions of common libraries, hallucinate the description of technical terms, straight up writing un-compilable c-code, or get confused by relatively small code-bases. Useful but not majorly changing my work at the moment (pretty good at comments, test cases, or as google replacement).

Granted, I've only tried models up to Opus 4.8, and not had experience with the newest "tier" of models with Fable, Kimi K3 or GPT 5.6; but the prices on those are also starting to compete badly with my salary at the moment.

Microsoft did research on this and it was found that only 14% of time was writing code.*

That 14% might have been hard, but it is definitely still the smallest part of being an engineer.

* https://www.microsoft.com/en-us/research/wp-content/uploads/...

IDK, I worked like in ~20 enterprises and I didn't really see what you describe.

"Navigating customer requirements" is mostly everyone speculating on customer needs and pushing the part they own, and whoever happens to get closer to the higher management's ear, wins. Then market decides if that's is a good thing or bad thing. If it's good, normally the person who pushed this doesn't even receive credit for it, because either the command chain too long or the stakeholder's memory too short and postfactum everyone pretends they authored good decisions and opposed bad ones.

It might be tiresome and exhausting, like all intense politics, but it's not hard in any technical sense. Most mediocre people can do it and do it.

For something to be hard and complex you need rules and professionals on all levels who understand and follow the rules and driven by meritocracy alone. That's simply never the case.

They do. Most economically viable software already exists today, most people's job is to make .1% improvements, and features on top. For this work it's obviously pivotal that any change should not worsen the existing software, as that instantly nullifies the value of improvements.

Another kind of highly valuable software is a new design which digitizes some process, like the ticket management of a rail company. If you don't follow the internal processes and workings of the firm exactly, or you do not interface with existing systems 100% accurately, your software very soon becomes worthless.

Figuring out how to create a piece of code that solves the exact problem the customer has, while not breaking anything, and fitting into existing operations seems to be a big head scratcher still, and something humans still need to do, at least that was my experience so far with LLMs.