Andrej Karpathy coined the term in early 2025: vibe coding. The idea was simple and slightly provocative. You describe what you want. The AI writes the code. You mostly just check if it looks right and move on. You feel the vibe of the system more than you understand every line.
A year and a half later, the conversation has matured. Vibe coding is real, it is genuinely useful, and it has changed how I build software. It has also been badly misunderstood by people on both ends: those who think it means AI writes everything perfectly, and those who dismiss it as a shortcut for people who cannot code. The truth is more interesting than either take.
What Vibe Coding Actually Means
The term captures a real shift in the unit of work. Before AI coding assistants, the unit of work was a line or a function. You wrote each line deliberately. Now the unit of work is a feature or a behavior. You describe the feature; the AI generates the implementation; you evaluate and correct.
This is not radically different from how senior engineers already work. A senior engineer does not think at the line level. They think at the architecture level and the behavior level. AI coding assistants extend that abstraction to junior engineers and let senior engineers move faster.
| Mode | Unit of work | Time per unit | Workflow |
|---|---|---|---|
| Pre-AI | Line / function | Hours | Write, test, debug line by line |
| Vibe coding | Feature / behavior | Minutes to hours | Describe, evaluate, correct, iterate |
What Actually Changed in 2025 to 2026
The thing that made vibe coding viable was not just better models. It was context. GPT-4 in 2023 could write decent functions in isolation. Claude Sonnet and GPT-4o in 2025 could hold an entire codebase in context and make changes that were consistent with the rest of the project. That is the actual unlock.
The second unlock was agentic tools: Claude Code, Cursor, Copilot Workspace. These are not just autocomplete. They can read your entire repository, understand the structure, run tests, see failures, and iterate until the tests pass. The feedback loop that used to take an engineer several minutes now runs in seconds, autonomously.
The tools I use in 2026
- -Claude Code (CLI) - for greenfield features, refactors, and any task that needs to touch multiple files. The context window and agentic capabilities make it the strongest tool for complex work.
- -Cursor - for in-editor work where I want inline suggestions while I type. Better for surgical edits to existing code.
- -Claude.ai chat - for architecture decisions, debugging strange errors, and explaining code I did not write.
How I Actually Use It: A Real Workflow
Here is the workflow I use for any non-trivial feature. It is not magic, but it is genuinely faster than writing everything by hand.
Step 1: Write the spec in plain English
Before I open the AI, I write a short spec. Not a formal document. Just a paragraph describing: what the feature does, what inputs it takes, what outputs it produces, and any constraints. This forces me to think clearly before I ask the AI. Vague prompts produce vague code.
# What I want:
# An endpoint POST /transcribe that accepts an audio file,
# sends it to the Groq Whisper API with language=ur,
# parses the response into {language, segments: [{start, end, text}]},
# deletes the temp file after processing,
# and returns 400 if no file is provided, 500 on Groq API errors.This spec becomes the first message to the AI. The more specific the spec, the less iteration you need.
Step 2: Generate, do not accept blindly
The AI generates an implementation. I do not accept it immediately. I read through it with one question: does this implementation actually match the spec? I am not checking for line-level correctness. I am checking for structural correctness. Does it handle the error cases? Is the data flow right? Are there obvious security issues?
This is the skill that separates good vibe coding from bad vibe coding. If you skip this step and just run the code to see if it works, you will ship bugs that are hard to find later because you never understood the code path.
Step 3: Test first, fix with AI
I write a test or run the feature manually before I move on. When it fails, I do not fix it manually. I copy the error output back to the AI with the original spec and ask it to fix the implementation. The AI almost always gets it right in one correction because the error message gives it precise information.
# Prompt for fixing:
# The above implementation fails with this error:
# [paste error here]
#
# The original spec was: [paste spec]
# Fix only the issue above, do not change anything else.Step 4: Refactor after it works
Once the feature works, I ask the AI to refactor for clarity. Not for cleverness. The goal is code that another engineer (or me in six months) can read and understand without having to run it. I have the AI add inline comments only where the why is non-obvious.
Where Vibe Coding Breaks Down
Being honest about the limits is important. Vibe coding does not work well in several situations:
- -Novel algorithms. If you need to implement something that is not in the training data, the AI will hallucinate a plausible-looking but incorrect implementation. You have to know the algorithm yourself to catch this.
- -Deep system-level code. Kernel code, firmware, memory allocators. The AI can generate it but the subtle correctness requirements are hard to verify without deep expertise.
- -Large undocumented codebases. If you drop the AI into a codebase with no documentation and inconsistent patterns, it will write code that fits some of the patterns and conflicts with others. Context quality matters.
- -Security-critical code. Never vibe-code authentication, encryption, or input sanitization without a manual security review. The AI will write code that looks correct and is subtly vulnerable.
What It Does to Engineering Skills
The common fear is that vibe coding makes engineers worse because they stop thinking about implementation details. The reality is more nuanced. Implementation knowledge matters less. Specification and evaluation skills matter more.
The best engineers I know who use AI heavily have gotten better at two things: writing precise specs and quickly evaluating whether generated code is correct. These are skills that transfer. The engineers who struggle with AI-assisted development are often the ones who never learned to think at the behavior level, only the implementation level.
The honest answer to whether AI makes engineers worse: it depends entirely on how you use it. Using AI to avoid thinking produces worse engineers. Using AI to think at a higher level of abstraction produces better ones.
The Productivity Numbers
I will share my own experience because vague claims about productivity are useless. On projects I have full context on, AI coding assistants make me roughly 2 to 3 times faster at the implementation stage. The specification and evaluation stages are largely unchanged. Architecture decisions still take the same amount of thinking. Debugging novel issues still takes the same amount of reasoning.
The biggest gains are on tasks that are conceptually simple but tedious to write: CRUD endpoints, form validation, data transformation, boilerplate setup, test cases for known behaviors. The AI handles these almost perfectly on the first try. On genuinely novel or complex logic, the gain is smaller and the review overhead is higher.
How to Start if You Have Not Already
If you have been avoiding AI coding tools because they seem like cheating or because you tried autocomplete tools and found them underwhelming, the landscape has changed significantly. The current generation of agentic tools are not autocomplete. They are collaborators.
- -Start with a small, self-contained task you understand well. Ask the AI to implement it from a spec you write. Compare the output to what you would have written.
- -Do not use it as a search engine. Use it as a collaborator. Give it context. Tell it what you already tried. Tell it what constraints exist.
- -Read every line of generated code the first few weeks. Once you calibrate how good the AI is at your specific tasks, you can be more selective about where you trust and where you verify.
- -Build the habit of writing specs before prompting. It makes the AI output better and it makes you a better engineer by forcing you to think before you build.
Vibe coding is not the end of software engineering. It is a shift in what software engineers spend their time on. The engineers who adapt to that shift will ship more, faster. The ones who resist it will get slower relative to those who do not.