The Skill I Almost Never Built, Because AI Kept Rescuing Me From the Struggle That Would’ve Built It 🧗
“You don’t remember the answer someone handed you. You remember the hour you spent lost before you found it yourself.”
I’ve told the intern story a few times now — following a Redux-plus-RxDart pattern my seniors handed down, not really understanding why any of it worked. What I usually skip is the part where understanding actually showed up. It wasn’t the day they explained it to me. It arrived months later, debugging a state-sync bug at 11pm with nobody around to ask, when the pattern finally clicked because I’d been stuck inside the confusion long enough to see its actual shape.
I went looking for research on why that kind of struggle matters, half-expecting to find nothing but nostalgia for a harder past. Instead I found a sharp piece by developer and coach Lars Faye, backed by a stack of real studies that made me rethink how carefully I want to keep using the tools I’ve written so much about.
The Paradox Nobody Wants to Say Out Loud 🪤
“The exact skill you need to use these tools well is the one they’re quietly wearing down while you use them.”
Faye calls it the skilled orchestrator paradox. Once I read the phrase, I started noticing it everywhere. Getting real value from an AI coding agent — knowing when to trust its output, catching a subtly wrong assumption, steering it back on course — takes the kind of judgment that only comes from years of debugging things the hard way. But the people entering the field right now, the ones who’d most need that judgment, are also the ones being told to lean on tools that prevent them from ever building it.
A novice needing expert-level instincts just to use the tool safely isn’t a minor irony. It’s the actual trap.
The Study That Actually Stopped Me 📊
“They thought they had a personal tutor. The data told a different story.”
A JetBrains-cited study — “The Widening Gap,” built on real, live coding sessions — turned up something genuinely counterintuitive. Developers leaning on heavy AI assistance often skipped planning entirely, since the model had already reasoned its way there for them. Sessions ended with what the researchers called an illusion of competence, not real understanding.
The ones who did better had developed something the researchers named negative expertise — the specific skill of spotting a wrong AI suggestion and ignoring it, instead of being quietly led somewhere they never meant to go.
A separate, large-scale UPenn study puts a harder number on it. Students leaning on an LLM to learn math performed 17% worse than students working from nothing but a textbook, and — almost cruelly — believed they were doing great the entire time. Confidence and competence had come apart, and nobody in the study noticed it happening to them.
What Actually Worked, In the Same Study 🎓
“Same tool, opposite result — because of how it got used, not whether it got used.”
This is the part that stopped me from writing the whole piece off as another “AI is bad” take. The UPenn researchers also tested a Tutor-mode version: students asked the AI for help, then solved the actual problem on their own instead of copying an answer straight through. That group performed 127% better in AI-assisted practice sessions than the plain-textbook group.
The difference was never the tool. It was who was doing the thinking. The moment the model stopped being the means of production and the friction stayed where it belonged — with the person trying to learn — the outcome flipped completely.
Anthropic’s own 2026 research into how AI assistance shapes skill formation reached a similar, faintly uncomfortable conclusion: getting stuck, genuinely and painfully stuck, seems to matter for building real mastery. Not despite the discomfort. Because of it.
The German Word for the Thing I Actually Missed 🖐️
“Fingerspitzengefühl. Fingertip feeling. The instinct that fires before you can even explain why.”
Faye’s piece borrows this word for the kind of intuition friction actually builds — the moment a developer looks at a piece of code and just knows, before being able to put it into words, that it’s going to cause trouble later. Watching someone else cook a perfect steak and asking sharp questions about it won’t give you that. Ruining your own first attempt will.
That line is the one that actually landed on me personally. Every layer in my own Claude Code setup — the hooks forcing it to state facts before touching a file, the hard line around anything irreversible — wasn’t really about distrust of the model. Without fully naming it at the time, I was trying to keep enough friction in my own process to keep building that fingertip feeling instead of slowly losing it.
Cognitive Debt Isn’t the Same Thing as Cognitive Offloading ⚖️
“One’s delegating the boring part. The other is quietly handing over your judgment and hoping nobody checks.”
This distinction is the single most useful thing I pulled from the whole piece — I’d never cleanly separated the two before seeing it named out loud like this. Offloading a genuinely rote task, boilerplate, a repetitive refactor, something you’ve already proven you understand, costs you nothing real. Offloading the actual judgment call — should this even work this way — is debt. It doesn’t show up on the invoice right away. It shows up later, as a gap in understanding you didn’t realize you’d been quietly accumulating.
Faye’s checklist for telling the two apart is worth sitting with instead of skimming past: could you do this without the tool if you had to? Are you using it to understand something more deeply, or just to finish faster? If you had to explain what the generated code is actually doing, could you? Have you checked this against anything besides the model’s own confident tone?
Where I Actually Land On This 💭
I’m not stepping away from AI coding tools. That would be an odd thing to claim after writing this many articles about them. But something genuinely recalibrated while reading this. The friction I used to treat as an inconvenience worth engineering away turns out to be the exact mechanism that built whatever instinct I currently have. Remove it entirely, and I don’t get permanently faster. I just quietly stop the next version of that instinct from forming at all.
Kent Beck said something I keep returning to: it’s the act of programming itself, not the explanation of it, that cements real understanding of the domain you’re working in. If that holds — and everything in this research points that way — then the skill actually worth protecting isn’t shipping speed. It’s making sure I’m still, on purpose, choosing to get stuck sometimes.
Tags: AI Coding Agents, Software Engineering, Developer Skills, Career, Learning, Agentic Coding
Before you go
- Please take a moment to like the post and follow the writer!
- Did you know that over 400,000 developers share what they’re building, learning, and discovering across our platforms every month? Learn how you can contribute here.
The Skill I Almost Never Built, Because AI Kept Rescuing Me From the Struggle That Would’ve Built… was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.