Laravel 12 + "Vibe Coding" Enters the Lexicon

Archive note: this is a backdated post, written years later while rebuilding this site. It’s dated to the moment it covers, but the hindsight is real.

Laravel 12 arrived February 24, and the release notes read like a deliberate exhale: minimal breaking changes, dependency upgrades, and the real news living beside the framework — new first-party starter kits for React, Vue, and Livewire, modern tooling included, replacing the aging Breeze/Jetstream lineage. After 11’s great slimming, 12 is maintenance-mode-as-philosophy: the framework is done in the best sense, and the annual release is now mostly a stability contract with the ecosystem. Upgrade cost from 11: the mildest yet. The annual cadence has fully become what it promised — boring, predictable, plannable.

Which frees this month’s column for the word everyone suddenly has an opinion about.

“Vibe coding”

In early February, Andrej Karpathy gave a name to something every developer with AI tooling had already felt: vibe coding — describing what you want, accepting what the model produces, pasting errors back when it breaks, and never really reading the code. “I just see stuff, say stuff, run stuff,” as the formulation goes. Fully giving in to the vibes. The term went from tweet to think-piece industry in about a week, which tells you it named a real thing.

Having spent three documented years on exactly this frontier, my position is unfashionably both-handed:

1. For throwaway software, vibe coding is simply correct. Weekend tools, one-off scripts, prototypes, the personal utility with one user — the rigor I’d apply to a payment flow would be malpractice-by-overhead here. Software whose failure costs nothing may be built by vibes; this category is enormous and was always underserved by professional gatekeeping. The grandmother’s recipe app gets built now. Good.
2. For production software, “unread code” is a liability with a deployment pipeline. Every codebase is a set of promises — about security, about edge cases, about what happens under load — and you cannot make promises about code nobody has read. The vibe-coded production app is this decade’s unaudited smart contract: it works exactly until the input nobody imagined arrives. The discipline gap will fund a generation of incident retrospectives and consulting invoices.
3. The interesting boundary is moving, though. The honest version of my unease: “must read every line” was calibrated when humans wrote the lines. As models improve and verification tooling matures — tests, types, reasoning models checking each other — the unit of professional review may legitimately rise from line to behavior. That’s not vibes; that’s abstraction doing what abstraction has always done. Assembly programmers said the same things about compilers that I’m tempted to say about vibe coders, and the compilers won.

The connecting thread

A 14-year-old framework shipping starter kits so polished you barely write boilerplate, and a new word for not reading what the machine wrote — these are the same story at different trust levels. The entire history of this craft is deciding which layers we’re allowed to stop reading. The only rule that survives every cycle: you may stop reading a layer when something trustworthy is reading it for you — a compiler, a type system, a test suite, a framework’s conventions. The vibes, as currently practiced, have no such guarantor. Yet.

Meanwhile: composer create-project on a fresh Laravel 12 this week took four minutes to a working, styled, authenticated app. Some of that I didn’t read either. The boundary moves; the judgment about where stays the job.