Vibe Coding 101: Notes from a Developer Who Got Tired of Writing Code by Hand

작성자

카테고리:

← 피드로
DEV Community · Putu Adi · 2026-06-18 개발(SW)

Vibe Coding 101: A Practical Developer’s Guide (2026)

My personal notes and a guide for anyone who wants to start vibe coding properly — not just typing prompts and hoping the AI figures it out.

Table of Contents

What is Vibe Coding?

The term vibe coding was coined by Andrej Karpathy in early 2025. The idea is simple: you describe your intent and the outcome you want — not a detailed technical spec — and the AI writes the code.

What changed in 2026: this is no longer an experiment. Vibe coding has become a recognized development methodology, and the tooling is mature enough to use on real production projects.

But there’s one thing that frustrates most beginners: AI works from context. Give it the wrong context and the output will miss — or worse, look correct but actually be wrong.

This guide is about how to properly “brief” your AI before you start building together.

1. Choose Your Editor / Environment

First question: do you want a GUI editor or a CLI agent?

GUI Editors (IDE-based)

Best if you prefer visual feedback, editing directly in the editor, and strong codebase awareness.

Editor Character Best For Cursor AI-native, built on VS Code. Best for single-session work and codebase context. Developers who want a fast, familiar AI copilot Windsurf (now Devin Desktop) Agentic, proactive — the AI acts without being asked. Cascade agent for multi-file edits. Teams that want AI to take initiative Antigravity Multi-agent: run up to 5 agents in parallel inside one editor. Early-adopter energy. Parallel task experiments, power users VS Code + Copilot Familiar, massive ecosystem, but the AI feels “bolted on”. Developers who don’t want to switch editors

Note (June 18, 2026): Windsurf officially rebranded to Devin Desktop under Cognition on June 2, 2026. Cursor remains the most stable choice for teams; Antigravity is the most interesting for multi-agent workflows.

CLI Agents (Terminal-based)

Best if you prefer the terminal, want full control, or need tight git workflow integration.

Agent Default Model Character Claude Code Claude Opus/Sonnet Terminal-first, agentic, supports subagents. Bundled with Claude Pro ($17/mo). Gemini CLI Gemini 3.1 Free to start, Google integration. Great if you’re already in the Google ecosystem. OpenAI Codex CLI GPT-5.x Latest from OpenAI, paired with the ChatGPT app. Windows desktop client available May 2026.

Personal tip: If you use Claude Code, just run claude in your project root. The difference is immediately noticeable — the agent reads context from your entire codebase, not just the active file.

2. Pick the Right Model

As of this writing (June 18, 2026), here’s the most relevant model landscape for vibe coding:

Model Comparison

Model Coding Score (SWE-bench) Price (per 1M tokens) Best For Claude Opus 4.8 88.6% Verified $5 / $25 Primary coding agent, long-running tasks, large codebases Claude Sonnet 4.6 ~85% $3 / $15 Best daily driver. 98% of Opus quality at 60% less cost GPT-5.4 74.9% $2.50 / $15 All-rounder, largest ecosystem Gemini 3.1 Pro 63.8% $2 / $12 Long context (1M tokens), data-heavy apps DeepSeek V4 Competitive $0.14 / $0.28 Budget option, self-hostable Claude Haiku 4.5 ~70% $1 / $5 Quick edits, subagent tasks, high-volume work

How to Choose Practically

New project, small-to-medium codebase?
→ Claude Sonnet 4.6 (best price-to-performance sweet spot)

Large codebase, complex agentic tasks?
→ Claude Opus 4.8

Already in the OpenAI ecosystem / using Cursor?
→ GPT-5.4

Lots of data, very long context needed?
→ Gemini 3.1 Pro

Tight budget, repetitive tasks?
→ DeepSeek V4 or Haiku 4.5

Enter fullscreen mode Exit fullscreen mode

Pro tip: Don’t default to the most powerful model for everything. Routing tasks to the right model tier can cut your AI bill by 2–5x without any quality loss. Quick edits and simple tasks? Haiku is more than enough.

3. Give the AI “Knowledge” — Use a Skills Library

This is the part most people skip.

AI coding agents work entirely from context. Every session starts fresh — there’s no memory from the previous one. A skills library is how you give the agent reactivatable knowledge whenever it needs it.

Think of it this way: if the AI is a new developer joining your team, Skills are the onboarding docs they read before their first day.

Skills Libraries I Use

1. Superpowers (skills.sh/obra/superpowers)

This one is a game-changer. Superpowers isn’t just a collection of skills — it’s a software development methodology that runs on top of your agent.

The workflow Superpowers enforces:

Brainstorm → Design → Plan → Implement (TDD) → Review → Merge

Enter fullscreen mode Exit fullscreen mode

Why does this matter? Without this structure, the AI will start writing code before you’ve even agreed on what you’re building. Superpowers forces the agent to ask first, code second.

Install in Claude Code:

/plugin install superpowers@claude-plugins-official

Enter fullscreen mode Exit fullscreen mode

Key features:

  • Hard gate before coding: The agent won’t write a single line until you’ve approved the design
  • TDD enforcement: Always write a failing test first, then implement
  • Subagent-driven: Dispatches parallel subagents for execution with a two-stage review
  • Git worktree workflow: Every task runs on its own branch — no clobbering each other

Repo: github.com/obra/superpowers — 190K+ GitHub stars at time of writing.

2. Anthropic Official Skills (skills.sh/anthropics/skills)

The official Anthropic skill library for Claude Code. Includes:

  • frontend-design — design system, tokens, typography
  • docx, pdf, pptx — create and edit documents
  • file-reading, pdf-reading — read various file formats

3. Figma / Design Skills

If you work from Figma designs to code, these skills give Claude context about your design tokens, component names, and naming conventions from your Figma project.

How Skills Work

Skills are structured .md files containing explicit instructions. The agent reads them when needed and follows them as a process — not just a prompt, but an activatable workflow.

User: "Build a login feature"
Agent: [Reads brainstorming skill]
       "Before we start, I have a few things to clarify..."
       [Asks 3–4 context questions]
       [Presents design options]
       "Please review this design before I begin implementation."

Enter fullscreen mode Exit fullscreen mode

Compare that to without skills:

User: "Build a login feature"
Agent: [Immediately writes 300 lines of code]
       → Auth stack turns out to be wrong, pattern doesn't match codebase
       → 2 hours of revision wasted

Enter fullscreen mode Exit fullscreen mode

4. Set Up Starter Documentation

Before starting a vibe coding session, the single most impactful thing you can do is create initial project documentation the agent can read at the start of every session.

Every AI coding tool has its own “magic file” that’s loaded automatically when a new agent session begins — this is how you provide context without re-typing it every time.

CLAUDE.md vs GEMINI.md vs AGENTS.md — Which One?

This is the most common question, especially if you use more than one tool.

The short answer: every tool has a different filename, but the purpose is identical — give the agent context before it starts working.

Side-by-Side Comparison

CLAUDE.md GEMINI.md AGENTS.md .cursorrules Read by Claude Code Gemini CLI Codex CLI, Cursor, Gemini CLI, Windsurf, Copilot, 60K+ tools Cursor (legacy) File location Project root or .claude/ Project root or ~/.gemini/ Project root, subdirectories, ~/.codex/ Project root Hierarchy Nested folder support Reads up & down the folder tree Walks from root to working dir Single file Open standard? Anthropic-only Google-only ✅ Yes — Linux Foundation (AAIF) Cursor-only Claude Code reads it? ✅ Native ❌ No Via symlink / @AGENTS.md import ❌ No Exclusive features Hooks, tool permissions, Skills integration Plan Mode, Google Search grounding AGENTS.override.md for local overrides Glob-based rule scoping Best for Teams fully on Claude Code Teams using Gemini CLI Multi-tool / mixed teams Solo Cursor users

Multi-Tool Strategy: One File for All

If you or your team uses more than one tool (e.g. Claude Code for heavy lifting, Gemini CLI for quick exploration), there are two popular approaches:

Option A: AGENTS.md as source of truth + symlinks

The community’s most recommended approach. Write one file, symlink the rest:

# In project root
touch AGENTS.md          # Write all context here

# Create symlinks for other tools
ln -s AGENTS.md CLAUDE.md
ln -s AGENTS.md GEMINI.md

Enter fullscreen mode Exit fullscreen mode

Result: update one file, all tools stay in sync. No drift between files.

Note: Claude Code does not read AGENTS.md natively. Use a symlink, or manually import it inside CLAUDE.md with the @AGENTS.md syntax.

Option B: AGENTS.md for universal rules + per-tool files for specific features

project/
├── AGENTS.md          # Universal: tech stack, conventions, rules
├── CLAUDE.md          # Claude-specific: hooks, tool permissions, skills
└── GEMINI.md          # Gemini-specific: instructions to prevent scope expansion

Enter fullscreen mode Exit fullscreen mode

This works well when you need different instructions per tool — for instance, Gemini needs explicit instructions not to modify files outside the task’s scope (a known Gemini behavior that differs from Claude).

My Project Structure

project/
├── AGENTS.md                # Source of truth — read by all tools
├── CLAUDE.md -> AGENTS.md   # Symlink to AGENTS.md
├── GEMINI.md                # Gemini-specific tweaks (scope control)
├── .claude/
│   └── settings.json        # Claude Code config (permissions, model)
├── .codex/
│   └── config.toml          # Codex CLI config
└── docs/
    ├── architecture.md
    ├── business-logic.md
    └── tech-stack.md

Enter fullscreen mode Exit fullscreen mode

What Goes Inside the Config File?

This template works for AGENTS.md, CLAUDE.md, or GEMINI.md — same structure, different filename.

Golden rule: A good config file is 50–200 lines. Beyond that, the model starts ignoring parts it deems irrelevant. Only write what the AI can’t infer from the code itself.

Minimal contents:

# Project: [Project Name]

## Context
[One paragraph: what this app does, who it's for, what problem it solves]

## Tech Stack
- Framework: Next.js 15 (App Router)
- Database: PostgreSQL + Prisma
- Auth: Clerk
- Styling: Tailwind CSS v4

## Folder Structure
- Components: `/components`
- Hooks: `/hooks`
- API routes: `/app/api`
- Types: `/types`

## Coding Rules
- Always use TypeScript strict mode
- Never use `any` — use proper types
- Naming: camelCase for functions, PascalCase for components

## Critical Business Rules
- [Business rules the AI must never violate]
- [Example: prices are always in the smallest unit (cents), never decimals]

## Do NOT Do
- Don't change the database schema without discussing first
- Don't install new libraries without confirmation
- Don't modify files outside the scope of the requested task

## Key Commands
- Dev: `npm run dev`
- Test: `npm run test`
- Build: `npm run build`
- Lint: `npm run lint`

Enter fullscreen mode Exit fullscreen mode

For Gemini CLI — add this section to GEMINI.md to prevent scope expansion:

## Gemini-Specific Instructions
- Do not modify files unrelated to the current task
- Always confirm before creating new files outside the existing structure
- If unsure about scope, ask — never assume

Enter fullscreen mode Exit fullscreen mode

Scenario 1: Starting from Scratch ✨

This is the ideal situation. You can set everything up correctly from the beginning.

Steps:

  1. Generate initial config file — ask Claude to help create one based on your project brief
  2. Install Superpowers before writing the first line of code
  3. Define your folder structure so the AI knows where things belong
  4. Run a brainstorming session with the agent before starting any feature
# In the terminal, with Claude Code running:
"I want to start a new project: [description].
Please help me create a comprehensive AGENTS.md
and suggest an appropriate folder structure."

Enter fullscreen mode Exit fullscreen mode

The advantage of starting fresh: you establish conventions from day one. The AI will follow the patterns you set, rather than guessing from existing code.

Scenario 2: Existing Codebase 🏗️

This is more challenging. There are two things you need to understand before vibe coding in an existing codebase:

a. Understand the existing structure

Before giving the AI access to the codebase, you need to be able to answer:

  • What is the main folder structure and why is it organized that way?
  • How does a request flow from entry to response?
  • What libraries/patterns are already in use and can’t be changed?
  • Which parts are “fragile” and need extra care?

Quick approach: ask Claude to reverse-engineer the documentation from the code.

"Read through this entire codebase and create:
1. An architecture summary in markdown
2. A list of business rules you can infer from the code
3. Potential gotchas I should know before making modifications"

Enter fullscreen mode Exit fullscreen mode

b. Understand the business flows already running

This is the most commonly skipped step. If you ask the AI to modify an existing feature without business context, the risk of breaking production is very high.

Before modifying anything, document:

  • The main flow that’s already working (happy path)
  • Edge cases already handled
  • Inter-feature dependencies
# Business Flow: Checkout Process

## Happy Path
1. User adds item to cart
2. User clicks checkout → validate stock (realtime from inventory service)
3. Select payment → payment gateway
4. Success → send confirmation email + update stock
5. Webhook updates order status

## Existing Edge Cases
- Out of stock at step 3: rollback cart, notify user
- Webhook timeout: retry 3x with exponential backoff
- Duplicate order: idempotency key in payment service

## DO NOT change without discussion:
- Payment flow (compliance issue)
- Stock calculation logic (finance depends on this)

Enter fullscreen mode Exit fullscreen mode

My Daily Vibe Coding Workflow

1. Open Claude Code at project root
   ↓
2. Agent reads AGENTS.md/CLAUDE.md automatically (context loaded)
   ↓
3. Describe intent: "I want to add feature X for Y"
   ↓
4. Superpowers activates → Brainstorming session
   (Agent asks for clarification, proposes approach)
   ↓
5. Approve design → Agent creates implementation plan
   ↓
6. Execute: Agent creates worktree, writes failing tests first
   ↓
7. Implement → Review → Merge
   ↓
8. Commit with a descriptive message

Enter fullscreen mode Exit fullscreen mode

Pre-flight Checklist

  • [ ] Config file exists (AGENTS.md / CLAUDE.md / GEMINI.md) with tech stack + business rules
  • [ ] If using multiple tools: symlinks are in place, no files have drifted
  • [ ] Superpowers is installed on the agent
  • [ ] You can explain the main business flow to the AI (not just “build feature X”)
  • [ ] There’s a clear definition of done for the task at hand
  • [ ] For existing projects: basic architecture documentation exists

Closing Thoughts

Effective vibe coding isn’t about writing “magic” prompts. It’s about building a system where the AI always has enough context to work correctly.

Skills library = reactivatable knowledge.
Starter docs = persistent memory.
Clear workflow = guardrails so the AI doesn’t jump straight to implementation before the problem is understood.

With the right setup, one developer doing vibe coding can ship faster than a team of three using AI ad-hoc.

Written June 18, 2026. Model references will keep changing — check skills.sh for the latest skills and each model provider’s official docs for current pricing.

원문에서 계속 ↗

코멘트

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다