Paraphrasing of a talk delivered at Web Directions AI Engineer Melbourne, June 2026
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 generation is faster but code review is now backed up, and review doesn’t scale the way generation does. Review is paced by how fast a human can hold a concept in their head, think about it, and form a view on whether it should go in.
One of two things happens: either review becomes the new bottleneck and everyone gets frustrated or, more likely, review quality slips. The PRs get bigger, the diffs get harder to follow, reviewers stop reading line by line and start trusting the shape of it. More “LGTM”s. And the cognitive debt builds.
There’s a phrase from sociology that captures this: the normalisation of deviance. It comes from Diane Vaughan, who coined it to explain the Challenger disaster. The engineers had data showing the O-rings eroded in cold weather, but every previous launch had succeeded, so each flight made the risk a little more acceptable. Vaughan’s phrase is that NASA developed “a definition of the situation” that let them carry on.
Your teams develop a definition of “reviewed” that lets everyone carry on. Those LGTMs are the deviance. Every time the model writes the right thing without anyone watching closely, the bar for when you need to watch closely drops a notch - one merge that didn’t blow up, then another, until one does. That’s the standard drifting.
You can’t review every line - that’s never going to survive this much code. Review has to move up a level - checking the architecture, the tests, and letting the machine help check the machine. The danger is when review moves up a level and nobody holds the theory underneath it. Some human judgement has to stay put.
The signals stopped meaning what they meant
Another challenge is that the signals we used to read a codebase don’t mean what they used to. Simon Willison - co-creator of Django, and one of the sharper commentators on AI - talks about assessing repos for quality. A hundred commits, a good README, a comprehensive test suite used to mean care and attention. It was a signal that someone had invested in the thing. Now? A hundred commits, a good README and a comprehensive test suite is half an hour with an agent.
He says: “Even for my own projects, I can’t tell the difference.” And so much of how we run engineering organisations rests on reading those signals - hiring, promotion, trust between teams. All of it now runs on signals that are a lot noisier.
So we have faster generation, a review bottleneck, and the signals we rely on getting corrupted. The whole lifecycle was calibrated for a production rate that no longer exists.
What the data is starting to show #
Before I talk data, I need to say something about it: we’re still early.
Almost all of the research is new, mostly on small samples, mostly self-reported, mostly with selection effects the authors themselves flag. Some headline numbers have already been revised by their own authors. If someone tells you they know with confidence what AI is doing to engineering productivity, they’re getting ahead of the evidence.
So what follows isn’t proof but it’s a pattern - multiple groups, measuring different things in different ways, starting to point in a consistent direction.
Lauren Peate’s team at Multitudes surveyed just over 400 engineers about what concerns them about AI tools. The top three:
The top concerns aren’t “it’ll take my job” or “the tool is bad.” They are, in order: we’ll end up with code we can’t maintain, we’ll get worse at solving problems, and we’ll stop understanding what we’ve built. That’s cognitive debt, in the engineers’ own words.
The same data shows PRs merged up about 27% - which sounds great - but out-of-hours commits up almost 20%. The throughput gain is real, but some of it is borrowed from evenings, and from weekends.
The Multitudes also covers quality. Teams without a quality bar see PR size creep up - AI is verbose by default - and as PRs grow, review quality drops and defects slip through. Teams that track quality as a leading indicator steer AI the other way: one team merged 161% more PRs while shrinking PR size by 8.5%. That smaller, reviewable change is how you can keep cognitive debt from building. The difference is whether the organisation said anything about what good looks like.
I should be fair about the counter-evidence, too, because the picture is mixed. Juniors do gain more from AI - across several studies, less experienced engineers see the bigger gains. Satisfaction runs high; 72% in one ZoomInfo deployment. Code generation is faster. It’s also true that in a Tilburg University study, senior engineers ended up reviewing so much more code that their own output dropped 19%. DORA found that as adoption rises, delivery throughput and instability climb together. Bugs per developer were up 54% in the Faros AI data. And work from Anthropic’s safety fellows found 17% worse retention on newly learned skills among heavy users. The question isn’t “is AI good or bad.” It’s whether you’re paying attention to both columns or just one.
What are we trying to be good at? #
In our profession, the thing the machine does - the implementation - has become dramatically cheaper. The thing the machine can’t do - judgement, knowing what to build, knowing whether it’s right, knowing what to throw away - has become much more valuable. Pope Leo XIV thought this significant enough to warn, in his first encyclical, that AI tools can “weaken personal creativity and judgment”.
Which leaves the question I think the whole industry is wrestling with: what are we trying to be good at?
The answer is no longer “writing the code.” The expensive part is everything around writing the code - knowing what’s worth building, knowing the trade-offs, knowing what to keep and what to throw away, and holding the theory of the system in your head.
We’ve run a version of this experiment before. After Kasparov lost to Deep Blue, he invented Advanced Chess, where a human plays paired with a computer. The machine handles the tactics and the raw calculation; the human is freed up for strategy. And in the team version, freestyle chess, the winners weren’t the grandmasters or the strongest computers. They were the teams with the best process for working together.
Meanwhile, researchers at the University of Mannheim studied the doctors using AI diagnostic tools. They found that resistance to tools wasn’t about whether the AI worked, it was about professional identity - specifically the fear of losing expertise and autonomy.
The Leiden Declaration on AI and Mathematics makes the point for a third profession, insisting that mathematics “is, and should always remain, a profoundly human endeavour”.
What we’re really asking people to do is move from hands on the keyboard to hands on the wheel. The skills that make you good at your job change and the satisfaction you get from it changes too.
Think about self-driving cars; if all you want is to get from A to B, a self-driving car is probably the better option - faster, safer, and you can do other things on the way. But some people love driving: the pedals, the gear change, the road. Telling them the car will now drive itself isn’t a productivity win, it’s a loss of something they care about.
Some of your engineers got into this business because they love writing code - not as a means to an end, but as the thing itself - the craft of it. You can’t mandate an identity shift but you can create the conditions for it.
This is a change to what expertise means in your organisation.
What to do about it #
So what do you actually do?
1. Name the fear properly
Walk into your next leadership conversation treating engineer pushback as change resistance to be steamrolled, and you’ll get friction. Acknowledge that this transition asks something real of your engineers - that it shifts what expertise means, that cognitive debt is a genuine organisational risk, that the people slowing down are often the ones who understand the system best - and you’ll get a different conversation.
Your most cautious engineers are your early warning system.
2. Protect the learning conditions
According to Atlassian’s Teamwork Lab, younger tech workers are 38% more likely to hide their AI use from the team. The people doing the experimenting are doing it in private, so the learning isn’t transferring.
You need to model the behaviours you want and promote psychological safety. Say “I tried this with the agent and it worked,” or “I tried it and it didn’t, here’s why.” The Multitudes data showed that peer-to-peer learning - engineers sharing what actually worked in your context - is the most effective adoption accelerant after simply paying for the licences. Create the time and the structures for it, and then protect that time when delivery pressure mounts.
In the teams I’ve worked with, what helped was giving small groups explicit permission to experiment - “try this, see what works, tell us what you learn” - and then making the report-back the actual deliverable.
3. Make quality the floor, not the ceiling
Automated testing, coverage requirements, linting, security scanning - these are the conditions that make it safe to move fast, and they’re where the theory of the system gets preserved. When AI generates most of your code, these matter more, not less, because they’re how the discipline survives the volume.
Tell your teams that you want the speed and the quality - that the two aren’t in opposition.
One last thing #
Some of your engineers should be a little scared. They’re reading something that the rest of us haven’t caught up to yet. The question is whether you’re listening to what it’s telling you.
The calculator didn’t make mathematicians obsolete, but it did change what mathematical skill meant. We’re standing in the same kind of moment - and the engineering organisations that come through it well will be the ones that treated it as a change to what expertise means, not a tool to roll out.
Sources #
Storey, M-A. “What I’m Hearing About Cognitive Debt.” margaretstorey.com, February 2026.
https://margaretstorey.com/blog/2026/02/18/cognitive-debt-revisited/ Vaughan, D. The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA. University of Chicago Press, 1996.
Willison, S. “Vibe coding and agentic engineering are getting closer than I’d like.” simonwillison.net, May 2026.
https://simonwillison.net/2026/May/6/vibe-coding-and-agentic-engineering/ Rehberger, J. “The Normalization of Deviance in AI.” embracethered.com, December 2025. (Influenced the framing in Willison, above.)
https://embracethered.com/blog/posts/2025/the-normalization-of-deviance-in-ai/ Peate, L. & Katial, V. “What matters most for AI rollouts: How you lead.” Multitudes, 2025. (Telemetry from 500+ developers, N=372 for metrics analysis.)
https://www.multitudes.com/data-to-cut-through-the-hype Peate, L. & Lei, Y. “What matters most for embedding AI: How you adapt.” Multitudes, March 2026. (N=428 survey respondents.)
https://www.multitudes.com/what-matters-most-for-embedding-ai-how-you-adapt Leo XIV, Magnifica Humanitas §100, Vatican (15 May 2026) https://www.vatican.va/content/leo-xiv/en/encyclicals/documents/20260515-magnifica-humanitas.html
Jussupow, E., Spohrer, K. & Heinzl, A. (2022). Identity Threats as a Reason for Resistance to Artificial Intelligence: Survey Study With Medical Students and Professionals. JMIR Formative Research, 6(3). https://doi.org/10.2196/28750
Leiden Declaration Working Group (2026). Leiden Declaration on Artificial Intelligence and Mathematics. Lorentz Center, Leiden University. https://leidendeclaration.ai
Xu, F. et al. “AI-Assisted Programming Decreases the Productivity of Experienced Developers by Increasing the Technical Debt and Maintenance Burden.” arXiv:2510.10165 (econ.GN), October 2025 (rev. January 2026). https://arxiv.org/abs/2510.10165
Faros AI. “AI Engineering Report 2026: The Acceleration Whiplash.” Faros AI, 2026. (Telemetry from 22,000 developers, 4,000 teams.)
https://www.faros.ai/research/ai-acceleration-whiplash Harvey, N. & Baolin, J. “Balancing AI tensions: Moving from AI adoption to effective SDLC use.” DORA / Google Cloud, March 2026.
https://dora.dev/insights/balancing-ai-tensions/ Dasdan, A. et al. “Experience with GitHub Copilot for Developer Productivity at ZoomInfo.” ZoomInfo Engineering Blog, February 2025. https://engineering.zoominfo.com/experience-with-github-copilot-for-developer-productivity-at-zoominfo
Sands, M. et al. “New Grads are 1.5x More Likely to Use AI Daily.” Atlassian Teamwork Lab, April 2026.
https://www.atlassian.com/blog/ai-at-work/new-grads-ai-skills-hiring-strategy Shen, J.H. & Tamkin, A. “How AI Impacts Skill Formation.” Anthropic Safety Fellows Program, January 2026. https://arxiv.org/abs/2601.20245