Opinion
6 min read
Bart Jacobs is Head of Engineering at November Five, leading the engineering transformation across leadership and AI-led delivery. He writes about culture, what good engineering looks like at scale, and where AI fits in.
Skills decay through disuse, and heavy AI use means some of the skills we built our careers on are getting weaker without anyone noticing.
There are two kinds of getting worse. Conscious deskilling is a skill a team decided to let go. Unconscious deskilling is a skill nobody decided anything about, and that's the dangerous bucket.
Our own sense of how good we still are is unreliable. METR's trial found developers who felt 20% faster were measurably slower, and Anthropic's study found AI-assisted learners scored 17 points lower on comprehension.
This matters at team level because the approval gate in an AI-led delivery model is only as good as the judgment of the person approving. If that judgment decays, the gate becomes a rubber stamp at AI speed.
The fix isn't less AI. It's moving skills from the unconscious bucket to the conscious one. Keep two lists per team, ask "what did we get worse at?" in every retro, hold a small deliberate practice for the skills that stay, use AI to build understanding and not only output, and decide up front what juniors learn by hand.
I'll answer the question for myself first. Last month I got worse at writing Swift by hand.
I noticed it when I had to write a small piece of code without an agent open next to it. It was nothing complicated. Still, I was slower than I expected, I had to dig deep into my memory for syntax I used to type without thinking, and I realized I couldn't name the language changes that shipped in the last major release. I've written Swift for over a decade. That hadn't changed. What had changed is that I hadn't written Swift by hand in months, because I let AI write all of it.
The decline itself didn't surprise me. That part is predictable. What surprised me was that I hadn't noticed it until I was forced to.
That's the observation behind this post, and I'm sure it isn't unique to me. I see the same thing in the people around me. We rely on AI so heavily now that some of the skills we built our careers on are getting weaker, and most of us only find out when we need them.
Two kinds of getting worse
I want to separate two things that look the same from the outside but aren't.
The first is getting worse at something because we decided to. At November Five we're moving to a delivery model where engineers direct and review far more than they type. That's a choice, and it has consequences we've accepted. Fewer people will remember the exact signature of an API. Fewer people will write a view from scratch. Some muscle memory will go, and that's fine, because we've decided the time is better spent on specifying what to build and judging what comes back. I'd call this conscious deskilling. We know what we're letting go, we know why, and we can revisit it.
The second is getting worse at something because nobody decided anything. Nobody at November Five decided that we'd read documentation less closely. It happened because AI summarizes it for us. Nobody decided we'd read pull requests less carefully. It happened because a review tool reads them first and the diffs are larger than they used to be. Nobody decided we'd stop debugging from first principles. It happened because pasting a stack trace into a chat usually works. I'd call this unconscious deskilling. No one chose it, no one tracks it, and the person losing the skill is usually the last to know.
The same skill can sit in either bucket. What separates the two is whether someone made the call.
Why you won't notice on your own
The uncomfortable part is that our own sense of how good we still are isn't a reliable signal. METR ran a randomized controlled trial last year with sixteen experienced open source developers working on codebases they knew well. With AI tools they took 19% longer to complete their tasks. Afterwards, those same developers estimated that AI had made them about 20% faster.
METR's follow-up, published this February, suggests the slowdown has since turned into a speedup. The original developers measured around 18% faster late last year, although the error bars are wide and the authors call the number an unreliable signal. The speed figure will keep moving as the tools improve. The gap between what the developers measured and what they felt is the part that matters here, and the follow-up repeats that self-reported speedups are unreliable.
Anthropic's own study from earlier this year points at the same gap from the other side. Developers learning an unfamiliar Python library with AI assistance scored 17 points lower on a comprehension quiz than developers who coded by hand, and they didn't finish meaningfully faster. The participants who did retain the material used AI to build understanding, by asking follow-up and conceptual questions, rather than only to produce code.
I read both as evidence for the same thing. Skill decay through disuse happens, our perception of it lags, and the only way to see it is to look for it on purpose.
Why this matters more for a team than for a person
If this were only about my Swift, it would be a note to self. It matters at team level because the delivery model we're moving to depends on exactly the skills that decay quietly.
In our model humans define the outcome, AI proposes and builds, and humans approve. That approval is only worth something if the person approving can still judge the work. Judging an AI-written pull request means being able to read it closely, spot a wrong abstraction, notice that the code is correct but not idiomatic for Swift in 2026, and see that a test passes for the wrong reason. Those are the skills that decay when you stop writing and start accepting. If they go, the approval gate turns into a rubber stamp, and because AI produces far more output than an engineer would, that rubber stamp lets more wrong decisions through, faster.
There's a second version of this problem for people who never built the skill in the first place. An engineer who joins us this year and has used AI from day one won't deskill. They'll skip the skill. That's no better, and it's harder to spot, because there was never a baseline to compare against.
What we should do about it
The answer isn't to use AI less. It's to move as much as possible from the second bucket to the first.
Write it down. Each team keeps two lists. The first holds the skills we've decided to stop maintaining. The second holds the skills we keep sharp on purpose, and how we do that. Anything that isn't on either list is in the unconscious bucket by definition, and that's the list to worry about.
Ask the question in the retro. "What did we get worse at this month?" takes five minutes. If nobody can name anything, don't conclude that nothing changed. More likely, nobody looked.
Keep a deliberate practice for what stays. This means a small, regular dose of the skill without AI, not a return to the old way. That can be one pull request a month written by hand. It can be a debugging session where the stack trace stays out of the chat window until you have a hypothesis of your own. It can be reading the Swift or TypeScript release notes as a team instead of asking for a summary.
Use AI for comprehension and not only for output. The Anthropic study is useful here because it shows the same tool producing both outcomes. Asking why the generated code works is a different activity from accepting that it does.
Decide it for juniors before they start. If a new engineer is going to learn the codebase through a coding agent, decide up front which parts they learn by hand first, and check that they did.
I'll add one more reason to do this. If we tell clients that engineers approve what AI builds, we should be able to say what makes those engineers qualified to approve it. A team that can name which skills it let go and which it keeps sharp can answer that question. A team that can't is guessing.
The question is for you
I chose the title because the question works as a tool. Ask it of your team this week, and ask it of yourself. Mine was Swift. I'd like to hear what yours was.
