How Do We Stop Vibe Coding?

Alex Klos, July 2026. The answer to the title is that we don't stop it, and shouldn't try — the thing to fix is the trust problem underneath it. He discloses in the piece that one of the two tools he ends up endorsing is his own.

His starting position is not skeptical. Claude Code took off in late December 2025, most developers moved coding agents into their main workflow within months, and Karpathy said on No Priors in March 2026 that he had not typed a line of code since December. Klos believes him, partly because he hasn't either. The anxiety he is writing into is the one shared by people who have already made the switch: will the slop ever end, and what would it even mean to stop it.

Agents abstract away the code

The frame he borrows is Grady Booch's three golden ages of software engineering. The first, from the late 1940s to the 1970s, was the age of the algorithm, where high-level languages and compilers abstracted away the machine. The second, 1970s to 2000s, was object-oriented abstraction. The third, starting around 2000, is the age of systems — libraries, platforms, and APIs abstracting away entire subsystems. Booch is careful that AI did not start this age, only accelerated it, but he compares coding agents to the arrival of compilers in Grace Hopper's time, and that is the comparison Klos takes.

Compilers abstracted the machine. Agents abstract the code. For the first time you can generate code directly from intent, which is the capability whose absence killed model-driven development, and Klos suggests it may be time to revisit MDD in some form. The cost of moving up to intent is that you lose the tooling that made working at the code level reliable.

The problem is trust, stated twice

Vibe coding gets criticized on two grounds: it damages your understanding of the solution and architecture, and it is unreliable because prompts are under-specified, natural language is a lossy interface, and generation is non-deterministic. Klos accepts both and describes the mechanics.

You stop understanding the codebase. The mental model you build is vague and leans on your prior experience as a programmer rather than on this system. You lose awareness of dead code, redundant code, and stubs. You lose track of what was implemented and why. You cannot explain the architecture to someone else or reason about where it might break.

You also have almost no visibility into what is about to change. The agent writes a short essay describing its plan, and that essay does not show a blast radius, does not tell you it is only implementing part of the thing, and does not flag the crucial piece it decided to omit because you thought it was obvious. Even when the information is technically in there, plans have no learnable structure, so you don't reliably catch it.

Both failures reduce to the same thing: you can't trust your own understanding of the codebase, and you can't trust that the agent did what you asked.

That gives him three requirements for any real solution. The agent should reliably do what it was asked, ideally deterministically, which may not be achievable but is the right target. You should be able to audit and track what it did to the codebase, ideally without having to read the code. And friction has to stay minimal, because vibe coding is winning on being the path of least resistance and the disciplined path has to become the easy one rather than the virtuous one.

Why the current crop fails

Markdown specs are the most common answer he hears, and he reproduces the pitch as a single breathless run-on sentence about pipelines that review, implement, reconcile, and update. His questions are the ones the pitch never survives: is there a structured format for these specs, how do you know which parts are actually implemented, how do you know the code doesn't do anything beyond what's specified, and why not just prompt the agent directly. He points at Addy Osmani's February 2026 O'Reilly Radar piece as the best version — five principles, a six-section format, a study of 2,500 config files, every tool name-dropped — and says the problem is not that it's vague but that it's dense, and underneath the density it is prompt engineering in an agentic context. The spec is a guiding prompt, not a source of truth. There is no enforcement mechanism and no reconciliation mechanism beyond asking the agent whether the code follows the spec, which it can answer any way it likes because there is no shared syntax.

Skills are conditionally injected context, and they fail identically: everything still depends on the agent choosing to follow them. He picks gstack's oversized QA skill as the example and suspects that prompting "find and fix bugs plz" performs about as well.

Spec Kit and OpenSpec are the process-shaped attempts. Spec Kit drops markdown templates into your project and has you run six commands in order — specify, clarify, plan, tasks, analyze, implement — keeping the outputs around as context for later prompts. Klos calls this almost a start, because it imposes some structure, but the structure is loose, the developer drives the whole thing, six commands replace one, and you still cannot see anything. OpenSpec is the lighter version: explore, propose, apply, archive, with plain-markdown WHEN/THEN scenarios instead of EARS. Same bet, same failure. You drive the process, the agent grades its own homework, and nothing mechanical checks the spec against the code.

Kiro gets the most sympathetic reading. It steers agents toward markdown specs with EARS requirements through hooks, and Klos thinks both halves are genuinely good ideas. EARS (Easy Approach to Requirements Syntax) turns "users should get logged out after a while if they're inactive" into "WHEN a user session has been inactive for 15 minutes, the system SHALL terminate the session and redirect the user to the login page," which helps the agent and helps the human, because unstructured prose cannot be scanned the way code can. Hooks force the agent to react to triggers and follow steps, which is structure even without determinism. Kiro still falls over twice: feature specs accumulate rather than compose, so there is no auditable graph, and nothing ever reconciles requirements against shipped code. His line for it is that Kiro builds the courtroom and never holds the trial.

Test-driven development is the one thing on the list with real deterministic enforcement. A test's name states intent in natural language, the test itself anchors that intent to real code, and higher-level tests can act as functional dependency graphs. The catch is who writes them. Developers make the agent write the tests because it's easier, which reintroduces the exact problem. Writing them by hand means knowing the implementation and writing code, which is a retreat from the intent level the whole exercise is trying to reach. He notes CodeSpeak hit this directly: their original thesis was that developers would write spec files manually, most alpha testers made their agents do it instead, and they pivoted to extracting structured intent from natural-language prompts automatically.

He also drops one market data point into the middle of this. Tessl raised $125M on the promise of spec-driven development and has quietly moved away from selling SDD to developers, toward "skills are the new code."

The two he thinks are pointed the right way

CodeSpeak, started by Andrey Breslav (creator of Kotlin), bets that trust can be compiled away. You write concise markdown specs organized into modules that import each other, and codespeak build compiles them into Python, Golang, or TypeScript that you are not really meant to review. The compiler framing is taken seriously: specs are validated for consistency before a build, tests run after it, and codespeak takeover reverse-generates specs from an existing codebase. Since the pivot they have added a requirements layer where conversations with the agent get distilled into structured requirements mapped to the files implementing them, with drift flagged when a change diverges, and they are still working on formalizing the spec language toward deterministic or near-deterministic builds.

Scryer, Klos's own project of the past six months, bets the opposite way: trust in the agent is irreducible, so spending it should be as cheap as possible. It is model-driven development for coding agents. You and the agent share a model of the system, a C4-style hierarchy where each node states what it is responsible for in short, language-independent claims, mapped to the source lines implementing them and the tests proving them. The agent reads and writes the model over MCP; you browse it as wiki-style pages and diagrams instead of reading code. The model leads and the code follows, so planning a change produces a git-style diff over the entire model, which is the blast radius the agent's plan essay never gave you. Underneath sits a deterministic observability layer reporting what is built versus planned, which claims are anchored and test-backed, and where code has drifted from the model since the last reconcile.

Where this lands against the rest

Klos's closing position is that hand-written code stays for bespoke and novel work, that LLMs are genuinely better than humans at re-implementing standard patterns, and that what is needed is intent as a first-class artifact checked against the code, rather than prompt rituals dressed up as process.

That puts him in a specific spot in the vault's vibe-coding cluster. cult-of-vibe-coding (Bram Cohen) says the failure is refusing to read the code and prescribes reading it — audit, discuss, then execute. control-the-ideas-not-the-code (antirez) says reading the code is mostly wasted effort and prescribes owning the design instead. Klos agrees with antirez that reading lines is the wrong level and disagrees that holding the design in your head is enough, since the whole point is that your mental model is the thing you can no longer trust. His answer is to externalize the design into something mechanically checkable against the code, which neither position asks for. simonw-vibe-coding-agentic is the honest report from the middle, where the line between vibe coding and agentic engineering has already collapsed in practice.

The determinism argument connects two other pages. testing-heavy-no-review-workflow is the position Klos partially reaches by a different road: trust randomized testing rather than review, on the CPU-verification model. short-leash-ai-method is the opposite extreme, reading every diff at the permission prompt, which is the maximum-friction answer his third requirement rules out. reviewing-ai-code supplies the throughput evidence for why the review-everything answer cannot hold.

The closest thing to a shared thesis is slicer-agents-guess-code, which attacks the same blast-radius gap from the code side rather than the spec side: build an evidence-graded graph of what a change actually reaches, and mark the parts the analyzer cannot prove. Scryer's model diff and CodeSlicer's impact slice are two answers to one question, and neither asks the human to read more code.