Vibe coding was not merely “coding with AI.”
On February 2, 2025, Andrej Karpathy described “a new kind of coding” shaped by natural-language commands, repeated reactions, and a deliberate choice not to study the generated code. His post included “I ‘Accept All’ always” and “I don't read the diffs anymore,” and framed the method around throwaway weekend projects.
The term has since gained a broader, casual meaning. People now call many forms of AI-assisted programming “vibe coding,” even when developers review every change. That broader use is real, but it hides the most important distinction: generation is not the same as reviewed engineering.
Read Karpathy's original postUsing AI is not the key difference.
The useful dividing line is whether people can review, check, and understand the work, then take responsibility for it.
Pure vibe coding
The code may grow beyond the user's understanding. The user mainly watches what it does and keeps prompting in response.
AI-assisted development
AI suggests changes, but a developer reviews what changed, tests the behavior, checks security and long-term upkeep, and takes responsibility for the release.
Responsible vibe writing
AI suggests structures or prose. The writer checks claims, meaning, voice, sources, and what readers may reasonably take from the text.
Three ways of working, three levels of review
| Dimension | Pure vibe coding | AI-assisted development | Responsible vibe writing |
|---|---|---|---|
| Human input | Desired behavior and reactions | Requirements and clear rules for what counts as done | Purpose, evidence, audience, stance, and voice |
| AI role | Generate and repair code | Suggest limited code changes and tests | Suggest structures, drafts, alternatives, and edits |
| Review | Little or no review of the code | Read changes, test design, behavior, and security | Read changes, check claims, meaning, voice, and source credit |
| Sign of success | It appears to work | Defined behavior passes suitable checks | The text is accurate, supported, deliberate, and useful |
| Hidden failure | Security flaw or missed edge case | Missed requirement or weak test | False claim, lost qualifier, invented source, or misleading suggestion |
| Recovery | Often informal | Version history, restore, and roll back | Draft history, tracked changes, correction, or retraction |
The relevant question is not how many lines or words AI generated. It is whether the process can catch serious errors before release and make clear who is responsible afterward.
Writing can be checked. It cannot be fully proven.
Software tests are powerful because many requirements can become checks that run the same way each time. But people must still choose the right requirements and tests. Some parts of writing have clear, repeatable checks. Others need human judgment.
Check one claim, date, quotation, calculation, or definition.
Check that the headline, summary, body, caption, and page details tell the same story.
Check that an edit did not remove an approved qualifier or bring back an old error.
Ask whether the intended reader can understand the message and act correctly.
Check for confidential data, personal information, legal risks, and unsafe instructions.
Get a careful review from an editor, source owner, or subject expert.
Five writing risks a green check cannot resolve
Facts
A generated citation exists, but the source does not support the sentence attached to it.
Open the original source. Match it to the exact claim, number, quotation, and date.
Meaning
A rewrite changes “may” to “will,” quietly turning possibility into certainty.
Compare claims and qualifiers, not only changed words or sentence length.
Voice
A smoother paragraph removes hesitation that was central to the writer's honest stance.
Read it aloud. Compare its rhythm, confidence, detail, and deliberate quirks.
Attribution
A believable paraphrase blends several ideas until no source clearly supports or deserves credit for it.
Keep a list that links each sourced claim to the exact passage that supports it.
Audience
A policy email sounds reassuring but causes readers to expect a refund they cannot receive.
Ask someone from the intended audience what the text promises, rules out, and asks them to do.
Give a draft a release pipeline.
Writers do not need Git to use engineering discipline. They need focused changes, earlier versions they can restore, clear checks, and one reliable source to work from. The process below is our suggested writing framework, not an industry standard.
- 01
Brief
Define the audience, purpose, limits, evidence, and what “done” means.
- 02
Source baseline
Keep the notes, policy, interview, or human draft that is the main authority.
- 03
Focused AI change
Ask for one type of change instead of an uncontrolled full rewrite.
- 04
Review changes
Check additions, deletions, qualifiers, new meanings, and missing details.
- 05
Checks at each level
Check claims, meaning, voice, source credit, and what readers may understand.
- 06
Independent review
Choose a reviewer who fits the risk: an editor, expert, source owner, or compliance lead.
- 07
Publish and monitor
Keep the approved version. Make visible corrections if errors keep causing harm after publication.
Before asking for polish, define what the text must keep and what it must achieve.
Change structure, certainty, tone, or length one issue at a time.
Keep the source draft, major revisions, comments, and approved published version.
Return to a version you know is sound instead of using more prompts to fix a damaged rewrite.
A loose process has a place, within clear limits.
Explore freely
- Private brainstorming
- Temporary experiments with structure
- Unpublished headline alternatives
- Non-sensitive personal notes
Require stronger safeguards
- Journalism, research, and public accusations
- Health, legal, financial, or safety guidance
- Policy and contract-related messages
- Confidential, academic, or regulated work
Make the review stricter as the possible harm grows, not as the word count grows.
Six tempting shortcuts to avoid
01Does vibe coding mean any code written with AI?
People also use the term more broadly, but that goes beyond Karpathy's original example. It helps to separate unreviewed AI-generated code from AI-assisted development where a person reviews, tests, and understands the code they keep.
02If the program runs, is it correct?
No. It worked in the case you saw. Security, accessibility, speed, data transfer, long-term upkeep, and untested edge cases may still fail.
03Is writing too subjective to test?
Many parts can be checked: dates, names, quotations, calculations, policy conditions, links, and required sections. Fairness, voice, confidence, and what readers may understand still need careful human judgment. No fixed test can decide them every time.
04Does a clean diff prove the meaning stayed the same?
A comparison shows what changed on the page. It cannot show missing context that appears in neither version. It also cannot decide whether the new message is accurate or intended.
05Does human review mean reading the final output once?
A sound review checks the change against the brief, source material, unusual cases, audience needs, and relevant rules. Quickly approving smooth prose is still an “accept all” process in practice.
06Must a responsible writer manually type most of the words?
Word count is not the best measure. A better question is whether the writer directs the work, understands it, checks it, and takes responsibility for it.
A practical checklist for responsible vibe writing
- I know what the output must accomplish.
- I can see what changed from the source material.
- I checked claims against original sources.
- I checked words that limit claims, suggested meanings, and missing conditions.
- I can explain why every passage that could have serious effects remains.
- The voice and stance still represent the named writer.
- The intended reader can interpret and act on it correctly.
- I kept an earlier version that I can restore.
- A qualified person reviewed it when the risk called for one.
Borrow engineering's discipline, not the comforting fiction that a green check mark can prove that prose is correct.
Sources behind the comparison
Original documents describe engineering and editing practices. Sources from people in the field explain how they use the terms. None of these sources sets one universal definition of responsible writing.
- Andrej Karpathy: original public vibe-coding description
- Simon Willison: vibe coding versus reviewed AI assistance
- Google Engineering Practices: code review
- NIST Secure Software Development Framework
- Git: snapshots, states, and recoverable history
- Associated Press standards around generative AI
- NIST Generative AI Profile
- Nature Portfolio AI editorial policy