---
title: "Be ambitious where you can check the answer"
description: "The limit on what one person can build has moved. The limit on what one person can verify has not moved as far."
canonical: "https://www.rickblalock.dev/scratch-notes/be-ambitious-where-you-can-check-the-answer/"
date: "2026-11-04"
updated: "2026-11-04"
author: "Rick Blalock"
---

# Be ambitious where you can check the answer

> The limit on what one person can build has moved. The limit on what one person can verify has not moved as far.

Published: 2026-11-04

Catalog: SN-027

Dan Luu published a note built around something Michael Malis keeps saying to him: ["we should be more ambitious with the software we build"](https://danluu.com/ambitious/). Dan would say "can" rather than "should," and his examples are the kind of thing I would never have started: a regex engine tuned to his own workloads, a ripgrep fork, a Rust interpreter that sped up his cold builds. Each took him a low single-digit number of hours. That got him to "works for me" quality rather than product quality, and he argues that is a legitimate bar. I'm starting to agree with this approach.

His explanation for why people don't do this is curious. We are carrying a "pre-agentic cost model." Ten years ago, the person who rewrote their compiler because it was slow was the same person who started a 3D engine when they wanted to make an indie game. The one who never shipped. Most of us knew that was a pretty dumb use of time (in most practical scenarios), but a lot of folks still think that way after the reasons (or tech) changed.

I wrote about this from the other side in [A computer I can make my own](https://rickblalock.dev/scratch-notes/a-computer-i-can-make-my-own/). The Omarchy plugins I published were things I had wanted for years and always put aside. What I didn't work out in that note is how far to push, and that is where Dan's post gets interesting, because he includes the objection.

There's been this pervasive thinking that most people should be *less* ambitious and so it persists with AI-built software; the fear being they'll "experience abject failure." Yossi Kreinin's reason: most problems "don't lend themselves that well to 'agentic loops' since you don't have clear pass/fail criteria, and even when you do most people have trouble reasoning about giant black boxes which they can impose constraints on but can't understand the innards of."

Dan's answer is not that the models are good enough now. It is that you can usually build a check, even when the problem looks like it doesn't have one. He got close to a correct rule set for a board game with contradictory rulebooks by having the agent run consistency checks between the contradictory versions, then compared the result against someone else's implementation. He notes that fuzzing and property-based testing worked in every domain where people told him they wouldn't.

So the heuristic I'm borrowing from the two of them: be ambitious in proportion to how well you can tell whether the result is right. If I can check the output quickly and cheaply, I can afford not to understand the insides. If I can't, the black box is exactly as dangerous as Yossi says. Or another way to state it from a non-tech POV: If I can understand the business outcome, product effects, and customer impact, that's a lot further along than most people can do using AI, who are often removed from that so they have no real way of knowing if what their AI agents are doing is effective or not (this is THE reason why lots of software engineers are in danger).

Peter Geoghegan's example in the post is the picture of this. He had an agent write a Neovim function that formats Postgres code to his exact preferences by chaining clang-format, pgindent, and tree-sitter together. He calls it "inherently a Rube Goldberg device" and says, "I have only a vague understanding of how all this works, though. I don't even know Lua." It's fine, because CI tells him whether the formatting is right. He gets to be, in his words, unreasonably fussy about a tool because the check is free. His closing thought: LLMs are writing "software that'd be impossibly tedious for any human to maintain, relative to the value that it creates."

That is the cool part, in my view. There is a whole category of software that was never worth building because one person would have to write and maintain it for one person's benefit. A tool that fits exactly how I work. A game I want to play for an afternoon. A fix for an annoyance I've routed around for a decade. The economics of that category changed, and what I have to bring is the ability to recognize a right answer when I see one.

One last thought...

Dan's footnote is great: He cites Max Bittker's framing that models are very good at counterfeiting, and the expertise it takes to tell a counterfeit from the real thing goes up as models improve. Dan says the same thing about his own work: the gap between what a model can implement and what it can verify without hand-holding keeps widening. So the check has to keep up. The works-for-me bar is honest only as long as I am actually the one checking, and I can still tell. Where that stops being true, Yossi gets the last word, and I don't have a clean answer for where that line sits yet. They keep getting blurred.

---

[All Scratch Notes](https://www.rickblalock.dev/scratch-notes/)