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#

• Implementation Abundance Inverts Product Work — curating 90 cheap builds is allocation at the level of a whole feature exploration
• Role Averaging, Not Role Elimination — the averaged IC as allocator/steerer of agent work rather than character-by-character author
• Vibe Coding vs. Agentic Engineering — "coding is steering the AI" restates the allocator role: measure the steers, not the lines
• 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
• Research Taste as the Human Bottleneck — allocation scaled up to a whole research program: deciding which experiments are worth running once Claude can run them
• Recursive Self-Improvement — the essay's third future has humans moving "most of our effort towards oversight, validation, and verification," with pace set by compute — the allocator role at civilization scale
• AI as Primary Author — once AI authors most code, the human's residual job is allocation and direction, not authorship — the role this page names
• Planning / Execution Division of Labor — the allocator role, measured: Anthropic's 400K-session study finds humans make ~70% of planning decisions (what to do) while Claude makes ~80% of execution — deciding-what-is-worth-doing is empirically the human's retained share
• Unknowns as the Agentic Bottleneck — what the 99% of non-shipping tokens are spent on: Thariq Shihipar's blindspot passes, brainstorms, interviews, and references are all elicitation of the allocator's own unknowns

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)?

Resolved Questions#

• 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? Answered: Is Human Review of AI-Authored Code Still a Real Control, or Already Rubber-Stamping? — yes, it is the role's central failure mode, documented at three evidence layers (brain-fry error rates +11%/+39% and the under-engagement swap; Faros's 31.3% no-review telemetry; the CMU theory's P1–P4 load-and-plausibility mechanisms), with two allocator-specific aggravators: allocation quality has no feedback loop, and the human's retained 70% planning share is exactly where rubber-stamping is transcript-invisible. The framing survives only with structural countermeasures — understanding-gated merges (quiz gate), sample-based depth concentrated on high-stakes points, risk-tiered gating — that make understanding rather than signature the merge condition.

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
• Human-in-the-Loop Boundaries — operational boundary for when humans allocate, understand, and own risk vs. when they become manual throughput bottlenecks
• Is Human Review of AI-Authored Code Still a Real Control, or Already Rubber-Stamping? — the rubber-stamp question answered: yes at three evidence layers, survivable only via review redesign

Sources#

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