The experience debt problem nobody’s planning for
There’s a conversation happening in every engineering leadership Slack, group chat, and conference hallway I walk into. AI is changing software development. Teams are getting leaner. Code is getting cheaper. The question everyone is circling but not quite landing on: what actually matters now?
I’ve been building software teams for a long time — at GitHub, at Netlify, through acquisitions and scaling and the occasional spectacular implosion. More recently at n8n, where I work with enterprise customers who are navigating exactly this shift. I’ve always been more interested in solving problems than writing code for its own sake. I fell out of love with code-as-craft in my twenties. I stayed in love with shipping things that matter. Which means this moment feels less like a threat and more like the world finally catching up to a way of working I always believed in.
But I also think we’re getting some of the narrative wrong. Badly wrong, in some cases.
Leaner isn’t the whole story
“Leaner teams” is becoming received wisdom. Agentic systems are genuinely getting better. A small team with good tooling and a tight feedback loop can now deliver what used to require three times the headcount. That’s real. I’m seeing it.
What the leaner team story doesn’t tell you is which people you keep.
The discourse is dominated by what Gergely Orosz calls the trimodal market — the Stripes, the Shopifys, the companies already operating at the bleeding edge of engineering culture. They’re the ones getting quoted in TechCrunch about engineers who haven’t written a line of code since December. But most of the software world isn’t Stripe. Some companies still have six-month release cycles. Some are still in the middle of their cloud migration. Panic-adopting AI in those environments doesn’t produce 4x productivity. It produces faster slop.
Norberto Lopes, VP of Engineering at incident.io, makes this point clearly: AI amplifies your existing engineering culture. Strong review discipline and short feedback loops? AI accelerates good outcomes. Weak foundations? AI accelerates the problems. The boring stuff — fast builds, good tests, clear task breakdowns — pays double when AI is in the mix.
Most organisations aren’t there yet. And they’re being told to adopt AI before they’ve built the culture that makes it work.
Cognitive debt isn’t my biggest fear
A lot of the discourse right now is about cognitive debt — the idea that if AI writes all your code and you only review it, your ability to reason about code quietly atrophies. There’s research backing this up: developers who fully delegate to AI finish tasks fastest and score worst on evaluations. The skill you stop practising declines.
This is real, but it’s seniority-dependent; and not in the direction most people assume.
For some engineers — especially the best junior ones — AI is genuinely uplevelling. They’re using it the right way: asking for explanations, comparing approaches, intentionally breaking things to understand what happens. They’re learning faster in unfamiliar codebases and languages than any previous generation could. Cognitive debt only accumulates if you get lazy. And engineers who were going to get lazy were going to find a way to do that anyway.
For more experienced engineers, AI is letting many get hands-on again in ways that got squeezed out by management overhead. I’m spending more time in the actual problem space than I have in years.
So cognitive debt isn’t my primary concern. Something else is.
Experience debt is the real problem
Cognitive debt is largely recoverable. You can ask Claude to explain the code. You can rebuild the mental model. You can learn.
Experience debt is different. You can’t prompt your way out of it.
Experience debt is what accumulates when you’ve never been through a catastrophic release, never owned a 3am system failure, never made an architectural decision that seemed brilliant and then cost you eighteen months of pain to undo. It’s the absence of pattern recognition that only comes from proximity to failure.
The best engineers I’ve worked with aren’t just technically strong. They have a nose for trouble. They walk into a codebase and feel when something is about to go wrong. They’ve seen enough failure modes that they recognise the early signals. That judgment isn’t in any training data. It can’t be acquired by reviewing AI-generated PRs. It’s built through lived experience of consequence.
OpenAI’s Harness Engineering piece makes this concrete without quite saying it: a team of three engineers built a million-line production codebase in five months, with zero human-written code. The engineers didn’t write code; they designed the system that let AI write it reliably — the constraints, feedback loops, architectural boundaries, the “golden principles” baked into the repository itself. That kind of system design requires deep judgment. Knowing what to enforce, what to leave flexible, what will break under load and what won’t. You cannot build that from a standing start. It accumulates through years of getting it wrong.
And the natural forcing functions for building that experience are quietly disappearing. Junior engineers who never own anything that can break. Mid-levels shielded from production. Seniors whose job becomes increasingly “approve or reject what the agent produced.” The pipeline that created judgment through accumulated failure is being bypassed.
This isn’t an argument for artificial difficulty or gatekeeping. The question isn’t “did you suffer enough?” The question is: how do we deliberately engineer the conditions for judgment to develop, when the natural mechanisms are vanishing? That’s a leadership challenge. It means giving engineers real ownership of things that matter and can break. Post-mortems with teeth — not blame, but genuine interrogation of why. Blameless culture that still asks the hard questions. Simulation. Deliberate exposure to failure modes before they become crises.
The experience has to be created intentionally, not assumed. If we don’t figure this out, we’ll end up with teams that are fast, cheap, and brittle in ways that won’t show up on any velocity dashboard.
The bottleneck moved. Most teams haven’t.
A question that came up in a group chat recently: if we accept that AI is changing how software products are built and who we need to achieve that — what does it mean for leadership?
When code gets cheap, the constraint moves upstream. The bottleneck is no longer implementation. It’s product thinking — understanding the problem deeply enough to spec it well, making the call on what to build and why, translating between business strategy and engineering decisions. These skills were always valuable and chronically underinvested in. Now they’re load-bearing.
This has implications for almost every role.
Engineers: the ones who thrive are systems thinkers first. When I started out, you had to be — full stack wasn’t a job title, it was just the job. The last decade of hyper-specialisation, partly driven by scale and partly by having too much VC money to spend on headcount, created a lot of narrow specialists whose entire role was translating Jira tickets into syntax. AI isn’t replacing software engineering; it’s exposing that those roles were always a workaround. The engineers who survive the cut can hold the whole problem in their head, understand second-order effects, see how a change ripples through five other things. They’re also product-minded enough to question whether the thing is worth building at all. That used to be a senior superpower. Now it’s the baseline expectation.
PMs: product thinking becoming more valuable doesn’t equal more PM headcount. The traditional PM role was largely translation: business requirement to ticket to engineer to output. AI compresses that loop dramatically. An engineer with good product taste can now handle significant chunks of what PMs used to own. The PMs who survive — and flourish — are the ones doing actual strategy and genuine customer insight; not backlog grooming, not acceptance criteria, not the stand-up facilitator in a Notion doc. The PMs who were mostly process managers are genuinely at risk. What I actually need from my product function right now: more strategy from fewer people, and more product-minded engineers to execute. That’s not “more PMs.” That’s a different kind of PM, and a different expectation of engineers.
Accountability doesn’t compress
There’s one more thing the leaner team narrative gets wrong, and it matters particularly in enterprise contexts.
AI can write the code. It cannot sign the contract. It cannot own the post-mortem. It cannot look a CISO in the eye and explain what happened and what you’re going to do about it.
As teams get smaller and AI does more, the humans who remain don’t carry less responsibility — they carry more per head. The accountability doesn’t compress with the headcount. It concentrates. Every engineer, every EM, every leader on a leaner team has more surface area, more consequence per decision, more exposure when something goes wrong.
Charity Majors talks about outcome orientation being excellent preparation for the AI era — SREs judged on uptime, not elegance. I think that’s right. But outcome orientation under higher accountability is a different psychological and professional challenge than most people have been trained for.
The engineers who thrive in this environment aren’t just technically good and product-minded. They’re comfortable with consequence. They’ve been through enough to know what failure feels like and how to navigate it. Which brings us back to experience debt.
The next five years won’t be evenly distributed
The world is changing faster than most people’s planning horizons. Over the next five years, the SDLC and tools we use will look substantially different. But the distribution will be trimodal as always. Some companies will be at the bleeding edge. Most will be catching up. A non-trivial number will still be having the cloud migration conversation.
So the question isn’t “is AI changing everything?” It is. The question is what kind of engineer, PM, or leader you need to be to stay relevant across that distribution.
The ones who will matter are the ones with genuine judgment. Product judgment. Architectural judgment. Systems thinking that sees the whole board, not just the next move. The judgment that comes from having shipped things that mattered, broken things that hurt, and built back better. The judgment that AI cannot generate because it isn’t in the training data.
The leaner team is coming. What you need to figure out — as a leader, and as an individual — is whether you’re building the kind of judgment that survives the cut. And whether your organisation is creating the conditions for the next generation to build it too, rather than quietly assuming that speed is the same thing as growth.
It isn’t. We’ll find out the difference at 3am, when the system is on fire and the engineer who’s supposed to fix it has only ever reviewed AI-generated PRs.
Build the judgment. Deliberately. Now.