I ship code I haven't fully read. I look at the diff, it looks right, the tests pass, I move on. A few weeks of that, and I own code I can't explain.
This got worse as the tools got better. Back when Claude was not as good, I read every line, because I had to fix what it broke. Now it's good. So reading feels optional. And optional things get skipped.
One engineer, Carlos Esteban, said it plain: the tool "can also quietly make you worse at engineering. Not because it's wrong — but because it's too helpful."
The tool won't fix this. Writing code fast is what it's best at. Understanding the code is my job now.
So I tried a bunch of ways to use Claude to understand its own code. There's no single best one. It depends on the code. Some you should skim and forget. Some you should sit with. The trick is matching how deep you go to how much the code matters.

The code I tested on
I had Claude build one real thing. A retryWithBackoff helper for an HTTP client. It's 153 lines. It type-checks. It passes nine tests.
It's the kind of code with a dozen small decisions hidden in it. Like these:
It retries on 429 and 5xx, and on network errors. Not on other 4xx. Not on a cancel.
It waits a random amount before each try, and the wait grows each time.
If the server says "wait this long," it obeys that instead.
It gives up after 30 seconds of real time, not after a set number of tries.
It won't retry a POST unless you ask it to. Retry a POST and you might charge a card twice.
That's nine real decisions. Exactly the kind of code I'd skim and accept. I tried the tools below on it.
Small stuff: just ask
For a script you'll delete next week, asking Claude is enough. "What does this do?" You get one clean paragraph. Read it, move on.
You don't need to drill yourself on code that won't outlive the week. Most of the time, this is the right call. The mistake isn't using the quick option. It's using the quick option on code that deserves more.
Code you'll keep: make it quiz you
When you'll come back to this code, reading the explanation isn't enough. You'll nod, then forget it by the time it breaks. So flip it. Have Claude ask instead of tell.
Prasad Chalasani's socratic-quiz asks one question at a time. It gets harder or easier based on how you do. And it never just hands you the answer.
Suzanne's prompt writes a checklist to a file as it goes, then quizzes you with a real popup. Here's one question it wrote about my code:
Why retry GET / PUT / DELETE by default, but not POST?
A) POST requests are slower, so retrying wastes time
B) POST bodies can't be re-read after the first send
C) A retried POST might double-apply a side effect — e.g. charge a card or create two records — because POST isn't idempotent
D) The HTTP spec forbids retrying POST
The answer is C. You don't see it until you pick. That's the whole trick. You have to commit before you find out you were wrong.
Code you'll own: make the change yourself
For code you'll own for months, go one step further. Don't just answer questions about it. Change it.
Tutor Mode has Claude ask, you answer from memory, then you make a small real edit. On my code, it gave me a task. Add 408 to the codes it retries, write the test, make it pass.
You're done when you can do it without Claude. If you don't know where the retry rule lives, the code won't build and the test stays red. You can't fake that.

All three of these do the same thing. They make you say the answer, not read it. That's the oldest trick in learning. When you pull something out of your own head, it sticks. When you just read it, it doesn't. Scientists call the useful struggle "desirable difficulty." The best book on it is Make It Stick, by Brown, Roediger, and McDaniel.
And nobody planned this together. Suzanne at Anthropic, Prasad Chalasani, Matt Pocock, Carlos Esteban. They each built their own version, on their own, and all landed on the same move.
Learning something new: build it by hand
The tools above help you understand code that's already there. This one is different. If you're picking up a new topic, or you want the basics to stick, build it yourself.
Lathe writes a hands-on lesson, then you type the code by hand. Deven Jarvis, who built it, put the problem plainly: LLMs "do most of the work for you, and with that work gone they also take away the part that helped me learn." The tagline is "an experiment in using LLMs to teach you, rather than think for you."
Matt Pocock's teach skill is built for the long game. Small lessons, spaced out, with notes that carry from one session to the next. As it says, covering something isn't the same as learning it.
A simple way to choose: what does it leave behind?

The deeper you need to go, the more you want the session to leave a trace.
Asking Claude leaves nothing. A quiz leaves a file or a short summary — or, as my run put it, "nothing but the fading feeling that the budget check was the part you didn't really get." Tutor Mode leaves a passing test. Lathe leaves the code you wrote.
Match that to how much you'll need to remember. A trace you can come back to beats a good feeling that fades by Friday.
What this test is and isn't
No real person took these quizzes in my test. I caught what each one asks on real code, not someone actually passing. It was Claude grading code Claude wrote, which is easier than you in the hot seat. And it was one function, not a big study.
So take it as proof of what each one makes you do. Not proof you'll get it right.
You won't, the first time. That's the point of the ones that work.
There's no best tool here. There's a right depth for the task. Let Claude write the code, because that's what it's good at. Then decide how much you need to understand it, and pick the tool for that.
The one thing that doesn't change: understanding what you ship is still your job. And you're the only one who can choose to do it.
