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.

{% embed https://x.com/karpathy/status/1886192184808149383 %}

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.

![Comic: Senior developer explains you need to understand code first, junior admits he builds first then figures out structure](https://cdn.banatie.app/blog/henry-devto/img/c0c3ad3d-13ee-4dbf-9f4a-5db3bf64b378)

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.

![Infographic: AI adoption among developers - 76% use AI tools, productivity and trust metrics](https://cdn.banatie.app/blog/henry-devto/img/1175042e-1e41-4675-8fb3-25febe7cedea)

Here's what's out there — and what I actually use. Different approaches exist, giving more control at different stages of work. The point is knowing when to use which. In this article, I'll cover vibe coding itself and spec-driven development — then we'll go through other approaches in follow-up parts.

---

## Vibe Coding: The Entry Point

**Credentials:**
- Coined by [Andrej Karpathy](https://x.com/karpathy/status/1886192184808149383) (February 2, 2025)
- [Collins Dictionary Word of the Year 2025](https://www.collinsdictionary.com/woty)
- [Wikipedia article](https://en.wikipedia.org/wiki/Vibe_coding) documenting the phenomenon
- Referenced in academic papers: [arXiv 2512.14012](https://arxiv.org/abs/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.

![Comic: Developer shows Karpathy's vibe coding tweet, colleague says now he can do this officially](https://cdn.banatie.app/blog/henry-devto/img/c4c24f43-d0ac-45d2-84d0-6cb0624a8957)

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.

![Infographic: Vibe Coding DO and DON'T - when to use and when to avoid](https://cdn.banatie.app/blog/henry-devto/img/c5735016-326f-48f6-b8b7-cb35890739a8)

You might ask — is it even legitimate to use vibe coding at work? Absolutely! First, you only have so much attention in a day. I'd rather save my focus for the hard stuff — and delegate simple tasks and routine to AI. It'll do it faster anyway. 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](https://github.com/github/spec-kit) (open-source, MIT license, September 2025)
- Official announcement: ["Spec-driven development with AI: Get started with a new open source toolkit"](https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/) (GitHub Blog, September 1, 2025)
- Analysis by [Martin Fowler](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html): "Understanding Spec-Driven Development"
- Featured in [Thoughtworks Technology Radar](https://www.thoughtworks.com/en-us/radar) Volume 33 (November 2025)
- Production tools: [AWS Kiro](https://aws.amazon.com/startups/prompt-library/kiro-project-init) (spec-driven IDE, public preview July 2025), [Tessl Framework](https://tessl.io/blog/tessl-launches-spec-driven-framework-and-registry/) (closed beta, 10,000+ specs in registry)
- Community solutions: [BMAD Method](https://recruit.group.gmo/engineer/jisedai/blog/the-bmad-method-a-framework-for-spec-oriented-ai-driven-development/) (21 specialized agents), [OpenSpec](https://mcpmarket.com/server/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.

You decide WHAT to build, define the STRUCTURE, go as deep as you need. AI carefully handles the implementation.

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.

![Comic: Developer brags AI generated code in 15 minutes, colleague points out he spent 6 hours writing the prompt](https://cdn.banatie.app/blog/henry-devto/img/79c4c6fd-129a-499f-be04-f503eff018b5)

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.

No single right answer — pick what fits the situation.

---

*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.*
