Vibe coding today: what has changed with AI agents and what still needs checking

The term “vibe coding” was coined by Andrej Karpathy in February 2025: you describe what you want, the AI writes the code, you accept the changes without reading them and keep going until it works. Back then it was almost a provocation. Today it is how a good share of the apps I am asked to review come to life.

In less than two years the tools have changed a lot, and so have the problems. Here I describe what I see today: what AI really does, where it works, where it still breaks and the method I use to stay in control of the code.

What has changed: from suggestions to agents

At first the loop was simple: write a request, copy the code, paste the error, try again. Today I work mostly with agents such as Claude Code, Cursor or Codex, which do much more:

• they read the repository, not a single file: they understand how the parts connect before changing them;
• they run commands: they install packages, run the tests, read the errors and fix them on their own;
• they follow project rules written in dedicated files (CLAUDE.md, AGENTS.md, Cursor rules): stack, conventions, what not to touch;
• they connect to other tools through MCP (Model Context Protocol): databases, documentation, browsers, ticketing systems.

Alongside the agents there are app builders such as Lovable and Bolt: from a description they generate frontend, authentication and database (often on Supabase) in a few minutes. v0 does the same, mainly for the interface. It is the fastest way to have something to show. It is also the fastest way to have code in production that nobody has read.

Where vibe coding works

I use it every day, and there are cases where the time saved is clear:

• prototypes and MVPs to put an idea in front of real users before investing;
• internal tools with few users and non-critical data;
• repetitive work on existing code: migrations, guided refactoring, dependency updates;
• tests: writing test cases and running them is one of the tasks where agents perform best;
• reading unfamiliar code: asking the agent how a module works before changing it.

Where AI-written code still breaks

AI writes code that works in the expected case. The problems are almost always in what nobody asked it for. They are the same ones I find in check-ups:

• authorisation: tables without RLS policies on Supabase, checks done only in the browser, roles that users can change themselves;
• secrets: OpenAI keys or the Supabase secret key (service_role or the new secret keys) in the frontend or in the repository history;
• payments: webhooks that do not verify the signature, paid plans that can be unlocked from the browser;
• costs: API and database calls with no limits, which grow with users or with abuse;
• maintainability: huge files, duplicated logic, no tests. The agent fixes one bug and opens another, because nothing flags it;
• dependencies: outdated packages or, sometimes, packages that do not exist and that the model made up. Someone registers them on purpose to get them installed (it is called slopsquatting).

The more autonomous the agent, the more it matters where you let it work. An agent with access to the production database or to keys with broad permissions can do real damage, even without meaning to.

The method I use

The risk lies in skipping the foundations. With agents I work like this:

1. Specification first, then code. What the feature must do, what data it touches, who can see and change it. Ten lines written beforehand save hours of fixes afterwards.
2. Small steps. One task at a time, on its own branch, and nothing reaches the main branch without green tests and a review.
3. Tests before the feature. I write the test plan first, then the code, and run the tests at every step. They are the net that stops the agent when it breaks something.
4. Written project rules. Stack, conventions, folders not to touch, test commands: all in a file the agent reads at every session. Non-obvious decisions go into a decision record.
5. Security is not decided by AI. Authorisation on the server and in the database (RLS policies, roles), secrets only in server-side environment variables, automated checks on dependencies and on the Supabase Security Advisor.
6. The agent does not touch production. It works locally or in a test environment with test data; I run the commands on production myself.
7. Two reviews before launch. One automated, with separate agents looking for security, data and correctness issues; then mine, focusing on data, permissions and payments.

Before going into production

If your app was built this way, these are the questions to ask yourself before opening it to real users:

• Does every table have its RLS policies, including the ones added last?
• Is there a secret key in the code that reaches the browser or in the repository?
• Who decides whether a user has paid: the server or the browser?
• Do calls to paid APIs have a limit?
• Are there tests that run on every change?
• Do you have a backup, and have you ever tried restoring it?

If your answer to any of these is “I don’t know”, the app is not one to throw away: it needs someone to read it with different eyes from those of the AI that wrote it.

With the AI Code Check-up I read your app’s code and tell you what is broken, what is dangerous and what to fix first. Fixed price, NDA before access, read-only access. The AI Code Check-up page