Skip to main content
Portrait photo of Robby Ferguson
boristane.com •

How I Use Claude Code

by Boris Tane

Read the full article

This article is available on the original website.

boristane.com

Never let Claude write code until you've reviewed and approved a written plan. The annotated markdown file is the contract.

ai claude-code workflow engineering

Boris’s whole workflow turns on a single rule: never let Claude write code until you’ve reviewed and approved a written plan. Everything else — the research phase, the annotation cycle, even the choice of plain markdown over Claude Code’s built-in plan mode — exists to make that rule enforceable.

The four phases

  1. Research. Claude reads the relevant code “deeply” (his word, deliberately chosen) and produces research.md. The vocabulary matters — saying deeply, intricacies, thoroughly visibly changes how much surrounding context the model loads. This is the step that prevents implementations which pass tests in isolation but break the surrounding system.
  2. Planning. Boris asks for a plan.md with concrete approaches, snippets, and exact file paths. Crucially, he refuses Claude Code’s built-in plan mode in favor of a markdown file he can annotate.
  3. Annotation cycle. This is the part most workflows skip. Boris adds inline notes directly into the plan — correcting wrong assumptions, killing approaches, injecting domain knowledge — and re-prompts. One to six iterations, all under the standing instruction “don’t implement yet.” The plan file becomes shared mutable state between him and Claude.
  4. Implementation. Only after the plan is locked in does he say “execute everything in the plan.” Strict typing, run type-checks continuously, mark each task complete.

What I find most interesting

  • Markdown as the contract, not chat. Chat is ephemeral and lossy; an annotated plan.md is reviewable, editable, and survives compaction. Treating the plan as the artifact (not the conversation) is the real insight.
  • Word choice as a steering wheel. “Read this deeply” producing measurably different output than “look at this” is a real thing in practice. Prompts aren’t incantations, but vocabulary picks the depth of work.
  • Terse mid-execution corrections. During implementation he drops to one-sentence nudges like “You didn’t implement the deduplicateByTitle function.” Long prompts are for planning; short prompts are for course-correction.
  • He hasn’t seen context-window degradation at 50%. Counter to a lot of folk wisdom — credits Claude’s auto-compaction plus the persistent plan doc as the reason long sessions still work.

Hot takes worth flagging

  • The default “prompt → fix errors → repeat” loop produces “a mess that completely falls apart for anything non-trivial.”
  • Claude Code’s built-in plan mode “sucks” — markdown beats it on editability.
  • He’s skeptical of orchestration scaffolding (ralph loops, MCP towers, multi-agent setups) — says the results “are a mess” the same way ad-hoc prompting is.

My one-line takeaway

The annotation cycle is the move I want to steal. Most of the productivity gap between people getting great results from Claude and people getting slop comes from whether there’s a written, mutable, reviewed plan sitting between the prompt and the diff. The implementation step is almost a formality once the plan is right.