Skip to content

Vibe Coding: programming with AI at the speed of thought

Jamie Liu
Published date:
Edit this post

The term was coined by Andrej Karpathy in early 2025: “Vibe coding is when you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” Two years later it is already part of the industry’s vocabulary, although it is still misunderstood.

Developer in front of multiple screens with code
AI-assisted development changed the relationship between the programmer and the code.

It’s not “letting AI code for you”

The most common misunderstanding: vibe coding = not knowing what you are doing. The reality is the opposite. For AI to produce useful code you need:

Vibe coding is high-level design executed at high speed. It doesn’t eliminate the need for technical judgment; it amplifies it.

The flow in practice

A typical vibe coding cycle today looks like this:

  1. Clear intention — you define the what and the why accurately.
  2. Quick AI draft — you get 70-80% of functional code.
  3. Review and guide — you correct the course, clarify invariants, add context.
  4. Iterative refinement — several short rounds until the result is solid.
  5. Tests and final review — you never skip this step; AI introduces technical debt if you don’t supervise it.

The most valuable thing is not the raw speed, but that AI frees you from the cognitive scroll — that layer of boilerplate and syntax that separates you from the real problem.


What tools define the ecosystem in 2026

ToolPurposeStrong point
GitHub CopilotAutocomplete + agent in editorNative VS Code integration
CursorAI-first editorFull codebase context
WindsurfAutonomous editing agentMulti-file flows
Claude (API)Complex reasoningHuge context window
Gemini 2.0 FlashSpeed and costFast iterations

The skills that gain more value

Vibe coding does not deprecate all technical skills, but it redistributes their value:

Gain more value:

Lose relative relevance:

A cultural change, not just a technical one

Some developers resist vibe coding for a legitimate emotional reason: control. Writing every line gives the feeling of completely understanding the system. But that feeling was always partially illusory in large projects.

The question is not should I use AI? but how do I build trust in a system I didn’t completely write myself? The answer is the same as always: tests, reviews, and judgment. Only now applied to a larger volume of production.

The developer of the future is not the one who produces the most code or the one who uses AI the least. It is the one who builds systems that work, using the best available tools with the best possible judgment.

Previous
Urban photography: finding the frame in the chaos of the city
Next
Docker Compose in 2026: best practices that actually matter