Skip to content
←

Split View: 무엇을 깊게 배우고, 무엇을 흘려보낼 것인가 — AI가 다 답해주는 시대의 학습 전략

|

무엇을 깊게 배우고, 무엇을 흘려보낼 것인가 — AI가 다 답해주는 시대의 학습 전략

들어가며 — 답이 공짜가 된 세계에서

질문 하나가 3초 만에 해결되는 시대에, 무엇을 굳이 머릿속에 넣어야 할까요.

가장 단순한 답은 "AI가 모르는 것만"입니다. 그런데 이 답은 쓸모가 없습니다. AI는 거의 다 알기 때문입니다. 그래서 이 글은 다른 축을 씁니다. 무엇을 깊게 배울지는 "AI가 모르는 것"이 아니라 "AI가 틀렸을 때 당신이 알아차려야 하는 것"으로 갈립니다.

앞선 글 AI는 정말 개발자를 빠르게 만드는가에서는 "오늘 내가 더 빨라졌는가"를 물었습니다. 이 글은 시간 지평이 긴 쪽을 묻습니다 — 나는 더 나아지고 있는가. 그리고 학습과학이 이 질문에 내놓는 답은, AI 도구를 쓰는 사람에게 유쾌하지 않습니다.

실력을 만드는 것은 검색이 아니라 인출이다

핵심 실험부터 보겠습니다. Roediger와 Karpicke의 2006년 논문(Psychological Science 17권 3호)입니다.

워싱턴대 학부생들이 짧은 과학 지문을 학습합니다. 실험 2에서 조건은 세 가지였습니다.

  • SSSS — 지문을 네 번 읽는다. 시험 없음.
  • SSST — 세 번 읽고 한 번 회상 시험을 본다.
  • STTT — 한 번 읽고 세 번 회상 시험을 본다. 피드백은 주지 않는다.

5분 뒤 최종 시험을 보면 결과는 상식대로입니다. SSSS가 83%, SSST가 78%, STTT가 71%. 많이 읽은 쪽이 이깁니다.

일주일 뒤에는 순위가 완전히 뒤집힙니다. STTT가 61%, SSST가 56%, 그리고 네 번을 꼬박 읽은 SSSS는 40%로 주저앉습니다. 여기서 가장 인상적인 숫자는 노출량입니다. SSSS 집단은 지문을 평균 14.2회 통독했습니다. STTT 집단은 3.4회 읽었을 뿐입니다. 네 배 넘게 읽고도 일주일 뒤 21%포인트를 더 잊었습니다. 일주일간의 망각률로 보면 SSSS는 52%를 잃었고 STTT는 14%만 잃었습니다.

그리고 이 논문의 진짜 폭탄은 설문 결과(Table 2)에 있습니다. 학습 직후 "일주일 뒤에 이 지문을 얼마나 잘 기억할 것 같은가"를 7점 척도로 물었더니 —

  • SSSS: 4.8
  • SSST: 4.2
  • STTT: 4.0

가장 확신한 집단이 가장 못 기억했습니다. 저자들의 표현으로 반복 읽기는 "repeated studying inflated students' confidence" — 학생들의 자신감을 부풀렸을 뿐입니다. 그리고 논문의 결론 문장은 이렇습니다. "Testing is a powerful means of improving learning, not just assessing it."

용어를 정리해 둡시다. 인출(retrieval) 은 내 머릿속에서 스스로 꺼내는 행위입니다. 조회(lookup) 는 남이 꺼내 주는 것을 받는 행위입니다. 기억을 만드는 것은 앞쪽입니다. 뒤쪽은 기억을 만든 것 같은 느낌 을 만듭니다.

바람직한 어려움, 그리고 바람직하지 않은 어려움

왜 이런 일이 생기는지는 Bjork 부부의 2011년 글 "Making Things Hard on Yourself, But in a Good Way"가 설명합니다.

핵심은 학습(learning)과 수행(performance)의 분리입니다. 수행은 훈련 중에 관찰되고 측정되는 것이고, 학습은 지속되는 변화입니다. Bjork의 문장을 그대로 옮기면 "current performance can be a highly unreliable index of whether learning has occurred". 지금의 수행은 학습이 일어났는지에 대한 매우 부정확한 지표라는 뜻입니다.

그래서 역설이 생깁니다. 수행을 빠르게 끌어올리는 조건과 학습을 남기는 조건이 다릅니다. 다시 읽기는 익숙함(perceptual fluency)을 만들고, 우리는 그 익숙함을 이해로 착각합니다. Bjork의 이론 용어로는 인출 강도(retrieval strength)를 저장 강도(storage strength)로 오독하는 것이고, 그 결과 우리는 더 나쁜 학습 조건을 스스로 선호하게 됩니다.

그래서 Bjork는 일부러 어렵게 만드는 조건들을 바람직한 어려움(desirable difficulties) 이라 부릅니다. 그가 꼽는 목록은 학습 조건 바꾸기, 인터리빙(주제 섞기), 분산 학습, 그리고 제시 대신 시험을 학습 이벤트로 쓰기입니다. Bjork 연구실은 여기에 생성(generation) 을 더합니다 — 읽는 대신 스스로 만들어내기. 이 효과의 출발점은 Slamecka와 Graf의 1978년 연구입니다.

수치도 하나 있습니다. Bjork가 인용하는 Rohrer와 Taylor(2007)의 실험에서, 문제를 섞어서 푼 집단은 일주일 뒤 새 문제의 63% 를 맞혔고, 유형별로 몰아서 푼 집단은 20% 를 맞혔습니다. 그런데 훈련 중에는 몰아서 푼 쪽이 더 잘했습니다. 늘 그렇습니다.

여기서 이 글 전체를 지탱하는 단서를 하나 붙여야 합니다. Bjork 본인이 강하게 경고합니다 — "Many difficulties are undesirable during instruction and forever after." 모든 어려움이 좋은 게 아닙니다. 어려움이 바람직해지려면 학습자가 그것을 성공적으로 감당할 배경지식을 갖고 있어야 합니다. 그렇지 않으면 그건 그냥 바람직하지 않은 어려움, 즉 낭비입니다. 이 단서를 기억해 두세요 — 조금 뒤에 이것이 "언제 AI에게 맡겨도 되는가"의 기준이 됩니다.

AI 시대의 함정 — 인출을 아웃소싱할 때

이제 문제를 한 문장으로 줄일 수 있습니다.

실력을 만드는 것은 인출인데, AI는 인출 기계입니다. 모델에게 대신 꺼내게 하면, 전문성을 만드는 바로 그 행위를 건너뜁니다. 이 도구는 하필 당신이 남에게 맡기면 안 되는 일을 가장 잘합니다. 그리고 이건 유추가 아니라 측정된 결과입니다.

Bastani 등(PNAS, 2025). 튀르키예 고등학생 약 1,000명을 대상으로 한 현장 실험입니다. 세 집단 — GPT Base(일반 ChatGPT 인터페이스), GPT Tutor(답을 주지 않고 교사가 설계한 힌트를 주도록 안전장치를 건 버전), 그리고 AI 없는 대조군.

  • 연습 중에는 AI가 압도적으로 이깁니다. 성적이 GPT Base는 48%, GPT Tutor는 127% 올랐습니다.
  • 그런데 AI를 걷어내고 혼자 시험을 보게 하자, GPT Base 집단은 AI를 한 번도 써 본 적 없는 대조군보다 17% 낮은 점수를 받았습니다.
  • 안전장치를 건 GPT Tutor는 이 손해를 대체로 없앴습니다. 다만 없앴을 뿐, 대조군보다 더 잘하게 만들지는 못했습니다. 연습 중의 127%는 시험장으로 따라오지 않았습니다.

저자들의 진단은 한 단어입니다. 학생들이 AI를 "crutch"(목발)로 썼다는 것. 이건 Bjork가 예측한 학습·수행 분리가 실험실 밖에서 그대로 재현된 장면입니다. 연습 중 수행은 치솟고, 학습은 남지 않았습니다.

Lee 등(CHI 2025, Microsoft Research + CMU). 지식 노동자 319명에게 실제 업무에서의 생성형 AI 사용 사례 936건을 받아 분석했습니다. 핵심 발견은 신뢰의 방향입니다 — "higher confidence in GenAI is associated with less critical thinking". AI를 더 신뢰할수록 비판적 사고를 덜 했고, 자기 자신을 더 신뢰할수록 비판적 사고를 더 했습니다. 그리고 AI를 쓸 때 비판적 사고의 성격 자체가 정보 생성에서 정보 검증·통합·감독으로 이동한다고 보고합니다.

이 논문은 Bainbridge의 고전적인 '자동화의 역설'도 불러옵니다 — 일상적인 작업을 기계에 넘기면, 예외 상황을 다룰 근육을 기를 기회를 함께 잃는다는 것. 그리고 예외는 언젠가 옵니다.

두 연구의 한계는 지금 밝혀 둡니다. Bastani는 고등학생과 수학입니다. 시니어 엔지니어가 아닙니다. Lee 등은 자기보고 설문이고 상관관계입니다 — 제목부터 "Self-Reported"라고 적혀 있습니다. 그리고 앞선 글에서 봤듯이, AI가 자기 성과에 미친 영향에 대한 자기보고는 우리가 가진 도구 중 가장 못 믿을 것입니다. 메커니즘은 그럴듯하게 전이되지만, 효과 크기는 그대로 옮겨오지 않습니다.

무엇을 깊게, 무엇을 얕게 — 반감기로 가르기

전략은 읽기 목록이 아니라 배분입니다. 당신에게는 유한한 '바람직한 어려움' 예산이 있고, 그걸 어디에 쓸지가 전부입니다. 기준은 두 가지 — 반감기와 틀렸을 때 알아차릴 수 있는가.

긴 반감기 — 직접, 깊게, 인출로. 이것들은 왜 를 설명하고, 수십 년을 갑니다.

  • 운영체제 — 프로세스, 메모리, 파일 디스크립터, 스케줄링
  • 네트워크 — TCP, TLS, HTTP 시맨틱스, 타임아웃과 재시도
  • 데이터베이스 — 트랜잭션, 격리 수준, 인덱스, 쿼리 플랜
  • 분산 시스템 — 일관성, 파티션, 멱등성, 실패 모드
  • 디버깅 방법론 — 가설 세우고, 관측하고, 이분 탐색하기
  • 자료구조와 알고리즘 — 암기가 아니라 비용을 추론하는 수준으로
  • 글쓰기 — 생각을 검증 가능한 형태로 만드는 기술

TCP는 당신이 배운 모든 프레임워크보다 오래 살아남았습니다. 그리고 이것들이 바로 AI의 출력을 심판할 때 꺼내 쓰는 도구입니다.

짧은 반감기 — 훑고, AI에게 맡기세요. 프레임워크 API, 문법 트리비아, 설정 주문(呪文), CLI 플래그, YAML 스키마. 이것들은 세 가지 이유로 정확히 AI의 영역입니다. 문서가 많아 모델이 잘하고, 검증이 몇 초면 끝나고(돌아가거나 안 돌아가거나), 그리고 어차피 낡습니다. 여기에 깊이 투자하는 것은 감가상각 자산에 투자하는 일입니다.

두 통을 가르는 시험은 하나입니다. 모델이 틀렸을 때 당신이 알아차릴 수 있는가.

  • 잘못된 CLI 플래그는 명령이 실패하며 스스로 신고합니다. → 훑으세요.
  • 미묘하게 잘못된 격리 수준, 빠진 멱등성 키, 재시도 경로에 숨은 레이스는 아무도 신고해 주지 않습니다. 몇 달 뒤 청구서로 옵니다. → 이건 당신이 소유해야 합니다.

AI의 대표적 실패 양식은 "거의 맞지만 완전히 맞지는 않음"입니다. 그리고 '거의'를 잡아내는 능력은 왜 를 아는 사람에게만 있습니다. 익숙함과 검증 비용으로 작업을 가르는 격자는 앞선 글에 정리해 두었습니다.

실천 — 먼저 시도하고, 그다음에 확인한다

처방은 "AI를 쓰지 마라"가 아닙니다. 순서를 바꾸는 것입니다. 인출 시도를 조회 앞에 놓으세요.

근거는 Kornell, Hays, Bjork의 2009년 논문(JEP: LMC 35권 4호)입니다. 설계가 거의 잔인합니다. 연구진은 시도가 반드시 실패하도록 재료를 만들었습니다. 존재하지 않는 상식 문제("Calumet 전쟁을 끝낸 평화 조약은?" — 그런 전쟁은 없습니다)와, 정답을 맞힌 드문 시행은 아예 분석에서 제외한 단어 연상 과제.

  • 시험 조건 — 먼저 답을 시도해 보고, 그다음에 정답을 본다. (시도는 100% 실패합니다.)
  • 읽기 조건 — 문제와 정답을 함께 본다.

결과는 이렇습니다. "Unsuccessful retrieval attempts enhanced learning with both types of materials." 실패한 시도조차 정답을 바로 보는 것보다 나았습니다. 저자들의 결론은 오답을 피하는 게 아니라 어려운 시험을 치르는 것이 효과적 학습의 열쇠일 수 있다는 것입니다. 이것이 처방 전체입니다. 다섯 가지로 옮기면 —

1. 프롬프트 전에 5분간 답을 써 보세요. "이 버그는 커넥션 풀 고갈 때문일 것이다." "이 쿼리는 인덱스를 안 탈 것이다." 틀려도 됩니다. Kornell의 결과가 말하는 건, 틀린 시도가 바로 그 정답을 설치한다는 것입니다.

2. AI를 자동완성이 아니라 비평가로 쓰세요. "이거 짜 줘"가 아니라 "내 설계는 이렇다. 어디서 깨지는가?" 같은 도구, 정반대의 인지적 위치입니다. 생성은 나에게 남고, 반증은 모델이 맡습니다.

3. 설명을 요구받는 쪽이 되세요. 방금 머지한 코드로 나를 퀴즈해 달라고 시키세요. 당신의 실제 코드베이스 위에서 하는 인출 연습입니다.

4. 긴 반감기 영역에서는 의도적으로 도구를 끄세요. 금욕이 아니라 훈련입니다. Bastani 실험은 정확히 '도구가 사라졌을 때 무슨 일이 벌어지는가'의 측정이었습니다. 도구는 언젠가 사라집니다 — 새벽 3시의 장애, 격리된 망, 혹은 그냥 모델이 자신 있게 틀리는 문제 앞에서.

5. 짧은 반감기 영역에서는 죄책감 없이 쓰세요. 반감기로 가르는 이유가 이것입니다. CLI 플래그를 기억해내려 끙끙대는 것은 Bjork가 말한 바람직하지 않은 어려움입니다. 아무것도 쌓이지 않습니다.

같은 방향을 가리키는 프리프린트도 있습니다("Struggle First, Prompt Later", arXiv 2025) — 먼저 시도한 뒤 AI를 쓰는 방식이 특히 복잡하고 고차원적인 과제에서 효과적이라는 보고입니다. 다만 동료 심사를 거치지 않았고 표본 크기를 확인하지 못했습니다. 근거가 아니라 이정표로만 받아들이세요.

정직한 한계

이 글의 논지가 과대 포장되지 않도록, 약점을 직접 적어 둡니다.

실험실에서 실무로의 전이는 유추입니다. Roediger와 Karpicke는 학부생이 산문을 일주일간 기억하는 과제를 측정했습니다. Bjork의 어려움들은 대체로 단어 목록, 운동 과제, 교실 자료에서 확립됐습니다. 그 어느 것도 "엔지니어가 3년에 걸쳐 분산 시스템을 익히는 일"이 아닙니다. 방향은 잘 재현되었지만, 당신의 직무에서의 크기는 측정된 적이 없습니다.

그리고 가장 불편한 숫자. 엘리트 선수의 멘탈에서 다뤘듯이, 에릭손은 '1만 시간의 법칙'이라는 말을 쓴 적이 없고 — 그의 표현으로 "there is nothing special or magical about ten thousand hours" — Macnamara 등의 2014년 메타분석은 의도된 연습이 성과 분산을 게임에서 26%, 음악 21%, 스포츠 18%, 교육 4%, 그리고 직업 영역에서는 1% 미만 설명한다고 보고했습니다. 하필 우리에게 가장 가까운 영역이 가장 약합니다. 저자들의 결론도 딱 그만큼입니다 — 의도된 연습은 중요하지만 주장되어 온 만큼은 아니라는 것. 이 숫자는 제 논지에 불리하고, 그래서 더 정확히 적어 둡니다. "의도적으로 연습하라"는 조언은 직업 영역에서 천장이 낮고, 이 글은 그 천장 안에서만 유효합니다.

때로는 배우지 않는 것이 옳습니다. 평생 한 번 만질 도구라면 AI에게 통째로 맡기세요. 그건 게으름이 아니라 전략이 작동하는 모습입니다.

마치며

한 문장으로 줄이면 이렇습니다. AI는 당신이 대신 시켜 버리면 결코 잘하게 될 수 없는 바로 그 일을, 놀랍도록 잘합니다.

이건 금욕하라는 말이 아닙니다. 배분하라는 말입니다. 당신의 바람직한 어려움 예산은 유한합니다. 반감기가 긴 것, 그리고 AI가 틀렸을 때 반드시 당신이 잡아내야 하는 것에 쓰세요. 나머지에는 한 푼도 쓰지 마세요. 포스트잇에 적을 수 있는 버전은 세 줄입니다.

  • 먼저 시도하고, 그다음에 확인한다.
  • 오래 가는 것은 스스로, 금방 낡는 것은 도구로.
  • "무엇을 배웠는가"가 아니라 "AI가 틀렸을 때 알아차릴 수 있는가"를 묻는다.

이 습관들은 다행히 작습니다. 프롬프트 전 5분, 그것뿐입니다. 작은 것이 왜 실제로 붙는지는 습관은 21일에 만들어지지 않는다에서 다뤘습니다.

마지막으로, 이 글에서 하나만 가져간다면 Roediger의 표를 가져가세요. 지문을 열네 번 읽고 자신을 가장 확신했던 집단이, 일주일 뒤 가장 적게 기억했습니다. 유창하고, 빠르고, 확신에 차 있었죠. AI는 매일 당신을 정확히 그 자리에 앉힙니다. 이해한 느낌과 이해라는 사실은 갈라지고, 도구가 사라졌을 때 나타나는 건 둘 중 하나뿐입니다.

참고 자료

What to Learn Deeply, What to Skim — A Learning Strategy for the AI Era

Introduction — When Answers Became Free

If any question resolves in three seconds, what is still worth putting in your head?

The simplest answer — "only what the AI doesn't know" — is useless, because the AI knows almost all of it. So this piece uses a different axis. What you learn deeply is not defined by what AI doesn't know. It's defined by what you must be able to catch AI getting wrong.

An earlier post, Does AI Actually Make Developers Faster?, asked whether you are faster today. This one asks the long-horizon version: are you getting better? And the answer learning science gives is not pleasant for anyone who uses these tools daily.

Retrieval, Not Lookup, Is What Builds Skill

Start with the experiment. Roediger and Karpicke, Psychological Science, 2006 (vol. 17, no. 3).

Washington University undergraduates studied short science passages. In Experiment 2 there were three conditions:

  • SSSS — read the passage four times. No test.
  • SSST — read it three times, take one recall test.
  • STTT — read it once, take three recall tests. No feedback given.

On a final test five minutes later, the result is common sense. SSSS scored 83%, SSST 78%, STTT 71%. More reading wins.

One week later the ranking inverts completely. STTT held 61%, SSST 56%, and SSSS — the group that dutifully read it four times — collapsed to 40%. The most striking number is exposure. The SSSS group read the passage an average of 14.2 times. The STTT group read it 3.4 times. Four times the reading, and 21 percentage points worse a week later. Measured as forgetting over that week, SSSS lost 52% of what it had; STTT lost 14%.

And the real bomb in the paper is the questionnaire (Table 2). Right after studying, participants rated how well they thought they would remember the passage in a week, on a 7-point scale:

  • SSSS: 4.8
  • SSST: 4.2
  • STTT: 4.0

The most confident group remembered the least. In the authors' words, "repeated studying inflated students' confidence." Their conclusion: "Testing is a powerful means of improving learning, not just assessing it."

Fix the vocabulary. Retrieval is pulling something out of your own head. Lookup is having it handed to you. The first builds memory. The second builds the feeling of having built memory.

Desirable Difficulties — and Undesirable Ones

The mechanism comes from Bjork and Bjork's 2011 chapter, "Making Things Hard on Yourself, But in a Good Way."

The core idea is the split between learning and performance. Performance is what you can observe during training; learning is the durable change. As they put it, "current performance can be a highly unreliable index of whether learning has occurred."

Hence the paradox: the conditions that raise performance fastest are not the conditions that produce learning. Rereading generates perceptual fluency, and we mistake that fluency for comprehension. In Bjork's theoretical terms, we misread retrieval strength as storage strength — and as a result we actively prefer worse learning conditions to better ones.

So Bjork calls the conditions that hurt now and pay later desirable difficulties. His list: varying the conditions of learning, interleaving topics rather than blocking them, spacing rather than massing, and using tests rather than presentations as study events. The Bjork lab adds generation — producing the answer instead of reading it — an effect traced to Slamecka and Graf's 1978 study.

One number, from Rohrer and Taylor (2007) as cited in the chapter: learners who practiced problems interleaved solved 63% of new problems a week later; those who practiced them blocked by type solved 20%. During training, of course, the blocked group looked better. It always does.

Now the caveat that holds this whole essay together. Bjork warns hard: "Many difficulties are undesirable during instruction and forever after." Not all struggle helps. A difficulty is only desirable if the learner has the background knowledge to meet it successfully. Without that foothold, it is simply an undesirable difficulty — wasted effort. Hold on to that: in a moment it becomes the test for when handing the work to AI is exactly right.

The AI-Era Trap: Outsourcing Retrieval

The problem compresses to one sentence.

Retrieval is what builds skill, and AI is a retrieval machine. Let the model pull the answer out, and you skip the precise act that creates expertise. The tool is best at exactly the thing you cannot afford to delegate. And this is not an analogy — it has been measured.

Bastani et al. (PNAS, 2025). A field experiment with nearly a thousand Turkish high school math students. Three arms: GPT Base (a standard ChatGPT-style interface), GPT Tutor (prompts safeguarded to give teacher-designed hints instead of answers), and a control group with no AI.

  • During practice, AI wins overwhelmingly. Grades improved 48% with GPT Base and 127% with GPT Tutor.
  • Then the AI was taken away and students sat an unassisted exam. The GPT Base group scored 17% lower than the control group that had never touched AI at all.
  • The safeguarded GPT Tutor largely eliminated that harm — but note carefully: it eliminated the harm; it did not beat the control group. That 127% practice gain did not follow anyone into the exam room.

The authors' diagnosis is one word: students used GPT-4 as a "crutch." This is Bjork's learning/performance dissociation reproduced outside the lab. Performance during practice soared; learning did not stick.

Lee et al. (CHI 2025, Microsoft Research and CMU). A survey of 319 knowledge workers covering 936 real-world examples of generative AI use at work. The key finding is about the direction of trust: "higher confidence in GenAI is associated with less critical thinking." The more people trusted the model, the less they thought; the more they trusted themselves, the more they thought. The authors also report that AI shifts the character of critical thinking away from producing answers and toward verifying, integrating, and supervising them.

The paper also invokes Bainbridge's classic irony of automation: hand the routine work to the machine and you also lose the reps that keep you capable of handling the exceptions. The exceptions still come.

Both studies' limits, stated up front. Bastani studied high schoolers doing math, not senior engineers. Lee et al. is a self-reported survey and correlational — the title itself says "Self-Reported." And as the earlier post showed, self-report about how AI affects your own performance is the least trustworthy instrument we own. The mechanism transfers plausibly. The effect sizes do not.

What to Learn Deeply, What to Skim — Sorting by Half-Life

The strategy is not a reading list. It is allocation. You have a finite budget of desirable difficulty, and the only question is where to spend it. Two criteria: half-life, and whether you could catch the error.

Long half-life — own it, deeply, through retrieval. These explain why, and they last decades.

  • Operating systems — processes, memory, file descriptors, scheduling
  • Networking — TCP, TLS, HTTP semantics, timeouts and retries
  • Databases — transactions, isolation levels, indexes, query plans
  • Distributed systems — consistency, partitions, idempotency, failure modes
  • Debugging method — hypothesize, observe, bisect
  • Data structures and algorithms — not memorized, but at the level of reasoning about cost
  • Writing — the craft of making a thought checkable

TCP has outlived every framework you have ever learned. And these are precisely the instruments you reach for when judging what the model just handed you.

Short half-life — skim it, let AI carry it. Framework APIs, syntax trivia, config incantations, CLI flags, YAML schemas. These belong to AI for three reasons: they are well documented, so the model is good at them; they are verifiable in seconds (it runs or it doesn't); and they expire anyway. Learning them deeply is investing in a depreciating asset.

The test that sorts the two buckets is single: would you notice if the model were wrong?

  • A bad CLI flag announces itself — the command fails. → Skim it.
  • A subtly wrong isolation level, a missing idempotency key, a race hiding in a retry path: nothing announces those. The bill arrives months later. → You must own these.

AI's signature failure mode is "almost right," and only someone who knows why can catch the "almost." The grid for sorting tasks by familiarity and verification cost is in the earlier post.

The Fix: Attempt First, Then Check

The prescription is not "don't use AI." It is reordering. Put the retrieval attempt before the lookup.

The evidence is Kornell, Hays and Bjork (2009, JEP: LMC, vol. 35, no. 4), and the design is almost cruel. The researchers engineered materials so the attempt was guaranteed to fail: fictional general-knowledge questions ("What peace treaty ended the Calumet War?" — there was no such war), and word-association items where the rare correct guesses were thrown out of the analysis.

  • Test condition — try to answer, then see the answer. (The attempt fails, 100% of the time.)
  • Read-only condition — see the question and the answer together.

The result: "Unsuccessful retrieval attempts enhanced learning with both types of materials." Even a failed attempt beat going straight to the answer. The authors' conclusion is that taking hard tests, rather than avoiding errors, may be a key to learning. That is the entire prescription. In practice, five moves:

1. Spend five minutes writing your answer before you prompt. "This bug is connection-pool exhaustion." "This query won't hit the index." Being wrong is fine. Kornell's result says the wrong attempt is what installs the right answer.

2. Use AI as a critic, not an autocomplete. Not "write this for me" but "here is my design — where does it break?" Same tool, opposite cognitive position. You generate; the model tries to falsify.

3. Be the one who gets questioned. Ask the model to quiz you on the code you just merged. That is retrieval practice on your actual codebase.

4. In long-half-life territory, deliberately switch the tool off. Not asceticism — training. The Bastani study is precisely a measurement of what happens when the tool goes away, and someday it will: an incident at 3am, an air-gapped network, or just a problem the model gets confidently wrong.

5. In short-half-life territory, use it without guilt. That is the entire point of the split. Straining to recall a CLI flag is exactly Bjork's undesirable difficulty — nothing accumulates.

A preprint points the same way ("Struggle First, Prompt Later," arXiv 2025): attempting first and prompting afterward helped most on complex, higher-order tasks. But it is not peer-reviewed, and I could not verify its sample size. Treat it as a signpost, not as evidence.

Honest Limits

So this doesn't get oversold, here are the weak points, written by me.

Lab-to-workplace transfer is an analogy. Roediger and Karpicke measured undergraduates recalling prose over one week. Bjork's difficulties were established largely on word lists, motor tasks, and classroom material. None of that is "an engineer learning distributed systems over three years." The direction replicates well; the magnitude in your job has never been measured. Discount accordingly.

And now the most inconvenient number. As covered in The Elite Athlete Mindset, Ericsson never coined the "10,000-hour rule" — in his words, "there is nothing special or magical about ten thousand hours" — and Macnamara, Hambrick and Oswald's 2014 meta-analysis found deliberate practice explains about 26% of performance variance in games, 21% in music, 18% in sports, 4% in education, and under 1% in professions. The domain closest to ours is the weakest one. Their own conclusion is exactly that measured: deliberate practice matters, but not as much as has been claimed. That number cuts against my thesis, which is why I am stating it plainly — "practice deliberately" has a low ceiling in professional work, and this essay is only valid underneath that ceiling.

Sometimes not learning is correct. If you will touch a tool once in your life, hand it to the AI entirely. That is not laziness — that is the strategy working.

Closing

Compressed to one sentence: AI is extraordinarily good at precisely the thing that, if you let it do that thing for you, guarantees you never get good at it.

That is not an argument for abstinence. It is an argument for allocation. Your budget of desirable difficulty is finite. Spend it on what has a long half-life and on what you must be able to catch AI getting wrong. Spend nothing on the rest. The sticky-note version is three lines:

  • Attempt first, then check.
  • What lasts, learn yourself; what rots, let the tool carry.
  • Ask not "what did I learn" but "would I catch it if the model were wrong?"

Mercifully, these habits are small — five minutes before a prompt is the whole thing. Why small is what actually sticks is covered in Habits Aren't Built in 21 Days.

If you take one thing from this, take Roediger's table. The group that read the passage fourteen times and rated themselves most confident is the group that remembered the least a week later. Fluent, fast, and certain. AI puts you in that exact chair every single day. The feeling of understanding and the fact of understanding come apart — and only one of them shows up when the tool is gone.

References