Vibe coding is building software by describing what you want to an AI coding assistant and accepting what it writes, often without reading the code closely. The term was coined by Andrej Karpathy in a post on X in February 2025.

Is vibe coding safe for a small business?

It is safe for prototypes and internal throwaway tools where a mistake costs little. For anything that touches payments, customer data, live stock or messages to customers, add guard rails: small steps, pull requests, no secrets in code, evidence of testing and a person approving deploys.

Do I need version control if I'm the only person coding?

Yes. Git gives you an undo button for the whole project, and opening a pull request for each change gives you a moment to read the diff before it becomes real. It also leaves a history you can follow when something breaks later.

How do I stop an AI assistant leaking API keys?

Keep keys in environment variables or your hosting platform's secret manager, never in source files or chat prompts, and add files such as .env to your ignore list before the first commit. Run a secret scanner such as gitleaks, and rotate any key that does leak, because deleting the commit does not remove it from history.

How do I make an AI coding assistant follow my rules every time?

Write the rules in a file the assistant reads at the start of every session, such as CLAUDE.md for Claude Code or AGENTS.md for tools that support it. Include your stack, style, approval rules and past mistakes, and add a line whenever the assistant repeats an error.

Vibe coding best practices: get the speed without the risky shipping

Vibe coding works for a small business when you treat the AI as a fast, keen junior who never gets the keys. Plan before you prompt, work in small steps, keep everything in version control, keep secrets out of code and prompts, insist on evidence rather than a cheerful "tested", and keep a human approving anything that touches money, customer data or live stock. Do that and you keep most of the speed without shipping things you can't trust.

What vibe coding actually is

The term was coined by Andrej Karpathy in a post on X in February 2025. He described a way of building where you say what you want, accept what the AI writes, paste errors back in when things break and largely stop reading the code. For a weekend experiment, that is a perfectly reasonable way to work.

For a business, the interesting part is who can now build. The person who knows exactly how quoting, picking or reordering should work is often the owner or the operations lead, not a developer. AI coding assistants let that person turn their knowledge into a working tool. The catch is the "stop reading" part. An assistant sounds equally confident when it is right and when it is wrong, and a tool your team relies on every morning deserves more than vibes.

When it's fine, and when it isn't

Vibe coding is fine for:

Prototypes and mock-ups you will throw away or rebuild properly.
Internal, throwaway tools: a script to tidy a spreadsheet you will check by eye, a one-off report, a quick calculator.
Learning how something works before you commit to it.

It needs guard rails for anything that:

Touches money: payments, refunds, invoices, prices, discounts.
Reads or stores customer personal data.
Changes live stock levels or orders.
Sends messages to customers or suppliers.
Other people depend on day to day.

A useful test: if this is quietly wrong for a week, who notices, and what does it cost? If the honest answer is "nobody, nothing", carry on. If the answer involves a customer, a supplier or your accountant, slow down and use the rest of this list.

Plan before you prompt

Before the assistant writes a line, write a short plan in plain words: the problem, who uses the tool, what data it reads, what it writes, what "done" looks like and what it must never do. Then ask the assistant to read the plan, ask you questions and propose an approach, and tell it not to write code until you agree. Ten minutes spent here can save an afternoon of undoing work that solved the wrong problem.

Keep the AI on a short leash

Big prompts produce big changes that nobody reads properly. Ask for the smallest change that moves things forward, check it, save it, then ask for the next one. If the assistant announces that it has also refactored three other files while it was there, stop and ask why. Small steps make mistakes cheap to spot and cheap to undo.

Use version control and pull requests, even on your own

Git gives you an undo button for your whole project. Put every tool in a repository, make each change on its own branch and open a pull request, even if you are the only person who will review it. The pull request is where you read the change with fresh eyes before it becomes real. Never push straight to the main branch.

We work this way at Green & Home. Every change goes through a pull request, and the owner approves merges. It feels like ceremony for about a week, then it feels like a seatbelt.

Never put secrets in code or prompts

API keys, passwords and tokens belong in environment variables or your hosting platform's secret manager, never in source files and never pasted into a chat with an assistant. A few habits that cover most of the risk:

Add files such as .env to your ignore list before the first commit, not after.
Run a secret scanner such as gitleaks before you commit and again in your automated checks.
Watch for credentials hiding in less obvious places, such as a repository URL with a token embedded in it.
If a key does leak, rotate it straight away. Deleting the commit is not enough, because the history keeps it.

The same applies to customer data. Do not paste a real customer list into a prompt to "test" something. Make up sample data that has the same shape.

Evidence or it didn't happen

Assistants will happily say "I've tested this and it works." Our house rule is that "tested" means the command that was run and its actual output are shown. If the assistant cannot show you both, it was not tested. The same goes for "deployed", "fixed" and "all checks pass". Ask for the evidence every time; it costs seconds, and it catches the cases where the assistant described what it intended to do rather than what it did.

Preview, then confirm, for anything that writes to a live system

Any tool that changes a live system should work in two steps. First, a preview that shows exactly what will change: these 14 orders, this price moving from one figure to another, these three stock items being archived. Second, a separate, deliberate confirmation that applies it. Nothing is written on the first step.

This matters even more when an AI is the one calling the tool. The AI may prepare the change; a person confirms it. The hosted MCP server for Linnworks we are building follows exactly this pattern for every write action: a preview first, then a single-use confirmation that expires after ten minutes.

Read the diff

You do not need to be a developer to read a diff for its shape. Look at which files changed, whether anything was deleted, whether there is anything you did not ask for, any new third-party packages, hard-coded values, or web addresses you do not recognise. Ask the assistant to explain each change in plain English. If a one-line fix touched thirty files, find out why before you merge it.

Write the rules down where the AI reads them

Assistants do not remember your preferences between sessions unless you give them something to read. Claude Code reads a CLAUDE.md file at the start of each session (see its documentation), and many tools support AGENTS.md, an open format for the same purpose. Put your house rules there: the stack, the coding style, pull requests only, no secrets in git, show evidence for "tested", things it must never do, and mistakes it has made before. When the assistant gets the same thing wrong twice, add a line.

Keep humans approving merges and deploys

Let the AI draft code, run tests, open pull requests and write the release notes. A person merges and a person deploys. At Green & Home that line is firm, and it extends to the business itself: an AI never issues refunds or moves money, whatever the amount. Automation is there to take the typing off your plate, not the judgement.

A short checklist

Decide whether this tool touches money, customer data or live stock.
Write the plan first and let the assistant ask questions.
Work in small steps, one branch and one pull request per change.
Keep secrets in environment variables and run a secret scanner.
Ask for the command and the output behind every "tested".
Build writes as preview, then confirm.
Read the diff, and ask about anything you did not request.
Keep the rules in a file the assistant reads every session.
A person approves every merge and every deploy.

If you are wondering which tools to put around all this, we cover that in good AI stacks to get stuff done fast. And if the tool you are tempted to build is a report someone runs every Monday, read the reports your ops manager can stop running first; you may not need to build anything.

These are the rules we build our own apps by. See what they produce in our apps, from Trade Order POS to the hosted Linnworks MCP server.