How to Use Claude Code and Still Understand Your Own Code

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.

Claude is great at writing code fast. Understanding the code is our responsibility.

So I tried a bunch of ways to use Claude to help me understand the code it wrote.

TL;DR: There's no best approach. 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.

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:

That's nine real decisions. Exactly the kind of code I'd skim and accept. I tried the tools below on it.

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.

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:

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.

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.

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.

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. Tutor Mode leaves a passing test. Lathe leaves the code you wrote.

Match that to how much you'll need to remember.

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.