The skill that used to build itself for free
I spend a lot of time speaking to engineering leaders about how AI is actually changing their teams, not the version you’d get on a conference stage, the real version. One of the ways I do that is through an online webinar series, bringing a small group of them together at a time to talk honestly about what’s working, what isn’t, and what nobody’s quite worked out yet.
There’s a moment in most careers where you learn something the hard way: stuck on a problem, no shortcut available, forced to sit with it until you actually understand what’s wrong. Nobody enjoys that moment. Almost everyone can point to it later as the point they got good at something.
AI is quietly removing that moment, and the people closest to it are the ones most worried about what that costs.
“I find this laziness factor starting to happen where I just ask the agent to solve a problem, so I’m thinking less,” one engineering manager told me on a recent session. He leads engineering at a large European energy company, and he’s not a junior. He’s been in engineering and engineering management for years, and he’s still only early into using AI day to day. “That grit that gets developed with struggling to solve a problem and eventually being successful. I’m just wondering, how do we manage the sense of learning a bit less along the way and delivering more?”
That’s the honest version of a question a lot of organisations are avoiding. It’s easy to worry about whether AI writes good code. It’s harder to admit that the people writing it, at every level of seniority, might be quietly getting worse at the thing AI is doing for them.
Understanding and output used to be forced together
For as long as software has existed, you couldn’t ship code without engaging with the problem behind it. Writing it out, line by line, was slow enough that understanding happened as a side effect. You didn’t have to try to learn how the system worked. You couldn’t avoid it.
AI breaks that link. It’s now entirely possible to go from idea to working code without ever really sitting with the problem in between. That’s the whole appeal, and it’s genuinely valuable. It’s also why the skill that used to form for free now has to be built on purpose, or it doesn’t get built at all.
The clearest evidence of this came from an engineering manager at a UK HR software company, who told me about losing his team’s only junior developer over exactly this. “She wasn’t learning how to be a good developer from just sitting in the driving seat and letting the AI write all of the code,” he said. “I do think that’s really valid.” His team runs one of the most AI-mature setups I’ve come across, and it still couldn’t retain a junior against this exact problem.
If a team that far ahead on AI adoption is losing junior talent to this, and a manager with years of hard-won experience is watching his own instincts dull, this isn’t a junior-engineer problem. It’s a workforce problem, and it doesn’t discriminate by seniority.
Experience is a hedge, but not a permanent one
Another engineering leader on one of these sessions has been writing critical software for thirty years, most of it for medical devices, including software running inside active devices in the human heart. He was also studying neural networks before most people had heard of them, back when AI research was going through what he calls its winter. That combination, deep domain judgement built over decades plus genuine familiarity with what AI can and can’t be trusted to do, is exactly why his team treats AI as a pre-processor rather than a decision-maker on anything critical. “We use AI as a pre-processor, just to do a lot of testing and pre-calculation,” he told me. “But in the end, we have to manually go through every line of code to guarantee the governance and sign it off.”
That’s not caution for its own sake. It’s what deliberately protecting the skill looks like once you’ve already built it. The judgement he brings to reviewing critical code exists because he spent thirty years building it the slow way. What his approach raises, without quite saying it out loud, is what happens to the next generation of engineers who never get thirty years of the slow way to draw on.
The fix isn’t less AI. It’s relocated friction.
Nobody in this group thinks the answer is to use AI less. The HR software company’s engineering manager, has responded by building a new kind of friction back in, deliberately, where the old kind used to sit for free: juniors are asked to explain a piece of AI-generated code back, in their own words, before it merges. Not because it’s slow. Because it forces the same engagement that writing the code by hand used to force automatically.
It’s a genuinely good instinct, and it’s still only a partial answer. Nobody in the group described it as solved. What’s changed isn’t the need to build understanding, it’s that understanding now has to be engineered into a process on purpose, the same way code review or testing is, rather than something that simply happens as a by-product of how the work used to get done.
Why this is the hardest part of workforce planning right now
Most conversations about AI and work focus on governance, or productivity, or which tasks get automated. Those are real questions, but they’re mechanical, and mechanical problems tend to get solved. This one isn’t mechanical. It’s about what happens to human capability when the thing that used to build it quietly disappears, and it’s the reason upskilling is turning out to be the hardest part of planning a workforce for the AI era, harder than the technology itself.
Who this is for
I’m putting these webinars together for engineering leaders who are actually in it, running teams that are adopting AI, wrestling with what to trust it with, and figuring out what it costs when nobody’s watching. If that’s you, and you’d find it useful to compare notes with others facing the same thing, I’d genuinely like you there.
If you’re interested in being at the next online webinar, reach out to me.