Compute Allocator

Sources#

• How I AI: Thariq Shihipar on Replacing Markdown with HTML for AI-Powered Development

Summary#

Thariq Shihipar's framing for what the human becomes once the model can do most of the producing: "we're all becoming compute allocators." The main job is no longer generating the work — it is deciding what is worth spending compute on, and investing in the alignment and communication that ensures the compute spent is well-spent.

The framing's sharpest statistic: maybe only 1% of the tokens Thariq generates end up in production code. The other 99% are spent on rich, often disposable scaffolding — HTML plans, custom interfaces, status updates, design systems. That 99% is not waste; it is the alignment and communication investment that makes the 1% that ships "exactly what it needs to be."

The 1% / 99% split#

"Thariq mentioned that maybe only 1% of the tokens he generates end up in production code. The other 99% are spent on this rich, beautiful, and sometimes disposable scaffolding."

Read carefully, this inverts the usual mental model of an engineer: output is no longer the artifact you ship; output is the scaffolding around the decision. The shipped code is a small, high-leverage residue of a much larger deliberation surface. Allocating compute well means choosing which deliberations to fund and how richly — a brainstorm here, a throwaway editing UI there, a living design system to keep future work on-brand.

What "allocation" means in practice#

• Decide what's worth building before building it — the brainstorm-in-HTML step exists so the human can choose well among options, each with its own risk assessment.
• Spend on legibility, not just production — pay tokens for plans and interfaces the human will actually engage with (see HTML as the New Markdown).
• Spend on disposable tooling — spin up a micro-app to make one decision better, then throw it away.
• Trust the model with the rest — "I trust you here"; under-specify and let capability fill in (a prompt-level The Bitter Lesson).

The abundance mindset#

The behavior only makes sense under what Thariq calls an abundance mindset: generation is cheap enough that you can afford to produce throwaway scaffolding to make your own process more efficient and enjoyable. Scarcity thinking ("don't waste tokens / don't build something you'll discard") is the wrong frame; the constraint that actually binds is human attention and judgement, not generation cost. This is the same economic shift Printing Press Software Democratization describes — when the cost of production collapses, value migrates to what and whether, not how.

Relationship to the rest of the wiki#

• "Coding is solved (for me)" (Boris Cherny) names the precondition; compute allocator names the role that remains once it is true. Boris writes 100% of his code via Claude and runs hundreds of agents; the residual human job is allocation and direction.
• Product taste as the bottleneck skill (Engineer PM Convergence, Cat Wu: "as code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write") is the same claim from the org-design side. Compute allocation is product taste exercised at the level of individual model invocations.
• Harness shrinkage with a twist — as the model-facing harness shrinks (Harness Shrinkage as Models Improve), the human-facing harness (the 99%) grows, because the allocator needs ever-richer artifacts to decide well. See the harness-tension section of HTML as the New Markdown.
• What doesn't migrate inward — The Bitter Lesson dissolves model-facing structure; the allocation decision and the human-facing scaffolding that supports it are precisely what stays on the human side of the line.

Connections#

• Thariq Shihipar — coined the framing
• Claude Code — the tool through which the allocator spends compute; increasingly serves "decide what to build," not "type the code"
• HTML as the New Markdown — the medium the allocator spends the 99% in
• Disposable Micro-Apps — abundance-mindset tooling, funded by allocation
• Living Design System — a durable allocation: spend once, reuse as context forever
• Boris Cherny — "coding is solved (for me)" is the precondition for the allocator role
• Engineer PM Convergence — "deciding what to write" as the bottleneck skill; allocation is taste at invocation scale
• Printing Press Software Democratization — the abundance economics that make 99%-disposable rational
• Harness Shrinkage as Models Improve — model-facing harness shrinks while the allocator's human-facing harness grows
• The Bitter Lesson — the allocation decision is what does not migrate into the model
• Outsource Your Thinking, Not Your Understanding — Karpathy's twin framing: you can outsource the thinking (and the compute), but the understanding that lets you allocate well stays human
• Software 3.0 — MenuGen ("that app shouldn't exist") is allocation in action: deciding the neural net should do the work directly rather than spending compute on scaffolding

Open questions#

• Is 1% a Thariq-specific number or a regime? For larger, more code-heavy projects the production residue is presumably higher; what sets the ratio?
• Allocation quality is hard to measure — what's the feedback loop that tells an allocator they spent compute badly (vs. just spending a lot)?
• Does treating humans as "compute allocators" risk the oversight-fatigue / accountability failure modes the HBR research flags, where the human nominally decides but actually rubber-stamps?

Derived#

• Does the Human-Facing Harness (HTML Artifacts) Hit Its Own Bloat Ceiling? — finite human attention is the conserved resource the allocator spends; rubber-stamping is how the human-facing harness breaches its bloat ceiling

Sources#

• How I AI: Thariq Shihipar on Replacing Markdown with HTML for AI-Powered Development