Claude Code Creator’s 6-Step Workflow, with the Most Important 7th Step Added in the Comments

A post on X compiled the complete setup of Claude Code creator Boris Cherny, centered on a six-step framework diagram. The original post called this his workflow, and the comments quickly pulled the focus back from “bookmarking” to “how to actually use it.”

First, some background. Claude Code is Anthropic’s coding agent; users can use natural language to have it read code, edit files, and run tests. Boris Cherny is its creator. For readers who don’t write code, think of it as an AI programming assistant that can actually take action; for developers, the hard part was never “can it generate” but “how do you get it to work according to an engineering process.”

The six steps in the diagram, unpacked as intended:

1. Plan node default mode. Non-trivial tasks enter plan mode first; when problems arise, stop immediately and re-plan.
2. Subtask strategy. Keep the main window clean; put research, exploration, and analysis in subtasks.
3. Self-improvement loop. After correcting mistakes, update the task or lessons document, iterate continuously, and reduce repeated mistakes.
4. Verify before completion. Don’t mark a task complete without proving it works; run tests and check logs.
5. Elegant balance of requirements. When making non-trivial changes, pause and ask whether there’s a more elegant way, and challenge your own approach along the way.
6. Autonomous troubleshooting. When you receive a failure report, fix it immediately without asking for help first; point to the logs, errors, and failing tests, then resolve it.

This diagram isn’t complete; at the bottom there are also task management and core principles. It contains more information than the title “six steps” suggests. What it actually describes is a set of management actions: planning, delegation, review, acceptance, rework, and troubleshooting. Managing the agent like a colleague sounds a bit odd, but engineering processes have always worked this way.

The comments are closer to the real-world situation than the main text. One user said the setup isn’t that important; writing a clear spec before touching the code is the bigger part. That judgment isn’t new, but it always gets buried by tool posts. No matter how complete the six-step framework is, if the spec is vague, the agent will just go off track faster.

Another easily overlooked point is lessons.md. A user reminded that this loop needs pruning. If left alone, it will grow to hundreds of lines of rules, contradict itself, and the agent will quietly skip half of it. Documentation isn’t safer just because it’s longer; rules can rot too.

Another user added the loading mechanism: Claude Code only automatically reads CLAUDE.md at startup, and the lessons file is read only when Claude decides to open it. To make it take effect in every session, you can write a line in CLAUDE.md with @ immediately followed by the lessons path, with no space in between, to load it via import. This detail is small, but it determines whether the self-improvement loop above is actually connected.

The sharpest addition is step 7: before clicking accept, read what it actually ran. The original six steps didn’t include this; the comments added it. Many people bookmark workflows, screenshot plan mode, and then close their eyes at the acceptance stage. The agent can troubleshoot autonomously, but responsibility still lies with the human.

Some users put it even more directly: what really works may just be a good CLAUDE.md. That statement is a bit absolute, but the direction is right. The stronger the tool, the more valuable project descriptions, boundaries, and acceptance criteria become. The six-step framework isn’t magic; it just puts these old problems on the AI programming table.

Original post here: Miles Deutscher’s post. If you only remember one thing, remember what the comments said: write a clear spec first, then let it touch the code; before clicking accept, look at what it actually did.