DEV Community: Henry Bonson

What Is Vibe Coding in 2026? One Year From Karpathy's Tweet

Henry Bonson — Mon, 02 Feb 2026 09:03:12 +0000

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.

// Detect dark theme var iframe = document.getElementById('tweet-1886192184808149383-633'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1886192184808149383&theme=dark" }

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.

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

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.

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.

Inside Claude's Sandbox: What Happens When Claude.ai Creates a File

Henry Bonson — Wed, 07 Jan 2026 15:31:12 +0000

Did you know that every Claude conversation runs in its own sandbox container with a real filesystem? Understanding how it works — and where Claude saves files — gives you a significant advantage. Without this knowledge, it's easy to lose work or spend time debugging "missing" files that aren't actually missing.

Let me show you what's actually happening under the hood.

Note: File creation requires a paid plan (Pro, Max, Team, or Enterprise). Free users only have access to Artifacts.

Claude's Sandbox Filesystem Structure

Here's the thing about Claude's sandbox: it's a proper Ubuntu container with a defined directory structure. Knowing these paths saves debugging time.

You can explore this yourself. Start a new Claude chat and try this prompt:

view /mnt/user-data/

The critical distinction: files in /mnt/user-data/ persist across sessions. Files in /home/claude/ might disappear when the container times out.

Knowing this structure lets you navigate confidently and give Claude precise instructions — "save to outputs," "move from home directory," "show me what's in uploads."

Pro tip: Files in /home/claude/ can still be opened in the sidebar — click the filename in Claude's tool output (when it creates or edits a file). But they won't appear in the sidebar's file list until moved to outputs.

What Happens When Claude Creates a File

When you ask Claude to create a file, it follows a two-step process. First, Claude creates the file in /home/claude/. Then, after finishing work on it, Claude copies it to /mnt/user-data/outputs/ using a tool called present_files.

This is where things get interesting — and where most confusion happens. When Claude uses present_files, you end up with two copies of the same file. One in Claude's working directory, one in outputs. This duplication is the source of most confusion around file management.

Understanding this Claude file creation process is key to avoiding the "where did my file go?" frustration.

Common Claude File Problems and Solutions

In simple scenarios, Claude handles files well. But in longer conversations with multiple file operations, things can go sideways. The most common issues are: Claude created a file but didn't copy it to outputs (invisible file), Claude edited the version in /home/claude/ instead of /mnt/user-data/outputs/ (changes don't appear), and confusion about which files you shared during the conversation.

Don't panic. Once you understand the filesystem layout, fixing these is straightforward.

How Claude Creates Files: Step-by-Step Walkthrough

Let me demonstrate with a real example. We'll build a news compilation document and watch exactly how Claude handles the file through multiple edits.

Creating an Internal File

Follow along in a fresh Claude chat — you can copy-paste these prompts directly. I started a conversation with this prompt:

Your task is to find and compile AI news into a single markdown document.

Workflow:
1. I give you a topic or search query
2. You search, find relevant news, select the best match, append to document
3. We repeat until I say "done"
4. You show me the complete document for final review

Rules:
- One news item per search
- All items go into the same file (append, don't overwrite)
- Include: headline, source, date, 2-3 sentence summary

Search for: the funniest AI news from the last two months

Here's what happened:

Notice: I deliberately didn't specify where to create the file. Moreover, I hinted to Claude that work on the file would continue through my subsequent requests — this pushes it toward working with an internal file. In practice, this is a common scenario: Claude works with files internally without showing them to the user until completion. As a result, Claude created ai-news-compilation.md in /home/claude/. The file is NOT visible in the sidebar.

Appending Content

I continued with another request:

Now find the most important news about AI image generation for the last two months

Claude uses str_replace to append content. The file still isn't in the sidebar — it's an internal working file.

Viewing Internal Files

What if I want to see the contents? Click the filename in Claude's tool output.

The file opens in the sidebar preview panel:

But notice: it's a preview, not an entry in the file list. This file is still in /home/claude/ and could disappear.

Moving to Outputs

To make the file persistent and downloadable, ask Claude to move it:

move this file to /mnt/user-data/outputs/

Claude runs mv /home/claude/ai-news-compilation.md /mnt/user-data/outputs/. Now it appears in the sidebar's file list. Since we moved (not copied), there's only ONE file to work with. Clean.

The "Wrong File" Problem

Let's test another scenario. Start a new conversation with the same initial news compilation request and add a few news items first.

This time, let's see what happens when Claude uses present_files:

present this file to me

The file appears in the sidebar. Now continue adding news:

Find the most performant AI coding agent released in the last two months

Check the file in sidebar.

What happened? Claude edited a file in /home/claude/ — not the one in /mnt/user-data/outputs/. If present_files was used earlier, both locations have the file. Claude picked the working copy.

The sidebar shows the old version. The new content exists only in /home/claude/.

This situation is common when working with complex multi-step scenarios. Claude doesn't always track which copy you care about — especially in longer conversations with many file operations.

The Fix

Simple solution:

move this file from /home/claude to /mnt/user-data/outputs/ (override the existing file)

The updated file overwrites the old one. Sidebar now shows all content including the latest addition.

Summary

What we learned: Claude creates working files in /home/claude/ by default. Files only appear in sidebar when in /mnt/user-data/outputs/. The present_files tool creates a copy, resulting in two files. Claude may edit the "wrong" file when duplicates exist. Solution: explicitly move or copy to outputs when needed.

Claude File Commands: Quick Reference

Claude uses these tools internally: view for reading files and directories, str_replace for editing content, create_file for new files, bash_tool for shell commands, and present_files for making files downloadable.

You interact with natural language. Try these prompts:

"Show me what's in /mnt/user-data/" — triggers view
"Create a file test.txt with 'hello world'" — triggers create_file
"Run ls -la /home/claude/" — triggers bash
"Copy test.txt to /mnt/user-data/outputs/" — triggers bash with cp
"Show me the file for download" — triggers present_files

Tool names are implementation details. Claude picks the right one automatically.

Why This Matters: Filesystem MCP

Understanding the internal filesystem is one thing. But when you add Filesystem MCP to the mix, there are now two filesystems Claude can work with — and this is where confusion multiplies. Claude might read from one and write to another without you noticing. I've been burned by this more than once: expecting a file on my local disk, finding it only in the sandbox, or vice versa. In these scenarios, explicit instructions matter.

Filesystem MCP gives Claude access to your local disk. True persistence, files land directly in your project directory, ready for version control. Downside: requires setup and only works in Claude Desktop (not the web interface).

But here's the catch. Adding MCP complicates the system: it's no longer enough to say "create a file" or "copy file to folder." You need to be more precise with your commands and clarify which filesystem you mean — the internal sandbox or your local disk via MCP.

Use the Claude sandbox environment for quick explorations. Use MCP for serious projects where files need to persist.

The most productive approach — edit files with Claude in its sandbox, then save them to disk:

Bonus: The Two-Tab Experiment

Let's have some fun to wrap up, and also confirm that we have access to the same container when opening the same chat in different tabs or in Claude Desktop.

Try this in a new Claude chat:

Tab 1:

Create a file `/home/claude/test.txt` with a content "hello world"

Now open this same chat in a second browser tab (keep the first one open):

Tab 2 (same chat):

Change the file content to "hello claude"

Switch back to Tab 1 (don't refresh):

Tab 1:

output the content of that file

Claude reads the file:

The content is "hello claude". Claude in Tab 1 is confused — it doesn't see the modification command in its conversation history, but the file has changed.

This confirms: the sandbox container is shared across all sessions of the same chat. The filesystem is consistent, even if conversation history isn't.

What's Next

That's the filesystem. No magic, just directories and persistence rules.

Now you know how it works — which means you can direct Claude precisely where to save, what to edit, and when to move files to outputs. Next time something seems off, you'll know exactly where to look.

Go build something great with Claude. Your files will be exactly where you expect them.