What is vibe coding in 2026? Exactly one year ago — February 2, 2025 — Andrej Karpathy posted the tweet that started it. But here's the thing: what Karpathy meant and what "vibe coding" means now are two different things.
When Andrej Karpathy first used the term, he meant something specific. You tell the agent what to do and evaluate the result. The key "vibe" is that you don't dig into HOW the code is written. Something doesn't work? Just write the next prompt, and so on.
Now "vibe coding" often means any AI-assisted development at all. Though honestly — in many cases, that's exactly how it works. We're already seeing derivatives — vibe design, vibe ops, vibe anything. But professional developers need more than vibes. That's where approaches like spec-driven development come in — and that's what this series is about.
Let's be honest: when you accept the agent's changes without looking, you catch yourself thinking — is this actually done right, can I trust what the LLM generated without reviewing it? When a colleague says they vibe-coded some functionality — do you picture thoughtful architecture or more like "somehow works"? Is vibe coding cheating and irresponsibility, or a perfectly professional approach?
What I know for certain — AI development is here, whatever we call it. According to Stack Overflow 2024, 76% of developers use or plan to use AI tools. About a third of senior developers — those with 10+ years of experience — generate more than half their code with AI.
Let's figure out what exactly we can do with AI. Different approaches exist, giving more control at different stages of work. Choosing the right one and applying it consciously — that's the professional approach. In this article, I'll cover vibe coding itself and spec-driven development — then we will go though other approaches in follow up parts.
Vibe Coding: The Entry Point
Credentials:
- Coined by Andrej Karpathy (February 2, 2025)
- Collins Dictionary Word of the Year 2025
- Wikipedia article documenting the phenomenon
- Referenced in academic papers: arXiv 2512.14012 "Professional Software Developers Don't Vibe, They Control" (University of Michigan, December 2025)
What it is:
- Iterative prompting until code works
- No upfront planning, minimal specification
- Trust AI to handle details, fix issues as they appear
- Evaluate results visually or by running the code
Vibe coding is a great approach. Really. I use it often myself — though I still use my keyboard for this. It works perfectly for non-critical features, dev tools, prototypes, experiments.
When do I use it? When the result is easy to evaluate visually. When scope is obviously localized to one or a few files.
Do I look at the diff? Honestly, almost always. But I don't check every line — I quickly assess which files changed, what was added or removed. This lets me catch moments when the AI "went off track" fast.
Does it produce bad code? Maybe, but there are simple ways to improve quality: describe code style in CLAUDE.md (or AGENTS.md), describe the architecture of the relevant part, provide examples of existing similar features as templates, ask the agent to run typecheck, linter, and prettier when done.
On the other hand, there are pitfalls. 27% of companies have banned AI tools at least temporarily over privacy and security concerns. Apple restricted ChatGPT and Copilot. Amazon banned ChatGPT after discovering responses resembling internal data. Samsung had an employee leak confidential information through ChatGPT.
Be careful with security. Don't use vibe coding on critical infrastructure. Especially where you can't easily roll back changes.
You might ask — is it even legitimate to use vibe coding at work? Absolutely! First, you save significant energy on simple things. Your brain resources are limited — delegate simple tasks and routine to AI. It'll do it faster, and you can spend your focus on more important stuff. Second, techniques exist beyond vibe coding that significantly improve development quality and reliability.
So what are these methods?
Spec-Driven Development: Structure First
Credentials:
- Formalized by GitHub Engineering Team: GitHub Spec Kit (open-source, MIT license, September 2025)
- Official announcement: "Spec-driven development with AI: Get started with a new open source toolkit" (GitHub Blog, September 1, 2025)
- Analysis by Martin Fowler: "Understanding Spec-Driven Development"
- Featured in Thoughtworks Technology Radar Volume 33 (November 2025)
- Production tools: AWS Kiro (spec-driven IDE, public preview July 2025), Tessl Framework (closed beta, 10,000+ specs in registry)
- Community solutions: BMAD Method (21 specialized agents), OpenSpec (lightweight CLI, brownfield-first)
- Widely used by: Claude Code users, enterprise teams, GitHub Copilot Workspace
How it works:
Write detailed specification BEFORE code. Spec includes requirements, architecture, API contracts, error handling, edge cases. AI executes against the spec. The spec becomes living documentation — often saved as CLAUDE.md or .spec files in project root.
Human focuses on WHAT. AI handles HOW.
This is actually my main approach for large projects. Especially when adding a new section or functionality that didn't exist before. Time spent writing spec is often significant. But it gives good control — modern models follow instructions pretty well. You can vary the degree of freedom for the agent: you can specify file and folder names yourself, or just give an outline of the solution.
After spending half a day on specification, you watch Claude Code finish implementation in 10 minutes. Feels unfair, but the results are solid.
The spec becomes reference for future work. Months later, a new session starts with "read the spec, find the code" — and the agent has full context immediately.
Long-term challenges:
To continue development later, you need to keep documentation current. Specs often start drifting from real code even during initial implementation. Details change, paths get renamed during refactoring. Keeping the spec up to date adds cognitive load. My solution: commit spec changes alongside code changes. Treat documentation as part of the codebase. Instruct the AI agent to always update the document after completing any task.
Pro tip:
Use Claude Desktop for spec development: give it Filesystem MCP for code access, enable web search for current documentation. Brainstorm the solution together with AI, define architecture — and only then ask it to write the spec.
What's Next
This was Part 1 of the "Beyond Vibe Coding" series. We covered vibe coding itself and spec-driven development — two ends of the planning spectrum.
In Part 2, we'll explore the autonomy spectrum: AI pair programming (where you stay in the driver's seat) versus agentic coding (where you let the AI run free). Plus the infamous Ralph Loop — 14-hour autonomous coding sessions.
In Part 3: Human-in-the-Loop patterns and TDD + AI — when you need guardrails and quality guarantees.
Different approaches for different stakes. Choose consciously.
What's your experience with vibe coding? Do you use specs, or prefer to iterate? Share in the comments — I'm genuinely curious what works for you.
Top comments (0)