Vibe coding means building software with an AI model without reviewing the code it writes. That is Simon Willison's definition of the term Andrej Karpathy coined in February 2025. Employers who allow AI in interviews screen for the opposite: reading, testing and owning AI written code. Most developers say vibe coding is not part of their professional work.
Where did the term come from?
Andrej Karpathy used it in a post in February 2025; Simon Willison dates it to 6 February. Karpathy described giving in to the vibes and forgetting that the code even exists, and presented it as fine for throwaway weekend projects.
Willison, writing in March 2025, drew the line that most engineers now use. Building with an AI model while reviewing, testing and understanding what it writes is ordinary software development. Vibe coding is the version where you do not review the code. His own rule is that he will not commit code he could not explain to someone else.
How many developers vibe code at work?
Few say they do. In Stack Overflow's 2025 Developer Survey, 80% of developers said they use AI tools in their work, yet nearly 72% said vibe coding is not part of their professional work, and a further 5% said they emphatically do not do it. Trust in the accuracy of AI output fell to 29%, from 40% in earlier years.
So the common picture is heavy AI use with human review, not unread code going to production. Even Canva, which requires AI in its interviews, said when it changed them that almost half of its frontend and backend engineers were daily users of an AI coding tool: common, but far from everyone, and with the engineers still owning the result.
What do employers say about it?
Employers that allow AI in interviews are explicit that unread code is a failure, not a style. Canva asks whether candidates can ensure AI generated solutions meet production standards and expects engineers to take full ownership of the code they produce. One Canva engineer, the same post says, worried that the new format would turn into vibe coding sessions.
Shopify's head of engineering wants most of the work done with AI, but not all of it, and wants candidates to read the output and spot the wrong line. Rootly's reviewers mark down candidates who keep asking the AI to fix it until things work, and Meta candidates have reported being marked down for leaning on the assistant as a crutch.
Is vibe coding ever fine?
For low stakes work, by Willison's account: a prototype, a personal tool, something nobody else will depend on. He lists the risks that appear the moment stakes rise: secrets such as API keys exposed in code, private data leaking to places it should not go, load on other people's services, and usage based bills that run up without a limit.
Problems of that kind are what our practice rounds hide in their checks: each round has one production trap the brief does not mention, and code that passes every visible test can still fall into it.
How do you show you are not vibe coding in an interview?
Make your review visible. Read the code before asking for changes, and read each change before you accept it. Run the tests after every step and say what you are checking. Reject edits that change a test to make it pass. Fix one character bugs by hand. When you choose a design, say why, and say what you would do with more time.
Then practise until it is a habit. Our practice rounds and the rubric are built around these behaviours, and the transcript stats tool shows, for example, how often you ran the tests.