Learning to Code Is Not About Speed—It's About Depth, Retention, and Fighting Cognitive Decline
We’ve built a culture that glorifies speed. Ship fast, iterate quickly, move fast and break things. In education, we celebrate the student who can breeze through material and get the right answers. In tech, we celebrate the developer who ships features in a day.
But we’ve missed something critical: speed without depth is just motion, not movement.
I realized this recently while learning Neo VIM. There’s no shortcut to muscle memory. I can’t ask Claude or ChatGPT to write code in my editor for me—I have to sit down and type :wq until my fingers know it without thinking. Every character I type manually reinforces neural pathways. Every mistake I make and correct teaches me something an AI executor never could.
This is the exact inverse of what many developers are doing with AI tools.
The AI Math Study: A Warning Sign
In 2025, researchers at Wharton and Carnegie Mellon published a study that should concern every educator, parent, and learner: “Generative AI without guardrails can harm learning: Evidence from high school mathematics.”
The findings were stark. Nearly 1,000 high school students were given access to GPT-4 to help study for math. Initially, this seemed great—students with AI support showed performance improvements of 48% to 127% compared to peers without it. But here’s the critical part:
When the researchers removed access to AI, students who had been using it performed 17% worse than students who never had AI at all.
Let that sink in. Using AI as a shortcut didn’t just fail to help in the long term—it actively made students worse learners.
Why? Because students were using AI as a crutch during practice problems. They weren’t struggling through the hard part of learning—they were outsourcing it. Their brains never had to do the actual cognitive work. When the tool was gone, they had nothing but weak mental models and hollow understanding.
The study identified one safeguard that worked: when AI tools had built-in constraints that forced students to do the actual thinking—answering questions step-by-step before getting help, for example—the negative effects largely disappeared. In other words, when AI became a consultant rather than an executor, learning improved.
Surface Learning vs. Deep Learning: An Old Problem in New Clothes
This isn’t new. Educational research has known for decades that there’s a difference between surface learning and deep learning.
Surface learners skim, memorize, and look for shortcuts to get right answers. They’re good at test-taking. They’re also forgotten everything within weeks.
Deep learners struggle, question, make connections, and build mental models. They’re slower at first, but what they learn sticks. Years later, they can still apply the principles because they understand them at a fundamental level.
The tragic part? Students have always been incentivized toward surface learning. Schools reward the right answer, not the process. Cheating—or modern “skimming by”—works. You can get a 4.0 GPA while learning almost nothing, because the system measures outputs, not understanding.
Now we’ve automated surface learning. We’ve built tools that make it frictionless.
The Personal Experiment
I’m deliberately walking against the tide right now. I’m teaching myself Neo VIM entirely manually. No AI code generation. When I get stuck, I ask Claude questions—but I write the code myself. I make mistakes. I delete 20 lines and rewrite them three times. My productivity is terrible compared to what it could be with full AI assistance.
But here’s what’s happening: I’m learning VIM. Not just learning about it, but actually internalizing it. My fingers are building muscle memory. My brain is making connections between the problem and the solution. When I hit a new problem in the editor, I’m more likely to think “I should try…” rather than “let me ask AI.”
I’m also writing code always by myself and using AI strictly as a consultant. When I need to solve a problem, I think first. I try things. I fail. Then I ask Claude for guidance, not execution. “How would you approach this?” not “write this for me.” I use AI for judgment questions, architectural decisions, and when I’m stuck—but the originality and actual coding is mine.
Is my code slower to write? Yes. Is it better code? Absolutely. More importantly, am I actually learning? I’m certain I am, because I’m doing the work.
The Cognitive Decline Connection
There’s another dimension to this, and it’s more profound than productivity metrics.
Research consistently shows that cognitive leisure activities—especially learning new skills and engaging with intellectually challenging material—are among the most powerful preventive factors for cognitive decline and dementia as we age.
A 2017 meta-analysis published in Clinical Interventions in Aging found that learning new skills, problem-solving activities, and cognitively demanding hobbies significantly improve cognitive function and build what researchers call “cognitive reserve”—essentially, the brain’s resistance to degeneration.
Here’s the uncomfortable truth: if you’re using AI to execute everything, you’re not getting that benefit. You’re outsourcing the cognitive work that keeps your mind sharp.
When you force yourself to write code manually, to debug without asking AI first, to struggle through a problem until you solve it—you’re not just learning that specific thing. You’re training your brain’s pattern-recognition systems, your working memory, your ability to hold complex models in your mind. You’re building cognitive reserve that might matter decades from now.
This isn’t poetic. This is neuroscience.
Why We Cheat Ourselves
We’ve gotten really good at rationalizing shortcuts.
“I’m just using tools more efficiently.” “The AI can do this better than I can.” “I don’t need to understand this part, I just need it to work.” “Time is money, why waste hours learning when I can ship in minutes?”
These are surface learning arguments dressed up in professional language.
The parallels to academic cheating are too obvious to miss. A student who gets someone else to write their essay has a perfect paper and zero learning. A developer who gets AI to write their code ships faster and learns almost nothing new. The system rewards the output. It doesn’t measure understanding.
But here’s what both miss: you’re not cheating the system, you’re cheating yourself. The system doesn’t care. The system just wants the essay, the feature, the metric. You’re the one who loses—in real skills, in adaptability, in the ability to think when the tool isn’t there.
The Long Game
I think about this a lot in the context of our industry. We celebrate developers who move fast. But moving fast means different things.
There’s moving fast because you’ve put in the work to understand systems deeply, so you can ship confidently.
And there’s moving fast because you’ve outsourced all the hard thinking and you’re just assembling pre-built pieces without understanding them.
The first person will thrive when things break, when requirements change, when they have to learn a new stack, when they’re debugging in a codebase they’ve never seen.
The second person will be stuck. And then they’ll ask an AI what to do, which is fine until the AI is wrong, or the problem is unusual enough that no training data exists for it.
Learning to code properly is learning to think. Not learning syntax. Not learning frameworks. Not learning “how to prompt an AI to write code.” Learning to think through problems, to understand tradeoffs, to build mental models that transfer to new domains.
That doesn’t happen quickly. It doesn’t happen if you outsource the cognitive load.
What “Deep Learning” Looks Like
So what does the alternative actually look like?
Struggle through problems yourself first. Don’t immediately ask for help or reach for a tool. Try three approaches. Fail twice. Learn something from the failure.
Write code by hand. Whether it’s VIM or VS Code or a notebook. Don’t let an AI autocomplete your thoughts. Type it. Let your fingers encode the patterns.
Use AI as a consultant, not an executor. Ask “why would you do this differently?” not “write this for me.” Ask “what am I missing?” not “fix this.” The guidance is helpful. The execution is learning.
Embrace small, intentional constraints. Learn one thing at a time. Pick VIM and don’t use VS Code shortcuts. Pick a language and don’t use ChatGPT to write it. Pick a problem and don’t look up the solution until you’ve failed enough times to understand why you can’t solve it.
Measure retention, not speed. Can you do this without AI next week? Can you explain why you made that choice? Can you apply the principle to a new problem? Those are the metrics that matter.
The Real ROI
We talk about learning to code as a career move. And sure, it is. You can make good money shipping code quickly.
But there’s a longer game here. The developers who stay relevant, who become architects, who can tackle novel problems—they’re the ones who learned deeply. The ones who struggled. The ones who built real understanding instead of just pattern-matching outputs.
And there’s the cognitive health angle. In a world where cognitive decline is a growing concern, the habit of learning new, difficult skills is one of the most effective preventative medicines available. Not a pill. Not a supplement. The actual practice of doing hard things that require thinking.
Learning to code the right way—slowly, manually, with AI as a consultant and not an executor—is an investment. Not just in your career. In your ability to think. In your brain’s resilience against time.
When you sit down and write code without shortcuts, you’re not just shipping features. You’re literally building the neural pathways that might protect your mind decades from now.
The Case for Friction
Friction is uncomfortable. We’ve built the entire modern tech stack to eliminate it.
But some friction is actually the point. The friction of learning manually is what creates learning. The friction of struggling through a problem is what creates understanding. The friction of writing code yourself—in VIM, with careful keystrokes, at a pace that might look slower—is what creates mastery.
This is especially critical right now, when we have incredibly powerful AI tools that make it easy to do the wrong thing. It’s easy to become a code-generation monkey. It’s hard to become a real engineer.
The good news? The choice is yours. You can keep moving fast. Or you can move carefully, build depth, and play the longer game.
I’ll be here in Neo VIM, typing :wq one keystroke at a time.
References & Further Reading
-
Bastani, H., Bastani, O., Sungu, A., Ge, H., Kabakcı, Ö., & Mariman, R. (2025). “Generative AI without guardrails can harm learning: Evidence from high school mathematics.” Proceedings of the National Academy of Sciences, 2025. SSRN Version
-
Klimova, B., Valis, M., & Kuca, K. (2017). “Cognitive decline in normal aging and its prevention: a review on non-pharmacological lifestyle strategies.” Clinical Interventions in Aging, 12, 1315-1323.
-
Roediger, H.L., & Butler, A.C. (2011). “The critical role of retrieval practice in long-term retention.” Trends in Cognitive Sciences, 15(5), 227-234.
-
Wang, H.X., Karp, A., Winblad, B., & Fratiglioni, L. (2013). “Late life leisure activities and risk of cognitive decline.” The Journals of Gerontology, 57(5), P410-P416.