If you were to take a lead from online communities and social media, you’d reasonably think the whole world has immediately jumped into AI-assisted code generation with great success. Everyone, all of the time, writing everything with AI. Can that actually be true? My own experiences have been different. Initially, I found it annoying: it could generate trivial code, with overzealous auto-completion writing features I didn’t want. The solutions that were generated were OK… plausible. They looked kinda like something that would work. Sometimes they worked. It was like junk food. It was highly palatable, easy to consume, and provided a lovely dopamine hit, but slightly hollow. It had the calories, the lines of code. But it wasn’t nutritious.

I remember in the late 90s, my dad, in an effort to achieve a six-pack, bought a QVC abdomen stimulator. You sat on the sofa watching reruns of Only Fools and Horses, drinking a can of lager with the device attached to your stomach. It would electrocute you, tensing the muscles of your abdomen and giving you the feeling that something was happening. I think he knew it was doing nothing, but he used it for a couple of weeks in the hope that he might wake up with washboard abs. It never happened. It was a performance… it gave him the feeling of doing something beneficial without any of the actual benefits. It felt like ab work even though it wasn’t. We love these things: they give us dopamine and help us avoid the pain. Unfortunately, there is no way to strengthen your muscles without damaging them. It’s only stress that causes them to strengthen.

There are other examples of this phenomenon, where progress requires stress. Only in response to stress does improvement happen. The Arizona Biosphere project showed how trees grow to be fragile without environmental stresses (https://en.wikipedia.org/wiki/Biosphere_2). Humans lose bone and muscle mass in space. People kept in isolation can develop without capable immune systems. Without adversity, there is nothing. In the role of the software engineer, adversity exists in a bunch of different places. The iterative process of writing software is full of failure. You think something will work, and it doesn’t. You believe you understand the requirement, but as you dig into it, you find contradictions. You believe your solution will perform well, but issues and unforeseen scenarios arise. The friction is valuable for two reasons:

  1. It provides an opportunity for greater cognitive engagement. You presumed it would work, it didn’t. Now you need to lock in.
  2. It makes you stronger. Curls make your arms stronger, singing makes your voice stronger, and solving problems makes you a better problem solver.

I know people who are poor problem solvers who earn a living writing software. They don’t really ask why; they don’t really engage with the problem. They require a dedicated QA or test engineer to make sure their solution is appropriate (because they’re not sure themselves). They require a BA to write up the requirements for them into a specification. They can work on the production line, turning stories into executables. But they can’t actually solve problems.

For that kind of engineer, LLMs are rocket fuel on a bad fire. If you already don’t ask why, now you can ship even faster without ever starting. You can generate convincing code, tidy commit messages, and plausible explanations for decisions you never made. The output looks polished, so the gaps hide for longer. But reality always collects the debt: in production incidents, in brittle systems, in teams that stop learning because nobody is wrestling with the work anymore. If your value was typing speed, LLMs have just commoditised it. What’s left is judgment. Curiosity. Taste.

We’ve seen this movie before with calculators, sat navs, and search engines. They didn’t destroy thinking by default; they offloaded effort so we could spend attention on higher-order decisions. That’s cognitive offloading: you delegate the mechanics, but you still own the conclusion. You sanity-check the output. You can explain the why. You can do enough of the work yourself to spot when the tool is wrong.

The failure mode is cognitive surrender. That’s when the tool doesn’t just help you think, it replaces thinking. You don’t form an independent view, so there’s nothing to compare against what the model gives you. You inherit confidence without inheriting reasoning. In software teams, that compounds as comprehension debt: more code shipped, less understanding retained, and nobody able to reconstruct key decisions when things fail. Addy Osmani’s post on this is worth your time and says it well: Cognitive Surrender. The line between offloading and surrender is now one of the core leadership problems in engineering.

So what do we do?

I don’t think we have a perfect answer yet, especially on skill atrophy. But we do have evidence of what helps.

We’ve run tutorials across the department on the difference between being an informed sceptic and a fearful one. Informed scepticism asks for evidence, tests assumptions, and learns the tool properly. Fearful scepticism dismisses everything and opts out. Those sessions created space for people to share lessons, ways of working, wins, and losses without pretending it’s all brilliant or all terrible.

That openness has mattered. More people are now engaging with AI in a practical way, and they are more honest about trade-offs. We hear both sides: where it speeds up delivery and where it introduces shallow understanding. That honesty is progress.

We’ve also invested in our own in-house agent with business-specific context, custom skills, and integrations. That has improved relevance and reduced generic, made-up answers. It helps people get to useful output faster. But faster output is not the same as stronger engineers, and we need to keep those two ideas separate.

The hardest next problem is early careers. We have new joiners arriving soon, and they need to learn how to solve problems from first principles and understand the inner workings of a system, while still using AI as a normal part of engineering work. We can’t pretend AI doesn’t exist, and we can’t let it do all of the thinking either.

Another way I think about this is the difference between testing and training in sport. Match day is testing. Training is where you build the strength to perform when it counts. Most software work is testing: we’re shipping into a marketplace where everyone is now AI-enabled. But if all we ever do is test, and never train, we don’t get stronger.

And training is not the Magic Abs Machine. Training is reps. Real reps. Struggling with a problem long enough to build a mental model. Explaining design choices from first principles. Debugging the thing you wrote until you truly understand why it failed.

For now, my working view is simple: use AI as a tool, let people choose when to use it, but deliberately design teams, onboarding, and review culture to protect those reps and help people form their own experience-based opinions. Many developers mostly learn through their day job rather than outside it. So if we don’t create space for genuine learning in the work itself, we may ship a lot in the next few years and still end up with too few people ready to lead software teams in ten years time.

This probably means adding more friction into the ways of working. Being more challenging. Ensuring people are strong enough to compete before you put them onto the pitch.