Vibe Coding Is Maturing — But Enterprises Need More Than Vibes
Vibe coding shifted how we build software overnight. But what started as playful experimentation is hitting real limits in production environments. Here's why spec-driven AI development is the logical next step — and what that means in practice.

Datum
Vibe Coding Is Maturing — But Enterprises Need More Than Vibes
When Andrej Karpathy coined "vibe coding" in February 2025, it captured something real. "You fully give in to the vibes, embrace exponentials, and forget that the code even exists." You describe what you want, the model delivers, you paste the error back, and somehow it works. Productivity studies backed this up: developers completed tasks up to 55% faster with AI code generation.
A year later, Karpathy himself says vibe coding is passé. What replaced it? He calls it "Agentic Engineering."
What Changed
85% of developers now use AI tools regularly. That's not a trend anymore — it's baseline. Claude Code, Cursor, GitHub Copilot: they've landed in most development environments.
What also changed: the hangover.
A GitClear study analysing 211 million lines of code found that refactoring activity dropped ~60% between 2021 and 2024, while copy-paste instances rose 48%. In some projects, code duplication increased eightfold with AI-assisted development. Vibe-coded projects accumulate technical debt three times faster than traditionally built software.
89% of CTOs surveyed reported production incidents directly caused by AI-generated code. That's no longer an abstract risk.
In February 2026, Moltbook — a social network for AI agents, built entirely by vibe coding — shipped to production with a publicly accessible Supabase database and no access controls. Speed as the only metric, consequences as the only teacher.
Vibe coding has no inherent specification discipline
Projects start euphorically — the AI delivers fast, everybody is energised. But after a bit, it starts unravelling. Decisions made in long chat threads are no longer traceable. Context is gone. The AI fixes one file and quietly breaks three others it never saw.
This is structural. Vibe coding has no inherent specification discipline. Requirements drift. Architecture decisions evaporate into chat history. What looked like a fresh prototype at week two is an unmaintainable tangle of well-intentioned prompts at month three.
This isn't a failure of AI tools. It's a methodology problem.
Spec-Driven Development
The response crystallising across the industry is spec-driven development — specification first, then implementation.
The core idea isn't new. The execution with AI agents is. You write a formal, machine-readable specification before any code is generated. That spec becomes the single source of truth for everything downstream: code generation, tests, documentation, validation, and AI agent guidance. Decisions are versioned. Audit trails appear automatically. Multiple teams can collaborate because the spec is the shared understanding — not a chat thread only one person remembers.
Where Shipwright Fits
I built Shipwright precisely because I didn't like how I worked with replit - chat, implementation, correction and the loop starts again. No structure, no thinking process, just start working... That is what I wanted to change. Shipwright is an open-source AI framework that implements spec-driven development as a seven-phase SDLC pipeline: from project decomposition and planning through TDD implementation, code review, deployment, and changelog generation.
The idea is simple: the spec lives in version control, every phase gate enforces it, and AI agents operate within that structure rather than improvising from a blank context window. It doesn't eliminate the need for engineering judgment — it gives that judgment a durable place to live.
The Real Trade-off — It's Smaller Than You Think
The classic objection to spec-driven development: it's slow. You spend weeks writing specs before anyone writes code. Analysis paralysis. Documentation drift.
With Shipwright, that objection largely disappears. The AI conducts the specification interview — asking the questions that need asking about scope, constraints, edge cases, compliance requirements. You answer. The AI writes the spec. The overhead is a structured conversation, not a waterfall document. Minutes, not weeks.
And because the spec lives in version control alongside the code, documentation stays current automatically. Every build, every change, every deployment updates the relevant documentation as part of the pipeline. There's no drift because there's no manual sync step to forget.
The practical trade-off: a bit more effort upfront — the thinking you should be doing anyway — with maximum payback across the entire lifecycle. Every phase downstream runs faster and more reliably because the context is already there.
The Practical Answer
Vibe coding still makes sense for prototypes, spikes, and exploration — exactly what Karpathy originally described. But for production systems, the transition to structured workflows isn't optional, it's eventual.
The competitive advantage in 2026 isn't which AI tool you're using. It's whether your process captures the decisions that matter before they vanish into a chat thread.
Sources:
- The New Stack: Beyond vibe coding: the case for spec-driven AI development
- DZone: Vibe Coding Is Not a GenAI SDLC Strategy
- Augment Code: Vibe Coding vs Spec-Driven Development
- The New Stack: Vibe coding is passé — Karpathy's new term
- Wikipedia: Vibe coding
- Salesforce Ben: 2026 Predictions: The Year of Technical Debt
- Towards Data Science: The Reality of Vibe Coding: AI Agents and the Security Debt Crisis
- Itential: Spec-Driven Development: The Fix for Vibe Coding's Flaws
