Vibe Coding and the Review Bottleneck: Who Checks What the AI Produces?

Vibe coding made writing code cheap. You describe what you want, and an AI agent ships a working version, often in minutes. That is real, and it changes how software gets built. But writing code was rarely the only bottleneck. The bottleneck is review.

Ship ten times more code, configuration and drafts while reviewing at the same speed, and you have not automatically become faster. You have moved the queue from writing to review.

The bottleneck moves

Every system has a narrowest point. Speed up another step and work piles up in front of the slow one. AI agents do exactly that to software work: production becomes fast and cheap, so understanding, judging and owning the result becomes the scarce resource.

This reaches well beyond code. Agents now produce data migrations, quotes, copy, reports and first-draft product decisions. Every result has to be checked before it reaches production, a customer or the books. More output means more review work, not less.

Two review lanes

• Machine-verifiable: linting, type-checking, automated tests, schemas, contracts and CI/CD can decide whether an output is technically correct.
• Judgment-dependent: product decisions, ambiguous business rules, tone, UX and meaningful data mappings need human judgment.

In the first lane, review scales. You write the check once and it runs on every future AI suggestion. How to Stay in Control When AI Writes Code covers those hard boundaries for AI code.

In the second lane, a green build is not enough. You need clear acceptance criteria, reference examples, sampling, dry runs and explicit sign-off. The practical framework is in Acceptance Criteria for AI Tasks.

Two projects from our own work show what the two lanes feel like in practice. In the automated DATEV export for MAFU-SHERPA, the recipient itself decides what is right: DATEV accepts the file or rejects it, and debit-credit markers, decimal separators and column order can be checked by machine before every run. That step belongs entirely in the first lane. In the item capture of XPO Inventory, the AI suggests name, description, color, category and unit from a photo; whether the category is right is visible only to someone who knows the material. Dimensions and quantity deliberately stay manual there, because those values are too critical for inventory workflows. Both projects left us with the same rule. First settle who decides what is right; then decide how to check.

The triage question

For every agent task, ask one question: can a machine decide whether this is right? If yes, put the task behind automated checks. If no, put it behind deliberate human review.

• Move as much work as possible into the machine-verifiable lane.
• Scope tasks small enough that criteria become unambiguous.
• Define before generation who signs off on the result and by which criteria.

How much review each task deserves and how to match review to risk without losing speed is covered in How Much Review Does AI Code Need?.

More agents do not solve it

More agents increase throughput on the production side, the side that is already fast. If five agents produce pull requests, quotes and reports while one person checks everything, each result waits behind another. Questions come back later. Wrong assumptions remain unnoticed for longer. More parallel production merely lengthens the queue; the same person remains the bottleneck and the risk.

The results therefore need to be easier to check. Small, clearly scoped tasks with explicit criteria are faster and safer to review than large, vague assignments.

Review is senior work

Judgment-dependent review requires an understanding of the business, the architecture and the consequences. An experienced human therefore has to stand behind the AI output and own the result.

That responsibility belongs to a named person who understands the software and its consequences. AI brings speed. Tests, types and CI/CD set hard boundaries; everything else needs business judgment rather than hope.

Build it yourself or have it built?

This does not mean you should never build with AI yourself. The opposite: for tools with low business risk, vibe coding with tools like Codex or Claude Code is often the right and cheapest choice, as long as someone can read, test and own the result. A mistake in an internal helper tool usually costs little.

But once software becomes business-critical, involves multiple users and sensitive data, or has to run for years, the review bottleneck becomes the real cost factor. Then having it built pays off, because architecture, tests, reviews and ownership decide total cost; the AI tools' code is rarely the problem. Which option fits when is covered in Custom Software vs. Off-the-Shelf.

What happens to a half-finished vibe-coding project?

Many companies are at exactly this point: a clickable application exists, built with an AI coding tool, but there is no dependable path to a first version that carries daily work. The start was still useful. It makes the idea visible and gives everyone involved something concrete to discuss. How the project was started does not matter for the next step.

The next step is taking stock, not assigning blame. First ask for a protected copy of the current state before anything changes. Then have someone review what already works, what can be kept and what blocks dependable operation, and set a smaller target for the first usable version. The result is either a working core path or a clear takeover plan when the existing base needs more work than a bounded first step can carry.

After that review you know whether the project should be continued, simplified, partly rebuilt or stopped. Not every generated feature survives it, and that is the point: a small, reviewed core carries more than a large, unreviewed surface. Which parts stay is decided by the same two lanes as in the DATEV export and XPO Inventory. What machines can check is easy to keep; what needs judgment gets re-evaluated.

Want AI speed without losing control of quality? Talk directly to the developer.