Don't Box the Model In
Give the model tools and a goal, not a rigid workflow — scaffolding gains get wiped out by the next model.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 90%
When building on an LLM, the instinct is to constrain it: strict step-by-step workflows, heavy orchestration, lots of pre-loaded context. Boris argues the opposite produces better results — give the model a goal and a minimal set of tools and let it decide what to do and in what order. This is an applied corollary of Rich Sutton's Bitter Lesson: the more general approach beats the more specific one, and scaffolding's ~10-20% gains typically vanish with the next model.
Origin
Boris Cherny's design philosophy for Claude Code, which he explicitly grounds in Rich Sutton's 2019 'The Bitter Lesson' essay.
Core principles
- 01The more general model will always outperform the more specific model (the Bitter Lesson)
- 02Give the model a goal and tools; don't hard-code the sequence of steps
- 03Provide a tool to fetch context rather than dumping all context up front
- 04Scaffolding may add 10-20% today but that lift is usually erased by the next model
- 05Bet on the general model — avoid fine-tuning and tiny special-purpose models unless you have a strong reason
How to run it
- 1
State the goal, not the procedure
Give the model the outcome you want instead of a mandated step-one-step-two-step-three workflow.
Pro tip 'Ask not what the model can do for you' — ask what tools it needs to do the job itself.
Watch out Heavy orchestrators that force a fixed sequence usually underperform a model left to plan its own path.
- 2
Expose minimal tools
Give the model a small set of tools and let it choose which to run and in what order. Claude Code inverted the norm — 'the product is the model' with minimal scaffolding around it.
- 3
Let it fetch its own context
Rather than pre-loading a large context blob, give the model a tool so it can retrieve the context it actually needs.
- 4
Default to the general model
Prefer the most general model over fine-tuned or tiny models. If you're adding scaffolding for a 10-20% gain, consider just waiting for the next model instead.
Watch out Scaffolding you build today is a depreciating asset — the next model release often makes it redundant.
In the wild
In an early Claude CLI demo, Boris gave the model a single bash tool and asked 'what music am I listening to.' He never told it how to use the tool for that; the model figured out on its own how to write code to answer a question he wasn't even sure was answerable.
→ Convinced Boris that exposing the model with minimal instruction beats prescribing how it should work.
Common mistakes
Layering strict workflows on the model
Forcing 'do step one, then two, then three' via a fancy orchestrator constrains the model and almost always yields worse results than giving it a goal and tools.
Over-investing in scaffolding and fine-tunes
Custom scaffolding and small fine-tuned models buy a small short-term lift that the next general model typically erases, wasting the engineering effort.
Is it for you?
Best for
Engineers and PMs designing agents or LLM-powered features who are deciding how much structure to impose
Not ideal for
Narrow high-stakes tasks with hard compliance or determinism requirements where a fixed workflow is mandatory
From the transcript
“don't try to box the model in”
“almost always you get better results if you just give the model tools, you give it a goal, and you let it figure it out”
“the more general model will always outperform the more specific model”
“maybe scaffolding can improve performance maybe 10 20% something like this. But often these gains just get wiped out with the next model.”
From the episode
Head of Claude Code: What happens after coding is solved
Boris Cherny