Vibe coding downsides: a risk checklist and how to reduce them

The question "vibe coding: good or bad" is poorly posed: the tool is good for some tasks and dangerous for others. Briefly, in this approach you state the task in words, the agent writes and edits the code, and you judge the result by how the program works rather than by reading lines. Below are the downsides of vibe coding as a checklist: each risk has a sign and a measure you can apply today.

When the approach is justified and when it is not

Justified:

• prototypes and demos that will not live long;
• one-off scripts, data migrations with result checking;
• internal utilities without other people's data;
• boilerplate (forms, CRUD, configs) where you can verify the outcome quickly.

Dangerous:

• payments, authorization, access rights, encryption;
• medicine, finance, anything where a mistake costs money or health;
• code that will be maintained for years while only the agent understands it;
• projects with other people's personal data.

Risk checklist

1. Vulnerabilities in generated code

Sign: queries built by string concatenation, passwords in code, authorization checks "on the client", certificate verification disabled just to make it work.

Measure: put security requirements in the project rules (CLAUDE.md or the equivalent): parameterized queries, input validation, secrets only from the environment. Run a static analyzer and tests on every change. For critical parts, have a second agent or a person do a separate review. A model can be confidently wrong, so "the code looks fine" is not an argument.

2. Leaked keys and secrets

Sign: a key landed in a repository, a chat, a log, a screenshot.

Measures:

• keep keys in .env and add the file to .gitignore before the first commit;
• add secret scanning before commit (pre-commit);
• create a separate key per project and restrict it: a daily and monthly dollar limit and a list of allowed models (allowed_models). This is described in the key limits docs↗;
• do not paste real keys into requests to the agent and do not ask it to "look at my .env".

If a key does leak, revoke it immediately and create a new one; the procedure is in the post what to do if a key leaks↗.

3. Code nobody understands

Sign: you cannot explain what a module does, and to fix a trifle you ask the agent again.

Measure: move in small steps and read the diff before accepting. A simple rule: do not commit what you could not explain to a colleague. Ask the agent to comment non-obvious decisions and to keep a short list of architectural decisions in the repository.

4. The agent loops

Sign: the agent edits the same file again and again, repeats the same command, "fixes" a test by breaking its neighbor.

Measure: watch the session and interrupt it yourself if there is no progress after two or three attempts. Give the agent a stop criterion: "if the test still fails after three fixes, stop and describe the problem". Limit the key with a daily cap. A detailed breakdown is in the post the agent got stuck in a loop↗.

5. Unexpected costs

Sign: the balance melts faster than you work.

Calculating the possible loss. Suppose a looping agent made 100 calls, sending a 80,000-token context on each and getting 1000 tokens back. Model claude-sonnet-5-5 (0.4 / 2, prices as of 18 October 2026), OpenAI format without a cache discount:

100 × 80,000 = 8,000,000 input tokens × 0.4 / 1,000,000 = $3.20 100 × 1000 = 100,000 output tokens × 2 / 1,000,000 = $0.20 Total $3.40 for a single looped episode.

In the Anthropic format most of the input would go at the cache read price (0.05) and the sum would be lower, but the order of magnitude is clear: one unnoticed loop costs noticeable money, and an unattended overnight run can repeat it many times.

Measures: a key limit (daily and monthly), a separate key per agent, model choice by task, a regular look at the "Usage" page in the dashboard.

6. Invented packages and methods

Sign: the code imports a library you have not heard of or calls a method that is not in the documentation.

Measure: before installing each new package, check that it exists, is current and belongs to the expected author. Such a package may turn out to be a fake with a similar name. Ask the agent to give a documentation link for any new API and verify it.

7. Destructive agent actions

Sign: the agent deleted a directory, overwrote a file, ran a migration on the wrong database.

Measures:

• work in a separate git branch and commit before each large edit;
• keep the mode where the agent asks for confirmation before changing files and running commands. Enable modes without confirmation only in a container or a disposable environment;
• do not give the agent access to production databases and servers;
• make backups.

8. Project data leakage

Sign: personal data, trade secrets or code under NDA ended up in a request.

Measure: decide in advance what may be sent to a model. Everything sent goes to the model provider. Anonymize test data and exclude files with real data from the context. If company policy forbids external services, the approach does not fit. Request logs may also contain extra data: do not write full prompt texts to them unless you need to.

9. Loss of skill and dependence

Sign: without the agent you cannot debug your own project.

Measure: keep for yourself what you want to learn and regularly solve tasks on your own. Use the agent as a partner: form a plan yourself first, then compare with the agent's proposal. What the approach itself is, is covered in the post vibe coding: what it is↗.

A short memo before launching an agent

1. The repository is under git, a clean tree, a separate branch.
2. .env is in .gitignore, secret scanning is on.
3. A separate key with a limit and a restricted list of models.
4. Project rules are written in CLAUDE.md.
5. The agent has no access to production systems.
6. Tests run with one command.
7. You are ready to read the diff.

A key with a limit is created in the dashboard↗.

FAQ

Is vibe coding good or bad?

It depends on the task. For prototypes and scripts it saves time; for payments and security without human review it is dangerous. A good practice: speed up where the result is easy to verify.

Can I trust code written by an agent?

Like the code of a new colleague: verify it. Tests, diff review and static analysis are mandatory, especially for security.

How do I avoid overspending?

A key limit, a separate key per project and spend monitoring. One looped session in our calculation costs about $3.40 on claude-sonnet-5-5, but unattended it can repeat.

What if a key ended up in a repository?

Revoke it, create a new one, clean the repository history and check spending over the leak period.