Most AI developers treat their CLAUDE.md like a legal document. Hundreds of lines, every edge case pre-handled, every step scripted out. The logic makes sense on the surface: more instructions, better control, fewer surprises.
Boris Cherny does the opposite. And as a sharp breakdown recently shared on r/PromptEngineering made clear, Cherny is the Anthropic Staff Engineer who literally built Claude Code.
The author behind that post dug into Cherny’s actual day-to-day workflow and found something worth sitting with. His entire CLAUDE.md is barely 100 lines. His prompts are even shorter. One of his go-to bug-fix prompts is a single word: “Fix.”
Not a simplified example. His actual prompt.
What you’ll take away from this
- Why a 100-line CLAUDE.md can outperform a 500-line one
- How to set up a self-improving lessons file that builds codebase knowledge over time
- What outcome-focused prompts look like, and how they differ from process-focused ones
- How Cherny runs 10+ parallel sessions without losing control
The core idea: don’t babysit
Cherny’s team operates on one rule: Don’t babysit. No micro-managing the model, no scripting every decision in advance, no checking each step along the way. Instead, they focus on two things: managing the context window and letting Claude learn from its own mistakes.
On the context management side, Cherny runs 10 or more parallel sessions simultaneously. Each session gets a clear, bounded scope and runs without interruption. They don’t overlap. They don’t compete. They just work.
On the learning side, there’s a mechanism most people skip entirely.
Claude is instructed to log its own mistakes and unexpected discoveries to a lessons.md file. At the start of every session, it reads that file. Every mistake gets added to it. Over weeks of use, the agent builds an increasingly precise understanding of your specific codebase, without you doing anything after the initial setup.
That distinction matters. Most developers try to write the perfect upfront system. Cherny builds a system that improves itself.
Old approach vs. Cherny’s approach
The conventional thinking: write comprehensive instructions so the model never goes wrong. Pre-define every scenario. Explain every constraint. Anticipate every edge case in advance.
Cherny’s thinking: write the outcome you want, not the process to get there.
When he wants a code review, he doesn’t write a multi-step checklist. He writes: “Grill me on these changes and don’t make a PR until I pass your test.” When he wants a redesigned solution, he writes: “Knowing everything you know now, scrap this and implement the elegant solution.”
The model determines the steps. That’s the point. You’re not managing a process. You’re directing a capable collaborator.
Longer prompts don’t add precision. They add noise, and they shift cognitive work from the model back to you.
⚙️ The four-part setup, step by step
- Keep CLAUDE.md under 100 lines. Project context, not micro-instructions. What the codebase is, what the conventions are, what the key constraints are. Give Claude orientation, not a script.
- Create a lessons.md file and wire it in. Add this to your CLAUDE.md: “When you make a mistake or discover something unexpected about this codebase, log it to lessons.md. Read that file at the start of every session.” That’s the full setup. Claude handles the rest automatically.
- Write outcome prompts, not process prompts. “Fix this bug” works better than “check lines 12-35, look at the handler, run the test suite, then verify the output matches.” Give Claude the goal. Let it determine the steps.
- Run parallel sessions with bounded scopes. Assign each session a specific area of the codebase and let it run without interruption. Cherny keeps 10 or more going simultaneously, each focused without bleeding into the others.
The lessons.md system is where the long-term value compounds. Your CLAUDE.md stays lean. The agent’s understanding of your project deepens with every session. It’s a setup that gets better over time without ongoing maintenance from you.
The real takeaway
Writing longer prompts is often a signal of not trusting the model. You’re pre-computing decisions that Claude can make better than you can, mid-task, with full context it can see and you can’t.
Claude can code. It can debug. It can architect. What it needs from you is clear goals, relevant context, and a mechanism for remembering what it learns. Everything beyond that is overhead you’re creating for yourself, not for the model.
The original breakdown in r/PromptEngineering goes deeper into Cherny’s full task management system and includes a reconstructed copy of his actual 100-line CLAUDE.md file. Worth reading if you’re running Claude Code at any meaningful scale.
Frequently Asked Questions
Q: If CLAUDE.md is only 100 lines, where do the lessons go?
lessons.md is a separate file where Claude logs discoveries as it works. The trick is being explicit about it in your instructions, something like “update lessons.md before wrapping up”, because the model tends to skip it when context gets tight near the end of a session.
Q: How reliable is Claude Code? People are reporting bugs and mistakes.
Claude Code is genuinely powerful, but like any tool, it’s not perfect. Users have caught issues with line numbers and extra code. Think of it more as a really smart coding partner than a replacement for human review. Always double-check critical code, especially anything heading to production.
Q: How does “don’t babysit” work if Claude still makes mistakes?
It’s not about blind faith, it’s about building a learning system. Claude documents what went wrong in lessons.md, so the next time you work together, it knows better. You’re still in charge: managing context, running parallel work, and reviewing the important bits. You’re just not fussing over every single step.
The 100% practical guide to Claude Code—straight from its creator.
by u/Exact_Pen_8973 in PromptEngineering