ExpertsFMTokenmaxxing: How Top Builders Use AI To Do The Work Of 400 Engineers
Y Combinator Startup Podcast · May 8, 2026
5 Selected Lessons:
heuristic · 3 framework · 1 prediction · 1
CEO/10-star meta-prompting via Brian Chesky's 10-star exercise
Source
Y Combinator Startup Podcast — Tokenmaxxing: How Top Builders Use AI To Do The Work Of 400 Engineers (May 8, 2026) · at 9:47 ▸
When this applies
when scoping any new initiative and wanting to avoid settling for the obvious, minimum-viable version
The takeaway
Use a role/persona + extreme-rating framing to force a system (human or AI) out of default, incremental thinking into maximal-ambition thinking.
Why it works
Prompting the model to imagine an idealized stakeholder (e.g. a legendary product founder) pushing the rating scale far past normal ('what's a 10-star experience?') pulls the model's latent space toward more ambitious, higher-value solutions it wouldn't otherwise surface.
One level up
Deliberately engineer the framing of a question, because the frame itself determines the ceiling of the answer space explored.
Where it stops holding
This stops working when the task genuinely only needs a minimal solution and over-engineering ambition wastes effort, or when the model has no real way to act on the expanded vision.
Detail
procedure:
- Take an existing plan/review prompt
- Reframe it by imagining an idealized high-bar stakeholder (e.g. 'imagine Brian Chesky sitting with you')
- Ask explicitly: what is the platonic ideal of this? What is the 10-star experience?
- Add the '10X check': what is more ambitious and delivers 10x more value for only 2x the effort?
rationale: Coming out of latent space, this framing helps the model 'really visualize' and unlocks disproportionate ambition from 'literally two little sentences.'
In their words
What is the 10X check? What is more ambitious and delivers 10x more value for only 2x the effort? Right. And so, for whatever reason, coming out of latent space, this helps the model like really visualize.
Token maxing / boil the ocean
Source
Y Combinator Startup Podcast — Tokenmaxxing: How Top Builders Use AI To Do The Work Of 400 Engineers (May 8, 2026) · at 4:53 ▸ · at 21:33 ▸ · at 35:53 ▸
When this applies
when a scarce-feeling resource (compute, tokens, money) is actually cheap relative to the value of a more complete output
The takeaway
When the marginal cost of an input collapses, push consumption of that input until marginal value, not habit, is the limiting factor.
Why it works
Because machine cost per unit of additional thoroughness is near zero compared to human labor cost, you can spend far beyond the 'minimum viable' threshold a human would stop at, capturing completeness that was previously uneconomical.
One level up
Re-examine every 'that's too expensive to do fully' assumption whenever the underlying cost structure of an input has fundamentally changed.
Where it stops holding
This stops working when token/compute costs are not actually trivial relative to the value created, or when more context just adds noise instead of signal.
Detail
rule: Don't settle for what a human would do with limited time/budget — use agents to gather maximal sources, cross-reference them, and feed it all into the prompt, because 'the machine doesn't care.'
threshold: Go from one source to 20 sources, from 1 month of human research compressed into minutes/hours, from minimal to 80-100% test coverage.
rationale: You pay more money and 'token max' but get dramatically more complete, representative, and awesome output.
In their words
This is sort of going back to the philosophy of boil the ocean, which is one of my essays. It's like, particularly when building a Gentex software now, you don't have to settle for what we did when we were humans writing the code.
Thin hardness, fat skills — markdown vs. code split
Source
Y Combinator Startup Podcast — Tokenmaxxing: How Top Builders Use AI To Do The Work Of 400 Engineers (May 8, 2026) · at 19:23 ▸ · at 21:33 ▸
When this applies
when architecting any system that mixes judgment-based decisions with mechanical, repeatable actions
The takeaway
Route judgment, context, and special-casing to the flexible, understanding-capable layer; route repeatable, deterministic actions to the rigid, reliable layer.
Why it works
LLMs have latent space understanding of intent, context, and special cases, while code is a brittle, deterministic executor that has no understanding — so using code for judgment calls fails on edge cases, and using LLM prompting for pure mechanical actions wastes capability and reliability.
One level up
Match each subcomponent of a system to the layer (flexible vs. rigid) whose properties actually fit the nature of that subcomponent's task.
Where it stops holding
This stops working when the 'deterministic' actions actually require nuanced judgment (then markdown/LLM is needed) or when tasks that seem to need judgment are actually simple enough to hardcode reliably.
Detail
rule: If you were an event planner writing instructions for the next person, whatever you'd write in plain English goes in markdown; whatever is a literal repeatable action (like calling 20 venues) goes in code via a deterministic API call.
rationale: A lot of the difficulty in agentic engineering today is people trying to do markdown-appropriate things in code, and it fails because code is brittle and doesn't understand special cases.
In their words
There's like a lot, you know, sort of all of the difficulty in angentic engineering today is when people try to do things that should be in markdown in code, and it fails because code is brittle.
Always keep a human-in-the-loop via 'ask user question'
Source
Y Combinator Startup Podcast — Tokenmaxxing: How Top Builders Use AI To Do The Work Of 400 Engineers (May 8, 2026) · at 16:58 ▸
When this applies
when automating any workflow end-to-end and deciding whether to fully remove the human decision-maker
The takeaway
Even in heavily automated systems, preserve an explicit checkpoint where the human supplies judgment/intent that the automated layer cannot infer.
Why it works
The agent lacks the operator's unique understanding of intent, priorities, and 'what we're building' — this understanding can't be fully encoded in advance, so a checkpoint for human judgment is structurally necessary.
One level up
Automate execution, not agency — the 'why' and 'what' should remain with the human operator even as the 'how' is delegated.
Where it stops holding
This stops working when the task domain is narrow and fully specifiable enough that no human judgment input adds value, or in true end-to-end autonomous settings the speaker says he doesn't believe exist yet.
Detail
rule: Build in heavy reliance on 'ask user question' steps so the human vibe coder/operator supplies understanding of what's being built.
rationale: 'It would surprise me very much if someone really, truly did manage to make a thing that could just make software without the human in the loop... I never want to be entirely out of the loop.'
In their words
The G-Stack relies very heavily on ask user question. So, because, you know, and that's, that to me like really important. That's where the human, you know, vibe coder, operator, agentic engineer needs to supply their understanding of what's going on.
Personal AI vs. corporate-controlled AI — the coming choice
Source
Y Combinator Startup Podcast — Tokenmaxxing: How Top Builders Use AI To Do The Work Of 400 Engineers (May 8, 2026) · at 33:34 ▸
When this applies
when a new powerful technology is emerging in both a rough personal/open form and a polished corporate/hosted form, and users must choose which to build their dependency on
The takeaway
When a powerful new technology bifurcates into a self-owned, self-directed form and a corporate-hosted, opaque form, choosing the self-owned path preserves agency at the cost of present-day roughness.
Why it works
Corporate-hosted AI systems embed someone else's priorities, business model, and algorithm choices invisibly, while self-written prompts and self-owned data/integrations keep the user's own intent in control of the system — this mirrors the earlier personal-computer-revolution choice between owning your tools and depending on a host.
One level up
Technological revolutions repeat a structural choice — own-and-control versus host-and-depend — and the early 'rough' period is where that choice is actually made, not after the winner is obvious.
Where it stops holding
This prediction fails if corporate-hosted AI products end up incorporating enough genuine user-controlled personalization/data ownership that the dichotomy collapses, or if self-hosted personal AI never reaches usable reliability for non-technical people.
In their words
I guarantee you, like this time next year, like everyone's going to be saying what you heard here first, which is like every single person on the planet will have their own personal AI