Vibe Coding vs Traditional Development

I am not a developer, but for an early sojourn into commercial roles before I found my way into operations and technical roles, I probably would have been. Over the years I've created dozens of hobby projects - even one or two that became something more - but that's about the extent of it.

One of the perhaps unexpected side effects of the public launch and meteoric rise of LLMs has been the birth of "vibe coding". In February 2025, the term captured the imagination after Andrej Karpathy, formerly of OpenAI and Tesla, tweeted about it - sorry Elon, sounds better than “X’d about it”.

In essence, it’s the term for creating code by using natural language to describe what you want and letting Generative AI tools do the heavy lifting for you. This initially happened natively in the chat windows in front of LLMs, but now a whole range of dedicated tools and applications have grown up to fill this space with incredible speed, allowing a more dedicated experience.

Before the "AI revolution", building software meant rolling up your sleeves and getting your hands dirty with code. Developers would follow structured processes, plan out features, write code line by line, and test (and test, and test) until things worked. Part science, part creative - with a little guesswork and a lot of caffeine. It has evolved with new technology, tools, techniques, and roles as an industry, but for the most part, it’s recognisably the same as it was 50+ years ago.

What’s changed? With vibe coding, you no longer need to have spent years learning languages, frameworks, Git, testing, or the curse of the missing closing curly bracket… with a few prompts you can get something generated for you in minutes. Some of the tools can assist in demoing and even deploying it for you - or at least tell you what to do.

No longer do you need to be a developer to bring your website or application to life. You don’t need to know what language you’re using, whether your backend is in React, what version of Postgres (that popular NoSQL database) your data resides in, whether you’re deploying blockchain in Amazon Azure or Google, or if you're using Docker or Visual Basic.

Reduced time, increased democratisation, and - for the most part - low costs of development… it’s possibly the most seismic shift since the explosive growth of the industry following the introduction of personal computing.

So what’s the catch? Well, for a start, if you’re not a technologist and were thinking about building something, you should know most the paragraph before last just caused anyone involved in building or running applications/software to meltdown and breathe into a paper bag - it was nonsensical garbage! Let’s also not forget: AI doesn’t always get things right.

Personally, I think the rise of vibe coding is an incredibly exciting development. I’ve been using it for a variety of things I wouldn’t have attempted previously. I do strongly believe, however, that it should come with a large health warning

At present, the technology that's available has been trained on historical data, documentation, and information. It takes input (prompts) and generates a response - in this case, code. It cannot do the creative or innovation part in isolation - that still needs a human. There are already reports of a lot of similarly “looking” and “feeling” sites and applications coming to market, given that the tools generating them - and much of the training data - are the same.

There are widespread stories of other challenges with vibe-coded applications being in the wild. This isn’t true across the board, but the inconsistency is part of the issue:

• Code quality ranges enormously. Some is surprisingly good, some is surprisingly bad. This can impact all sorts of things: user experience, performance, reliability.
• Security: there are reports across the industry of the introduction of out-of-date libraries, plugins, or techniques - potentially opening security vulnerabilities in these newly built applications and services.
• Consistency: you might expect this wouldn’t be a problem - but especially in larger codebases, maintaining consistency in the code has proven challenging.
• Knowledge: by vibe coding and deploying the code, there isn’t the familiarity with what’s been built that there would ordinarily be. This could lead to future developers having to reverse engineer the code just to understand it.

For those outside of the industry, there’s a term - “technical debt” - which refers to the potential cost in time, effort, or money of fixing technical problems within an application. Tech debt has always existed, and one argument could be that this might help reduce it - which might be valid in some cases, but certainly not all. The difference is that in most cases, tech debt is known about and sits on a backlog somewhere, and the application works in the meantime. The final point above means the vibe-coded tech debt won’t be obvious - and might prove a showstopper when it comes to light.

In the hands of developers and technologists, the mixture of their skills and experience means these tools could deliver a huge productivity boost, allow them to enter new sectors, expand their offerings more quickly, and get ideas to market faster. In the hands of those who aren’t, there’s the potential for significant unintended consequences.

Does that mean they shouldn’t use it? Absolutely not… but understanding the limitations and risks is important. There are plenty of use cases where they’re far less of a problem:

• Internal tools
• Proof of Concepts & MVPs
• Marketing Websites & Brochureware
• Personal Projects & Hobby Apps

It’s very early days, and as the tools and services mature, many of the current challenges will fade - or be mitigated - but not all.

I’d love to hear of your experiences with vibe coding. Have you built something you could only dream about before? And how about my friends and contacts in the development space - are you embracing it or being more cautious?