Skip to content
Journal

Engineering

Vibe Coding Is a Spectrum, Not a Methodology

Headshot of Alex Fujimoto
Alex Fujimoto
April 2, 2025 · 3 min read

Since Andrej Karpathy gave the practice a name in February, "vibe coding" has become the discourse of the season: fully giving in to the tools, accepting the generated code, barely reading the diffs, seeing where it takes you. Half my feed says it is the future of programming. The other half says it is the end of engineering. Both halves are having the wrong argument.

Here is the position we run the engineering team on: vibe coding is not a methodology you adopt or reject. It is one end of a spectrum of verification rigor, and the entire skill of engineering in 2025 is matching the rigor to the stakes.

The spectrum, made explicit

Every piece of code we ship now gets an implicit classification. We have started making it explicit:

  • Throwaway. Prototypes, spikes, internal one-offs, a script to rename five hundred files. Vibe away. Reading every line of a disposable artifact is a waste of the one resource that got more valuable this year: senior attention.
  • Load-bearing but low-risk. Marketing sites, CMS glue, internal tools. Generated freely, reviewed at architectural altitude, gated by linters, types, and tests rather than line-by-line human reading.
  • Critical. Checkout flows, auth, data migrations, anything touching money or personal data. Here the tools draft and humans own every line. No exceptions, no matter how confident the diff looks.

The vibe coding disasters making the rounds, leaked keys, security holes, apps that fell over on contact with real users, are almost all category errors: throwaway-level rigor applied to critical-level stakes. The practice did not fail. The classification did.

Verification moved; it did not disappear

The deeper shift is where quality control lives. When humans wrote every line, verification was distributed through the act of writing itself. Typing was slow, so thinking rode along for free. Generation removes that built-in checkpoint, which means verification has to be rebuilt somewhere else, deliberately. For us that means the harness got promoted:

Types are strict, everywhere: the machine's first reviewer.
Tests describe behavior we require, written or approved by humans.
CI blocks raw values, dead exports, and dependency drift.
Review happens at the architecture level, not the semicolon level.

I would put it this way: we are no longer paid to write code. We are paid to specify systems and to verify that what exists matches what we intended. The tools compressed the middle. They did nothing to the two ends, and the two ends were always the hard part.

What this does to hiring and craft

The uncomfortable question for the industry: if juniors learn by writing the code that machines now write, where do the next seniors come from? I do not have a clean answer, but we are trying one: our junior engineers spend deliberate time in "manual mode" on real features, tools off, precisely because debugging your own hand-written mistakes builds the mental models that make you a competent verifier later. You cannot review at altitude if you have never been on the ground.

And a note on quality, since vibe coding gets blamed for a coming wave of terrible software. Terrible software never needed AI. What the tools change is the shape of failure: less syntax-level breakage, more plausible-looking systems with confidently wrong architecture. The failure mode moved up the stack, which is exactly why the engineers who thrive now are the ones with system-level judgment.

Vibes for the disposable. Rigor for the load-bearing. Paranoia for the critical. That is not a hot take, it is just engineering, same as it ever was, with the boring parts finally automated.

Building something this could apply to?

We take on a small number of flagship projects each quarter.

Start a project