AV
HomeAboutProjectBlog

© 2026 Ave syah Shina. All rights reserved.

  1. Home
  2. Blog
  3. 01 — What Is Vibe Coding — The Director, Not the Typist

01 — What Is Vibe Coding — The Director, Not the Typist

August 13, 20269 min read
Download as Markdown

"Just let the AI write it all and hope" was how I dismissed vibe coding, and the dismissal hid the actual shift. The idea that the rest hangs off: vibe coding is not the absence of programming. It's a different job in programming. You stop typing syntax and start directing intent — describing what the application should do in natural language, and letting an LLM produce the code [1]. The skill that matters shifts from "do I remember this API" to "can I describe what I want well enough to be understood."

The framing that finally landed: AI is more like a junior developer sitting next to me than like a compiler. A compiler takes exact syntax and deterministically produces bytes. A junior takes a vague request, fills in gaps from their training, produces something close, and quietly gets things wrong in places I didn't specify. Vibe coding is the workflow built around that second reality — give context, review what comes back, correct, and steer [1][2].

Traditional — you type Vibe coding — you direct you exact syntax compiler deterministic working app you natural language AI agent probabilistic candidate code close, maybe wrong review & steer loop until right

That loop on the right — prompt, candidate, review, steer, repeat — is the entire shape of the job. The code that ships is the product of the loop, not of a single utterance.

The mindset shift that has to happen first

The hardest part wasn't learning a tool. It was accepting that "you don't need to review every line" is a goal, not a starting point [1]. The roadmap says it, and it's true at the end of a project. On day one, treating AI output as trusted by default is how apps ship with silent bugs and leaked secrets. The mindset the roadmap actually points at is more honest than the slogan: AI works like a junior who needs direction, context, correction, and a vision held by someone — me [2]. I set the direction. I review the output. I keep the project on course. I still need to understand the basics of programming. What I no longer need is to memorize syntax or solve every small detail alone [2].

Two failure modes I had to stop repeating:

  • The one-shot wish. Type one prompt, accept the result, move on. The AI filled in dozens of decisions I never stated. Half were wrong. The fix is treating the first output as a draft, not a deliverable.
  • The hands-off delusion. "The AI built it, so it works." No — the AI produced code that looks like it works. Without review, tests, and a security pass, "looks like it works" is the production bug report waiting to happen [3].

The honest version of the mindset: I am accountable for what ships, even the lines I didn't type. That accountability is what makes the speed safe.

Where it fits, and where it doesn't

Vibe coding is best for fast prototyping and for the long tail of boilerplate that makes up most of a real codebase — forms, CRUD handlers, migrations, glue code [1]. It shines when "a working thing I can click" is more valuable than "a hand-tuned implementation I can cite."

It is weaker where I need to defend correctness against an adversary (security-critical code), where the task is novel enough that the model has no strong prior (research-y internals), and anywhere the cost of a silent bug is high (payments, auth). For those I still read every line, write the test first, and treat the AI as a pair-programmer I veto, not an author I trust.

The tools: terminal agents, AI editors, autocomplete

The roadmap groups the tooling into three shapes, and the shape matters more than the brand. A tool's shape decides what it's good at, and I pick by shape first [4][5][6][7][8].

Terminal agent Claude Code · Gemini CLI runs in your shell sees the whole repo long autonomous tasks explains unfamiliar code best for: reasoning, debugging, big refactors AI-first editor Cursor · Windsurf VS Code underneath AI woven into editing select code → ask codebase-wide context best for: navigating code you didn't write Inline autocomplete GitHub Copilot lives in your editor suggests as you type lines & whole functions learns your style best for: staying in flow while typing
  • Terminal agents — Claude Code, Gemini CLI. These run in the shell with access to the whole repository. Claude Code is built to reason through complex problems, explain unfamiliar codebases, and walk a specific issue step by step [4]. Gemini CLI is Google's equivalent for the same terminal-native workflow [5]. The strength is agentic: give them a problem and a budget, and they'll explore, edit, run, and iterate. The cost is that I'm not editing directly — the feedback loop runs through their decisions.
  • AI-first editors — Cursor, Windsurf. Built on VS Code, with AI woven through the editor itself. Cursor is built for navigating and editing large codebases I didn't write — select any part and ask it to explain, fix, or rewrite without reading every surrounding line [6]. Windsurf (Codeium) is the same shape, with a focus on keeping context across the whole codebase rather than just the current file [7]. The strength is that I stay in the editor; the AI is a copilot in the same surface where I type.
  • Inline autocomplete — GitHub Copilot. A different shape: it lives inside whatever editor I already use, suggesting lines and entire functions as I type, learning from my style and comments [8]. It's a coding partner that finishes my sentences. Lowest-agency, lowest-disruption — the right pick when I want to stay in flow and just type less.

The honest rule I use: autocomplete (Copilot) when I'm typing the thing myself, an AI editor (Cursor/Windsurf) when I'm working in a codebase I need help navigating, and a terminal agent (Claude Code) when the task is "go figure out why this is broken, across many files, and fix it." Different shapes for different jobs — not one tool to rule them all.

How I use this

The practical habit is a role check before each task. Before I start, I ask: am I the typist here or the director? If the task is "ship a clickable prototype fast," I direct — terminal agent, broad prompts, accept drafts, iterate. If the task is "fix the auth bug that's leaking tokens," I'm the typist — AI as autocomplete and explainer, but every line reviewed and the security model mine. Naming the role up front is what stops me from accidentally going hands-off on something that needed my hands.

References

[1] roadmap.sh, "Vibe Coding — What is vibe coding?," 2026. [Online]. Available: https://roadmap.sh/vibe-coding/what-is-vibe-coding

[2] roadmap.sh, "The Vibe Coder Mindset," 2026. [Online]. Available: https://roadmap.sh/vibe-coding/the-vibe-coder-mindset

[3] Databricks, "Passing the Security Vibe Check: The Dangers of Vibe Coding," 2026. [Online]. Available: https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding

[4] Anthropic, "Claude Code Overview," 2026. [Online]. Available: https://code.claude.com/docs/en/overview

[5] Google, "Google Gemini," 2026. [Online]. Available: https://gemini.google.com/

[6] Cursor, "Cursor Docs," 2026. [Online]. Available: https://cursor.com/docs

[7] Codeium, "Windsurf Docs — Getting started," 2026. [Online]. Available: https://docs.windsurf.com/windsurf/getting-started

[8] GitHub, "GitHub Copilot Docs," 2026. [Online]. Available: https://docs.github.com/en/copilot

Knowledge check · Question 1 of 5

Vibe coding is best described as…

Comments

Leave a Comment

You must be signed in to comment

0 Comments

No comments yet. Be the first to comment!