Vibe coding — describing what you want in natural language and letting an AI system produce the implementation — has genuinely changed what a small team can build. We use it every day and it has compressed our delivery times substantially.
It is also, used carelessly, the fastest known method of producing a codebase nobody understands, with no tests, an incoherent data model, and security holes invisible until someone finds them. A growing share of our work is now triage on projects built exactly that way.
This is a practitioner's account of where the acceleration is real, where it is not, and what discipline makes the difference.
What vibe coding actually means
At its simplest: you describe the behaviour you want and an AI system writes the code. In practice, done seriously, it is a workflow rather than a single act — specification, generation, review, hardening and deployment, running four to six times a day per engineer.
The term has acquired a slightly pejorative edge because of the version where nobody reviews anything and the result works until it does not. That version is real and it is what most rescue engagements involve. The disciplined version is a different practice with the same tooling.
What gets faster — and what does not
AI is extremely good at producing a first draft of well-understood things: CRUD interfaces, form validation, API clients, data transformations, test scaffolding, migration scripts, component variants, documentation. In these areas we see genuine three to five times acceleration.
It is much weaker at anything requiring judgement across a whole system: deciding the data model, choosing consistency guarantees, designing an authorisation model, diagnosing why a production issue occurs under load, and deciding what not to build. These remain human work and they are the parts that determine whether a system is any good.
So the shape of a project changes rather than simply compressing. Discovery and architecture take about as long as they always did. Implementation collapses. Review and hardening expand, because reading a large volume of generated code carefully is real effort. Net, a project that took fifteen weeks runs in about six and a half.
| Phase | Traditional | With review discipline | Change |
|---|---|---|---|
| Discovery and architecture | 2 weeks | 2 weeks | Unchanged — judgement work |
| Design system and UI | 3 weeks | 1.5 weeks | Faster: generate variants, curate |
| Feature implementation | 8 weeks | 1.5 weeks | Dramatically faster |
| Review, tests, hardening | 2 weeks | 1.5 weeks | Roughly steady |
| Total | 15 weeks | 6.5 weeks | ~2.3x on the whole project |
The five-step loop we run
Intent: a written specification of the slice in plain language, including states and edge cases, agreed with whoever owns the outcome. Generation: AI produces the implementation against house conventions encoded as rules the model reads. Review: a senior engineer reads every line, specifically hunting the failure modes generated code exhibits. Harden: types tightened, tests written for the paths that matter, accessibility verified, performance measured. Ship: behind a preview, then to production.
Step three is non-negotiable under any deadline pressure, and it is done by someone with enough experience to recognise wrong when it is written confidently. That last quality is the whole thing — generated code is fluent, and fluency is precisely what makes a subtle error hard to spot.
The guardrails that make it safe to keep
Strict TypeScript with no implicit any, so a wrong assumption about a data shape fails at compile time rather than in front of a user. Schema validation at every boundary where data enters the system. Tests covering authentication, authorisation, money handling and any calculation a customer will check. Migrations under version control applied identically in every environment. Dependency scanning, and a policy against pulling in a package to solve a ten-line problem.
And crucially, house conventions in a file the generator reads before writing. That single practice determines whether the codebase reads as one hand or as forty. Without it, every generated file is idiomatic to the model rather than to the project, and the result is technically correct and cognitively exhausting.
In practice
How vibe-coded projects fail
The symptoms are remarkably consistent across the rescue engagements we take on. The application mostly works but nobody can safely change it. There are no tests. The same logic exists in four slightly different forms because it was generated four times. The database grew organically without constraints. Secrets are in the repository. And there is no deployment process — someone runs a command on their laptop.
The specific code-level failures are also consistent: missing authorisation checks on endpoints that look fine, unhandled error paths, plausible but subtly incorrect business logic, N+1 query patterns, and confidently invented library APIs that happen to compile because the call was wrapped in a try block.
Our rescue sequence is fixed. Stabilise — version control, remove secrets, set up environments, add monitoring. Understand — map what exists and document the data model as it actually is. Contain — put tests around behaviour you must not lose. Then refactor incrementally, highest-risk area first.
The half-of-all-prototypes rule
About half of everything explicitly labelled a throwaway prototype ends up in production, because it works and the deadline arrives. If there is any chance of that, the extra week to build it properly is the cheapest insurance available.
What it means for what you pay
If a vendor's delivery got two and a half times faster and their price did not move, you are paying for hours that no longer exist. Clients are right to ask about this directly.
Our position is that the price should reflect the outcome and the accountability rather than the keystrokes. Architecture, review and being answerable when something breaks at 4 PM on a Friday have not become cheaper. Typing has. In practice our comparable-scope projects cost around forty per cent less than they did two years ago, and take under half the time.
What has not changed, and should not, is who is accountable. A named human reviews every line and answers for it. That is the part worth paying for.
Key takeaways
- Acceleration is real for well-understood implementation and roughly nil for system-level judgement.
- A whole project compresses by around 2.3x, not by the 5x the generation step alone suggests.
- The review gate is what separates maintainable output from a codebase nobody can change.
- Encode house conventions in a file the generator reads — it is what makes the codebase read as one hand.
- Never let it design your data model. That decision has the longest half-life in any system.
Frequently asked
Reviewed, tested and typed — yes, and we run it in production for clients handling significant volume. Unreviewed — no, and the risk is not obvious failure but subtle wrongness that looks correct. The recurring problems are missing authorisation checks, unhandled error paths, plausible but incorrect business logic and invented APIs. All are caught in review by someone who knows to look for them.
Yes, if conventions are enforced. We encode house rules that the generator reads, so output matches the project idiom in naming, structure and file layout, and we hand over the conventions file plus a session on the method. Clients routinely take these codebases over — that is the point of doing it this way.
No. We use enterprise tiers with training explicitly disabled, work in your repository under your access controls, and sign an NDA before receiving anything. Where a client requires it — regulated data, defence-adjacent work — we run without AI assistance entirely and price traditionally. We tell you up front which mode a project is in.
Yes, and increasingly that is what clients want. Two days of workshop plus about four weeks of pairing: conventions files, prompt patterns that actually work, the review checklist, guardrail tooling and honest guidance on where not to use it. Teams usually reach a stable, safe rhythm in about six weeks.