Someone asked me how to use Claude Code as a CS student without hurting their learning. I programmed for 30 years before coding agents came along, and I’ve been using them daily for over a year now. They write all my code for me now. But when I want to understand something, I learn differently than I used to.

Do, Ask Why, Reflect

I tell the agent to do something. Then I ask it why it made the choices it did.

Build a REST API for user registration

Then:

Why did you choose this approach? What are the tradeoffs?

It explains its decisions — why it picked a library, why it structured things that way, what alternatives exist. Then I tell it to reflect and do better:

What's wrong with this? How would you improve it?

Then ask why again. The agent has defaults and biases. Sometimes good, sometimes not. Figuring out which is which — that’s the skill you’re building.

High-Level vs. Low-Level Decisions

When I work with a coding agent, it makes a lot of decisions. It picks a library, chooses a file structure, writes a query, names a variable.

I split them into two buckets:

  • High-level — architecture, data modeling, API design, library choices, how services talk to each other. These shape the whole project. I pay attention to these.
  • Low-level mechanical work — wiring up a form, adding validation. Mostly fine to delegate — though some things like database migrations I still review myself.

If you’re still learning, understand more than you delegate. The agent picks a library you’ve never used? Stop and ask why. Or not — maybe it’s just a script running locally and you figure it doesn’t matter. The coding agent gives you that flexibility. It creates a database schema? Make sure you understand the relationships and could design something reasonable yourself.

Over time, you build intuition for which decisions to override and which to let go. Every time you override, write it down in your AGENTS.md.

AGENTS.md as a Learning Journal

Every project I work on has an AGENTS.md — instructions the agent reads at the start of every session. How to run tests, what patterns to follow, what to avoid. I wrote about how I maintain these files in detail.

For someone still learning, it doubles as a journal of decisions. Every time you disagree with the agent or learn something about a tradeoff, add it. “Use PostgreSQL, not SQLite, because we need concurrent writes.” “Validate input at the API boundary, not in the database layer.”

Over weeks, the file becomes a record of your growing understanding. It makes the agent better too — it stops repeating mistakes you’ve already caught.

Build Things You Couldn’t Build Alone

The biggest gain isn’t speed — it’s scope. A full-stack app with auth, payments, and deployment. A CLI tool with proper error handling and tests. These are projects you understand conceptually but would take weeks to build from scratch.

With a coding agent, days. Building real things teaches more than any tutorial — you hit real problems. CORS errors, migrations gone wrong, deployment configs that don’t work. When they happen, slow down and watch how the agent fixes them — coding agents display their chain of thought and logic, so you can follow along as they debug.

Don’t let the agent build it and move on though. Read the code. Ask why. Change things and see what breaks.

Think Before You Code

I have a spec skill that interviews me about what I’m building — technical implementation, UI, tradeoffs, concerns — then writes a detailed spec before any code gets written.

The interview forces you to think through the problem first. You discover gaps in your understanding early — “What database should this use?” “How should auth work?” “What happens when this API call fails?” The agent helps think through the questions, but you decide.

Read the Diffs

I read more code than I write now. That’s the nature of working with agents. When the agent writes code, don’t just run it and check if it works. Read the diff. Every time. This is because you’re in learning mode. When you’re past that — using coding agents to get things done — you should aim to go agentic, skip reading where you can, and delay review to the end so you can multi-task.

You see patterns, idioms, approaches you wouldn’t have thought of. When the agent writes something you don’t understand, stop and ask. When it writes something you think is wrong — even better. That’s judgment developing.

Don’t Skip the Fundamentals

Coding agents generate code well. They won’t teach you how computers work, how algorithms scale, how networks behave, or how to debug something you’ve never seen before — unless you know to ask. Write code without the agent sometimes — especially when learning a new concept. The agent is a multiplier, but it needs something to multiply.

A good test: if the agent’s code breaks, can you figure out why? If not, you’re delegating too much.

If You’re Brand New to Programming

If you haven’t built anything yet — don’t know how to break a problem into modules, haven’t thought about how pieces of a system fit together — I’d hold off on coding agents. Not forever, but until you can look at a small project and reason about its architecture.

Without that foundation, you won’t know what to ask the agent or how to tell if its output is wrong. Once you have the basics, start by asking the agent about code you’ve already written — “How could I improve this?” “What’s wrong with my approach?” — then gradually move to building together.

Getting Started

Pick a project you actually want to build — something slightly beyond your current ability. Install Claude Code or another coding agent. Start building, but interrogate every decision. Create an AGENTS.md and add your preferences as you discover them. Read every diff. Ask “why” constantly.

The goal isn’t to write less code. It’s to build more things, understand more decisions, and develop the judgment to know when the agent is right and when it’s not.