The Moat Was Never the Code
For decades, the ability to write code was the moat. AI just drained it. Here's what's actually hard now, and which engineers get left behind.
Rich Barrett put it more bluntly than I would have dared: "Engineers who need every requirement handed to them are running out of road."
I read that and thought about the dozen conversations I've had in the last six months where someone in a technical role has gone quiet, slightly defensive, when the subject of AI comes up. Not the curious kind of quiet. The kind where you can see someone doing the maths on whether the thing they're best at is about to stop being scarce.
Here's the uncomfortable bit. For a long time, the ability to write code was the moat. If you could turn a vague idea into working software, you held something other people in the business couldn't replicate, couldn't fully scope, and couldn't easily replace. That gave you leverage. It also, if we're honest, gave a certain type of engineer permission to go all-in on being deeply technical at the expense of everything else. The product context, the customer, the commercial reality, the awkward conversations. All of that could be somebody else's problem, because the code was the hard part and you were the one who could do it.
The code isn't the hard part anymore.
I say that as someone who builds production systems for a living now. AI writes the code. It does it cheaper, it does it faster, and it does it without the sighing and the "well, that's not really how I'd have done it" that tends to come with this particular flavour of engineer. I've shipped things this past year I'd waited months for under the old model, and the writing of the code was the cheapest, fastest part of every one of them.
So if the code is solved, where did the hard part go?
It went to the questions nobody can hand you on a ticket.
What are we actually trying to fix here, underneath the feature request? What does the happy path look like, and more importantly what does the unhappy path do when a real customer hits it at 4pm on a Friday? Where does the data come from, and do we trust it? Who actually owns the decision this thing is about to automate? And the one everyone skips until it's too late: what happens when it goes wrong?
None of those come on a requirements doc. They come from sitting close enough to the product, the customer and the commercials to know what matters before anyone writes it down. That's the work now. The code is just the easy bit at the end.
I want to be careful here, because it would be lazy to read this as "technical people are finished." That's not it at all. The value in technical thinking hasn't been diminished. It's moved. It's shifted from can you produce the artefact to do you understand the problem well enough to know what artefact is even worth producing. I've argued before that the things that actually drove a strong year for me came down to behavioural traits rather than the typing. The engineers I'd back in this new world are the ones who were always a bit more than just coders anyway. The ones who asked annoying questions in planning. The ones who wanted to know why before they'd touch the how.
The ones who are going to struggle are the ones who only ever wanted to do a narrow slice of the job. Head down, hand me the spec, leave me alone, I'll deliver exactly what's on the card and not a millimetre more. That was a perfectly viable career for thirty years. I'm not sure it's a viable one for the next ten.
I'd rather say that out loud than let people find out the quiet way.
Because the engineer of the future isn't a worse version of the engineer of the past with some AI bolted on. They've got a wider field of view. They understand the product they're building, the customer they're building it for, and the commercial logic that decides whether any of it was worth doing. The narrow specialist who needed everything pre-chewed was a product of an era where the scarce skill was the typing. That era is closing.
The moat was never really the code. We just thought it was, because for a long time the code was hard enough to hide behind.
It isn't anymore. And honestly, I think that's the most interesting thing to happen to this profession in my career.