Your engineers aren't afraid of AI - they're afraid of becoming junior again | Andy Kelk

Paraphrasing of a talk delivered at Web Directions AI Engineer Melbourne, June 2026

Download the slides (PDF)

I’d like to tell you a story about a new technology arriving in workplaces, and the people who’d built their careers around the old way of doing things.

The professionals were worried. They held meetings and had heated debates. The arguments went like this:

“People will become dependent on this technology. They won’t learn the fundamentals.”

“They’ll get results without understanding what they’re doing.”

“Our job is about thinking, not just getting the correct answers. This technology short-circuits that.”

“What happens when they don’t have access to it? They’ll be helpless.”

“We’re producing a generation that won’t know how to think for themselves.”

Some organisations banned the technology outright. The people who’d spent their careers mastering the craft - whose identity was bound up in being good at the thing the machine could now do - watched their work being devalued and pushed back.

But this was 1976. The technology was the pocket calculator, and the professionals were maths teachers.

The research came in over the following decade, and the picture turned out more mixed than either side had argued. On standardised tests, students using calculators showed gains in conceptual knowledge and problem-solving. Computational skills mostly held up, though not everywhere - there were losses, particularly in grade four. By the mid-eighties, Connecticut became the first US state to require calculators on its exams. The skill set the system tested for had changed.

We’re in that moment now. Except that the thing at risk isn’t long division.

Every engineering organisation is seeing this change. From above, leadership is pushing for speed. From below, you’re hearing the opposite - slow adoption, too busy, AI slop, and the recurring question, “but who reviews it?” In the middle sit engineering leaders trying to work out why this rollout, which on paper should be the easiest sell of their careers, is producing so much friction.

I want to offer a diagnosis of that friction, because I think we’ve been getting it wrong.

They’re not afraid of AI

Your engineers aren’t afraid of AI. They’re afraid of becoming junior again.

Let me unpack that. What does “junior” mean? It means not knowing what’s happening in the codebase, shipping something you can’t fully explain, and asking questions you feel you should already know the answer to. Every senior engineer in your organisation has spent a decade or more climbing out of that feeling - and now there’s a tool that drops them straight back into it.

When agentic tools started showing up in teams I was working with, I saw two reactions. The first was “this is just better autocomplete” - people who’d used Copilot in its earlier form and dismissed agent mode as more of the same. If you’ve used a coding agent recently, you know it’s a lot more than glorified autocomplete. The second reaction took some digging and a few candid conversations, but what came out was something like: “I don’t know what I’m supposed to be good at anymore.”

That’s a very different kind of resistance from “I don’t like change.” And if we treat it as the same thing, we’ll get the same response we’ve always got.

Cognitive debt

I want to borrow a concept from Margaret-Anne Storey, a professor of computer science at the University of Victoria. She published a piece called What I’m Hearing About Cognitive Debt.

We all know technical debt. It lives in the code - the shortcuts, the workarounds, the architectural decisions made under pressure that you’d undo if you had the time.

Cognitive debt lives in the team and is the gap between how the system has evolved and how well the people responsible for it actually understand it.

Storey’s point is that teams hold a distributed theory of the system they work on. The theory isn’t only in the code but also in people’s heads, the test suite, the conversations engineers have at standup, whatever documentation is worth reading, and in the tooling. It’s held collectively.

As Storey puts it, the software may be “working”, but the theory of the system becomes harder to access and keep track of. It’s the shared understanding of why it works the way it does - what trade-offs were made, what it was meant to do - that erodes.

And once the people who held the theory are gone, or once enough of the system was generated by a process nobody understands, you can’t simply get the theory back. You have to rebuild it from scratch, which is slow and expensive - and sometimes you can’t rebuild it at all.

That’s what your senior engineers are feeling. They might not call it cognitive debt, but they know what it feels like.

The bottleneck moves

Your leadership may think you’re going faster, and that the coding bottleneck has gone. The bottleneck never goes, it moves.

Code...