What vibe coding actually means for UK teams.

01

The term is doing two jobs at once.

When the phrase first spread, it described something quite specific: building conversationally with an AI model, staying in flow, describing intent rather than typing every line. That is a genuine shift in how software gets made.

It has since picked up a second, less flattering meaning — shipping whatever the model produced without reading it. Both meanings are now in circulation, often in the same meeting, which is why buyers are understandably wary when an agency uses the words.

We use the first meaning and we are strict about the second. The platforms set the pace; engineers still decide what is true.

02

Where the acceleration is real.

AI tooling earns its keep on work that is well understood and tedious to type. In those areas the productivity difference is not marginal, it is the difference between a fortnight and an afternoon.

• Scaffolding predictable surfaces — forms, tables, admin screens, standard CRUD
• Turning an agreed design into component markup and styles
• Test fixtures, seed data and the unglamorous plumbing around a feature
• Mechanical refactors where the target shape is already decided
• Reading unfamiliar code and explaining what it appears to do

03

Where it is not.

The acceleration collapses wherever a decision has consequences that stay quiet for months. A model will answer confidently regardless, which is precisely the problem — you get a plausible answer with no signal about how much it should be trusted.

• Data modelling and anything that becomes a migration later
• Authorisation and access paths — who can see and change what
• Money: payments, invoicing, tax, anything reconciled by a human afterwards
• Integrations with systems you cannot easily test against
• Performance characteristics under real data volumes

04

The review bar.

Our rule is simple to state and slightly awkward to live with: every meaningful change is read by someone who could have written it. Not skimmed, not summarised by another model — read.

That review looks at application logic, the shape of the data, and how access is enforced. AI review tools run alongside it and are genuinely useful for catching the obvious. They do not get the final say, because a tool that produced the code is poorly placed to certify it.

The practical effect is that velocity comes from the tooling and confidence comes from people. Mixing those two up is how teams end up with a demo that impresses and a codebase nobody wants to touch.

05

What to ask a supplier.

If you are buying work that will be AI-accelerated — and increasingly you are, whether or not it is disclosed — these questions separate a method from a marketing line.

• Who reads the code before it merges, and can they explain it without the tool open?
• What happens to a change the reviewer disagrees with?
• Who designed the database schema, and when?
• What are we handed at the end, beyond a running site?
• If you disappeared, could our next developer pick this up?