Is vibe-coding safe?

Vibe-coding, using AI coding assistant to write code, is all the rage. But is it safe?

I have reviewed a number of applications for clients and here is what I found out.

Here are some of the top risks of vibe coding, and some recommendations. I’ll split the recommendations in two:

• if you can’t code at all → 🤖
• If you can code → 🧑‍💻

Here we go, in no particular order. I’ll call “assistant” any coding assistants such as models used in Windsurf and Cursor, no code solutions like Lovable and Bolt, etc.

Third-party components are outdated/unsupported

Models are trained on old code and use the old versions they have seen used.

✅ Recommendations

• 🤖 Ask your assistant to use up-to-date versions of 3rd party components (although I have not been very successful with that)
• 🧑‍💻 Review your package.json / equivalent and ensure you are using recent / safe versions (e.g., npm audit)
• 🧑‍💻 Ensure the packages you are using are supported and trustworthy (Who is using it? Is it actively maintained? Do they have good security practices? etc.)

Poorly written code

Assistants can solve problems a million ways (literally), and they are not always consistent. This makes your code more and more complicated. Why bother reusing code when it’s so easy to write. The problem is that it eventually leads to code that’s really difficult to maintain, even for assistants.

✅ Recommendations

• 🤖 Instruct your assistant to follow good and consistent coding practices, such as SOLID, DRY, KISS, etc.
• 🤖 Give your assistant specific coding guidelines or patterns you want them to follow
• 🧑‍💻 Review proposed changes, and ask your assistant to refactor if this doesn’t meet your standards

Remove tests so they pass

This happened to me several times. You have good tests in place (linting, unit tests, end-to-end tests) and the assistant decides removing a test was easier than trying to pass it.

✅ Recommendations

• 🤖 Ask your assistant not to remove/modify tests
• 🧑‍💻 Review all changes

Poor type checking

Most web projects these days use Typescript instead of just Javascript. This can greatly help assistants avoid mistakes but they also forces them not to take shortcuts.

✅ Recommendations

• 🤖 Instruct your assistant not to use “any”, but “unknown” if they can’t know what the type should be (humans should do that too, by the way)
• 🧑‍💻 Enforce the above using linting rules

Poor input/output validation

Who cares, what can go wrong?

✅ Recommendations

• 🤖 Instruct your assistant to verify the data as it comes in and out, defining what “good” is
• 🧑‍💻 Use libraries like Zod or other 3rd party tools to verify what comes in and out looks like what is expected

Loss of understanding of your codebase

Assistants can write a lot of code and there is a chance you don’t understand it all, then less and less. This is really risky when it comes to fixing bugs or problems the assistant can’t fix for you.

✅ Recommendations

• 🧑‍💻 Make sure you stay in control of your code and understand it

Short-sighted architecture

Models have the big picture, they don’t always know where the code is going to run, etc. This can lead to code that doesn’t scale well, isn’t secure, or is difficult to maintain.

✅ Recommendations

• 🤖 Understand the limits: Vibe-coding it fantastic for a simple website or a throwaway PoC, but it’s not yet ready for a production-ready application (if you are serious about your user’s data)
• 🧑‍💻 Review all changes

Private API keys used in the wild

Models don’t always understand what are public keys and what are private keys. You don’t want your private keys used on the client side. And you don’t want them to train the next model either (see Loss of IP below).

✅ Recommendations

• 🧑‍💻 Review all changes

Loss of intellectual property

“When it’s free, you are the product”. This still holds true here. Most free models give themselves permission to appropriate your code for a various range of use: Train models, demo, etc.

✅ Recommendations

• 🧑‍💻 Ensure the licenses associated with your assistant meet your IP/Privacy requirements