Vibe Coding vs Harnessed Delivery: What the Extra Work Buys
An app builder can put a working page in front of you in minutes. Our harness took about three hours of Claude’s time, 492 model calls, and about $71 for a change to a live booking platform. The difference is in what a preview cannot show. The extra work found a bug that could have stopped the last places being sold, and closed a security gap. It kept staff’s settings through a migration, and left around 50 new tests and a reviewed change behind. If nobody will rely on the software, build it yourself. If they will, that is what the extra time buys.
The question we hear most about AI delivery is a fair one. If an app builder such as Replit or Lovable can produce a working page in minutes, why does our approach take hours, hundreds of model calls, and a person’s review? Why not just build it yourself?
We recently measured one change closely enough to answer with evidence. The full account is in Anatomy of an AI Change. Two complex, linked user stories on one of the booking platforms we build went from open business questions to two merged pull requests in 15 hours 35 minutes, overnight included. Claude worked for about three hours, and the engineer driving it spent an estimated 25 to 50 minutes hands-on.
This post sets that effort against the ten-minute version, and asks what the difference in output is and whether it matters.
Why does harnessed delivery take so much longer?
Because it is doing a different job. An app builder, used the way vibe coding uses it, produces the part you can see. You describe a screen, it appears, and if it seems to work you move on.
The change we measured included a screen, but most of it sat underneath:
- two new database entities and a migration
- more than a dozen stored procedures, most of them changed rather than new
- a new endpoint behind a scope guard that limits staff to the sites they manage
- admin screens and settings, and a change to the public availability feed
- a mapping that carries staff’s settings across from the legacy system being replaced
- around 50 new automated tests for the first story, and broad regression runs of several hundred tests before merge
Where the time went tells the same story. Running tests took more of Claude’s time than anything else, including writing code. The people’s share was small: under an hour of the engineer’s attention, plus a manual session with a QA analyst and a business analyst that happens whichever way the software is built.
What did the extra work produce?
The table sets what a preview would show against what the harness delivered alongside it. Everything in the right-hand column happened in the session we measured.
| What a preview shows | What the harness also delivered |
|---|---|
| A screen where staff can set availability to automatic, limited, or full | Acceptance criteria checked against the business’s own decisions before any code was written |
| The setting saves and displays | A fix so that a display threshold cannot stop the last places being sold |
| The feature appears to work for the person testing it | A scope guard, proven by tests, so staff can only change the sites they manage, with the same gap closed on the existing endpoints |
| A working feature on a fresh database | A migration mapping so staff keep the settings they had chosen on the legacy system |
| Code that runs | Code that follows the system’s own patterns, reviewed by an expert engineer against the architecture before it merged |
| Nothing else | Around 50 new tests, every acceptance criterion tied to a named test, feature flags confirmed on the test and staging environments, and documentation updated |
None of the right-hand column is visible in a demo. All of it decides whether the feature is safe to put in front of customers and cheap to change next year.
What would vibe coding have missed in this change?
Each row below compares three ways of making the same change. The first column is what happened in the session we measured. The other two are our expectations from how we see these approaches go, not measurements:
- Claude Code, no harness: an experienced developer using the same model, without the project’s rules, skills, gates, or review subagent.
- Vibe coding with an app builder: someone using an off-the-shelf tool such as Replit or Lovable, accepting what runs, with no engineer reviewing the code.
| Area | Harnessed delivery (what happened) | Claude Code, no harness (our expectation) | Vibe coding with an app builder (our expectation) |
|---|---|---|---|
| Starting point | Work inside an established codebase, following its own patterns, database, and pipeline | The same codebase, with the developer restating its patterns in prompts | App builders are designed to create applications from a prompt, so a change inside an established enterprise codebase is a poor fit from the outset |
| Requirements | Planning found that two acceptance criteria still asked for an option the business had dropped, and raised the question before any code was written | The model builds the dropped option, because the criteria still ask for it | The tool builds whatever the prompt describes, and there is no step that checks the criteria against each other |
| Security | The existing endpoints beside the new one checked the edit permission but not which sites a user manages; the build closed that gap and proved it with tests | A permission check on the endpoint looks like enough, and nothing prompts a search one layer deeper | Access rules are whatever the generated code happens to include, and nobody who knows the permission model is looking |
| Correctness | Reading the booking path showed that a display threshold would have fed into whether an item could be booked, which could have stopped the last places being sold | The natural implementation reuses the displayed state, the tests agree with it, and the fault appears in production as lost sales | The feature works in the preview, which is the only test, and the fault appears when the last places fail to sell |
| Traceability | Every acceptance criterion in both stories was covered by a named test, and over two thirds of the manual test cases were linked to the automated test that covers them | A pull request and a commit message | No link between requirements and tests, and usually few automated tests to link to |
| Review | An expert engineer reviews every pull request against the architecture before it merges | Depends on the developer’s own discipline | Nobody reads the code closely, because the point of the approach is not to |
Why should you care about the difference?
Each item a preview cannot show has a cost that arrives later, and it usually lands on someone other than the person who built it. In this change, each one maps to something concrete:
- The correctness fix protects revenue. A booking system that cannot sell its last places can lose money for weeks before anyone connects it to a change.
- The scope guard protects the business. Without it, anyone with the edit permission could change records on sites they have nothing to do with.
- The migration mapping protects staff. Without it, most migrated records would have arrived on the default, and staff would have had to redo settings they had already chosen.
- The tests and review protect the next change. Code that follows the system’s patterns, with tests that say what it is meant to do, can be changed safely by the next engineer. Code that only runs cannot.
In a demo, the ten-minute version would most likely have looked the same as ours. The difference would have shown up later, as lost sales, a security incident, or a migration that had to be redone.
Why not just build it yourself?
For some things, you should. If the aim is a prototype, a demo, or a throwaway internal tool that nobody will rely on or maintain, an app builder is a quick and cheap way to learn. We would not argue otherwise.
The line comes when the software starts to carry weight: real users, real money, personal data, other people’s permissions, or a need to keep changing it. From that point the useful question is no longer how quickly the first version appears. It is what it costs when the software is wrong, and who finds out.
The extra rigour is also cheaper than it looks. For this change, AI usage came to about $71 at list prices. The engineer’s attention came to under an hour, Claude worked for about three hours in total, and more than half of the elapsed time was overnight. We estimate the same scope would have taken 42 to 72.5 hours of people’s time by hand. The rigour comes from a harness applying the checks a careful senior engineer would make, on every change.
For teams whose prototype has already reached real users, we offer a vibe coding rescue service.
Where does the rigour come from?
The model can be the same in both approaches. The difference is what surrounds it. On the project we measured, the harness has these parts:
- Project memory and pattern rules: more than 30 rule files that Claude reads before writing each layer of the system, recording the traps the team has been caught by.
- Delivery skills: more than 20 written procedures for planning, building, and QA, each with gates and hard rules.
- Independent review: a separate model reads the full diff against the rules before anything is committed.
- Guard tests: around two dozen test classes that fail the build when a known rule is broken.
- A traceability gate: a story cannot pass while any acceptance criterion has no test that names it.
- People: who answer the questions, review every pull request against the architecture, review the test cases, and sign the work off.
Our harness engineering guide covers how to build one.
How can you tell which one you are buying?
A demo will look much the same either way. These questions tell the approaches apart:
- What does the model read before it writes? Ask to see the rules, and ask when the last one was added and which defect prompted it.
- What fails the build? A harness has checks that refuse to pass, not just checks that report.
- Who reviews the code? Every pull request should get an expert human review, including a check against the architecture.
- How is each acceptance criterion tied to a test? Ask to see it for a recent story.
- What got through recently, and what did you change? A supplier with layered checks will have a specific answer. If the answer is that nothing got through, ask how they would know.
For the wider picture of when AI coding tools suit a job and when they do not, see our decision framework for Copilot, custom AI, and vibe coding tools.