Vibe coding, honestly assessed

Vibe coding is building by describing intent and accepting what the model produces, steering by result rather than by reading each line. You judge the output by whether it works, not by whether you would have written it that way.

This is a real change in how software gets made, and dismissing it is as unhelpful as overselling it. Something that turns a two-day prototype into a two-hour one has obvious value. The question worth asking is which two days it can replace.

It is worth separating the practice from the tooling. Using an assistant while reading everything it writes is ordinary modern development. Vibe coding specifically means not reading it, and that distinction is where all the risk sits.

It works best where the cost of being wrong is low and the feedback is immediate. Prototypes, throwaway scripts, unfamiliar-library exploration, test scaffolding, one-off data transformations — in all of these you find out quickly if the result is wrong, and nothing downstream depends on the internals.

It also works well as a translator. Describing a regular expression, a SQL window function or a Terraform block you half-remember is faster than looking up syntax you use twice a year. The model is good at the parts you could verify but would rather not retype.

The common property is verifiability. Where you can look at the output and immediately know whether it is right, you get the speed without the risk, because the reading step is replaced by a check that is genuinely cheaper.

• Prototypes meant to be discarded
• Glue code and data wrangling with visible output
• Boilerplate where the shape is conventional
• Syntax you can verify but do not memorise
• Tests for behaviour you can state precisely

The failure mode is not code that does not run. It is code that runs, passes a casual check, and is wrong in a way that surfaces later. Off-by-one handling in an edge case nobody tested. A retry that masks a failure rather than reporting it. An authorisation check that looks present but compares the wrong identifier.

These slip through because the reviewing effort scales with the code you did not write. Reading generated code carefully takes nearly as long as writing it, and the whole appeal was not doing that. So it is skipped, and the defect ships.

The risk concentrates in exactly the places you would expect: anything touching money, permissions, personal data, or state that is expensive to correct after the fact.

Conventional technical debt is code you understand and know is bad. What accumulates here is different: a codebase nobody has read. It can be entirely reasonable code and still leave the team unable to answer why a component behaves as it does under load.

That matters at exactly the wrong moment. Incidents are resolved by people who can hold a system in their head. A team that shipped fast and understands little has borrowed against its own future response time.

It compounds differently from ordinary debt as well. Bad code you understand can be refactored deliberately; code nobody has read cannot even be assessed, because nobody knows which parts are load-bearing.

The practical compromise most experienced developers land on is to generate freely and review selectively, with the selection decided in advance rather than by how tired you are. Anything on the security, money or data-integrity path is read line by line regardless of how confident the output looks.

Reviewing against behaviour helps more than reviewing against style. Ask what happens when the input is empty, when the call fails halfway, when two of these run at once — those are the questions that surface the defects generated code actually contains.

Tests are worth more here than they were, and slightly different ones. Write them yourself for the properties you care about, rather than generating them from the same description that produced the code, or you are checking the implementation against its own assumptions.

The skill that appreciates is judgement about correctness — reading code critically, knowing which failure modes matter, deciding what deserves scrutiny. Typing speed was never the bottleneck, and now it is visibly not.

The realistic posture for 2026 is fluent use plus retained standards: generate the first draft, then review it the way you would review a competent stranger who does not know your production constraints. Candidates who can describe that discipline interview far better than those who either refuse the tools or trust them completely.

There is a real concern about how people acquire that judgement now. It was previously built by writing a great deal of mediocre code and watching it fail, and if juniors skip that, the reviewing skill has no obvious way to develop. Reading generated code closely, rather than only running it, is the nearest available substitute.

• Be fluent with the tools — refusing them reads as incuriosity
• Review generated code against your own bar, not the model’s confidence
• Never delegate security, money or permissions without reading every line
• Be able to explain any code you shipped, whoever typed it