How to maintain the ability of continuous learning in the era of large models?

Shen Translation Bureau is a translation team under 36Kr, focusing on technology, business, workplace, life and other fields, with a focus on introducing new technologies, new perspectives and new trends from overseas.

Editor's Note: In the era where AI can churn out answers in seconds, directly "copying others' work" is eroding your brain. Don't let large language models think for you. Transform them into a "Socratic mentor" to regain the ability of deep learning through deliberate struggle. This article is translated and compiled.

I want to talk about how I keep learning new things in the LLM (Large Language Model) era, since this has become extremely hard. Large language models, AI, agents, no matter what you call them, can get things done in one go, and as a result, they wipe out all the fun that comes from "making mistakes". I will mainly take programming as an example here, but I believe these principles apply to any field. In the past, when we learned new frameworks, new programming languages and new paradigms, we often made mistakes first and then learned lessons from them. But now everything moves too fast, and we are no longer willing to spend time making mistakes, even though making mistakes is more beneficial to us in the long run. It is exactly that kind of struggle that allows the brain to truly learn new things.

Frankly speaking, I have this problem myself. I used to put in a lot of effort to grind through learning new things, but now I feel it makes little sense, because large language models can give you anything you want. These thoughts brought me to this point: I hit a bottleneck, and I had to learn more no matter for work needs or personal interests. Below is the process of me rediscovering the learning method in the large language model era.

I was reading a paper called "Bitcask" at that time. If you are interested in programming and haven't read it yet, I suggest you give it a try. It is a very lightweight paper that even non-senior programmers can understand, because as long as you are willing to get your hands dirty, the concepts in it are easy to digest and implement. Anyway, I started reading this paper and planned to implement it without the help of large language models, and I basically made it. When writing code, I got stuck somewhere and wanted to turn to the large language model for help, but this time I didn't ask it to write the stuck part for me. Instead, I asked it to clarify the concepts so that I could write it on my own. That's when I realized that I could totally get the large language model to teach me, instead of letting it give me all the answers. What's more, it can handle all the tedious and tiring work, so that I won't get bored. For example, you want to learn something by building a chat application. You need two things: a server side and a client side; suppose you only want to practice how the server side works. If you are not interested in the client side, why kill your enthusiasm to implement it? This is exactly where large language models come in handy. You can let it finish those boring parts for you, such as testing, tooling and visualization. I am not saying these things are useless, but if they don't arouse your interest, you don't have to do them yourself.

So I started looking at how others did it, and found a skill called "socratic-code-mentor". It will not give you the answers directly, but by asking the right questions, it lets you reach the answers on your own, which is exactly how knowledge can be retained.

Here is a simplified example:

Me: My sum is supposed to be 6, but it turns out to be NaN:

Large Language Model: How many elements are there in nums? What is the index of the last element?

Me: Three elements, so the last index is 2.

Large Language Model: What values will i take in your loop?

Me: 0, 1, 2, 3... Oh. nums[3] is undefined, and 6 + undefined is NaN.

Large Language Model: Exactly:

i:       ▲  ▲  ▲  ▲  ← one step too far

How are you going to fix it?

Me: Use i < nums.length instead.

So the large language model didn't directly tell me "your loop went one step too far". It just asked a few questions and drew a diagram, and I found the bug on my own. I won't forget it, because it forced me to think through the whole thing by myself.

We learn by figuring things out on our own, not by accepting every fact given by others. The book Make It Stick — by the way, it's a great book if you are interested in learning psychology — puts it very well:

"When you are required to make a hard effort to solve a problem before seeing the solution, the solution you learn afterwards will be better mastered and remembered longer."

Even my dear friend and CTO will play this kind of thinking game with me. When I ask "Why don't we do it in the X way?", he will reply "Why do you think we should do it in the X way?". I explain my reasoning, and he then asks another question in response to my answer, and finally I come up with a decent answer on my own. And this answer will be remembered very firmly.

So you have to give your brain proper exercise. This skill does exactly that: it keeps you asking and questioning nonstop.

The second problem is to maintain motivation, which requires self-discipline. If you work on a project with a certain level of complexity to learn something, it can't be completed overnight. So plan the goals you need to achieve in advance, so that you won't waste time wondering what to do next. Otherwise, the next time you start working, you may stare at a blank screen for 30 minutes — at least that's what happens to me. When we lack motivation or self-discipline, we tend to procrastinate.

The ideal state is: you sit down in front of the computer, say to the large language model "Let's continue", and it will pick up where you left off last time and lead you forward. Surprisingly, large language models are extremely good at helping you make to-do lists of goals.

For example, you want to make a toy version of LevelDB, which is an LSM tree (sorry if you are not a programmer but are still reading this article). Ask the large language model to break it down into several stages, and each stage has clear goals. This way, every time you start a new learning session, you can tick off a box.

After finishing reading Bitcask, I wanted to do something more difficult related to databases, so I started building an LSM tree and named it tinylsm (I will probably keep working on my tiny-xyz series of projects). Below is the streamlined version of PLAN.md I wrote for tinylsm:

# tinylsm — Build Plan

**Golden Rule:** At the end of each stage, the system can run and all tests pass.

Never leave two half-finished features at the same time.

## Stage 2 — WAL (Write-Ahead Log)

**Goal:** Resilient to crashes. Each write is written to the log first, then to the memory, so that after a crash, replaying the log will not lose any data.

**Steps:**

1. Encode / decode a record.

2. Append the record to the file.

3. Replay the file on startup; stop cleanly when encountering the last half-written record.

**Completion Criteria:** Kill the process during writing, after restarting, all completed writes are still there.

**Pitfall:** A crash may cut the last record in half. This is an expected scenario, not data corruption.

## Progress

- [x] Stage 1 — Skiplist

- [x] Stage 2 — WAL

- [ ] Stage 3 — Memtable

Each stage has the same four parts: goals, small steps, a "completion criteria" that you can actually verify, and pitfalls that will trip you up. The checklist at the bottom is the part corresponding to "Let's continue": the large language model reads it and knows exactly where you are.

This way you don't have to spend any willpower deciding what to do, and the effort you need to get yourself moving is greater than you imagine. This is even more true nowadays: large language models, Shorts and other things keep giving us dopamine hits. We want to get things done, and fast. Planning gives you exactly that feeling. Even when you are completely exhausted, you can do a little bit, and treat it as a small victory.

What's more, doing this actually allows you to learn more, because you will come back to the same project again and again for a short period of time over days and weeks. It's like walking in the fog described by Shunryu Suzuki, a Zen master: you don't feel you are getting wet, but little by little, your clothes are soaked. Psychologists call this spaced practice: a little forgetting between two learning sessions forces the brain to retrieve the content again, and it is exactly this effort that makes knowledge stick firmly.

So far, we have talked about how to correctly use large language models for learning instead of letting them give you the solution in one go, and how to make plans so that you never procrastinate. But one thing is still missing.

Personally, I enjoy what I am doing more when I can get visual feedback. It can be a rough UI, a REPL (interactive command line), anything. It forces me to stay in the game and stay curious about what will happen next. When working on tinylsm, I asked the large language model to set up a small REPL for me: I can pour data into the database, watch SSTables stack up one by one, and run benchmarks on reads:

tinylsm> bench 

miss latency vs L0 height 

88 tables ██████████████████████████████ 174.9µs 

1 table ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 1.7µs

To be honest, seeing with my own eyes that the compaction code I wrote makes reads 100 times faster really boosts my motivation.

I suggest you do the same in your next big project. The skill I shared at the end of this article also covers this point, but you can fully use your imagination. With large language models, you can build anything that motivates you to keep moving forward.

Last tip: Make your next project a little ambitious. Before the emergence of large language models, implementing something like an LSM tree meant rummaging through piles of GitHub repositories and reading specific chapters of certain books. Now, you just need to say "I want to learn how XYZ works", and the large language model will do the research for you and find everything you need. So in a sense, things have become easier, but we have also become lazier. I guess this has always been the case. We just love to take shortcuts.

Summary

The short version (TL;DR) for lazy people like me:

• Don't let large language models give you answers directly, treat them as mentors.

• Leave the tedious work to large language models: testing, tooling, etc.

• Make plans in advance together with the large language model to maintain motivation with the least willpower. We barely have any willpower left these days anyway.

• Make progress visible: a REPL, a chart, anything that keeps you in the game.

• Pursue small victories. Even if you only study for 30 minutes a day, sticking to it is better than cramming for two days straight and then not coming back for ten days.

• Stay curious and learn things that go beyond your current capabilities. Even if you are not the smartest one, you can say "I don't understand" to the large language model a hundred times, and it will still explain it to you again. So don't settle for easy stuff.

The skill I use is called socratic-code-mentor. I found the original version and modified it according to my own learning style. You can use it, or modify it to fit your own situation.

Finally, I will end with a sentence that I try my best to live by:

"When you do things, you should burn completely like a good bonfire, leaving no trace of yourself."

—— Shunryu Suzuki

Translator: boxi.