Bolvrk blog

Vibe coding without being reckless

2026-09-10T00:00:00Z

Vibe coding — describing what you want, accepting what the model writes, running it, and iterating on the result rather than the code — is a genuinely good way to build a lot of software. Most of a product is UI, glue and business logic that is cheap to be wrong about, because being wrong shows up immediately and costs a retry. The reckless part is not the vibe. It is applying the same loop to the small set of changes where being wrong shows up later, at scale, and is not undone by a retry.

So the question is not "should I vibe code" but "which parts of this change are safe to vibe". The answer turns out to be short.

The parts you can vibe

Anything with a fast, honest feedback loop. If a mistake makes a test fail, a page render wrong, or an API return the wrong shape, you will see it within seconds and the model will fix it on the next turn. Components, handlers, transformations, most refactors, most tests. Let it drive. Read the diff the way you would read a colleague's, not the way you would audit a contractor's.

The parts you cannot

Three kinds of change have no fast feedback loop, because the failure mode does not exist in a development environment.

Schema migrations. On a dev database with forty rows, every migration is instant and every migration works. ALTER TABLE orders ADD COLUMN status text NOT NULL (BV002) succeeds on an empty table and fails on a full one. An index built without CONCURRENTLY (BV003) takes a second locally and blocks writes for twenty minutes in production. The model has seen millions of migrations and almost none of them ran against a table with a hundred million rows, so it has no reason to prefer the safe form. Neither does your test suite.
Credentials. A model that needs a database URL to make a script work will happily inline the one it found in .env, and a model that is asked to "make the migration self-contained" will do the same. The commit passes every test. It also passes the connection string into git history, where it stays. Nothing in the vibe loop flags this, because nothing in the vibe loop is looking.
Destructive data operations. DROP COLUMN (BV030), DELETE without a WHERE, a backfill that rewrites every row. These are correct in the sense that they do exactly what was asked. They are only wrong in the sense that the previous deploy is still reading the column, or that the rows were not yours to delete. That context lives in the deploy window and the business, not in the code the model can see.

What these have in common is that the person or agent making the change cannot observe the consequence before committing to it. The loop is open. Something has to close it.

Close the loop with a rule, not with vigilance

The tempting answer is "just review migrations carefully". It does not survive contact with a team that ships forty pull requests a day, half of them opened by agents, at eleven at night. Vigilance is a budget; it runs out exactly when the migration count goes up.

The answer that scales is a gate that does not get tired. For the three categories above, the dangerous forms are known and enumerable — locks, rewrites, missing defaults, missing timeouts, credentials in the diff — which means they can be checked deterministically: the same input, the same verdict, every time, with a rule id and a fix attached. That is what Bolvrk is. It sits at the three places a generated change passes through, and it does not matter which one catches it.

Before the draft leaves the agent — the MCP server gives the agent a check tool, and the skills library tells it to call the tool before proposing SQL. The agent revises its own migration; you never see the first draft.
Before you commit — npx bolvrk check migration.sql in the terminal, and bolvrk secrets on the diff or on any output the agent pasted. No account, exit code 1 on findings.
Before it merges — the GitHub Action fails the job above the severity your team chose and explains each finding on the pull request. This is the one that holds when the first two were skipped.

A working rule of thumb

Vibe everything whose mistakes you would see in the next sixty seconds. Gate everything whose mistakes you would see in the next sixty days. The gate should be a program, not a person, and it should give the same answer to the agent that it gives to you.

That is the whole discipline. It costs one command per migration and one Action in the repo, and it lets you keep the speed for the ninety percent of changes that deserve it.

Deterministic checks for AI-written migrations

2026-09-10T00:00:00Z

A coding agent asked to "add a status column to orders" will do it in seconds. It will also, more often than not, write the version that fails on a table with rows in it, or the version that takes an exclusive lock and holds it for the whole rewrite. Not because the model is bad at SQL — because the dangerous form and the safe form look almost identical, and the difference only matters at production scale, which the model never sees.

-- what the agent wrote
ALTER TABLE orders ADD COLUMN status text NOT NULL;

-- what survives contact with a table that has rows
ALTER TABLE orders ADD COLUMN status text;
UPDATE orders SET status = 'open' WHERE status IS NULL;  -- in batches
ALTER TABLE orders ALTER COLUMN status SET NOT NULL;

That first statement is BV002. It is one of the oldest and best-understood migration mistakes there is, and it is exactly the kind of thing an AI reviewer will sometimes catch and sometimes wave through, depending on the prompt, the context window, and the day.

Why the reviewer cannot be another model

The obvious fix is to ask a second model to review the first model's migration. It works often enough to feel like it works. It does not work in the way a team can build a process on, for three reasons.

It is not repeatable. The same migration reviewed twice can get two verdicts. A pull-request check that is red on Tuesday and green on Wednesday for the same diff teaches people to click through it.
It cannot say what it did not check. A model that returns "looks fine" gives you no list of the properties it verified. A rule corpus is a list by construction: these 104 patterns were checked, these fired, these did not.
Its claims are not verifiable. When a rule says "this rewrites the table under an ACCESS EXCLUSIVE lock", that claim was tested against a real Postgres and the fixture is in the repository. A model's claim is a sentence.

None of this is an argument against using agents to write migrations. It is an argument about where the trust boundary goes. The agent proposes; something deterministic disposes.

What a deterministic check looks like in an agent workflow

The check has to sit where the agent can reach it, and it has to return the same shape every time so the agent can act on it without interpretation. Three placements cover most setups.

Inside the agent's loop. Bolvrk runs as an MCP server. An agent that has just drafted a migration calls the check tool, gets findings back as JSON with a rule id, a severity and the fix, and revises before the human ever sees the draft. The skills library in the public repository tells the agent when to do this unprompted.
In the terminal. npx bolvrk check migration.sql — no account, no config, exit code 1 on findings. This is the same rule set the MCP server runs, so a person double-checking an agent's work sees exactly what the agent saw.
On the pull request. The GitHub Action posts one summary comment and fails the job above the severity the team chose. Whoever, or whatever, opened the PR, the gate is the same.

The point of running the same corpus in all three places is that the verdict does not change as the migration moves from the agent's draft to the terminal to CI. The agent cannot talk its way past the Action, because the Action is not listening to arguments.

The rules that matter most for generated SQL

Looking at what agents actually produce, a handful of rules do most of the work.

BV002 — ADD COLUMN … NOT NULL without a default.
BV003 — an index created without CONCURRENTLY, blocking writes for the whole build.
BV034 — a lock taken with no lock_timeout, so one slow transaction turns into a queue behind it.
BV030 — a DROP COLUMN while code that reads the column is still deployed.

Every one of these has a page that says what the rule catches, the SQL it fires on, and the safe pattern. That is deliberate: when an agent explains a finding to a person, or a person to an agent, the explanation should come from the same place and say the same thing.

What this is not

A rule corpus does not know your business. It cannot tell you that the backfill will take four hours on your data, or that the column you are dropping is read by a report nobody has looked at since 2024. Live-schema context narrows that gap — a read-only connection lets the rules see the real table sizes and constraints — but judgement stays with the team. The corpus removes the category of mistakes that need no judgement at all, so the judgement can go where it is needed.

If you are letting agents write migrations, the question is not whether to review them. It is whether the review is something you can rely on the same way every time. Start with npx bolvrk check on the last migration an agent wrote for you.