Read 93 Lines, Skip 1,000: When Ignoring AI Code Is Engineering
Three Posts, Forty-Eight Hours, One Argument
On July 28th and 29th, three separate items landed on the Hacker News front page. Read individually, each is a curiosity. Read together, they are the same argument arriving from three directions.
The first was a Show HN: a formally verified 3D mesh intersection algorithm written in Lean 4, at roughly 111 points and 48 comments. The interesting part wasn't the algorithm. It was the review instructions the author attached to it. Read the 93-line specification. Run the Lean checker. You never need to inspect the 1,000+ lines of implementation the AI wrote — or the 60,000+ lines of formal proof the agent generated along the way. The work was built mostly with Claude Opus 4.8, with some early proof strategies from Fable 5, and individual steps consumed 24+ hours of autonomous agent time.
The second was SpecForge, a platform for authoring formal specifications, at 61 points the same week.
The third was Robert C. Martin — Uncle Bob, the man who taught a generation of engineers to care about the shape of their code — posting that his current strategy is "to not read any of the code written by my agents." Fifty-three points, fifty-three comments, and eighteen months ago that sentence from that author would have been heresy.
It isn't anymore. But it also isn't the whole story, and the missing half is where founders get hurt.
Not Reading The Code Is A Behavior, Not A Method
Here is the trap, and it is a subtle one.
"I don't review the AI's output" describes what someone does. It says nothing about whether they're safe. Two people can adopt the identical habit and end up in opposite places, because the habit isn't the thing doing the work — whatever sits underneath it is.
The Lean project has something underneath it. A 93-line specification a human can actually hold in their head, and a mechanical checker that will refuse the implementation if it violates that spec. Sixty thousand lines of proof go unread on purpose, because something other than a human is verifying them. That is not trust. That is delegation with a receipt.
The founder shipping AI-generated features off a Slack thread and three voice notes has the same behavior and none of the substrate. Nobody reads the code. Nothing checks it either. The feature works in the demo, the demo becomes the product, and the gaps surface eight weeks later as "that's not what I meant" — usually in front of a customer.
Not reading the code plus a verified contract is engineering; not reading the code plus a Slack thread is the rebuild cycle. Same behavior, opposite outcomes, and the spec is the entire difference.
When You Stop Reading The Code, The Spec Becomes The Product
This is the shift almost nobody has priced in yet.
For thirty years, the code was the artifact of record. It was the thing you reviewed, argued about, and inherited. Specs were scaffolding — written to get to code, then abandoned in a Google Doc nobody opened again.
The moment generation gets cheap and volume gets high, that inverts. The reviewable surface shrinks from 1,000 lines to 93. What survives is the document that says what the system must do — because it's the only remaining place where human intent is written down in a form a human can check. Vibe coding gets you a convincing prototype. What turns that into a product people can depend on is a specification that holds when the code underneath it gets regenerated.
You don't need Lean. Almost no founder lives in formal-methods territory, and pretending otherwise is how this advice becomes useless. What you need is the same shape: a spec small enough that you can actually hold it, and a checking layer strong enough that you can accept output you didn't read.
For a product team, that spec carries five things:
-
The behavior in observable terms — what goes in, what comes out, what the user sees on screen
-
The boundaries — what the system must never do, stated as flatly as what it should
-
The edge cases you've already decided — the ones you resolved deliberately, not the ones production will find for you
-
The acceptance conditions — how you, or anyone else, can tell the thing is finished
-
What is explicitly out of scope — the fastest way to stop a build from quietly expanding
Notice what isn't on that list: implementation detail, architecture opinions, library choices. Those are the 60,000 lines. Let them go unread.
What This Looks Like On Monday
Take the feature currently in build. Not the roadmap — the thing someone is generating code for this week.
Write its spec after the fact. Give yourself one page. If you can't get the behavior, the boundaries, and the acceptance conditions onto that page, you have just discovered that nobody on the team could have described "done" if you'd asked them. That's the finding, and it's worth the twenty minutes.
Then apply the test the Lean author applied to himself: what is checking this? If the answer is "we'll look at it when it's built," you're reviewing implementation — the exact thing that doesn't scale when an agent can produce a thousand lines overnight. If the answer is a written acceptance condition someone can run without you in the room, you have a substrate. You've earned the right to stop reading the code.
Do this before the build, not after, and the spec stops being documentation. It becomes the thing you approve.
Start With The Spec, Not The Prompt
Codalio exists for the part of this that founders can't outsource to a checker: turning fuzzy business logic into a specification precise enough that AI-generated software can be accepted, rejected, or rebuilt against it — before a single line gets written.
Start with the questions, not the code: codalio.com. It walks you through the behavior, boundaries, and acceptance conditions for one feature, and you finish with a spec you could hand to an agent or an engineer and get the same thing back.
References
-
Show HN: formally verified 3D mesh intersection in Lean 4 (July 28–29, 2026)
-
SpecForge — a platform for authoring formal specifications (July 29, 2026)
-
Robert C. Martin on not reviewing agent-written code (July 29, 2026)