Will the Vibe Survive Production?

AI assisted coding has made software development accessible to people who might never previously have attempted to build an application. An idea can become a working prototype in an afternoon, and the distance between describing a feature and seeing it on screen has shortened considerably. I think that is a genuinely positive development. Experimentation should not be reserved for people who already know how to build everything from scratch.

At the same time, I’ve become interested in what happens after the excitement of the first working demonstration. The term vibe coding captures something about the speed and informality of this new approach, but it can also obscure the difference between producing working code and taking responsibility for a working system.

The distance between a prototype and a service

A feature that behaves exactly as expected on a developer’s machine has answered only some of the questions that matter. We still need to know what happens when several people use it simultaneously, when an external service is unavailable, when a dependency changes or when someone attempts to access information they shouldn’t see. We need to understand how failures are detected, who is alerted and whether the system can be recovered without making the problem worse.

None of these concerns is new. Security, monitoring, configuration management and deployment controls exist because teams have spent years learning what can go wrong once software becomes part of everyday operations. AI can accelerate the production of code, but it doesn’t make that accumulated experience irrelevant.

I suspect the more interesting risk isn’t that people will use AI to write poor code. Poor code has always existed. It’s that the apparent ease of generating a solution may encourage confidence before there is enough understanding to justify it. Something that compiles successfully can create the impression that the difficult work is finished, when in reality the difficult work may only just be beginning.

Learning alongside the tools

That doesn’t mean people should stop using these tools until they have mastered software engineering. There is enormous value in building things, discovering limitations and learning through experimentation. What matters is recognising when an experiment is becoming something that other people will depend upon.

At that point, the questions change. Can I explain how this works? Do I understand what data it can access? Have I considered the consequences of a failure? Can somebody else maintain it? If the answer is no, the sensible response isn’t necessarily to abandon the idea, but to involve the expertise and introduce the discipline needed to make it dependable.

For experienced engineers, AI can remove repetitive work and create more space for design and judgement. For people learning to build, it can provide an extraordinary route into practical problem solving. Both benefits are real, provided we don’t confuse the ability to generate an output with the ability to understand and support it.

I’m enthusiastic about the possibilities of AI assisted development. I simply think that the measure of success should extend beyond how quickly we can get something running. The more interesting achievement is building something that continues to work when the novelty has worn off and real people begin relying on it.