Keep Learning While Claude Code Writes Your Software

Picture a developer who picked up PHP 5 years before AI assistants showed up. One forgotten semicolon could eat a few minutes, or an entire afternoon, hunting for the single bad line. A dynamic website took weeks: schema design, code structure, planning the whole project up front. Every stage of that was satisfying, from planning through to building, and the reward was real. You made something with your own hands after struggling, and you came out knowing more than when you went in.

Now compare that with today. In 2025 Claude Code arrived, and developers began handing it more of their daily work. A year later, many rarely open Stack Overflow, sketch less on whiteboards or paper before designing a feature, and talk less with coworkers, because most of their conversation happens with Claude. The speed is real, and nobody who has tasted it wants to give it up. But it has a price. A big chunk of the classic process, the one that quietly turns juniors into seniors, is going missing.

This isn't a complaint, a call to code everything by hand, or a rebellion against AI. It's a worry about one specific thing. Many people choose this profession partly to keep learning, and that learning fades when a model does all the thinking.

What the research says

Anthropic, the company behind Claude Code, published a study on how AI assistance affects the formation of coding skills. It points to a paradox: productivity gains from AI can come with slower skill growth, particularly for beginners. The advice that follows matches what many developers feel intuitively. Mental effort, including getting stuck for a while, is still necessary if you want to master something.

So the question becomes how to keep learning when Claude Code handles everything.

The friction we lost

Start by naming what the old workflow forced on you:

• Trying things until something worked
• Reading and rereading documentation
• Going back over your own code
• Tracing how a feature flows and in what order its functions run
• Debugging for minutes, hours or occasionally days

Those weren't obstacles to learning. They were the conditions for it. Future kids will hear about this era the way you'd talk about walking to school uphill both ways.

With that friction gone, so is what the study calls cognitive effort, the gap between writing code and understanding what you wrote. If the work no longer supplies the friction, you have to add it back on purpose.

Use the tool to teach

A good starting point is to treat Claude as a tool, and a remarkable one, yet still a tool that shouldn't replace the developer. It should make the job easier and help the developer grow. The old line says that if all you own is a hammer, every problem looks like a nail. A developer meets screws, bolts and dowels too, and that's where skill lives.

Rather than fighting the assistant, put it to work teaching you the other tools. If Claude can write an entire feature from one explanatory prompt, it can also ask questions about what it's doing. So the idea is to build deliberate friction into sessions. Not to stop Claude working, and not to return to hand-coding everything. In the middle of its work, it occasionally pauses and asks you something, like why you went with a certain approach.

Typical questions look like these:

• Why does this function behave the way it does?
• What happens when this call fails?
• Is this line necessary?
• Can you finish writing this function?
• Why this architecture over another?

The aim is simple: let Claude do its job, while you keep learning and, as a side effect, keep track of what it's producing.

How a teaching mode could work

You can build this as a Claude Code skill plus a few hooks. Install it once and it's available on your machine for every session. After a change, Claude looks at the diff, picks an interesting spot in the code, and asks you to explain it. A question might look like this:

🎓 Learner — src/auth/session.ts
You modified `refreshSession()` to delete the old session line before inserting the new one.
Why use this order rather than “insert then delete,” and what does a caller see if the insert fails after the delete has been committed?

Claude asks, then goes back to what it was doing. If you answer skip, it moves on without pushing.

The most interesting variant takes a short function you just changed, fetches the correct version from Git, and cuts parts out of the real file on disk. Frequency is controlled by a small shell helper that maps a setting to a number:

learner_synthesis_n() {
  case "${1:-}" in
    off)   printf '0' ;;
    rare)  printf '8' ;;
    often) printf '2' ;;
    # LEARNER-TODO Complete this part of code
    *)     printf '4' ;;
  esac
}

Then Claude asks you to fill the gap and waits. It won't finish the code for you unless you admit you don't know how, or type skip.

This is the most valuable kind of question, because it exposes the moments when you think you follow Claude's code but can't actually write it. One caveat: it briefly breaks your real source. A safeguard stops a session from ending with a hole in the tree, and that safeguard is the part of the design that most deserves critical review.

You can also trigger a quiz directly by typing learner quiz on a branch, instead of waiting for the hook. It's an excellent habit. If you can't answer questions about your own branch, reviewers won't be able to either.

An honest caveat: after a few weeks of use, it's still unclear whether everything works smoothly, or whether it truly helps everyone who wants to learn while using Claude Code. Feedback, especially disagreement, is what would improve the next iteration.

When you write the code yourself

All of this assumes Claude writes the code. What happens when it doesn't? Even with everything Claude Code can do, you might not want it writing every line. Sometimes you want to type it yourself, not because it's faster or because Claude couldn't, but because writing lines is how you learn.

So flip the arrangement. You write. Claude watches. At the right moment, it challenges you. It doesn't correct your code, take over, or hand you the answer. It just nudges you to think harder. An assistant like that does more than complete tasks and check your understanding. It acts as a sparring partner, someone who watches what you're doing and chips in with a well-timed question that adds something.

That's the direction a next version could take: coach rather than teacher. In the teacher model, the assistant builds first and quizzes afterward. In the coach model, you stay in the driver's seat, the assistant stays quiet until a question would actually help, and every line in the file remains something you chose to write. Growth then comes from your own typing and thinking, with a second pair of eyes that's practical instead of flattering. Developers who value craft would likely prefer that balance over fully outsourcing the keyboard, and it keeps the habit of struggling productively alive in daily work. If you have ideas for how it should challenge you, they're worth sharing.