The first week of January is usually quiet in developer tooling. Nobody ships between Christmas and the first Monday back. This year the most read thing in our corner of the industry was not a release at all. It was a thread from Boris Cherny, the engineer who created Claude Code at Anthropic, describing exactly how he uses it day to day. It went around on 2 January, hit the front page of Hacker News, and by the weekend every developer we know had an opinion about it.
We have used Claude Code alongside Cursor since late last year. Reading the creator's own setup was a useful check on ours. This post is what he does, what we already did, what we changed, and one thing we decided not to copy.
His Setup, in Plain Terms
Cherny's thread is thirteen points. Grouped, they come down to five habits.
Run many sessions, not one. He keeps five Claude Code sessions open in numbered terminal tabs with a notification when any of them needs him, plus five to ten more running on claude.ai in the browser. Work moves between the two with a hand-off command.
Use the best model with thinking on, always. His words: Opus 4.5 with thinking for everything, because a smarter model needs less steering even though it is slower.
Plan first, then build in one pass. Every session starts in plan mode. He iterates on the plan until it is right, then switches to auto-accept edits and lets the agent execute the whole plan without stopping to ask.
Turn every mistake into a rule. His repository has a single CLAUDE.md file, checked into git and shared by the whole crew. When Claude does something wrong, the correction goes into that file so it never happens again. He updates it several times a week and even has Claude propose updates during code review.
Automate the boring loop, then verify. Custom slash commands live in the repository, like a /commit-push-pr command he runs dozens of times a day. Subagents handle recurring chores: one simplifies code after a feature, one verifies the app. A formatting hook runs after every edit so CI never fails on whitespace. Safe shell commands are pre-approved in settings rather than by switching permissions off. And the step he credits with a two to three times improvement in output quality: Claude opens the app in a browser through the Chrome extension, tests the change end to end, and keeps iterating until it works.
None of it is exotic. That is the point. It is discipline, written down.
What We Already Did
The plan-first habit is our spec-driven process wearing a different hat. A Flight Plan produces a PRD and a phased roadmap; each roadmap item becomes a spec; each spec becomes a plan-mode session before any code is written. We had arrived at the same place from the client side: if you cannot describe the feature clearly enough for the agent to plan it, you are not ready to build it.
The browser verification loop we adopted in November when Cursor 2.0 shipped its browser tool, and we run the same thing in Claude Code. An agent that looks at its own work catches the embarrassing bugs before the fortnightly demo does.
What We Changed This Week
Three things, all cheap.
CLAUDE.md is now a Flight Plan deliverable. Every client repository gets one on day one, seeded from the Flight Plan itself: the architecture overview, the conventions we agreed, the things this codebase must never do. From then on it is the running log of corrections. When a client's own developers take over in Cruise & Maintenance, that file is the most valuable onboarding document in the repository, and it belongs to them.
Two standard subagents on every build. A simplifier that runs after a feature lands and removes the duplication agents love to introduce, and a verifier that runs the test suite and clicks through the affected screens. Both are checked into the repository so they travel with the code.
Slash commands for the repetitive git work. The commit, push and open-a-PR sequence is the same on every project. Making it one command with the status pre-computed is a small saving that happens fifty times a week.
What We Decided Not to Copy
Fifteen parallel sessions.
Cherny is building Claude Code with Claude Code, on a codebase he knows better than anyone, with a whole crew reviewing the output. That is a different job from building a client's product. The sharpest objection in the Hacker News thread came from a developer who said they did not need ten agents making fifty pull requests a week, they needed one agent that solved the most important problem correctly. For client work we are closer to that camp.
Our ceiling is three or four sessions per client repository: enough to work several roadmap items at once, few enough that one engineer can still hold every branch in their head and review it properly. Beyond that the review queue grows faster than the code, and unreviewed code is a liability we would be handing to a founder.
There is a budget reason too. Anthropic doubled usage limits over the holidays and the bonus expired today, and the developer forums are full of people surprised by how quickly they are now hitting the ceiling. Agent capacity is a real input to a build. It goes in the Clearance proposal like any other cost, and running fifteen sessions on a client's behalf would blow through it in an afternoon.
Why This Matters to a Founder
Most of the advice in that thread is about making the agent's work repeatable and checkable. That is exactly what you should want from anyone building your product with these tools.
Ask your developers where the rules live. If the answer is "in my head" or "in the chat history", the knowledge leaves when they do. If the answer is a file in your repository that gets better every week, you own something that outlasts the engagement.
Want the Same Discipline on Your Build?
At Dev Force One, the Flight Plan produces the roadmap, and Claude Code and Cursor turn it into software under rules that live in your repository, not in our heads.
What you get:
- A CLAUDE.md from day one, seeded from your Flight Plan and improved every week of the build
- Planned, verified features: every roadmap item planned before it is built and tested in the browser before you see it
- A codebase your own developers can pick up, with the conventions and commands checked in alongside the code
Curious what an agent-first build looks like with guardrails? Book a Pre-flight call and we will show you.