On those complex systems in particular the problems start long before any code is written.

A software engineer can create and understand the specs, requirements, design the system, architectural decisions, define everything about that software and data, model everything, failure, performance, operational topics, documents everything, etc. before a single line of code is written, and of course they can write good code. Then there are the coders who patch together chunks of code from Stack Overflow or whatever boilerplate they have in the company's repository. I know every coder likes to call themselves a "software engineer" but there's a world of difference between the two types.

For the first group code was never the hardest part. For the second group there was never any other part.

Yes, and absolutely nobody will care if it does the thing it was meant to do. Performance is near always an afterthought because there is no single team that gets judged on performance.

I don't think you're really disagreeing with the original sentiment? However, I think you're taking a much broader view of "code" than is intended by the original statement.

In your framing, you're kind of confounding code with architecture. Code is really just the act of making a computer do a thing you want it to do, for some definition of "thing you want it to do". Architecture is more about understanding which things you want the computer to do, and in which ways.

There are a million ways to code a task. That's the "code" the original statement is talking about. Understanding which of those ways is an appropriate way is a separate skill, whether you call it architecture, or something else.

Scientific programming, hardware interfacing, embedded, demoscene, game engines, HFT or HPC calls for much different breed of code, and generally way harder to formulate in code w.r.t. these enterprise projects. Trying to make hardware go faster with more efficient code is much harder than optimizing an SQL query and safeguarding it, and these are well understood problems, in general.

If you just mean a large company, I would say they do exist - though it may take some looking for them.

You can find them in companies that have to deal with "real" things (hardware, factories, production lines), or where there is an interest in taking advantage of emerging technology (advertising, e-commerce)

I would call my current project relatively systems-level too, as it's a network proxy. Not quite kernel level but definitely not trivial "if this then that" style coding.

My perspective is that application programming - CRUD, forms, IO orchestration - was always vulnerable, even before AI. Think about APIs for payments, APIs for subscriptions. E-commerce in a box type solutions.

That's why I always pushed to do more systems level work, on more exotic or weird technologies. It's not because I think I'm a better programmer, than someone slinging Spring code or React forms. But because in this industry it's better to be a goat than a cow.

I do, but the order of the keys makes a difference somewhat.

That last 10% is the value-add. If you aren't doing that, the other 90% can be done by pretty much anyone, and they won't be "SWE", they'd be minimum-paid white-collar workers.

A lot of people miss this in their haste to rationalise their evaporating value - "I'm still useful, because AI is only doing that 10%, I am still needed for the other 90%", not realising that if they aren't needed for that last 10%, they are interchangeable with the office receptionist :-/

Unfortunately it is still the job...

Advice to job seekers I remember in the 2010s was to not call yourself a programmer because that was where the bad "code monkey" jobs were, but it hadn't yet been much of a thing when I first started looking at the end of the 2000s.

https://www.youtube.com/watch?v=fcjBfSiyI0k

For example, one guy I used to work with wrote this really awesome algorithm about 25 years ago, and I'm responsible for maintaining it since he long retired. I can't go into details, but this is the core algorithm in moving billions of dollars between institutions overnight. It's about 10 screenfuls of c that had been converted from the original FORTRAN 77 with dozens of gotos and weird branching statements and about 20 parallel arrays that store indices for pointer chasing. It's almost impossible for a human to follow (I've actually fed it to an LLM and said rewrite this with for loops and no gotos so I can understand it - and it worked!) but it's blindingly fast. The actual problem it solves can be stated in about three sentences, but programming it was hard because of the context management. The reason that my company keeps getting royalties on this is that it's so hard that they'd rather pay us than write it themselves. But I bet an LLM could write it from scratch now.

So maybe programming is no longer the hard part, or at least context management is no longer the hard part and that humans should move up the chain to help manage the context for LLMs so they can get more done efficiently.

Switching topics a little...much of what I think makes coding the hard part was the tension between big-design-up-front and you're-not-going-to-need-it philosophies. Early in my career I worked in health care and that was BDUF and the coding was easy because program managers spent years defining every screen that would be shown to the users, what queries were needed to fill the screen, all of that. We just took the spec and coded it. Coding was easy. But the failure of BDUF was that it still didn't really match what the customer wanted.

Then enter agile and YAGNI, in that limit, coding is easy, just write what the user story says. But then you have to refactor from what was left behind on yesterday's user story. So smart engineers would cheat a little with YAGNI and say, yes we will put an abstraction in because the next user story. I would say that "good engineers" or "good coders" found that balance in abstraction to move fast but make abstractions not overkill. And I think that's what all the wailing and gnashing of teeth is right now: the good engineers aren't needed anymore.

I can tell an LLM to code something, and as I add complexity it's happy to refactor and manage the context so we don't need to worry about "clean code" or "quality code". As long as what the LLM writes meets the spec, then we're happy.

Ah, sorry long rant and ramble. But I just think the "hard part" has been managing context, and the context we're managing context is just changing. Those good at managing context will be good at coding with LLMs, and those that weren't won't be.

You can absolutely not do this

I type them in when I'm in front of the computer.

All the actual work though? That gets done in a space where there's no phone, no people walking up and talking to me, no distracting social media, no screens, just quiet-ish and a couple of hours to think.

Basically, all of it. By the time a programmer has enough experience to design and implement software properly they are “promoted” to some paper pushing management position.

And for a huge amount of code, it's not very hard to make it good enough, because the requirements, once understood, are pretty straightforward and perfect correctness often matters much less than you would think.

It's absolutely devastating to team morale. We never feel like we're contributing.

Likewise, coding is easy. It's just writing, and any child can learn it. Coding is not programming, and the hard part of the job lives in that distinction.

The truly difficult work is knowing when your client/boss asks you to "build a car," do they really just want/need a small Pinewood derby box car as a toy, do they need a four-door sedan that can legally drive on major highways, an 18-wheeler freight truck, or do they actually need/want a bicycle, or a shopping cart, or a railroad box car, or information about how to take public transit that will serve them cheaper and easier than anything you could build in their timeframe and budget.

That's what people mean when they say that code was never the hard part.

Now add the time dimension - keeping code correct as the business and the people in it change.

That's how I explain to people that LLMs will not replace us developers.

(In interesting ways this is programming’s greatest boon and curse: if we treated it more like building bridges or cars, the world would be a very different place.)

This is worth saying precisely because of this difference - people see huge amounts of bad code generated by LLMs and think it is equivalent to carefully written code because the results look similar at first glance and they don’t bother to read it.

Communicating like this is to try to get them to understand that The Code is barely about the text on the screen and is instead about much more - both abstract in the code (but how on earth do you explain that to someone nontechnical without just sounding like "no trust me my job is really hard, I promise.") and also in all the external stuff - the world The Code lives in (users, ops, support staff...).

Is it a perfect analogy? Of course not, and I'd never explain it like this to someone technical. But they're not the audience.

---

Adjacent: I've always gotten the feeling that even the most well-meaning/trusting nontechnical leaders have always been fairly nonplussed by software complexity and software development.

Deep down, they seem to think it can't possibly be that hard, despite the fact they can't write it themselves. Sometimes, even worse, they have dabbled in writing small, or even medium-sized solo projects. And think - well isn't software engineering just doing that but with other people? And their attitudes can reflect them, sometimes all the time, sometimes just slipping through when under duress like delayed projects etc.

And yet despite their attitudes, they then also find:

- if they try to outsource, they have a bad time

- if they try to proooompt, they have a bad time

- if they try to pay less, they have a bad time

and so the invisible hand of the free market itself forces their hand in paying prodigious salaries and fighting to retain talent. And all throughout they remain internally nonplussed even if they manage to keep up appearances.

That said, it's still reasonable to think that once (and only once) the hard part is done, then the easy part is easy. It would just be wrong to think that you can do the whole thing without having to do hard parts. I think the argument here is that with AI this is more possible—that the tasks are more separable. Even if it's the same one person doing the hard stuff and then passing what they learned to the AI to do the easy stuff.

Two reasons they might not separate well (there are others):

- If in a company's product development it's hard(er) to have one person doing H and another doing E, then you're generally going to have one person doing H and E. More or less, this means a person can only do E easily if they do H beforehand. So hard things are required no matter what.

- People come in whole persons. If people skilled/educated to do H tend to be the same people skilled/educated to do E (can be because of how programming is educated, but also can be because there aren't that many programmers), then you're always going to be plugging programmers who have both H and E into roles and it'll probably be more efficient to plug them into roles requiring both rather than just H or just E. You could, within that population, determine who is comparatively advantaged (and we do do this mildly with senior vs junior or with "architects"), but plugging a person into an E-only role is going to involve that person questioning what happened during the H part beforehand. In part because they're good enough at H to question it, but more importantly because they're implementing the H such that they're aware when their E might not be as easy as it could be.

Both of these seem like they might be less true now with AI (and also perhaps because there are more programmers).

Even in academia, you have meta structures that you constantly need to think about.

Of course, you can keep trying to isolate the "pure" thing from the "accidentals", but it's not going to work when the work gets sufficiently complex

For those cases where it is true, it is pretty much like your example, and the distinction is there in your example just like theirs. You supported their point.

For any product of any complexity you can can essentially never successfully delegate that process to a non-programmer.

Indeed you can not that often even trust that the client employee doing the asking knows what it is they need. Almost certainly someone in the organisation who was not in the meeting is better placed to tell you what is actually required.

This task needs an analyst; that analyst needs to have experience of writing meaningful code.

We have studied. We constantly educate ourselves (I have still not yet managed to work through the entire SICP on my own). Our tools are changing constantly. We are juggling information through devops, requirement engineers and customers. We advise daily. We get consolidated if something is complicated to summarize. We do forensics. Constantly under the pressure that some bit rot may open a new urgent bug we have to investigate. Money AND reputation on the line. It is a damn stressful job. So if we do our craft, we do it with incremental knowledge. Carefully. We build community of trust in our free time to get connected and improve. Any new member gets welcomed and onboarded. His knowledge im the future will supplement ours. So we mentor additionally.

Now comes AI. Collects the knowledge and hands it over to anyone. And we know: It is UNSAFE. Don't get me wrong; I consolidate it now as well, just to keep up with the increasing pressure to investigate. But the thing is:

While we did our craft so that we won't have to touch it in the next five years, the complexity increases every single day. And its out of our hands. If some junior comes in and starts writing decent code with ai it is nice. Until it breaks and AI won't help. Or worse: Gets applied on customer data in the wrong way.

A new ticket for the greybeards (by no means, I am not such). I think we are on the wrong track. Using ai decreases my abilities. It increases the load.

I think we should get twice the salaries. It has become unbearable.

Could you imagine that your local file server for your family consists of a enterprise database, a key-value store, possibly multiple reverse-proxies, a vector database.... my point beeing: Complexity. Invariants, frameworks to get familiar with... And the tool to supplement the demand is intransparent (but probably deterministic? Idk). It feels just so wrong.

It's always been funny to see the arrogance of some SWE who think that since they're the highest paid, they are also the most difficult and most important jobs, while it has zero to do with either of these two. Just luck of supply/demand. Otherwise mathematicians and physics would be sitting at the top with the highest paid careers and they... are not even close to that.

For this reason I don't really feel sorry for AI replacing programmers/SWE, at least the ones that were arrogant enough to think in the way i explained.

Thus, I insist on engineering being involved early to put real world constraints on wild ideation ("it would take 3 months for 5 engineers" quickly changes what's a must-have :)) — sometimes, a curious, critical mind can expose things like these without having to do the research or user testing themselves.

Now, throughout my 20 year career, it's been very rare to find a product person who will both understand customers deeply, tie their needs to business value, and be able to formalize the intersection of these in a form of good requirements for design and engineering to eventually build!

So I really believe an engineer's (and design) role there is to serve as a sanity check as they dive into actual building — does this really make sense? If they do not, they run the risk of a project completely failing or perhaps not even shipping once someone else questions the value of continuing to invest in this 3 month project 9 months in. ;-)

The difficulty of it has absolutely been a bottleneck to the supply of good devs, keeping salaries high.

Highly experienced programmers seem to have a hard time understanding this.

Why do we have tens of thousands of test cases and we still find new errors constantly? Why is our software so bloated and slow? We do we still have security breaches?

LLMs can be useful tools when guided by experts. I don’t think a PM with a dream is going to cut it in the long run.

But these are skills that can be taught to individuals.

But teaching an organization that their real bottleneck isn’t how fast they’re writing code; it’s producing production-ready software that people understand and are willing to take responsibility for… that’s much harder.

Many businesses want to treat software development like an assembly line and revert back to Taylorism. It’s knowledge work and there’s no royal road. Good teams get fast when they have the right mix of skills and trust from the organization.

What we’ve been delving into for the last decade has been a decline in the value of labour and work.

“Code isn’t the hard part,” isn’t meant as an insult at individual programmers or to devalue their work. That’s being done by big tech and their AI hype machine.

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.

Not even just the customer-facing stuff either, the internal tooling is on fire more and more often. It's not sustainable in the slightest

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.

... as long as the buyers could never discern

Even with wrangling agents, you’re really just making them right the “correct code”. Something EMs don’t do, or at least the good ones don’t do with their ICs.

One thing that is good to have in all those positions is an understanding of the code base and where it can slowly evolve to and how that positions the code base best in the market. I'd say the best way to build this understanding is still to build parts of the system yourself. Not talk to experts or agents about the code base.

This has nothing to do with any intrinsic difficulty with coding and more to do with the industries penchant to rewrite everything every couple of years. The reason you don't see people who went to management become ICs again, is because you have to spend time learning the new, correct™, way to do read and write code.

From the constant API churn for something like React, or even the 20 million updates to write "modern" C++, someone who has had those minute decisions abstracted away will struggle to write code.

Either move up the ladder or leave.