Vibe coding is winning. Here’s why the fixes aren’t working yet.
Andrej Karpathy told the No Priors podcast in March 2026 that he hasn’t typed a line of code since December 2025. That’s roughly three months without touching the keyboard for the person who coined the term “vibe coding.” He called the shift “extremely large” and said most people haven’t grasped how dramatic it is.
The author of this piece says the same is true for them. Coding agents are no longer a novelty. They’re the default workflow for a growing share of working developers. And that’s where the anxiety starts.
The abstraction argument
Grady Booch, co-creator of UML, frames this as the third golden age of software engineering. His timeline: the first age was the algorithm (late 1940s to 1970s), the second was object-oriented abstraction (1970s to 2000s), and the third, starting around 2000, is the age of systems where libraries, platforms, and APIs abstract away entire subsystems. Booch says AI accelerated this third age but didn’t start it.
His more pointed comparison is between AI coding agents and the arrival of compilers in Grace Hopper’s era. Compilers abstracted away the machine. Agents abstract away the code itself. You can now generate code directly from intent, which is something that killed model-driven development the last time anyone tried it.
️ What vibe coding actually breaks
The author identifies two core failure modes. First, vibe coding damages your understanding of your own codebase. You lose track of dead code, you can’t explain the architecture, and your mental model is vague and borrowed from whatever experience you had before the agent showed up. Second, the output is unreliable because prompts are under-specified, natural language is lossy, and code generation is non-deterministic.
There’s also no blast radius visibility. The agent writes a plan, but the plan doesn’t show you what will change across the full codebase before you approve it. It won’t flag partial implementations or omissions. The plans have no learnable structure, so you can’t build intuition about what to watch for. The result is what the author calls the black-box effect: you gradually stop being rigorous, and eventually you’re pushing commits without understanding what you shipped.
Why the popular fixes don’t hold up
The author runs through the current crop of solutions and finds each one wanting. The core problem is trust: you can’t trust your understanding of the codebase, and you can’t trust the agent did what you asked. Good solutions need to minimize how much you have to trust the agent’s output, and do it without adding more friction than vibe coding itself.
Markdown specs look like a system but are really just prompt engineering in a folder. There’s no enforcement mechanism. Asking an agent “does the code follow the spec?” fails because there’s no shared syntax. The agent grades its own homework.
Skills (context injected conditionally by task) have the same structural problem. The agent still decides whether to follow them. The author points to a large “QA” skill file from the gstack project as an example of what this looks like in the wild, and argues a simple “find and fix bugs” prompt would perform as well or better.
EARS-based spec tools like Kiro take a more interesting approach. EARS (Easy Approach to Requirements Syntax) formats requirements as structured WHEN/THEN and IF/THEN statements rather than prose, which is genuinely useful for both the developer and the agent. Kiro also uses hooks to force the agent to react to triggers and follow defined steps. But the author says it falls apart in two ways: feature specs accumulate without composing into an auditable graph, and nothing ever reconciles requirements against shipped code.
Test-driven development gets closer because a test name is a statement of intent anchored to real code. But the author notes that developers typically make the agent write the tests, which reintroduces the same trust problem. Writing tests manually requires knowing the implementation, which defeats the point of abstracting code away in the first place.
As a data point on how hard this is: Tessl raised $125M on the promise of spec-driven development and has since quietly shifted its pitch toward “skills are the new code.”
Two tools heading in the right direction
The author identifies two projects they believe are actually tackling the trust problem. One of them is their own tool.
CodeSpeak, started by Andrey Breslav (creator of Kotlin), bets that trust can be compiled away. You write markdown specs organized into modules that import each other. A codespeak build command compiles them into working Python, Go, or TypeScript you’re not really meant to review. Specs are validated for consistency before a build, tests run after it, and a codespeak takeover command can reverse-generate specs from an existing codebase. A requirements layer maps natural language conversations to structured requirements, which in turn map to the code files that implement them, with drift flagged when changes diverge.
Scryer (the author’s own tool, six months in development) takes the opposite bet: trust in the agent is irreducible, so make it as cheap as possible to spend. It’s model-driven development for coding agents. You and your agent share a C4-style hierarchy where each node states what it’s responsible for in short, language-independent claims, mapped to source lines and the tests that prove them. The agent reads and writes the model over MCP. You browse it as wiki-style pages and diagrams instead of reading code. When you plan a change, it shows as a git-style diff over the entire model, which is the blast radius view the author says is currently missing from every other tool. A deterministic observability layer tracks what’s built versus planned and where code has drifted from the model.
The operator takeaway
If your workflow depends on coding agents and you’ve felt the slow erosion of confidence in your own codebase, the author’s diagnosis is worth reading. The practical signal: markdown spec rituals probably aren’t fixing the trust problem, they’re just making the workflow feel more rigorous. The tools that might actually help are CodeSpeak and Scryer. Both are early, and the space is still actively experimenting.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
