“Vibe coding” — the term Andrej Karpathy popularized in early 2025 for writing software primarily by prompting an AI assistant — has become a mainstream practice and a source of strong opinions. Some teams build remarkable products this way; others end up with brittle, opaque codebases. The interview question “what do you think of vibe coding?” probes whether you can articulate the tradeoffs.
What vibe coding actually means
The user describes the desired behavior; the AI generates code; the user runs it; if it works, ship; if not, iterate via prompts rather than reading the code. The user may rarely look at the code itself.
This is different from AI-assisted coding (where you write code with AI help and read every line). Vibe coding shifts the human attention from “every line is reviewed” to “the behavior is verified.”
When it works
- Prototypes and proof-of-concepts
- Internal tools with one or two users
- Glue scripts and one-shot data transformations
- Small apps with low stakes (personal automation, learning projects)
- UI exploration where the goal is “does this layout feel right?”
For these, behavior verification is sufficient. The code being unreviewed is a reasonable trade for speed.
When it falls apart
- Production systems with real users
- Code that needs to be maintained for years
- Security-sensitive code
- Code that integrates with external systems and depends on edge-case handling
- Performance-critical code
For these, “does it pass the tests” is insufficient. Subtle bugs survive surface verification. Maintenance becomes painful when no human understands why the code works.
The maintenance problem
Six months later, you need to change something. The code was generated by a different prompt; now you do not remember the context. The model that produced it has been updated; the same prompt produces different output. You ask the AI to modify the code; the new version subtly breaks something the old version did. Without anyone reading the code, you cannot tell what changed.
Hybrid approaches
Most pragmatic: vibe code the first draft; review and refactor before committing. Specifically:
- Use AI to generate the structure
- Read every line before merging to main
- Refactor for clarity, naming, and idiom
- Add tests that verify behavior, not implementation
- Document non-obvious choices
The goal is to keep the speed advantage of AI generation while preserving the code’s maintainability.
The “AI knows my codebase” failure
Even when the AI has access to your codebase, it does not have the unwritten knowledge: why the team chose pattern X, what the historical decisions were, what is unsafe to change. Vibe coding works best in greenfield where the AI is filling a blank slate.
Senior engineer perspective
Senior engineers in 2026 use vibe coding for:
- Quickly testing an idea before committing to it
- Generating boilerplate that they then edit
- Translating between languages or frameworks
- Bootstrapping new tools when the upfront understanding is low-stakes
They do not vibe code production systems. They review every line that ships.
Junior engineer trap
Juniors who only vibe code never develop the muscle of reading and reasoning about code. After two years, they can prompt fluently but cannot debug a real production issue. Career ceiling: relatively low, until they invest in fundamentals.
The interview probe
“How do you balance AI-driven coding with maintainability?”
Strong answers:
- Acknowledge AI-driven coding is here to stay
- Distinguish prototypes from production
- Describe a specific review/refactor practice
- Give an example of when vibe coding helped and when it hurt
Frequently Asked Questions
Is vibe coding a “fad” or here to stay?
Here to stay for prototyping. The split between vibe coding (prototypes) and rigorous AI-assisted coding (production) is the durable pattern.
Can I vibe code my way to a senior role?
You can vibe code your way to a job at a low-rigor team. You cannot vibe code your way through a senior interview at a serious company.
What did Karpathy actually say about it?
His tweet was relatively neutral — describing his own practice, not making it doctrine. The hype around the term outran his original framing.