How Do We Stop Vibe Coding? Trust Beyond Prompt Rituals
Alex Klos’s July 2026 essay: vibe coding destroys mental models; markdown specs and skills aren’t enough. CodeSpeak, Scryer, and what actually rebuilds trust with coding agents.
On July 24, 2026, Alexander Klos published “How Do We Stop Vibe Coding?” — and Hacker News did what it does: argue definitions, cite skill atrophy studies, and ask whether the fix is better tooling or just turning the agent off. The essay’s real payload is sharper than the title: vibe coding won because it’s low friction, and every popular “discipline” layer so far is still prompt theater that never mechanically proves the agent did what you meant.
explainx.ai already covers what vibe coding is and how nightmares happen. This post is the trust / intent follow-on: Grady Booch’s third golden age, why Spec Kit and skills fail Klos’s bar, and the CodeSpeak vs Scryer bets.
TL;DR — What People Are Asking
Question
Answer
Core problem?
Trust — brain model + agent output both unreliable
Klos opens with Karpathy on No Priors (March 2026): he hasn’t typed a line since roughly December 2025. Whether you love or hate that, the distribution of workflows has shifted. Grady Booch’s framing (third golden age of software engineering — systems/libraries/APIs, accelerated by AI) lands the comparison that matters: compilers abstracted the machine; agents abstract the code. For the first time, we generate implementation from intent.
That climb up the abstraction ladder is why model-driven development failed last time (no reliable intent→code bridge) and why it might matter again. It is also why practitioners feel the slop tidal wave: casino vibes, pull the lever, hope.
The Black-Box Effect
When you’re vibe coding hard:
Mental models of the codebase go vague
Dead/redundant code and stubs accumulate unseen
You lose the “what / why” of implementations
You can’t explain architecture or reason about failure modes
Plans are essays without blast radius, partial-ship warnings, or learnable structure
Even careful users know the frustration Klos describes: elaborate prompts, 10–20 turns of negotiation, “passable” plan, then silent leftovers (“I wasn’t sure you wanted it completely gone”). Exploring via chat feels informative; reading the diff often finds a discrepancy. That is the agentic fatigue tax.
HN’s useful clarification: Karpathy’s original “fully give in to the vibes… forget that the code even exists” is turning the brain off by definition. Using LLMs with active review is a different mode — and conflating them poisons the debate.
Why Current Fixes Feel Rigorous but Aren’t
Klos’s success criteria for tooling:
Agent does what you asked (ideally deterministically)
You can audit changes without necessarily reading all code
Friction stays low — discipline must beat vibe on convenience
Markdown specs & “agent pipelines”
Dense essays like Addy Osmani’s “good spec for AI agents” still amount to prompt engineering. Without structured formats, implementation status, and reconciliation beyond “does the code follow the spec?”, the agent interprets freely. Spec is not source of truth.
Skills
Conditional instruction packs — still followed only if the model cooperates. Same failure mode as specs; often fluff.
Spec Kit, OpenSpec, cousins
Process wrappers (specify→…→implement or explore→propose→apply). Developer drives six commands instead of one; visibility doesn’t improve; agent still grades homework. Martin Fowler’s SDD notes (cited in HN) match: lots of verbose markdown you’d rather not review vs code.
Kiro + EARS
Structured requirements (WHEN/IF…SHALL) + hooks = real progress on scannability and process. Still: specs accumulate without composing into an auditable graph; no trial that reconciles requirements to shipped code.
TDD
Tests as named intent + anchors — closest to deterministic enforcement. Collapses when the agent writes the tests unconstrained, or when staying “at intent” means you refuse to touch implementation. CodeSpeak’s alpha lesson: testers made agents write the specs too — so they pivoted toward auto-extracting structured intent from natural language.
Tessl aside
Raised huge on SDD, then steered toward “skills are the new code” — Klos’s cautionary tale that selling pure SDD to developers is hard.
Two Bets Heading the Right Direction
CodeSpeak (Andrey Breslav)
Compile trust away. Concise modular markdown specs import each other; codespeak build emits Python/Go/TypeScript you’re not primarily meant to review. Validation before build, tests after, takeover to reverse-gen specs from repos. Requirements layer maps conversation → structured requirements → files, flags drift. Goal: near-deterministic builds.
Scryer (Klos)
Make trust cheap to spend. Model-driven development for agents: C4-style hierarchy of short, language-independent claims, mapped to source lines and proving tests. Agent reads/writes the model over MCP; humans browse wiki pages and diagrams. Plan = git-style diff over the model (blast radius). Deterministic observability: built vs planned, anchored/test-backed claims, drift since last reconcile.
Opposite philosophies, same diagnosis: intent must be a first-class artifact checked against code, not a ritual prompt.
If your team is “markdown specs in a folder + hope,” you’re in the immature-solutions bucket. If you’re wiring claims ↔ tests ↔ MCP, you’re closer to Scryer’s shape — whether or not you adopt that product.
Honest Limitations
CodeSpeak/Scryer are early; multi-developer ownership of “the model” may break (HN prediction).
Deterministic agent output may be unreachable; “cheaper trust” is the realistic target.
Turning AI off is a personal choice, not an industry equilibrium — labor markets already price agent leverage.
Security/malware/obscure langs still resist vibe workflows; niches remain for craft.
Klos has a dog in the fight (Scryer) — evaluate claims against your repo, not the essay alone.
Practical Takeaway
Separate vibe mode (brain off) from agent-assisted engineering (brain on).
Stop expecting prose specs to enforce anything.
Prefer tools that show blast radius and drift before merge.
Keep tests as intent anchors — but constrain who writes them.
Invest in harness + MCP + design docs that agents and humans share — see skills registry and loops on explainx.ai when you’re ready to operationalize.
What the HN thread got right
Pushback that “turning your brain off is optional” is true for agent-assisted work and false for Karpathy’s original vibe definition. Studies on skill atrophy are real; so is the productivity win on solo greenfield apps. The team-scale failure mode bentobean described — twenty AI-empowered people melting a shared codebase — is exactly why shared models / claims graphs matter more than better personal prompt templates. Pair-programming-style interactive agents (shared editor, interruptible plans) are the UX HN wants; most commercial harnesses still optimize for autonomous token burn.
A concrete audit you can run Monday
Pick one recent agent PR:
List the intent in five bullets (what should be true after merge).
Diff the PR and mark each file as supports / unrelated / contradicts.
Note anything shipped that wasn’t in the plan essay.
Note anything in the plan that never landed.
Ask whether a new teammate could reconstruct intent without the chat log.
If steps 3–5 hurt, you’re in Klos’s casino. Markdown specs alone won’t fix it; you need either compilation (CodeSpeak-shaped) or a shared navigable model (Scryer-shaped) — or a ruthless human review culture that treats agent output like junior-dev PRs with no ego.
For product managers who vibe-code prototypes, keep the PM vibe-coding guide for process, then graduate to trust tooling before the prototype becomes production. And if your anxiety is cultural as much as technical — “are we deskilling an entire generation?” — read that debate next to Yacine Kache’s programming / vibecoding thread and decide what craft you still want humans to own.
Primary source: Alexander Klos — “How Do We Stop Vibe Coding?” (alexklos.ca / prohobo, July 24, 2026) · Hacker News thread · Karpathy No Priors remarks · Booch golden-age framing as cited in the essay.
Tooling claims for CodeSpeak and Scryer reflect the author’s July 24, 2026 descriptions and may change. This article is analysis for builders, not an endorsement of any commercial SDD product.
