AI and vibe coding: what of it survives production

We use AI daily. That is not a confession, it is the reason we can say fairly precisely where it does not hold.

Five claims

“AI replaces developers”

What it replaces is the typing. What it does not replace is accountability. The person who decides the architecture, approves the code and carries the pager at night is a human. A model cannot be held liable.

“We don't need juniors any more”

Seniors come from juniors. Skip training them today and you buy the same experience back off the market in five years, more expensively and from a thinner supply. That is not sentiment, it is capacity planning.

“Vibe coding is production-ready”

For a prototype it is excellent, and that is exactly how we use it. For the code settling your payments at three in the morning, the question is not whether it runs but whether anyone can explain why it stopped. Generated code nobody has read is unreadable code with an extra step.

“We'll do everything with AI”

Then you own a dependency on a vendor whose prices, model versions and availability you do not control. Models get deprecated, prices change, and the same request returns a different answer after a version bump. That is an architecture decision and deserves to be made as one.

“AI saves money immediately”

It moves money: away from writing, towards reviewing. Whether that is cheaper depends on how often a result holds on the first attempt. And almost nobody counts that.

Where we actually use it

Prototyping

First version in hours instead of days. The model writes the boilerplate, we decide the architecture. Built to be thrown away, and then actually thrown away.

Test generation

Test suites from existing code. We check whether they cover the right cases, not whether they are green. Green tests that assert nothing are worse than none.

Data preparation

Unstructured input into usable formats. The invisible work that used to take days and now takes minutes.

Where we do not use it: migrations on systems that move money, unless a human has read every changed line. Not on principle, but because the mistake there only surfaces at reconciliation, and by then it is no longer cheap.

The most expensive item is not on the invoice

A development team's token cost is rarely the problem. The pain starts with the rework: the draft that only holds on the third attempt, the review that takes longer than writing it would have, the defect that surfaces in production because nobody read the generated line.

None of that appears on a bill, because it accrues in person-days rather than tokens. If you want to know whether AI pays off in your own building, you have to count both sides: what a call costs, and how often a result holds first time.

Our principle

For every project we decide again where it helps, where it is a risk and where it is simply unnecessary. No model makes that call. We do, and we say it out loud even when the answer is no.