Vibe coding safely
Vibe coding is fine for prototypes and dangerous in production. The guardrails that let you keep the speed: spec first, small diffs, tests before acceptance, CI controls, import review, data hygiene and provenance.
01Prototype versus production
- Tell when vibe coding is appropriate and when it is a liability
- Apply the guardrails that keep generated code reviewable
- Catch hallucinated packages before they become a supply-chain attack
- Run a promotion gate from prototype to production
Vibe coding is building by describing what you want to a model and accepting what it produces, iterating on behaviour rather than reading the code closely. For a throwaway prototype, a demo or exploring an unfamiliar API it is a genuine speed-up. In production security software it is a liability, because nobody has read the code that now sits on a trust boundary.
| Prototype | Production | |
|---|---|---|
| Goal | Learn fast, show the idea | Correct, maintainable, defensible |
| Data | Synthetic only | Real customer and tenant data |
| Network | Local or isolated sandbox | Internet-facing, inside trust boundaries |
| Review | Optional | Every line read and owned |
| Lifetime | Days, then deleted | Years, with on-call |
The demo that impressed the customer becomes the MVP next sprint. Mark prototype repos clearly, keep them away from real data and credentials, and require the promotion gate before any of the code moves into a product repo.
02Guardrails that keep the speed
- Spec and threat model first. Write the inputs, outputs, trust boundaries and failure behaviour before prompting. The model fills gaps with the average of the internet; a spec removes the gaps.
- Small diffs. Ask for one function or one change at a time. A 600-line generated diff does not get reviewed; it gets skimmed.
- Tests before acceptance. Write or approve the tests from the spec first, then accept code that passes them. Tests generated from the code tend to assert whatever the code does.
- CI controls that do not trust anyone: SAST, secret scanning, dependency pinning with lockfiles, licence scanning, and SBOM generation on every build.
- Review every import. Every new dependency is a supply-chain decision. Check it exists, who publishes it, its age, download history and whether you already have something that does the job.
- Data hygiene. Never paste secrets, customer data, logs with PII or proprietary code into tools your organisation has not approved.
- Record provenance. Note which code was generated, by which tool, so it can be found and re-reviewed later.
- ACTOR
- EDGE
- SERVICE
- DATA
- CONTROL
- Live flow
- Lookup / async
03Hallucinated packages and data leaks
Models sometimes invent package names that sound right: flask-jwt-secure, express-sanitize-input, pyyaml-safe. Attackers watch for commonly hallucinated names and register them with malicious install scripts. This is slopsquatting, typosquatting aimed at AI suggestions rather than human typing.
# Before adding any dependency the assistant suggests:
npm view express-sanitize-input name time.created maintainers repository
# - does it exist at all?
# - created last week? single maintainer? no repository link? -> stop
# - postinstall script? read it before installing anything
npm install --ignore-scripts --save-exact <pkg> # pin exactly, no install scripts
# CI: lockfile required, registry restricted to your proxy, new deps need approvalThe data-leak side is quieter. Pasting a production log into a public chatbot to "explain this error" can disclose customer identifiers, internal hostnames and tokens. Pasting proprietary detection logic can leak your crown jewels. Use only tools with an approved data agreement, redact before pasting, and never paste secrets at all: if a key has been pasted, treat it as exposed and rotate it.
Even an enterprise tool with no training on your data should not receive raw secrets or unredacted customer records. Minimise what you send as you would with any third-party processor.
04From prototype to production
Make promotion an explicit event with a checklist, not something that happens when a prototype quietly gets a production database URL.
| Check | Evidence |
|---|---|
| Spec and threat model written | Linked doc with trust boundaries and abuse cases |
| Every line read by an owner | PR reviewed by someone who can explain it |
| Tests derived from the spec | Negative and authz tests, not just happy paths |
| Dependencies reviewed and pinned | Lockfile, no unknown packages, licence scan clean |
| SAST and secret scan clean | CI run linked; exceptions documented with owner |
| No secrets or real data in history | Secret scan over full git history, keys rotated if found |
| Provenance recorded | Generated files tagged in the PR description |
| Security review for sensitive paths | Sign-off on auth, crypto, parsing of untrusted input |
"Vibe coding is fine for a prototype on synthetic data. Before anything goes to production it passes a promotion gate: spec and threat model, every line owned and reviewed, spec-derived tests, pinned and verified dependencies, clean SAST and secret scans, and provenance recorded. The speed stays; the unread code does not ship."
An assistant suggests `npm install express-sanitize-input`. The package was published four days ago by a single account with no repository link. What should you do?
Q1What is the difference between typosquatting and slopsquatting?+
Typosquatting bets on humans mistyping a real name (reqeusts). Slopsquatting bets on models inventing a plausible name that does not exist, then registers it so the hallucination resolves to malware.
Q2Why write tests before accepting generated code?+
Tests written from the spec define what correct means independently of the code. Tests generated from the code encode its current behaviour, including its bugs.
Q3A developer pasted an API key into a chatbot. What now?+
Treat the key as exposed: rotate it, check its usage logs for abuse, and add the incident to training. Deleting the chat does not un-send the data.