Yutori designer: coding got faster, code review did not

Maximillian Piras argues the agent industry has no equivalent of horsepower — a rough but legible metric that lets non-experts judge whether a new tool is worth adopting. Without it, he says teams cycle between overspending on tokens and abandoning agents entirely, because value can't be verified as fast as it's produced.

• Yutori's use case — Piras is founding designer at Yutori, which builds computer-use models that operate a computer like a human would when no API or MCP is available.
• The bill problem — Running parallel agents in the background is fun until the bill arrives, prompting the question of whether the token spend was worth it.
• Biased sample — He invokes Upton Sinclair to argue that people in the room selling or using tokens are early adopters, not representative of people who still copy-paste into ChatGPT.
• Watt's horsepower — In the 1700s James Watt studied horse gins powering mills, derived a rough, unscientific measure called horsepower, and used it to make steam engines' relative efficiency legible to people who 'thought in horses.'
• Overspend, underuse — Piras borrows Ramp's term for the current pattern: token-maxing into austerity, dropping out, then returning out of FOMO.
• Coinbase example — He cites a chart the Coinbase CEO posted showing AI spend diverging from token usage after the company stopped defaulting to frontier models for every task.
• Tokens are just output — He argues spend must trace to outcomes like bugs closed or support requests resolved, not raw token counts.
• Review bottleneck — Even Anthropic has said it hasn't solved code review, so the bottleneck has shifted from code generation to human review of pull requests.
• Noah Hein cited — Piras references a post by Noah Hein arguing that code review's underlying shared assumptions need to be revisited for the agentic age.
• Mouse power idea — He proposes 'mouse power' as a conceptual (not literal) equivalent of horsepower, though he jokingly tried having Claude build a literal cursor-movement measurement device and calls it a fool's errand.
• Entropy matrix — His framework plots uncertainty in task steps against uncertainty in acceptance criteria, drawing on Claude Shannon's entropy concept.
• Four quadrants — Low step uncertainty means write a script instead; high step uncertainty risks out-of-distribution, sparse-reward tasks; high acceptance-criteria uncertainty makes verification as costly as execution.
• Sweet spot — The viable zone is NP-style tasks that are harder to execute than to verify, meaning you can build a second agent just to verify the first agent's work.

In their words

So, when we think about our own token usage, uh is it really representative of all the people out there who have never touched an agent yet?4:58

one of the big barriers to adopting it would be this cognitive dissonance of trying to tell people who kind of think in horses, how do you adapt to this to this uh cold machine6:34

the problem of course is that we're all kind of dying by a thousand pull requests.11:40

even Anthropic who has uh, some people on the team have claimed have solved coding, uh, they have also admitted that they've not solved code review.11:44

Disclosure · Piras is founding designer at Yutori, the computer-use model company he uses as his working example throughout the talk.

One thing to add — One thing to add — the talk is explicitly a thought-starter rather than a finished framework; Piras admits the entropy matrix is "still in the works" and offers no method for actually measuring the two axes. It's most useful as a vocabulary for deciding which tasks to hand to agents at all, not as a ready-made ROI calculator.

One thing to try tonight
Before assigning your next task to an agent, plot it on Piras's two axes yourself: rate how predictable the steps are (script vs. open-ended) and how easy the output is to verify against a rubric, and skip the agent if either uncertainty is too low or too high.