What is vibe coding? A definition, its origin, and where it has no place in research

In summary

• Vibe coding means prompting a model for code and accepting the output because it appears to work, rather than because you have read and understood it. The term was coined by Andrej Karpathy in early 2025 for throwaway weekend projects — it is a real practice, not a joke, but most of the argument since has come from people applying it well outside that frame.
• Genuinely fine: throwaway exploration, one-off plots you will never publish, internal prototypes, scaffolding you intend to rewrite, and learning by taking something apart.
• Indefensible: analysis code that produces a number, figure or statistic in a paper, anything touching participant data, and anything another researcher will have to reproduce.
• Where to start if you want to try it — Emergent: Free $0 (10 credits/mo); Standard $17/mo annual (100 credits); Pro $167/mo annual (750 credits, 1M context, custom agents); Enterprise custom (SSO, RBAC, audit logs, VPC). You own the generated code and GitHub integration is on all tiers. Verified 18 August 2026.
• If prompt-generated code contributed to a published result, your methods section has to say so. Nobody will ask you for a prompt log until someone cannot reproduce your figure — and then everyone will.

Where vibe coding is fine, and where it stops being fine

Editorial assessment for research and academic settings, 19 August 2026

Dimension	Throwaway exploration	Prototype or internal tool	Analysis code behind a result
What you are producing	A quick look at a file, a scratch plot, a format conversion you run once	A dashboard, a form, a lab utility, a demo for a grant meeting	The number, figure, table or model that appears in the paper
Who depends on it being right	You, for the next twenty minutes	Your group, and whoever inherits it	Every reader of the paper, and everyone who cites it
If it is silently wrong	You notice, or it never mattered	Wasted time, an embarrassing demo, occasionally a data-handling incident	A wrong finding in the literature, and a correction or retraction later
Line-by-line review required	No	For anything touching real data, yes	Yes, without exception, by someone who understands the method
Disclosure in the methods section	Not applicable — it produced nothing	Not usually, unless it collected or transformed the data	Yes. State that generative assistance was used and that the code was reviewed
Verdict	Vibe away. This is what the term was coined for	Fine with a review gate before it touches anything real	Not defensible as vibe coding. Read every line or do not use it

The dividing question is not how complex the code is, nor how good the model is. It is whether anyone other than you will rely on the output — and whether you could explain, a year from now, why it produced the number it produced.

Vibe coding, defined — and where the term came from

Vibe coding is writing software by describing what you want to a language model, running whatever it produces, and iterating on the description rather than on the code. The defining characteristic is not the use of a model — almost everyone uses completion tools now — but the deliberate decision not to read the output closely. You judge the result by whether it behaves as expected, not by whether you understand how it works. If it breaks, you paste the error back and ask for another attempt.

The term was coined by Andrej Karpathy, a founding member of OpenAI and formerly director of AI at Tesla, in a short social-media post in early 2025. His framing was self-aware and quite specific: he described giving in to the vibes and effectively forgetting that the code exists, and he was explicit that he meant throwaway weekend projects rather than anything that mattered. The phrase spread far faster than the caveat did. Within months it had a Wikipedia entry, explainers from the large technology vendors, and a great deal of argument attached — most of it between people applying the practice well outside the frame it was coined in.

So is it real, or is it a joke? Both, and that is the honest answer. The name is a joke — deliberately unserious, coined in a register that signalled it was not a methodology. The practice is entirely real, widespread, and now describes how a substantial amount of software genuinely gets made. Treating it as a joke leaves you unable to discuss something your students and collaborators are already doing daily; treating it as an engineering discipline attributes a rigour to it that its own originator never claimed.

It is worth separating two things the phrase gets used for. Vibe coding in the original sense means not reading the code. AI-assisted development — prompting for a function, reading it, testing it, correcting it, keeping the parts that survive — is a different activity with a different risk profile, and it is what most working developers are actually doing. The distinction is not pedantry; it is the whole of what follows, because the risk lives specifically in the not-reading.

Where it is genuinely fine, and where it is indefensible

Most commentary on this subject is either dismissive or promotional, and neither helps somebody deciding what to do on a Tuesday afternoon. The useful question is narrower: does anyone other than you depend on this being correct?

Where vibe coding is genuinely fine. Throwaway exploration is the clearest case, and the one the term was invented for. Reshaping a file to see what is in it, a scratch plot you will look at once and delete, a format conversion, a quick sanity check on a distribution before deciding whether a question is worth pursuing — the output is a decision in your own head, and if the code were wrong you would probably notice, because you know roughly what you expected to see. Prototypes are the second. If you are trying to find out whether a data-collection instrument, a participant-facing form or an internal dashboard is worth building properly, a working artefact tells you more in an afternoon than a specification tells you in a week, and it is entirely legitimate to throw it away afterwards. Scaffolding is the third: boilerplate, the argument parser, configuration loading, plotting furniture. Nobody was reading that code carefully before models existed either.

Where it is indefensible. Analysis code that produces a result you publish. That is the bright line, and it does not bend for deadlines, for how confident the model sounded, or for how convincing the figure looks. If a number, a p-value, a model coefficient or a survival curve appears in a paper with your name on it, you are asserting to the literature that you know how it was produced — and you cannot make that assertion about code you have not read. A model will produce something that runs and yields a plausible figure while silently dropping rows on a merge, applying a filter in the wrong order, using a two-tailed test where the design required one-tailed, or handling missing values in a way you would never have chosen. None of those failures throws an error. All of them change the answer.

The same applies to anything touching participant data, where an unread data-handling path is a governance problem before it is a correctness problem, and to anything a collaborator must reproduce. Code nobody has read is not a method; it is an artefact whose provenance is a prompt you did not keep.

What your methods section has to disclose

Here is the scenario the generic explainers do not address. You prompted a model for the analysis script. It ran. The figure looked right, went into the paper, and the paper was accepted. Eighteen months later somebody cannot reproduce your effect size. What do you say?

The answer has to be built before submission, not after the query. Journal and funder policies on generative-AI use are not uniform, so read the specific policy of the venue you are submitting to rather than a summary. But the direction is consistent enough to plan around: disclosure of generative assistance is expected, authorship is not extended to tools, and responsibility for the content stays entirely with the human authors. That last point governs code. You are accountable for what the script did, whether or not you wrote it.

A workable practice, which costs very little if you set it up at the start of a project:

• Name the assistance in the methods or a software statement. Something as plain as: analysis code was drafted with generative AI assistance, reviewed line by line by the named authors, and archived at the repository below. That sentence is not an admission of weakness — it is what makes the record honest, and it is far easier to write than a correction.
• Archive the code itself, with a persistent identifier. A repository snapshot with a DOI turns an unanswerable question into a link. The highest-value habit here, and entirely independent of AI.
• Keep the prompts and the model version in the repository next to the script. Model behaviour changes between versions, and the prompt is the closest thing you have to a record of your intent at the time.
• Record who reviewed it. A named person who read the analysis path and understood the statistics is the difference between assisted work and unverified work.
• Keep the test that proves it does what you think. One check on synthetic data with a known answer is worth more than a paragraph of assurance.

None of this is exotic, and most of it is what good computational practice already asked for; generated code has simply removed the excuse that nobody had time. If you are also wondering how such code is identified from the other side — assessment, review, submissions — our guide to AI code detectors is blunt about how weak that evidence is, which is precisely why disclosure has to come from the author rather than from a scanner.

Choosing a tool — and the honest trade-offs

If your use case sits on the acceptable side of the boundary, the question becomes which tool. There are three shapes on the market: chat assistants you paste code in and out of, coding agents that work inside your repository, and app builders that generate and host a working application from a description. For prototypes, internal tools and participant-facing forms — the research uses that come up most often — the app-builder shape usually fits best, because deployment and the database are the parts that consume the week.

Our pick for that job is Emergent, mainly because you own the generated code and GitHub integration is available on every tier including the free one. In a research setting that one property does most of the work: the output can be reviewed later even if it was not reviewed at the time, archived alongside the paper, inherited by whoever replaces the postdoc who built it, and audited if a governance question arrives. Free is $0 with 10 credits a month, Standard $17/mo billed annually for 100 credits, Pro $167/mo billed annually for 750 credits with a 1M context window and custom agents, and Enterprise custom-quoted with SSO, RBAC, audit logs and VPC. Verified 18 August 2026.

The objection you are about to go and search. You will find Cursor, Replit, Lovable, Bolt, Windsurf and GitHub Copilot recommended in every thread on this subject, and some are better than our pick at specific things. The editor-based agents are genuinely stronger if you already have a mature codebase and want an assistant working inside it rather than a generator producing a new application, and the largest platforms have more polish and vastly more community material to search when you get stuck. We publish only prices we have read off a vendor page ourselves, so we will not quote figures for any of them — check their pricing pages, and check what happens to your source code on the plan you are considering, because that is where these products differ most and market most quietly. For a group whose priority is that generated code stays portable, inspectable and archivable, code ownership plus GitHub on the free tier is the property we would not trade away.

Do not buy any of this if the code in question is the analysis behind a published result and you are hoping a better tool removes the need to read it. It does not, no tool does, and buying one to solve that problem is money spent on a risk you are still carrying. Equally, do not buy a paid tier to evaluate the approach — the free tier exists for exactly that, and ten credits will tell you whether the workflow suits your problem. Our wider comparison of AI app builders and the full Emergent review go through the feature detail; and if you want to know which underlying models are actually strongest at code right now rather than which wrapper is fashionable, the LLM leaderboard is the more useful page.

What to write down before somebody asks

Most groups have no written position on this, which means the position is whatever each person improvises, and it varies enormously between the PI, the software engineer and the second-year PhD student. A single page settles it, and takes less time to write than the first awkward conversation it prevents.

State the boundary in your own terms. Ours is: generated code is permitted anywhere it does not produce a published result or touch participant data; anywhere it does, a named person reads it line by line before it runs on real data. Yours may differ — what matters is that it exists in writing.

Require the repository from the first day, not the last. Version control makes every other requirement enforceable, and it converts an unanswerable dispute about provenance into a log. This applies equally to hand-written code; generated code has simply raised the cost of not having it.

Make review a gate, not a virtue. Analysis code merges when a second person has read it. Not when the first person feels confident, and not when the deadline arrives. A gate that only applies when people remember it is not a gate.

Treat disclosure as normal. The groups that handle this worst are the ones where using assistance feels like something to conceal, because concealment is what turns a manageable methods-section sentence into a misconduct question. A policy that permits the practice and requires the declaration gets you a truthful record; silence gets you an untruthful one.

Ten free credits, and the code stays yours

If the job is a prototype, an internal dashboard or a participant-facing form rather than analysis behind a result, Emergent is the sensible place to test the approach: Free is $0 with 10 credits a month, no payment details needed to see whether it fits, and GitHub integration is on every tier so the generated code lands in your own repository from the start. Verified 18 August 2026.

Free tier · Standard from $17/mo annual

Start free on Emergent Opens on the vendor’s site · CASRAI referral link

Frequently asked questions

What is vibe coding, in one sentence?

Vibe coding is building software by describing what you want to a language model and accepting the code it produces on the basis that it appears to work, without reading it closely enough to explain or defend it. The distinguishing feature is the deliberate decision not to read the output — prompting a model, reading the result, testing it and correcting it is ordinary AI-assisted development and carries a very different risk profile.

Who coined the term vibe coding, and when?

Andrej Karpathy, a founding member of OpenAI and formerly director of AI at Tesla, in a short social-media post in early 2025. He described giving in to the vibes and effectively forgetting that the code exists, and he was explicit that he had throwaway weekend projects in mind rather than production software. The term travelled a great deal further than that caveat did, which is the source of most of the argument since.

Can I use vibe coding for the analysis in my paper?

Not as vibe coding, no. If a number, figure or statistic appears in a paper with your name on it, you are asserting that you know how it was produced, and you cannot make that assertion about code you have not read. Generated analysis code will run happily while silently dropping rows on a merge, filtering in the wrong order or handling missing values in a way you would never have chosen — none of which raises an error, all of which changes the answer. Use assistance to draft it if you like, then read every line, test it against a case with a known answer, and have a second person review it before it touches real data.

Do I have to disclose AI-generated code in my methods section?

Check the specific policy of the journal or funder, because they differ and are still changing. The consistent direction is that generative assistance should be disclosed, that tools are not authors, and that responsibility for the content stays with the human authors. A single plain sentence covers it: analysis code was drafted with generative AI assistance, reviewed line by line by the named authors, and archived at a repository with a persistent identifier. Keep the prompts and model version alongside the code — nobody asks until somebody cannot reproduce your figure, and then everybody does.

Which tool should I use if I want to try vibe coding?

For research uses on the acceptable side of the line — prototypes, internal dashboards, participant-facing forms — we would start with Emergent, because you own the generated code and GitHub integration is on every tier including the free one, which means the output is inspectable, archivable and inheritable even if you did not read it at the time. Free is $0 for 10 credits a month, Standard is $17/mo billed annually for 100 credits, Pro is $167/mo billed annually for 750 credits with a 1M context window and custom agents, and Enterprise is custom-quoted with SSO, RBAC, audit logs and VPC. Verified 18 August 2026. Start on the free tier — ten credits is enough to learn whether the workflow suits your problem, and the paid tiers buy volume rather than better judgement. If you want the alternatives side by side first, see our AI app-builder comparison.

Will vibe coding stop early-career researchers learning to code?

It is a legitimate concern deserving a straight answer rather than reassurance or alarm. The risk is not that people fail to learn syntax; it is that someone who has generated everything has never had to debug anything, and discovers that gap under deadline pressure or in front of a reviewer. The practical response is not prohibition, which would be ignored and would hide the practice from you, but expecting people to be able to explain what their own code does — and using generated code as something to take apart rather than only to run.

Related on CASRAI

• Best AI app builders compared
• Emergent review
• AI code detectors: what they can prove
• Which LLM is actually best at code
• All AI writing & research tools