Vibe coding helps ideas come alive quickly. But turning prototypes into production takes architectural vision and expert hands.
AI has opened the door to a new way of writing software: vibe coding. Instead of staring at a blank editor, you describe what you want, and an AI like ChatGPT, Cursor and Claude will generate working code in seconds.
It feels like magic, and for early prototypes, it can be. You can go from “what if” to “working demo” faster than ever before, and we’d be lying if we didn’t see the advantages of this when clients need to see a quick prototype of their vision. Indeed, we’re even being brought on to bring client-created vibe coded ideas into real, functioning apps.
If you believe the LinkedIn hype, this could be the end of coding as we know it, and our industry is about to inexorably change in favour of LLM-generated code, taking humans out of the mix at various points. This hyperbole is designed to incite emotion and make headlines – but is it anywhere near the truth?
Not quite. Or not yet, anyway.
Good vibes: The appeal of vibe coding
The upside of quickly generated code is obvious. Vibe coding makes it easier to experiment, allowing you to get ideas out of your head and into a demo you can click around within hours. It can speed up hackathons and early-stage projects, and even seasoned developers admit it feels like having ten interns on speed dial, happily churning through code. Tools such as ChatGPT and Claude offer real benefits when building simple features, or when working through repetitive code.
So far, so good. But…
Bad vibes: The hidden costs of AI generated code
Those shortcuts come with hidden costs, and we aren’t declaring the death of the programmer just yet.
For every line an AI helps write, there are lines that need to be written (or fixed!) by a human. Many engineers admit they spend more time fixing vibe code than writing it in the first place – think hallucinated package names, insecure defaults, or whole chunks of unnecessary script, which means more places for things to potentially go wrong!
One tech lead within Elemental Concept likened AI output to a sentence constructed by mixing slang from the 60s, 80s and 90s – the words might make sense on their own, and you can get the gist of it, but something’s inherently not quite right with the overall direction of the phrase. Thus enters the need for experienced coders to make it make sense so that it can be fully functional in the real world.
It’s also all too easy to get carried away with the excitement of creating a piece of software, but we should never forget that a lot of time goes into maintaining that software, beyond the initial build – somebody needs to be able to spot errors in existing code and fix them.
Knowing not just how to prompt, but when to prompt.
LLMs are great at remixing patterns they’ve seen before, but they can stumble on genuinely novel algorithms, which means there’s as much need for engineers to problem solve, design and create as before. Adding to this, with each prompt, without careful oversight, comes degradation of other areas of the product, as the AI can sometimes rewrite areas of code you intended to leave as they were. When it comes to fine tuning, we’ve found it’s often best to tackle that the old-fashioned way – by editing it yourself.
Vibe coding and legacy technology
When it comes to legacy technology and systems, the need for human engagement is clear.
AI models work best with modern, well-documented languages, frameworks, and patterns, so when you throw them into 20-year-old system or a heavily customised enterprise stack, they can struggle. Just think – hallucinating libraries, generating code that won’t compile, or missing the context of decades of bespoke patches; all these things can bring down the critical infrastructure of fragile legacy systems. This is especially true if the legacy code detours from the standards of the time, or from the training examples the LLM can find online.
But that’s not to say there isn’t an opportunity for AI in the legacy world, and there’s potential for vibe-coding to come into play. The key thing is people. You need expert hands that can ensure the AI output plays nicely with complicated systems. Professionals with domain expertise are essential here, as they know the quirks, the history, and the hidden dependencies that no LLM could guess.
A security sore spot
Security can sometimes be another sore spot. With the right safeguards, can accelerate delivery without compromising security, but without careful oversight, LLMs may skip input validation, pull in outdated libraries or happily delete things that should never be touched, creating a buggier and riskier product than a human team would build from scratch. As a business that prides itself on creating secure, high-quality products for clients, we believe cyber security should not take a back seat to quick delivery, prioritising delivering the right thing, not just the quick thing.
Great for senior engineers, but a potential stumbling block for juniors.
Then there’s the human side – you know, the people actually doing the coding in real life.
Reviewing AI code is a little bit like reviewing junior code: it only works if you already know enough to be aware of what you’re looking for. This means it might speed up development time for more senior engineers, but for juniors who are eager to get ahead, they must dedicate the time to truly learning and knowing their code languages for AI and vibe coding to genuinely be useful.
Developers love solving programs, and some say vibe-coding can be joyless, watching an AI solve problems that may have once given people a much-needed dopamine shot when they worked it out on their own. If all you do is copy-paste, you aren’t learning, and let’s be honest- that’s not fun. Not does it help you in a real-life conversation when you’re not in front of a computer screen and asked to explain the technical points of something you’ve created!
It’s a nuanced point. As a business, it’s important that we get the mix right; we need our team to deliver for our clients in an efficient and effective way, but we want them to enjoy the process, because curiosity and learning can lead to brilliant, unexpected results. Vibe-coding should be part of that, but we would never want it to take away from our abilities to solve problems for our clients; rather, it should help with the process.
The changing role of the engineer
Still, vibe coding isn’t going away. It just changes the job. Writing lines of code won’t be what engineers are focused on; instead, it becomes about the architectural vision. Thorough and diligent technical work won’t be replaced, but engineers will need to focus on designing brilliant systems and working out how the pieces fit together. Assessing the flaws and weak points and working to secure them. In other words: less typing, more thinking
This leads not only to a shift forward in engineering roles but gives revitalised approach towards roles that are less prominent in modern agile environments. Business Analysts, whose focus on building out requirements documents pre-Agile workflows, comes back into play under a new job title – as a developer prompt engineer – and requirements documents become prompt logs, keeping tabs on what was prompted to produce a particular output.
In conclusion
Vibe coding is brilliant for senior developers, experiments and prototypes, but it’s not production-ready on its own. Without expert oversight, you risk ending up with something insecure, unscalable and hard to maintain. But with expert oversight? It can be a powerful accelerator.
Our approach has always been about taking the time to do it the right way, not just the fastest way; AI won’t change that philosophy, even if it changes some of the technology.
