Waste Tokens, Save Time
Optimize for your calendar time and the final artifact, never for token spend.
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 6
- Confidence
- 72%
Most people optimize the wrong variable when working with frontier models: token spend. This framework inverts it. Treat tokens as the cheapest input in the stack, far cheaper than an hour of human time, and treat your own attention as the scarce one. Instead of learning prompt tricks, scaffolds and plan modes that the next model generation makes obsolete, give the model a rough brief and let it brute force. Fan the same problem across several frontier models at once and take the best answer. Accept that the first pass is not production quality, then spend more tokens on a dedicated rewrite pass when you actually ship. The mechanism is simple: inputs are cheap tokens and a loose brief, the process is parallel brute force plus a cleanup pass, and the output is judged only on the finished artifact and the calendar time it took to get there.
Origin
Extracted from Naval, where Naval describes deliberately refusing to learn prompt engineering tricks and instead throwing multiple frontier models at the same problem until something works.
Core principles
- 01Tokens are the cheapest input in the stack; your time is the scarce one.
- 02The model will improve faster than you can learn tricks to steer it.
- 03Parallel brute force beats careful single-shot prompting.
- 04First-pass output is a draft, not a shipping decision.
- 05Judge the finished artifact, never the transcript that produced it.
How to run it
- 1
Refuse the trick stack
Deliberately skip the prompt engines, scaffolding layers and mandatory plan modes people recommend. Assume the model improves faster than your technique for steering it.
Pro tip Revisit this every few months anyway, because the boundary of what the model can do unaided is a moving target.
Watch out This is a bet about the rate of model improvement, not a claim that technique never helps.
- 2
Write the shortest useful brief
State the outcome and the constraints, then stop. Over time you should find yourself typing less, not more, as the models absorb more of the specification burden.
Pro tip If the model asks clarifying questions or returns tradeoffs, answer them instead of pre-empting them.
- 3
Fan out across models
Send the same problem to several frontier models in parallel rather than iterating serially on one. You are buying diversity of attempts with tokens instead of buying it with your own hours.
Pro tip Keep a standing default of two or three models so the comparison is habitual, not a special occasion.
Watch out Do not average the answers. Pick the one you can defend.
- 4
Stop watching the meter
Do not treat token consumption as either an input metric or an output metric while work is in flight. Even expensive runs are cheap relative to the human hour they replace.
Pro tip Set a spend cap if you need one, then never look at it again during the session.
Watch out Token counts are a terrible proxy for productivity, in the same way lines of code always were.
- 5
Buy quality back with a rewrite pass
Assume the first working version is low quality, non-scalable code. When you decide to ship, spend a second budget of tokens explicitly on review, hardening and rewrite.
Pro tip Make the rewrite pass a separate session with a fresh context so the model critiques rather than defends.
Watch out Skipping this step is how brute force turns into unmaintainable production debt.
- 6
Re-benchmark each generation
Every model release, retest which parts of your workflow still need human care. Work that needed close collaboration last quarter is often brute-forceable this quarter.
In the wild
Naval describes not having written code in roughly two decades, then coding constantly through agents. What made it possible was not relearning the current language, framework and infrastructure stack, which was exactly what had pushed him out, but understanding software principles and algorithms well enough to direct the models. The assembly work that used to be the annoying barrier to starting is now absorbed by the agent.
→ Went from writing no code for twenty years to shipping software regularly, without learning the current toolchain.
A brute-forced prototype works but is knowingly unscalable. Rather than trying to get production quality out of the first attempt, the operator runs a dedicated pass instructing the model to review the whole thing, then rewrite it for production. The token cost of the second pass is treated as irrelevant against the time it saves.
→ Production-grade code without slowing down the exploratory phase that produced it.
Common mistakes
Measuring engineers by token spend
Token leaderboards are the modern version of counting lines of code. High consumption tells you nothing about whether the output was worth producing.
Treating the first draft as the verdict
Brute force produces working but low-quality code by design. If you judge the model on that draft you will conclude it cannot ship, when you simply have not run the rewrite pass yet.
Building a personal prompt-tricks moat
Technique that patches a current model's weakness depreciates with every release. Time invested there competes directly with time spent shipping.
Is it for you?
Best for
Founders and technical generalists building software through agents where speed of iteration matters more than elegance of process.
Not ideal for
Genuinely frontier creative or research work where you are past the model's capability and need slow, careful collaboration on unsolved problems.
From the transcript
“I'll throw Codex Claw and Gemini at the same problem over and over and just waste tokens to save time.”
“So I would say just waste tokens, save time. Don't look at the tokens either as inputs or outputs. Just look at your time and…”
“When the time comes and I want to ship it to production, I'll just throw more tokens at it.”
From the episode
Full Episode: The AI Industrial Revolution