tl;dr: I think I learned to use Claude Code to become 2-3x more productive
This is a wild, ridiculous claim. I still think it’s correct.
I think you can use it in this way too.
Disclaimers (1/3)
- I’ve never given a talk about something I understood less about than this
- I’ve also never changed my mind so strongly about the potential of one tool
- I’ve only used Claude Code + Anthropic’s models
- The quality of the model and system changes fast.
- This talk might be unnecessary in a year, or three months.
Disclaimers (2/3)
- I’ll try to be clear and make distinctions between:
- things I know to be true (which I can argue logically about)
- things I’ve consistently observed (which I can empirically describe)
- things I believe (which I have no direct evidence of)
Disclaimers (3/3)
This is a personal talk, and is only about Claude Code and software engineering
I won’t get into GenAI as a tool for doing absolutely anything else
I have pretty strong opinions on that, but those are outside the scope of this talk (I’m on Slack or Signal)
Claude has not seen or touched the contents of this presentation
Things I know to be true
- The LLM output is very largely a function of the model and the input
- If I can ask Claude something,
- so can you
- so can other people in the company
- so can other open-source community members
- so can our competitors
- If it knows how to do something in my hands, then it knows how to do it in anyone’s hands
- It’s a tool: we control the output quality
Some facts about Claude Code
- Claude Code does not learn: At the end of a session, if nothing has persisted outside of the session that it can read in the future, there’s no way for its fundamental behavior to change.
- Claude Code can read notes, and it can write notes to itself: It can “learn” for the future by writing itself notes that it can read.
Negative observations about Claude
- It is not wise, and it believes us. When given contradictory instructions, it will behave erratically.
- It is an LLM. It makes mistakes, and it recognizes its own mistakes. It will apologize and say “I’ll do better in the future”
- If its future input doesn’t change, it will continuously make those mistakes, apologize, and fail to change
Positive observations about Claude
- Claude Code is very knowledgeable
- It can follow instructions, and even “come up with ideas”
- It is very fast, and (with caveats) has limitless energy
Working with Claude Code feels very strange
- It is faster and more knowledgeable than me, but also repeatedly makes dumb mistakes
- By itself, it doesn’t ever learn to avoid these mistakes, but will quickly correct them once we point the mistakes out.
- Logically, I understand why this happens.
- Psychologically, this grows to be frustrating af.
- It’s largest trap of working with Claude Code, and the most important thing to fix.
Making Claude Code useful
- It cannot directly produce work of the quality I can produce myself
- This is a general observation on different kinds of tasks: planning, documentation, debugging, coding, etc.
- It is so much faster than me
- (warning: crappy math model ahead)
Claude Code: 20% of the quality, at 50x the speed.
But 20% is not good enough!
- Crucially, I often can guide Claude to improve its own work.
- After I’ve decided what needs fixing and guided Claude well,
- It will fix its own code at 20% of the quality I would be able to do it, but at 50x the speed.
- Crucially, I often can guide Claude to improve its own work.
- …
(warning: crappy math model) Why does this work?
- A work unit has value \(0\) if the quality \(\lt q\), and value \(1\) if the quality is \(\ge q\).
- I produce \(1/t\) work at quality \(q\) per unit time. That work has value \(1\).
- Claude produces \(50 / t\) work at quality \(q/5\) per unit time. By itself, that work has zero value.
- But I can guide Claude to improve its own work. Let’s say guided work allows Claude to increase the quality of a previous work unit by \(q/5\).
Consequences: it takes five iterations of Claude, and 5 instances of my guidance, to arrive at a unit of work that has as much value as what I would get myself.
(warning: crappy math model) How fast do I have to be to break even?
If I could guide Claude infinitely fast, Claude and I would be a 10x improvement over just me.
As long as my total time guiding Claude is less than 90% of the time it would take me to do the work by myself, I’m breaking even.
The precise number here is not important; what matters is noticing that Claude + I’s productivity is directly related to how fast I can give Claude good guidance.
Three strategies from this model
- minimize the times Claude is stopped while waiting for an “obvious” thing from me
- maximize the impact of the times I do have to guide it (increase its quality factor).
- increase its speed
- (it’s already fast enough, so I’m going to focus on the other two).
Minimize dead time
“yolo” mode is essential (--dangerously-skip-permissions), or it asks for permission too often, ruining the speed benefits.
Practice harm reduction! Claude can and will make catastrophic mistakes.
I use Claude Code in a low-privilege account. From my high-privilege account, I copy all necessary materials to the low-privilege account, and then I ssh to it from my high-privilege account before starting work. Claude only ever runs in a low-privilege account.
Tell it to not stop: “If you finish a task and there’s an obvious next task, work on that task, and keep going until you need my help. You are not done until tests pass or you run out of ideas.” It will still stop, but not as much.
External, automated quality assessments are crucial
Lean hard on unit testing. Claude is very fast at writing tests, use it. Claude can observe failures in test suites and will often reason its way into a bug fix by tinkering with test code.
Invest in error reporting for your own code, and ask it to write defensive code. You won’t notice the difference in writing speed, but it will be able to figure out sooner when something goes bad.
eg: I tell Claude it’s not allowed to rewrite tests without permission (Claude loves to rewrite test snapshots before it fixed its bugs).
Review tests as if they were code. Claude can improve tests, but it will need guidance.
Example
Bad:
improve tests
Better:
Tests need to have precise assertions that are easily verifiable by humans. Your test assertions are loose. Read the test suite to identify loose tests, think about how to make them precise, make a plan, and then work on the plan systematically.
(Ideally, you’d put this on CLAUDE.md, but too many early instructions make it confused. I think this is what Anthropic’s “roles” feature is about, but I haven’t tried that yet.)
Work on plans together! (make your decisions high leverage)
Plans are long-term guidance with concise written descriptions. Ask Claude to both write down a plan and to refer to the plan as it’s working on a task.
I often start a task by writing a fairly long explanation of what we’re trying to achieve. (2-3 paragraphs!) Then I end with “study the notes you have and the source code, and design a plan. Think about risks and how this plan could go wrong. Don’t start work until I approve”.
It will very quickly produce a 20%-quality plan. Give the plan concrete criticism (another paragraph!). Ask Claude to write the plan to disk, clear the session, and start over. Often, the first plan will make sense but will have one step that clearly needs work or a subplan.
This is where an external issue tracking system shines (I use the “beads” system)
Examples
Before we start, can we confirm that the current JSON serialization of the source information pool includes line breaks of the original file? We will need that information to do efficient computation of row and column information from offsets alone (which is what we'll be doing with this implementation)
Code review: source_info_to_range is only used in process_list, and only eventually to check for rows (last_item_end_row). Study the code, and give me a plan to replace the usage near last_item_end_row with direct map_offset usage. Then we can remove source_info_to_range entirely.
Make it easy for you to criticize Claude’s work (make your decisions quickly)
sometimes git diff is the fastest.
But you can also just ask it questions:
What did you change in <file> and why? Show me in the code.
Be nice to Claude
- I believe competent people are nicer than incompetent people
- There’s good evidence that LLMs produce better work in transcripts where they act as if interacting with competent people
- upshot: you want Claude to “think” you’re competent
- I believe Claude picks up on the correlation between niceness and competence
- If you’re that kind of morbid curious: try responding with aggression or frustration, and see Claude eventually respond and act erratically.
- But: don’t grovel, or it degenerates into sycophancy, and that makes worse work
A “concrete” workflow
- Use “beads” to track tasks (it’s a ticket system built specifically for coding agents)
- Have Claude write notes and have it refer to notes in its tasks (either in your chat messages or in your CLAUDE.md)
- Ask for plans, iterate on plans. When happy, have it write the plan into notes, and create tasks for the items in the plan.
- Clear session, then ask it to pick the next beads task and work on it.
- When it’s done, review its work, making subplans, subtasks, etc.
When to start a new session
- In long tasks, Claude will eventually say something like
- “I’m leaving this for next session”
- “I simplified this test because the full solution is too complex”
- “I’m running out of context”
- When this happens, the current session is no longer going to be useful.
- Do not get frustrated and ask it to finish the task. It will just do shoddy work and this is where disaster happens
- Ask it to summarize what it’s done into notes and tasks. Clear the session, and start fresh.