You Vibe It You Run It?

Though the term “Vibe Coding” is barely half a year old, it has already escaped the tech memesphere and entered common language. Everyone, it seems, is now a developer, requiring little more than a prompt and a prayer.

If you’ve astonishingly managed to avoid the concept over the last 6 months, Vibe Coding is the practice of writing software by prompting an LLM. More than AI-assisted coding, Vibe Coding eschews the requirement for programming expertise entirely.

The ‘Viber’ communicates their requirements via natural language conversation with an AI assistant (ChatGPT, Claude, etc), and the LLM generates the code. Andrej Karpathy, who coined the term, described it (tongue in cheek) as “see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.”

Let’s gloss over the word “mostly” for a moment and reflect on the lived experience of Vibe Coding (yeah, we all know you’ve done it too). For me, a developer with over 30 years of experience, the experience is astonishing and perturbing in equal measure. The ability to create working software - of significant complexity - by nattering to a chatbot, without having to write a single line of code, is insanely impressive and intoxicating. The speed of progress since the widespread emergence of LLMs has been breathtaking, leading many commentators, investors and businesses to speculate that the days of the highly skilled coder are behind us, and seasoned developers and students second-guessing their futures.

However, beyond the remarkable first impressions and the hungry salivations of the VCs, software practitioners are more sceptical that the emergence of Vibe Coding is altogether positive. This is understandable given the existential threat posed to their livelihoods if the most extreme loonshots are credible.

But beyond this, there are some very good reasons why anyone with more than a layperson’s understanding of the nature of software might be bearish about the prospect of widespread Vibe Coding contributing to the greater good.

Despite the wow-factor, practitioners know that the speed with which code can be written is rarely the bottleneck in software development, and the main challenges lie beyond expertise in syntax: intra and inter-team communication and coordination, architecture, testability, extensibility, security, maintainability and continuous delivery, to name just a few. If speed were the only problem, we could happily take the win of faster coding and focus our efforts elsewhere. But Vibe Coding introduces real risks, particularly around resilience, that are worth examining before we place too much faith in it.

Just a Higher Level of Abstraction?

One of the common observations about Vibe Coding is that it is just “another higher level of abstraction”. The history of computer programming is the unfolding of ever higher levels of abstraction. From its impenetrable genesis in machine code, through:

• assembly,
• procedural,
• functional
• object-oriented,
• declarative,
• DSLs
• low-code/no-code,

… each evolution in abstraction has gained productivity, convenience, expressiveness and safety, while trading off fine-grained control, precision and sometimes performance.

Vibe Coding is the latest evolutionary step up the abstraction mountain, allowing code to be generated from natural conversational language rather than programming syntax. So far, so good.

However, Vibe Coding’s vertical leap in abstraction also comes with a sideways stumble into non-determinism. While consistent source code in virtually all languages at all levels of abstraction comes with reasonable guarantees of consistent outputs, LLM prompts offer no such thing. Conversational language lacks the precision to describe consistent code, and so Vibe Coded code is non-deterministic between prompt runs, even before we consider differences between LLM implementation versions or foundational models.

Worse, typical Vibe Coding practice discards the prompt that generated the code, whereas the generated code itself is committed to version control, just as in standard development. This may sound sensible, but it’s analogous to a pre-vibe-coding developer throwing away their source code and committing compiled binaries to version control!

Even if the prompt was version-controlled as well, there is no guarantee that two subsequent executions of the same prompt will create identical output. While Vibe Coding can absolutely create impressive working software, it lacks the determinism, precision and communicability to be practical beyond impressive prototypes or small-scale projects.

It’s analogous to a developer throwing away their source code and committing compiled binaries to version control!

Vibe Coding is not just a higher level of abstraction; it’s something entirely new, and new systems come with new problems.

Vibe Coding is a Competitive Cognitive Artefact

Vibe Coding is, of course, just another tool to be deployed in the pursuit of solutions to problems. Evolutionary and Complexity Scientist David Krakauer categorises tools into 2 types: Complementary Artefacts and Competitive Artefacts. The best way of describing the difference is by example:

A map is an example of a Complementary Cognitive Artefact. It is complementary because it not only serves as a tool to navigate from A to B, but it also enhances the user’s own mental model of the route and terrain upon which they’re travelling. The map is an accurate model of reality at a convenient level of fidelity that remains in the cognition of the diligent user after it’s no longer physically in view.

Satellite Navigation, on the other hand, is an example of a Competitive Cognitive Artefact. It is competitive because it although it does a (mostly) marvellous job of getting us from A to B with less effort required than the map reader, it does nothing to build our mental model of the route or terrain on which we’re travelling. If you’ve ever found yourself lost without sat-nav while navigating a route that you’ve previously done many times before with sat-nav, you get the picture.

Vibe Coding, like sat-nav, is a competitive cognitive artefact, because while it offers a highly convenient method of navigating from point A (a software idea) to point B (software that runs), it offers nothing to the user that supports the development of a mental model of how the code that it creates actually works. This would be fine if software worked the first time and never needed to change…

Ultimately, competitive Cognitive Artefacts aren’t innately bad or good. That judgement is one to be made by the user who needs to consider whether the advantages are worth the trade-offs. Most surely consider the cognitive tradeoffs associated with sat-nav to be worthwhile. Do you feel similarly about Vibe Coding?

Vibe Coding Begets More Vibe Coding

Like many competitive cognitive artefacts, Vibe Coding not only does nothing to support the development of mental models, it passively contributes to their atrophy. As Principia Mathematica author Alfred North Whitehead said, “Knowledge does not keep any better than fish”, so you might expect that over a depressingly short time period, unused knowledge starts to stink.

Faced with the hard work of freshening up increasingly fishy skills, many will choose the easier path of relying more and more on the quick fix of Vibe Coding, which rolls the snowball of prompt-driven development, while valuable mental models so critical to the development and maintenance of reliable software erode away. Before long, the fun and games of Vibe Coding proliferate into vibe debugging, vibe diagnosing, vibe intervening, and vibe incident responding.

This itself would be no great tragedy if it worked 100% effectively, 100% of the time. But given the relative (un)reliability of LLM outputs compared to already unreliable software created with deterministic non-vibe methods, it's brave to put all one’s chips on a fully automated software lifecycle any time soon.

I previously described the experience of Vibe Coding as being intoxicating. This word is appropriate as the tendency of any artefact to require more and more of itself over time to maintain proper functionality is the hallmark of addiction, which (it goes without saying) tends to go badly. This pattern is a well-known systems archetype known as “Shifting the burden to the intervenor”, and it’s worth considering how one plans to counteract this tendency should Vibe Coding find utility beyond small projects and prototypes.

You Prompt It, You Run It?

“You build it, you run it” is a powerful practice familiar to most SREs and DevOps practitioners. Given what we’ve explored so far, the obvious question is, what does “you build it, you run it” even mean when the building was done by an LLM rather than anyone even remotely associated with your organisation?

The challenges of updating, deploying, securing, monitoring, patching, maintaining, testing, releasing, debugging and resolving incidents are already significant when the people doing those jobs (or those within the same organisation) have taken an active part in the system's development and have well-maintained mental models concerning its functionality. These jobs can only become harder when the folks responsible for them have played no part in their development and have increasingly few opportunities to exercise the muscles required to write code at all.

Have we Peaked?

Despite the hurricane of hype surrounding Vibe Coding in its first six months, and its obvious promise and power, there are signs that the peak of inflated expectations has been scaled, and we’re tipping over towards the trough of disillusionment. Examples of early (mis)adventures are being reported, and there is a healthy scepticism, at least amongst practitioners, as the lived experience of Vibe Coded software compares and contrasts with the hope and the hype.

We’ve also seen a less-than-euphoric reception to the recent release of GPT5.0, and Microsoft Azure CTO Mark Russinovich has recently cautioned that Vibe Coding tools aren’t capable of replacing human programmers for complex software projects.

In practice, I believe Vibe Coding has a compelling role to play as a tool for prototyping, allowing organisations to get fast user feedback with genuine working software early. If Vibe Coding is only ever used for this purpose, its value is immense, and we don’t (in my opinion) need to push it further towards production to benefit hugely.

At Uptime Labs, we’re massively interested in hearing how you’re facing the challenges and opportunities afforded by our increasingly AI-assisted reality, particularly how you’re approaching resilience and reliability.

So, what might “your build it, you run it” look like in your hypothetical AI-assisted future?

Further Reading

No article on automation would be complete without referencing Lisanne Bainbridge's “Ironies of Automation”. It’s a continual source of amazement how prescient this paper is to the challenges of today, despite being written in 1983.