3 Prompts to Immediately Improve Your Vibe Coding

If you’re using Replit or Lovable to build software, you’ve probably been blown away at how well it can build a real web app in minutes for you. At Sourcetoad, we both use these tools to rapidly prototype new projects, and we also review a lot of code that’s been generated from these platforms as clients come to us asking to help get these apps into production.

As we’ve reviewed the code that’s generated, we’ve noticed some things that could be done…better, from small annoyances in the codebase to major security problems that should never make it onto the public internet.

Here are three prompts that will immediately improve the quality of the code you’re writing with these tools, and make it easier to eventually get it off those platforms and into production:

Replit and Lovable tend to overlook some major security best practices at times, which can leave your code very vulnerable to being attacked. Help beef up your security by asking the agent this:

I want you to act like an expert security researcher and developer, who specializes in ensuring that web apps are secure at scale, and don't have any potential threat vectors exposed to the public. I want you to evaluate the codebase and find any security issues that may be present in the code and fix them. Some of the things you should be looking for: - Plaintext passwords or transmission of passwords in an insecure way - SQL injection opportunities (non-parameterized queries, etc) - Hardcoded secrets, keys or access tokens I want you to methodically work through every file in the app (except dependencies) to identify these potential threats, make a list of them, and then start to work on fixing them. Ensure that you have fully completed fixing every item on the list before you consider the task complete. 

When developers write code, they want that code to conform to a single, familiar style. That involves how the code is actually written. For example, some developers like to write a function like this:

function () {
  // function body here
}

And some like to write them like this:

function()
{
  // function body here
}

The only difference here is a line break before the opening brace. It’s a small thing, but it can have big impacts on how easy it is for human developers to read and understand the code.

You might be thinking – human developers? Why would I need that? Think of this as a small insurance policy. You might be right, and never need a human to look at your code. But, in the event that you do (which is way more likely than you think), this is a 30 second investment to save you hours or days of code review and cleanup later.

When you are writing code, you MUST always follow the AirBnB style guide for code formatting and linting purposes. Never deviate from this style unless working in a language that it doesn't apply to. This should be used 100% of the time for JavaScript files.

I’d recommend dropping this into your AGENTS.md file in the root of your project, which will mean your agent will follow these instructions every time, and you won’t have to keep copying and pasting that into the prompt. We wrote up a guide on how to do that here.

(Why AirBnb? They happen to have published the most widely used coding styleguide in use today, so aligning with that increases your chances other devs will be able to easily read your code.)

When you write code, sometimes you need to use the same piece of information over and over again. One example is ports, which simply tell a computer where to find your particular app running on a server (ELI5 – it’s more complicated than that, but that’s all you need to know).

Apps use things like this all the time. A simple port like mentioned above, which is usually a 4 digit number like 3000, might be used 10-30 times across a codebase. If you type it in the code each time (“hardcode” it), and you need to change it later, you have to hunt down every place you used it. It’s a pain, and causes your software to be much less predictable and stable.

Platforms like Replit and Lovable are notorious for hardcoding values like this. Adding this prompt to your AGENTS.md, and even running it once on an existing codebase, can help to clean all this up: 

Ensure that *reused* values like ports, URLs, paths, etc are stored as environment variables or use another global approach (if used across multiple files), so that they follow a reusable pattern and can be changed in a single location easily in the future.

Dropping these prompts into your new or existing projects in Replit and Lovable (or any other vibe coding platform) will immediately help make your code more professional, more stable and more performant.