Everyone is talking about vibe coding. The layer nobody mentions is vibe engineering, and it is where the actual work lives.
Vibe coding is real, and often good enough
Vibe coding is when you prompt Claude or Copilot, get code back that works, and that is it, job done. It is fast, it is impressive, and for a lot of use cases it is genuinely good enough.
But when we build AI systems for clients, “good enough” is not the brief. The brief is: will this still work in six months? Can their team maintain it? Does it run on infrastructure they control? What happens when the input data is messy, which it always is? Is it administrable? Is it secure? Can it be upgraded?
The 90% that has nothing to do with the model
None of those questions are about which model you pick. They are about properly decomposing the problem, choosing the right architecture, and writing test cases that reflect how real users actually behave, not how you hope they will. And it helps enormously to have been the user before, to have sat in the chair your client sits in.
They call it “Claude Mania” now. I use Claude every day, and it is exceptional. But the model is only the last 10%. The first 90% is still engineering, the same discipline behind decomposing a support process into ninety steps and using AI at only six of them. Tools change. The engineering does not.
Is your organisation vibe coding, or vibe engineering?