The vibe-coding trap has a name, and the name is not "the model"

A programming language shipped this week with a 99 percent AI-written compiler and no mention of the forty-year-old field it reinvents. The failure was not generation quality. It was that building got cheaper than reading, and nobody put a gate between them.

A language, a proof, and a field nobody looked up

Two stories ran side by side on Hacker News this week and they are the same story. The first is Bend 2, a language pitched for the AI coding era: humans write "laws", the AI writes implementations and proofs, and the compiler checks the proofs. It got six hundred points and a lot of admiration.

Then Liam Powell wrote a response that got three hundred more, and his point was not that the language is bad. His point was that the demo on the home page takes 58 lines to state that a player can never touch the flag, 442 lines of AI-written proof to establish it, and that the phrase "formal verification" appears nowhere on the website or in the codebase.

He then asked a model to redo the demo in SPARK, a language built for exactly this, with no further guidance, and it came back a fraction of the size. The README, a commenter noted, says the compiler is 99 percent AI-written and has not been fully audited.

The second story is Dan Abramov's account of vibing a proof of a conjecture of Conway's with a model, over days, in a long transcript he published in full. It is a good post and an honest one.

The most upvoted objection under it was a mathematician pointing to Gowers's essay from the same week on why he did not sign the Fields medallists' letter, and the older point Gowers has been making for twenty-five years: there is a difference between solving a problem and understanding a field, and the second is what makes the first mean anything.

Powell names the mechanism precisely and we are going to steal his sentence: vibe coding makes it possible to build a substantial solution before learning enough about the problem to recognise that a much better solution exists.

Why this is new

It has always been possible to reinvent a field badly. Every senior engineer has watched a junior build a job queue in a spreadsheet. What is new is the ratio.

For all of software's history, building was expensive relative to reading. Before you could produce 442 lines of anything, you had spent enough hours inside the problem that you had, almost by accident, tripped over the prior art.

You searched for the error message. You read the paper the library cited. You asked the person at the next desk, who said "oh, that's just a Bloom filter".

The cost of building was a tax that paid for an education. That tax is gone.

A model will produce the 442 lines in the time it takes to make coffee, and it will produce them competently enough that they work, and working code is the most persuasive argument in the world against going back to read.

Nothing in the loop ever forces you to discover that the field exists. The model will not volunteer it unless you ask, and you do not know to ask, because the whole point is that you do not know the field exists.

The old cost of building bought an education for free. The new cost does not.

Time axis illustrative; the shape is the point.

The Bend story is the pure case because a language is the most expensive thing you can build and formal verification is one of the best-documented fields in computer science. If it can happen there, at that scale, with that much talent, it is happening in your codebase this week at a smaller scale where nobody will write a blog post about it.

The agent that built your rate limiter from scratch instead of reading the one in your framework. The retry logic that reinvented exponential backoff without the jitter. The custom auth layer.

The gate goes before the build, not after

The instinct is to fix this with review, and review does catch some of it. But review happens after the 442 lines exist, when the sunk cost is already arguing for them, and the reviewer usually shares the author's blind spot.

The place to put the gate is the fifteen minutes before anything is built.

We run something we call the prior-art pass, and it is embarrassingly simple. Before an agent is allowed to build anything with a name, it has to answer four questions in writing and a person has to read the answers.

1. What is this problem called by people who study it?
2. What do they already use?
3. Why does the existing thing not work here?
4. What is the smallest version of this we could build on top of the existing thing instead?

The model is extremely good at answering these questions. It has read the field. It will tell you about SPARK, Dafny, Lean, and TLA+ in one paragraph if you ask it to, and it will tell you what each is for.

The trick is that somebody has to ask before the build starts, and that somebody has to be willing to hear "this already exists" as good news rather than as an obstacle to the thing they were excited to make.

The prior-art pass: four written answers, one human read, before an agent may build anything with a name.

Liam Nugent's piece from the same week, on why the most important product decision is what you do not build, makes the organisational version of the same point.

Nobody gets promoted for deleting things. Those who create and launch are the ones rewarded. The models have made creating and launching nearly free, which means the incentive that was already skewed towards building is now skewed by another order of magnitude, and the only counterweight is a deliberate, slightly unpopular gate that asks "does this need to exist" before the exciting part starts.

The pass in practice

A composite from our own work, because the pass sounds like a platitude until you watch it fire.

A team wanted a service that deduplicated inbound customer records, which arrive from four systems with inconsistent formatting, so that the same person is not created four times.

An agent, asked directly, would have built it in an afternoon: normalise the fields, hash them, compare.

The prior-art pass asked the four questions first, and the agent's written answers were, in order:

• This is called entity resolution or record linkage;
• The standard approaches are probabilistic matching in the Fellegi-Sunter family and there are mature libraries in every major language;
• The naive hash-and-compare approach fails on exactly the inconsistent formatting the team has, because it treats a transposed digit as a different person;
• The smallest version is to run an