Vibe coding, with an adult in the room

It helps to be precise about where the acceleration comes from, because the marketing around this is unhelpfully vague. 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 things requiring judgement across a whole system: deciding the data model, choosing consistency guarantees, designing an authorisation model, working out why a production issue is happening under load, or deciding what not to build. These remain human work, and they are the parts that determine whether a system is any good.

The practical consequence is that the shape of a project changes rather than simply compressing. Design and architecture take about as long as they always did — sometimes longer, because we now have capacity to explore more options. Implementation collapses. Review and hardening expand, because reviewing a large volume of generated code carefully is real effort. Net, a project that took sixteen weeks takes about six.

Every slice of work goes through the same five steps, and we do not skip the third under any deadline pressure.

First, intent: a written specification of the slice in plain language, including the states and edge cases, agreed with whoever owns the outcome. Second, generation: AI produces the implementation against our house conventions, which are themselves encoded as rules the model reads. Third, review: a senior engineer reads every line, and specifically hunts for the failure modes generated code exhibits — plausible-looking logic that is subtly wrong, missing authorisation checks, unhandled error paths, N+1 queries, and confidently invented API signatures. Fourth, harden: types tightened, tests written for the paths that matter, accessibility verified, performance measured. Fifth, ship behind a preview and then to production.

The loop typically runs four to six times a day per engineer. What makes it work is that step three is non-negotiable and is done by someone with the experience to know what wrong looks like when it is written confidently.

Speed without structure produces a codebase that resists change. We install the structure first, and it is largely conventional good engineering — it simply matters more when volume is high.

Strict TypeScript with no implicit any, so a wrong assumption fails at compile time rather than in front of a user. Schema validation at every boundary where data enters the system. A test suite covering authentication, authorisation, money handling and any calculation a customer will check. Database migrations under version control and applied identically in every environment. Dependency scanning and a policy against pulling in a package to solve a ten-line problem. And architecture decision records, because in a fast codebase the reason behind a choice is the first thing lost.

We also keep the generated code idiomatic to the project rather than to the model. Our conventions live in a file the AI reads before writing, so what comes back matches the surrounding code in naming, structure and comment density. That single practice is the difference between a codebase that reads as one hand and one that reads as forty.

On the web our method is well-settled: Next.js with server components, a typed API layer, PostgreSQL, and a design system generated as code from tokens. A functioning multi-page application with authentication, an admin area and real data typically exists within eight to ten working days.

On mobile the pattern is similar with React Native and Expo, and the acceleration is comparable — but the review burden is higher because mobile failure modes are harder to observe and store review adds latency to any correction. We compensate with heavier automated testing on the sync and offline paths, and a longer pilot with real users before wide release.

For both, we build the pilot to be the product rather than a throwaway. Prototypes that are explicitly disposable get shipped to production anyway roughly half the time — so we simply build to production standard from the start and accept a slightly slower first week.

A growing share of our work is triage on projects built this way without a review gate. The symptoms are consistent: the application mostly works but nobody can safely change it, there are no tests, the same logic exists in four slightly different forms, the database has grown organically without constraints, and secrets are in the repository.

Our rescue runs in a fixed order. Stabilise: get it into version control properly, remove secrets, set up environments, add monitoring so you know when it breaks. Understand: map what exists and write down the data model as it actually is, not as intended. Contain: put tests around the behaviour you must not lose. Then refactor incrementally, highest-risk area first, with the tests as the safety net.

It is usually cheaper than a rewrite and always less disruptive, because the business keeps running on the thing while it is being repaired.

We do not use AI-generated code without full review in systems handling payments, personal health information, or safety-related plant control. Not because the code is necessarily worse, but because the failure cost is asymmetric and the review effort is trivial by comparison.

We also do not let it design your data model. The schema is the single decision with the longest half-life in any system — you will change your framework twice before you change your core tables — and it deserves a human who has lived with the consequences of getting it wrong.