You write the lines that matter

What it is and why it matters

If you build your app with Claude and don't understand the code, the day it breaks you're stuck. You don't know where to look, and you ask for a fix to something you can't even describe. The bigger the app gets, the more that hurts.

Claude Code already has an answer built in: output styles. A style is a set of instructions that changes how Claude responds to you for the whole session. Besides the basic one, called Default, it includes four: Proactive, Concise, Explanatory and Learning. Learning is the one made for learning.

With Learning, Claude still does the routine work. But when it reaches a piece with a real decision, it leaves you a few lines to write and explains its own choices along the way. You still finish the app, but you wrote some of the key lines yourself. It's for people who build alone with Claude and want to understand their code well enough to fix it.

1. How to turn it on

There's one way for each place you use Claude Code. The command and both menus save your choice in the project's .claude/settings.local.json file: it applies only in that project, and only to you.

1. In the terminal: type /output-style learning. The command ignores upper and lower case. If you type just /output-style, it lists the styles and marks the active one.
2. Also in the terminal, with the menu: type /config and pick Output style.
3. In the VS Code extension: type / in the prompt box and pick Output styles.
4. In the desktop app: here /config opens the app's settings, not the menu. Write the outputStyle field yourself in the project's .claude/settings.local.json file, as shown below, then start a new session.

{
  "outputStyle": "Learning"
}

In the file, the capital letter matters: write Learning, not learning. A misspelled name gives no error: it leaves you in the Default style without telling you. If the file already has other settings, just add the outputStyle line inside the existing braces.

If you want Learning in every project, put the same field in your user file, ~/.claude/settings.json. But a project's settings win over your user settings: if a project has its own outputStyle, that's the one that applies there.

If you switch styles mid-session, in the latest version of Claude Code the new style applies from your next message: no need to start over.

2. What happens while it works

You give it a task as usual. From there, it goes like this:

1. It does the routine work: the files to create, the wiring, the parts that can only be written one way.
2. When it reaches a piece with a real decision, it stops. The documentation gives three examples: how to handle an error, how to structure the data, a rule of your app that can be written in more than one valid way.
3. In the file, at the exact spot, it leaves a placeholder comment: the English word for "to do" followed by (human). To find it, search the file for (human).
4. It sends you a Learn by Doing request in three parts: Context, what's already built; Your Task, what to write and where; Guidance, what to weigh while you write.
5. Then it stops and waits. You write those few lines where the placeholder is and tell it you're done.
6. It reads your code, replies with an Insight block about what you wrote and carries on with the task.

Meanwhile, before or after the code it writes, it adds Insight blocks: two or three points on why it made its choices, tied to your project. They stay in the conversation: they don't end up in your files as comments.

One thing to know right away: a style is an instruction, not a guarantee. Claude decides which pieces to leave you, and in a task with no real decisions it may leave you nothing. If you want a specific piece, ask for it: that's the next section.

3. Use it on a real feature

It pays off more on a feature you actually need than on an exercise. The lines worth keeping for yourself are your app's rules: they're the ones you'll change when the idea changes, and the first ones you'll look at when something doesn't add up. Write to it like this:

I'm adding [the feature, for example: at most 3 projects on the free version]. You write the routine part: files, wiring, interface. Leave my app's rules to me with the (human) placeholder, one at a time: what happens in each case and how to handle errors. For each one, tell me which file it's in, what I receive and what I have to return.

When you've written your lines:

I've finished the (human) placeholder in [file name]. Read my code and tell me if there's a case I don't handle, without rewriting it yourself. Then carry on.

4. When you're stuck, ask for a hint

Sometimes you look at the placeholder and don't know where to start. Don't ask for the solution straight away: if you read it ready-made, next time you're back where you started. Ask for a hint:

I'm stuck on the (human) placeholder in [file name]. Don't write the code. Give me just one hint: the first thing to check or the question I should ask myself. If I'm still stuck after two hints, show me a similar example, but not the same one.

If it's really not the moment, you can always tell it to write that piece itself. But try the hints first: that's where the code becomes yours.

5. When you're in a hurry, go back to Default

Learning slows you down, and that's the point. Its responses are longer than Default by design, so you use more output tokens. When you just need to get something done, go back to the basic style:

/output-style default

Default is in the list with the other styles, so you'll also find it in /config and in the VS Code menu. In the desktop app, remove the outputStyle line from the file. When you have time again, switch Learning back on.

6. If you only want the explanations: Explanatory

If you don't feel like writing code but want to understand what's going on, there's Explanatory. It does the work like Default and adds the same Insight blocks, with the reasons behind its choices. It leaves you nothing to write and doesn't stop to wait for you.

You turn it on the same way: /output-style explanatory in the terminal, or Explanatory in the file, with a capital E. Here too the responses are longer than Default, so more tokens. Explanatory works well when you're getting into code you don't know; Learning when you're writing a feature you'll have to maintain yourself.

Common mistakes

• Writing learning in lower case in the file. The file needs Learning: with a wrong name you stay in Default and nothing tells you.
• Expecting a (human) placeholder in every response. Claude decides which pieces to leave you: if you want one, ask for it.
• Leaving it on when you're in a hurry. Long responses use more tokens: go back to Default and turn it on again later.
• Putting Learning in ~/.claude/settings.json and not understanding why it doesn't start in one project. Project settings win: check whether that project has another outputStyle.
• Creating .claude/settings.local.json by hand and ending up committing it to git. When Claude Code creates it, it keeps it out of git on its own; if you create it yourself, add it to .gitignore.

Checklist

• Learning is on in the project I'm working in
• If I set it in the file, it says Learning with a capital L
• I asked it to leave my app's rules to me with the (human) placeholder
• I wrote my lines and told it I was done
• I read the Insight about my code
• I know how to switch back to Default when I'm in a hurry

Frequently asked questions