Skip to content

What is the human for? Show three catches.

When a fix takes a minute, the fix is worth nothing: the finding is the product. The only answer to "what is the human for?" that lands with someone who does not code is a log of what review caught last month, what each catch would have cost, and which automated check let it through.

pricing · founders

A client fixed the hole in a minute and asked what was next. That sentence is the whole pricing problem for anyone who sells engineering in 2026.

The answer first. When a fix takes a minute, the fix is worth nothing. The finding is the product. And the only answer to "what is the human for?" that lands with someone who does not write code is not an argument about context or ownership. It is a log: what review caught last month, what each catch would have cost, and which automated check let it through. In our experience, three rows of that log do more than any explanation.

Two threads, one question

In late September a freelancer wrote on r/cscareerquestions that a client of three years had let them go. The client had found they could build and maintain their own apps with a model, in days rather than the month or two the freelancer used to need. Before the end, the freelancer looked at one of the client's vibe-coded apps. It was about to go public. Any signed-in user could see every other user's login history and personal data: name, company, role. The client fixed it in a minute and asked what else there was.

The replies that rose to the top did not argue about rates. They said: sell the prevention of exactly this. Be the review layer for security, accessibility and architecture. Diagnosis and judgment are the billable part, not typing the code. One reply named the objection every studio will hear next: the client already has an AI checking the code the AI writes.

Ten days earlier, on r/coderabbit, an engineer described a different room with the same question in it. A manager two levels up wanted to know why a human still reviews a pull request when an agent writes it, an AI reviewer reads it and the tests pass. And why that step takes a day. The engineer answered with context and ownership. By their own account, it did not land.

The replies that worked were concrete. Show what you, the human in the loop, actually caught. Show the bad code that would have been committed and what it would have cost the business. One commenter turned it into a test: if your manual reviews find real issues, that is the argument, and if they do not, maybe you do not need them. Another offered a name for the slow failure: architectural drift, a fraction of a percent per commit, noticed six months later when nobody can say how it got there.

Why the explanation fails and the log works

Our reading: context and ownership are true, and they fail because they describe the reviewer. The buyer is asking about money. An explanation asks to be believed. A log asks to be read. Every row is something that nearly shipped, in words the buyer can repeat to their own boss.

This is also the studio's position on quotes, and it is ours, not a finding: the estimate breaks at the review line, not the build line. Generation got cheap. Verification is now the majority of the work, and an honest quote prices it as its own line. Without the log, that line is an assertion the client has to take on trust. With the log, it is a receipt.

The log

One row per catch. Plain text is enough; the format matters more than the tool.

catch        number, counting up, never reused
date         when review caught it
found        one sentence a non-coder can read
where        the feature, not the file
would have   what the user would have seen if it had shipped
cost         your estimate, in your own units: a slipped launch,
             refunds, a disclosure, support hours
passed by    which automated check was green when it went through:
             tests, AI reviewer, linter, type checker
caught by    human / second model / both
fix time     minutes; small on purpose

The first row of anyone's log can be the one from the thread. Nothing here goes beyond what the freelancer described.

catch        001
date         2026-09-26, as described on r/cscareerquestions
found        any signed-in user could read every other user's
             name, company, role and login history
where        user profile and session views
would have   a public launch with every account open to every
             other account
cost         the client's call; an open data leak at launch is
             not a bug ticket
passed by    not stated in the thread; the app was about to go
             public, so whatever had been run had passed it
caught by    a human reviewer, reading the app as a stranger would
fix time     about a minute

Notice where the value sits. The fix time is the smallest number on the row, and that is the point. The minute was cheap because the finding had already happened.

At the end of the month, the log rolls up into one block. This is the page you put in front of the person who asked.

review, <month>
rows                      N
caught by human only      N
caught by second model    N
caught by both            N
passed by green tests     N
passed by AI reviewer     N
median fix time           N minutes
worst row                 one sentence

The two "passed by" lines are the answer to "the AI already checks the AI's code." Not a counter-argument. The rows where that check said nothing.

The honest half

If the log stays empty for three months, the commenter on r/coderabbit is right: maybe that review is not needed. We would rather say so than invoice for a line nobody can see. The log cuts both ways, and that is why a buyer can trust it.

What would change our mind: a quarter of logs in which every human catch had already been raised by the automated reviewer before a person looked. Then the human line shrinks to the rows it still owns, and the quote should shrink with it.

How we run it ourselves, as process rather than proof: the reviewer that reads a change has none of the author's conversation, so it cannot be talked into a yes. A finding is closed only against the current state of the code, not against the diff it was raised on. Nothing in that loop is a secret. It is work that has to be done each time.

FAQ

The client already has an AI reviewing the AI's code. Isn't that enough?

Sometimes. The log is how you find out instead of arguing. If the "passed by" column keeps naming the AI reviewer, the human line is earning its keep. If the column stays empty, drop the line.

How many rows does it take to convince someone?

Our rule of thumb: three from last month, each with a cost the buyer can picture. Thirty rows from last year read like a backlog. Three recent ones read like a near miss.

What if we cannot put a number on the cost?

Write the consequence instead of the number. "Every user's data readable by every other user at launch" needs no currency. Let the buyer price it; they know their business better than you do.

Does the log replace the estimate?

No. It backs one line of it. The estimate still says what building costs. The log shows what verification is for, with dates.

Isn't a list of our own near misses bad marketing?

Each row is something that did not ship. A studio with an empty log either writes perfect code or is not looking. Buyers can guess which.

A related case

Holt, our language-learning product, lives by the same rule in a different shape: what a model writes is checked before a learner sees it. The case is at iloblique.com/holt.

If you have something worth building, we'd like to hear about it.

Sources