Turning CS Knowledge into Deep Smarts: Three Mechanisms for Building Real Expertise in the AI Era

• Target audience: Engineers wondering whether AI should change how they learn, and anyone unsure how to re-approach CS (computer science) fundamentals
• Prerequisites: Some exposure to undergraduate-level CS basics, such as data structures and algorithms
• Reading time: 15 minutes

Summary

AI is taking over implementation, search, and summarization, but that doesn’t mean the engineering profession is disappearing. Predictions of its demise have circled back roughly every decade since COBOL arrived 60 years ago, and each time, the abstraction layer moved up a notch and demand grew instead of shrinking¹. What AI is changing is the content of the job, not whether the job exists. If you accept that IT engineering is going to keep existing, then the foundation underneath it is still CS: data structures, algorithmic complexity, the basics of operating systems and networking, and how to reason about concurrency.

Knowledge that applies across the industry regardless of employer, the kind CS represents, is what cognitive scientists call domain-general knowledge. Knowledge that only works inside a specific company or industry is domain-specific knowledge. The two are learned differently and settle into the brain through different mechanisms. This article is about the former: CS as domain-general knowledge.

The real problem sits past that point. Knowing CS and being able to use it are separated by a gap that only practice closes. Cognitive science has shown for more than fifty years that expertise doesn’t come from memorization alone²³. A chess master doesn’t have the board memorized; the master perceives it as meaningful chunks. CS knowledge works the same way: reading a textbook doesn’t turn into usable judgment on its own. Now that AI can take over much of the implementation work, how you close that gap between knowing and using is what will decide whether your expertise as an engineer holds up.

This article walks through three cognitive mechanisms that close that gap: CS knowledge acting as a schema that speeds up new learning, a training loop built from deliberate practice and productive failure, and deep smarts, the process of turning experience into tacit knowledge. Together they sketch a way to convert CS knowledge into the kind of practical judgment AI can’t copy.

AI is changing what the job involves, not whether it exists

Let’s start with the premise. “Programmers are about to become unnecessary” has been predicted roughly every decade since COBOL showed up in 1960: fourth-generation languages in the 1980s, RAD and no-code tools in the 2000s, low-code in the 2010s, and now generative AI. Each time, people said you wouldn’t need specialized knowledge to write software, and each time, the abstraction layer moved up while demand grew anyway¹. When COBOL launched, the pitch was that clerks could write programs. What actually happened was that demand for engineers who maintain enormous COBOL-based business systems has persisted for more than 60 years.

The current wave of AI looks, so far, like it’s tracing the same arc. A 2025 METR study found that experienced developers were actually 19% slower when using AI tools⁴. Separate research found security vulnerabilities in 45% of AI-generated code⁵. Whatever “AI fully replaces coding” is supposed to mean, the evidence doesn’t support it yet.

What’s actually happening is that the center of gravity is shifting from writing code to verifying, judging, and integrating it. A lot of commentary frames this as a shift from memorizing syntax to judging edge cases and reading code⁶. But that framing carries a hidden assumption: that memorizing syntax used to be how you became an expert.

Was it, though?

The premise: expertise isn’t built by memorization

This isn’t a new discovery. In 1973, cognitive scientists Chase and Simon showed chess players, both experts and novices, a board mid-game for a few seconds and asked them to reproduce it from memory. What set the experts apart wasn’t raw memory. It was their ability to chunk the board into meaningful patterns. When the pieces were arranged randomly, in a way that would never occur in an actual game, that advantage nearly vanished². The same effect shows up in experienced programmers, who remember code as meaningful chunks rather than lines⁷. Psychologist K. Anders Ericsson and colleagues arrived at a related conclusion in 1993 with the concept of deliberate practice: not repetition for its own sake, but deliberate repetition of a well-defined task with immediate feedback³.

The clearest picture of how this process unfolds comes from the skill acquisition model the Dreyfus brothers proposed in 1980⁸. It describes five stages from novice to expert (novice, advanced beginner, competent, proficient, expert), and its central claim is that reliance on explicit rules falls away the further someone advances. An expert operating well isn’t recalling rules; the expert is acting on judgment that’s dissolved into intuition through thousands of prior experiences⁸. Memorized rules are a starting point for expertise, not its destination.

flowchart TB
    A["Novice<br>Relies on explicit rules"] --> B["Advanced beginner<br>Starts noticing situational cues"]
    B --> C["Competent<br>Conscious planning and analysis"]
    C --> D["Proficient<br>Intuitive grasp plus analytical checks"]
    D --> E["Expert<br>Fluid, intuitive judgment<br>beyond rules"]

So why have so many engineers poured hours into copying code by hand or memorizing entire APIs? The answer sits on the measurement side, not the learning side. In 1976, educational psychologists Marton and Säljö drew a line between a passive surface approach, aimed at reproducing text as-is, and an active deep approach, aimed at understanding and critically examining meaning⁹. Many certification exams, technical interviews, and early programming courses were built in a format where the surface approach scores just fine. Expertise itself never changed. What changed is that a proxy for expertise, whether someone could memorize something, happened to work as a stand-in for a long time. The shift in what’s worth learning, from syntax to code comprehension⁶, reads differently once you see it this way: AI has exposed and defused the part of the surface approach that used to hide behind rote memorization. What AI has made cheap is the territory the surface approach could already reach. The right-hand edge of the Dreyfus model, judgment dissolved into intuition through experience, still overlaps with what AI struggles at⁴⁵.

CS as the foundation for engineers, and how to actually use it

With that groundwork in place, here’s the main argument. If IT engineering is going to keep existing as a profession, its foundation is CS: data structures, algorithmic complexity, the fundamentals of operating systems and networking, concurrency, and basic type systems. A specific framework’s API gets rewritten every few years. How you think about computational complexity or the basic principles of concurrency holds up for a decade or more.

But there’s a trap here. Reading a CS textbook, memorizing algorithms, and learning complexity formulas by heart is, in Dreyfus terms, still just rule acquisition at the novice stage. Knowing CS and using CS are separated by a gap that only practice closes. Three mechanisms from cognitive science explain how to close it.

1. CS knowledge as a schema

Knowledge stored in long-term memory as connected chunks, or schemas, functions as scaffolding that lets new information get absorbed efficiently. As educational psychologist Richard Anderson put it, the schemas someone already has are the main thing determining what they take away from a new text¹⁰. CS fundamentals play exactly this role. If you understand how a hash table works, learning how a new database indexes its data connects to something you already have, so it clicks faster. Without that existing schema, new information stays as isolated fragments that never really settle in. The value of learning CS isn’t that it constitutes expertise on its own; it’s that it accelerates every learning experience that comes after it.

2. The loop of deliberate practice and productive failure

Learning a CS principle is one step. Knowledge turns into intuitive judgment only after you apply it repeatedly to real problems, check where it broke down, and fix it. Psychologist Kolb’s experiential learning theory frames this as a four-stage cycle: concrete experience, reflective observation, abstract conceptualization, and active experimentation¹¹. Educational researcher Manu Kapur’s work on productive failure takes this further. Learners who struggle and fail on their own before being taught the correct answer end up with significantly better conceptual understanding and transfer, according to a meta-analysis covering 53 studies and 166 comparisons (effect sizes g = 0.36 to 0.58)¹².

Someone who only knows the time complexity of a hash table in the abstract reacts very differently to the next design decision than someone who once shipped an N+1 query bug and had to fix it themselves. The first person has to recall the rule. The second person just feels that something is off, instantly.

That said, experience alone doesn’t automatically build judgment. Daniel Kahneman and Gary Klein spent years disagreeing about when intuition can be trusted, and the rare point they agreed on is that intuitive judgment is reliable only in an environment with enough regularity and fast, unambiguous feedback¹³. Some parts of software development meet that bar and some don’t. Tests and bugs give you results the moment you run them, so hands-on implementation work steadily builds real judgment. Architectural decisions are different: whether a choice was good often doesn’t surface for years. Where the feedback loop is broken, experience mostly builds confidence, not accuracy. That’s exactly why the third mechanism, writing down the reasoning behind a decision, matters: it’s a way of rebuilding a feedback loop that would otherwise never close.

3. Turning experience into tacit knowledge

Management scholars Dorothy Leonard-Barton and Walter Swap coined the term deep smarts, in their book of the same name, for the context-sensitive insight and rapid judgment that only years of hands-on practice can build¹⁴. It’s not accumulated knowledge in the usual sense. It only grows out of actually observing, doing, solving problems alongside other people, and being accountable for the outcome. The book organizes this acquisition process into what it calls the OPPTY process: Observation, Practice, Partnering (collaborative problem-solving), and Taking responsibility.

Here’s what turning CS principles into deep smarts actually looks like day to day. You’re in the middle of an incident and something clicks in seconds: “I’ve seen this pattern before.” In a design review, you say “this abstraction is going to break in this specific way down the road,” and you can’t fully explain why, but you’re confident anyway. These reactions can be deliberately trained. After an incident, write down what you were thinking and why you made the call you made. On the day you make a design decision, write down the reasoning and the alternatives you rejected. Doing this repeatedly builds up a store of experiential knowledge that’s hard for AI to replicate.

flowchart TB
    A["Learning CS principles<br>Building a schema"] --> B["Applying to real problems<br>Deliberate practice"]
    B --> C["Failure and friction<br>Productive failure"]
    C --> D["Reflection and articulation<br>Observation, taking responsibility"]
    D --> E["Experiential knowledge<br>Deep smarts"]
    E -.updates.-> A

Putting this to work in the AI era

Given all this, a concrete approach to learning CS starts to take shape.

Learn CS principles without shortcuts. This is the starting point, and the surface approach doesn’t get you there. Don’t just read the data structures and algorithms textbook; get to the point where you can explain why a design turned out the way it did. Asking AI “what’s the time complexity of this implementation” and taking the answer as given keeps you stuck at the novice stage of the Dreyfus model.

Take what you’ve learned somewhere it can break on purpose. In real work or side projects, when a decision hinges on a CS principle (how does choosing this data structure change performance, where could this concurrency design produce a race condition), make your own call first and verify it afterward. If you ask AI for the answer up front, you skip the core loop of deliberate practice: predict first, then correct based on feedback.

Use CS knowledge actively to check AI output. Ask whether the algorithm AI picked makes sense, whether its choice of data structure is wasteful, and evaluate both against CS principles. This creates a deliberate opportunity to put memorized knowledge to work, which is exactly the kind of practice that pushes you rightward on the Dreyfus curve.

Build a habit of writing down the reasoning behind decisions: why you made a design call, what you were thinking during an incident, what specifically felt off about an AI suggestion. Putting this into words is what Leonard-Barton’s OPPTY process calls observation and taking responsibility, and it’s what turns experience into tacit knowledge that sticks.

Finally, don’t confuse what’s measurable with what’s expert. Certification scores and completed tutorials are metrics the surface approach can also move. That doesn’t make them worthless, but they don’t prove expertise. The only real evidence of expertise is whether someone made a good call in a situation they hadn’t seen before.

Limits of this argument

A few caveats are worth stating directly.

First, the Dreyfus model has been widely applied across education, medicine, and professional development since 1980, but it has drawn more credit for its explanatory power than for empirical validation. Treat the five stages as a descriptive framework for how development tends to unfold, not a precise measurement scale.

Second, Marton and Säljö’s surface/deep approach distinction originated in research on how students read texts. Whether it transfers cleanly to skill acquisition in professional practice is, strictly speaking, a separate question that needs its own evidence. That said, subsequent education research has kept building on the distinction, and it’s become one of the central frameworks in the field.

Third, Leonard-Barton’s Deep Smarts is a general business book, not direct empirical research on IT or software engineering. A study focused on software engineering student projects did confirm that tacit-to-explicit knowledge conversion (the SECI model) works in that setting¹⁵, but the scope there is limited to student projects.

Fourth, this isn’t a claim that CS is the only foundation an IT engineer needs. CS is the clearest example of domain-general knowledge, but domain-specific knowledge, things that only apply in a specific industry or company, like financial-domain expertise or how a particular organization’s workflows function, matters just as much along a different axis. This article deliberately focuses on CS to describe the mechanism of expertise acquisition in concrete terms.

Fifth, it would be a mistake to assume that sharpening your CS skills boosts some general “thinking ability” that automatically transfers to unrelated domains. Meta-analyses examining whether cognitive skills from chess, music, and working memory training transfer to other areas found that the higher the quality of the experimental design, the weaker the evidence for far transfer becomes¹⁶. CS fundamentals genuinely help with near transfer, to adjacent territory like a new language, a new architecture, or a new database. Don’t expect them to produce far transfer into something like better business judgment.

Takeaways

• AI is changing the content of the job (implementation, search, summarization), not whether the job exists. If engineering is going to keep existing, its foundation is CS, domain-general knowledge that holds regardless of industry¹
• Expertise comes from repeated practice, experience, and feedback, not memorization. As the Dreyfus model shows, memorized rules are a starting point for expertise, not the destination, and what AI has made cheap is mostly the cost of reproducing that novice stage²³⁸
• Knowing CS and being able to use it are separated by a gap that closes only through practice. Three mechanisms close that gap and form the core of how to learn in the AI era. CS fundamentals work as a schema that speeds up later learning, not as expertise in themselves¹⁰. Applying principles to real problems and correcting through failure, the deliberate practice loop, turns knowledge into intuitive judgment, but only where the environment has enough regularity and fast, clear feedback¹¹¹²¹³. Observing and articulating the reasoning behind decisions, kept up over time, builds a store of experiential knowledge, deep smarts, that AI struggles to replicate¹⁴
• Certification scores and tutorial completions don’t prove expertise. The only evidence is whether someone made a sound judgment call in an unfamiliar situation
• Sharpening CS fundamentals doesn’t automatically transfer to distant domains. What it produces is near transfer to adjacent CS territory, so keep expectations in check¹⁶

Before asking what to learn in the AI era, there’s a prior question worth asking: was your way of learning ever the kind that builds expertise in the first place? Storing CS knowledge as a schema, sharpening it through deliberate failure, and letting it settle into experiential knowledge. Whether you’re actually running that conversion loop is what separates engineers in the AI era.

Related articles

More on this theme:

• CS Knowledge vs. Domain Knowledge: What to Learn First (A Cross-Industry Checklist) - The practical companion to this piece, with concrete CS fundamentals to study and industry-specific domain knowledge checklists
• Is “Coding Will Be Obsolete by Late 2026” for Real? The History of Programmer-Obsolescence Predictions and How What’s Worth Learning Has Shifted - Examines the shift in what’s worth learning against the empirical evidence
• The Priority Between Thinking and Knowing - Diagnoses what happens when the cycle between knowledge and reasoning breaks down
• Where “We Have AI, So We Don’t Need a Core Skill” Falls Apart - Checks the claim that AI has only made implementation cheap against primary research
• Why “Build It, Break It” Was the Strongest Way to Learn - The applied side of experiential learning cycles and productive failure
• What Happens to an Engineer’s Pattern-Recognition Skills in the AI Era - How chunking and pattern recognition need updating for the AI era

References

Numbered to match the citation markers in the text above.

1. 最古の「プログラマ不要論」とAI時代の「プログラマ不要論」の共通点 - Kishida Naoki, Hatena Blog (2025-12-30). Traces the roughly decade-long recurring pattern of “programmers will become unnecessary” predictions since COBOL. [Reliability: medium to high] ↩︎ ↩︎² ↩︎³

2. Perception in Chess - Chase, W. G., & Simon, H. A. (1973). Cognitive Psychology, 4(1), 55-81. A classic expertise study showing that chess masters perceive the board as meaningful chunks, and that this advantage largely disappears with randomly arranged pieces. Later replications found a small residual advantage even on random boards, though the core finding, that pattern recognition drives the effect, still holds. [Reliability: high, peer-reviewed and widely replicated] ↩︎ ↩︎² ↩︎³

3. The Role of Deliberate Practice in the Acquisition of Expert Performance - Ericsson, K. A., Krampe, R. T., & Tesch-Römer, C. (1993). Psychological Review, 100(3), 363-406. Foundational work establishing deliberate practice, repeated engagement with well-defined tasks under immediate feedback, as the key driver of expertise. [Reliability: high] ↩︎ ↩︎² ↩︎³

4. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity - METR (2025). An RCT with 16 experienced open-source developers across 246 tasks. Found a 19% task-completion slowdown when using AI. [Reliability: high, though sample size is small] ↩︎ ↩︎²

5. 2025 GenAI Code Security Report - Veracode (October 2025). Found security vulnerabilities in 45% of AI-generated code. [Reliability: high] ↩︎ ↩︎²

6. AI時代にプログラミングを学ぶ意味と効果的な学習ステップ - miruky, Qiita (March 2026). Points to a shift in what’s worth learning, from syntax memorization toward code comprehension and edge-case judgment. [Reliability: medium] ↩︎ ↩︎²

7. Knowledge Organization and Skill Differences in Computer Programmers - McKeithen, K. B., Reitman, J. S., Rueter, H. H., & Hirtle, S. C. (1981). Cognitive Psychology, 13(3), 307-325. A classic study showing that experienced programmers remember code as meaningful chunks. [Reliability: high] ↩︎

8. Dreyfus model of skill acquisition - Dreyfus, H. L., & Dreyfus, S. E. (1980). University of California, Berkeley. A five-stage model from novice to expert, describing the shift from rule-dependence to intuitive judgment. [Reliability: medium to high; applied widely across education, medicine, and professional development for over 40 years, though it has drawn more validation from explanatory power than empirical testing] ↩︎ ↩︎² ↩︎³

9. Approaches to Learning or Levels of Processing: What Did Marton and Säljö (1976a) Really Say? - Reviews and re-examines Marton, F., & Säljö, R. (1976), published in Interchange. Explains the original paper’s distinction between surface and deep learning approaches. [Reliability: high; a foundational text in educational psychology, subsequently re-validated by later research] ↩︎

10. A Complete Guide to Schema Theory and its Role in Education - Education Corner. An overview of schema theory, drawing on Anderson, Bartlett, Rumelhart, and others to explain how existing knowledge accelerates new learning. [Reliability: medium] ↩︎ ↩︎²

11. Experiential Learning: Experience as the Source of Learning and Development - Kolb, D. A., Prentice Hall (1984); 2nd edition FT Press / Pearson Education (2015). The original text proposing experiential learning theory’s four-stage cycle: concrete experience, reflective observation, abstract conceptualization, active experimentation. [Reliability: high] ↩︎ ↩︎²

12. When Problem Solving Followed by Instruction Works: Evidence for Productive Failure - Sinha, T. & Kapur, M., Review of Educational Research, Vol. 91, No. 5, pp. 761-798 (2021). A meta-analysis of 53 studies and 166 comparisons. Productive-failure groups showed a significant advantage in conceptual understanding and transfer (g = 0.36 to 0.58). [Reliability: high] ↩︎ ↩︎²

13. Conditions for Intuitive Expertise: A Failure to Disagree - Kahneman, D., & Klein, G. (2009). American Psychologist, 64(6), 515-526. Two researchers from opposing camps on intuition jointly lay out the conditions under which intuitive judgment can be trusted: environmental regularity plus fast feedback. [Reliability: high; peer-reviewed, and a rare joint statement from both camps] ↩︎ ↩︎²

14. Deep Smarts: How to Cultivate and Transfer Enduring Business Wisdom - Dorothy Leonard-Barton & Walter C. Swap, Harvard Business Review Press (2005). ISBN-13: 978-1-59139-528-7. Proposes “deep smarts,” experience-based practical wisdom, along with the OPPTY process (Observation, Practice, Partnering, Taking responsibility). [Reliability: high; a well-regarded business book in management studies, though it covers business broadly rather than IT or software engineering specifically, which would need separate validation] ↩︎ ↩︎²

15. Explicit and tacit knowledge conversion effects, in software engineering undergraduate students - Knowledge Management Research & Practice, 15(3) (2017). Demonstrates the effects of tacit-to-explicit knowledge conversion (the SECI model) in a software development project at a Mexican university. [Reliability: medium to high; peer-reviewed journal, but limited to a student-project setting] ↩︎

16. Does Far Transfer Exist? Negative Evidence From Chess, Music, and Working Memory Training - Sala, G., & Gobet, F. (2017). Current Directions in Psychological Science, 26(6), 515-520. A meta-analysis examining whether cognitive skills from chess, music, and working memory training transfer to other cognitive tasks and academic performance. Found that higher-quality experimental designs show weaker evidence for far transfer. [Reliability: high; peer-reviewed meta-analysis] ↩︎ ↩︎²