"We can vibe code it!" — a sentence that struck fear in our Technology Officer's eyes while planning one of our more complicated Zoho projects. Let's just say he was not entirely "vibing" with the idea. As a result of that discussion, we decided to share some of our insights about the subject and hopefully paint a clearer picture of how vibe coding, while powerful in the right hands, proves to be dangerous when wielded irresponsibly — and what to do about it!
So Anyway What is Vibe Coding?
Around February 2025, OpenAI co-founder and former Tesla AI Director Andrej Karpathy posted on X about his fun vibe coding weekends.
So it's a brand-new and shiny coding paradigm, based on "reasoning" Large Language Models like GPT 4o and Claude Sonnet. The models are given access to your codebase, your requirements, sometimes a search engine, and rules to follow while they're hard at work building your Next Big Idea.
In summary: "Tell the machine what to do and see what happens."
Usefulness (The Good Vibes)
In the hands of a seasoned software engineer, vibe coding makes sense. You're making architectural, high-level decisions on how the code should behave, while outsourcing the more boring, repetitive stuff to the talking machine (like reading a file).
As we can see it, here are the big wins of vibe coding.
Speed of delivery. In mere minutes you can have a working prototype. You can conjure up a Deluge script or REST integration in minutes instead of days — perfect for impressing your stakeholders before they change their minds. Fast prototyping can save up millions of dollars in avoiding bad projects.
Democratization of development. Non-engineers can riff out simple apps and automations by typing in plain English — perfect for your marketing intern to put in a Zoho CRM trigger that may or may not create duplicate leads every day.
Thinking assistant. Ask your AI for advice about how to build something, how to test a feature, or how to write a blog post *cough*. Sometimes thinking while talking to someone helps clear up what needs to be done and how, even if it's a machine you're talking to.
A chance for a unified coding standard. Vibe coding lets you give the AI a set of rules when writing code. Companies integrating vibes into their workflow have the opportunity to set up and share rule files for the different parts of their tech stack (front-end, back-end, testing, infrastructure, etc).
Dangers (The Bad Vibes)
Big projects have large codebases: a complicated architecture of systems and failsafes that are supposed to work together to keep services at the very least running and secure. They are maintained by seasoned veterans who know the ins-and-outs of many parts of a project. Because of the inherent limitations of current Large Language Models, entirely vibe coding the New Twitter won't cut it.
Here are some critical pitfalls to keep an eye on when vibe coding:
Subtle code degradation over time. Repeatedly re-prompting for tweaks can cause the model's understanding of the system, and thus output, to "drift", burying unsuspecting edge-cases or logic errors deep in your codebase.
Getting comfortable with a lack of understanding. Getting a correct answer once lulls teams into skipping full comprehension of the code. When those tests start failing — or production crashes — nobody knows why. If you're lucky, you may revert and rewrite some features, but do that many times, and you will understand the true pain of "spaghetti code."
A ticking time-bomb of technical debt. What seemed like a 1-hour vibe session on Friday can turn into a weekend-long debugging marathon. Time to go through the 5 stages of grief with: phantom API mismatches, race conditions, some tool-specific behavior that's poorly documented, and anything that can't be traced to a single line of code.
Security? What security? AI is notorious for not inferring security requirements for the software they are building. One false move and a couple of security vulnerabilities can leave you wishing you hired an actual developer (horrible, we know).
A lack of cost awareness. Today's SaaS businesses operate in "the Cloud" or some version of a data center. Beware the AI that would have your endpoint deployed as a Cloud Function, when it's supposed to be called thousands of times a day. Always double-check the expected cost for resourcing your deployments.
Data privacy on remote AI. If your AI is not running locally, then everything it "sees" is potentially compromised information (local files, codebase, search history, and more). If you happen to work in a high-secrecy industry — then vibe coding with good ol' Claude is a no-no.
Modern Problems Require Modern Solutions
Not everything easy is bad, and not everything bad is easy. Just like training interns who've never used git, so can we vibe code responsibly.
Here at Svennis we've arrived at a few rules to follow when vibe coding.
It's your code, not the machine's. Ownership and accountability over the behavior of the software is the developer's. If the AI stores or pushes passwords in plain-text, it's not the AI's fault (it's yours).
You are the expert, not the machine. This one is simple: do not purposefully make yourself replaceable by a machine. You are supposed to be (or become) the expert in the product you are building. You make the final decision over whether the machine's output is good enough to merge with the codebase, so you're responsible for knowing whether it's actually good or not (and why!).
Lock down your schemas. Have examples of your input/output contracts in JSON before you prompt. Schema clarity and stability helps reduce the AI "drift".
Micro-prompting. Break features into granular prompts. Require the code to be broken-down into small logical and well-named functions. Smaller context windows produce more predictable results.
Test-driven vibes. Just like test-driven development, write a couple of sanity-check tests before asking the AI to generate the solution. An understanding of the required behavior as test cases will stabilize the AI's results — and keep them in check in the long-run.
Of course, version your code. We are aware that many non-engineers will vibe code to get their ideas going, without waiting for a developer to answer their phone call at 3am. We think that is fine, just be aware that if your code is not properly versioned in a tool like Github, then once your project breaks you may have a bigger problem on your hands than you asked for.
If the project gets big, talk to your local developer. Again, if non-engineers are working on a large project that may end up impacting customers, that requires some thinking about things like "how to deploy", "how to test", "how to monitor" etc. So please reach out to your local software developer to ask for help on you know... the boring stuff that engineers do.
It's Here to Stay
We see vibe coding as a new tool in our toolbox as developers, one we can get really good at using. In the long run, vibe coding is here to stay, but we do not think AI will replace any good software developer anytime soon. If anything, we think it will create a long list of problems for teams who use it irresponsibly, without the guidance of an experienced engineer.
We hope you find this helpful. We've debated a fair bit to get to where we're comfortable with vibe coding at Svennis, and we'd like to know how you do it at your company. Additionally, if you disagree with anything in this post, or think we've missed something crucial, let us know on social media.