RFV-0001: Request for Vibes

Link: https://github.com/Request-For-Vibes/rfv/blob/main/rfv-0001.md

Status: Draft 

Author: Bruce Taylor 

Created: 2026-05-13 

Replaces: Common sense, apparently

Abstract

The software industry has adopted "vibe coding" at a pace that outstrips its ability to review the results. 

We have RFC (Request for Comments) for protocol design. 

We have RFP (Request for Proposal) for procurement. 

We do not have a formal mechanism for evaluating whether a piece of software was written by a human who understood the problem, or by someone who typed "make it work" into a prompt and accepted the first thing that compiled.

This document proposes RFV (Request for Vibes): a structured review process for code of uncertain provenance.

1. Problem Statement

A growing proportion of production code was not written by the person whose name is on the commit.

It was generated, accepted, perhaps briefly glanced at, and merged. The author may not be able to explain what it does. They may not know why it does it that way. They may not have read it at all.

Existing review processes assume the author can defend their work. This assumption is no longer safe.

The industry needs a formal checkpoint between "Claude said it was fine" and "it is in production."

2. Terminology

Vibe coded: Software produced by describing the desired outcome to a language model and accepting the output with minimal or no review. The developer's contribution is the prompt. The model's contribution is everything else.

Vibe debt: The accumulated cost of code that works but which nobody on the team understands well enough to maintain. Similar to technical debt, except the original author cannot explain the decisions because they did not make them.

Vibe check: The act of reviewing vibe coded software. Distinguished from a normal code review by the additional requirement of establishing whether anyone involved actually understands what the code does.

Vibe ratio: The proportion of a codebase that was vibe coded. A vibe ratio above 0.7 is classified as a Vibe Emergency (see Section 5).

Vibesmith: A developer who exclusively vibe codes. Not a pejorative (officially).

3. The RFV Process

An RFV is raised when any of the following conditions are met:

1. The author cannot explain a function they committed without re-reading it first.
2. A reviewer asks "why did you do it this way?" and the honest answer is "I did not."
3. The commit message contains the phrase "as suggested by" followed by a model name.
4. The pull request was opened within four minutes of the ticket being assigned.
5. The code works perfectly on the first attempt. (This alone warrants investigation.)

3.1 RFV Severity Levels

RFV-1 (Low): Code is vibe coded but the author has reviewed it, understands it, and can explain the design choices. The vibes are good. No action required beyond documentation.

RFV-2 (Medium): Code is vibe coded and the author understands most of it but cannot explain certain sections. The vibes are mixed. A senior engineer must review the unexplained sections before merge.

RFV-3 (High): Code is vibe coded and the author cannot explain significant portions. The vibes are off. A full review is required, including test coverage analysis and a brief written explanation of what the code does (written by a human, not generated).

RFV-4 (Critical): Code is vibe coded, the author cannot explain it, and it touches authentication, payments, or personal data. The vibes are catastrophic. The PR is closed. The author is asked to write the code by hand or pair with someone who can explain what is happening. Earl Grey is offered but not enforced.

3.2 The Vibe Interview

For RFV-3 and above, the author must answer the following questions without consulting the model that wrote the code:

1. What does this code do?
2. Why does it do it this way and not another way?
3. What happens when the input is null?
4. What happens when the input is not null but is wrong in a way you have not considered?
5. Where are the tests?
6. Did you write the tests, or did the same model write both the tests and the code they are testing? (Be honest. We will know.)

A score of four or more confident answers constitutes a pass. Fewer than four triggers a mandatory pairing session.

4. RFV Compliance Indicators

The following metrics shall be tracked per team per sprint:

• Vibe ratio: percentage of commits classified as vibe coded
• RFV pass rate: percentage of RFVs that pass the vibe interview on first attempt
• Time to comprehension: average time between "I wrote this" and "I understand this" (ideally zero; in practice, non-trivial)
• Prompt-to-production latency: time between the initial prompt and the code reaching production. Values under ten minutes are flagged automatically.

5. Vibe Emergency Protocol

A Vibe Emergency is declared when a team's vibe ratio exceeds 0.7 for two consecutive sprints. The following measures take effect:

1. All PRs require a handwritten (not generated) summary of what the code does and why.
2. The team lead must certify that at least one human read the code before merge. Actually read it. Not scrolled past it.
3. A "Vibe Audit" is conducted: a senior engineer picks three random commits and asks the author to explain them on the spot. This is not a punishment. It is a calibration exercise. (It does feel like a punishment.)
4. The team is given a copy of "Code Complete" and left to reflect.

6. Exemptions

The following are exempt from RFV review:

• Boilerplate configuration (nobody understands Webpack configs, vibe coded or otherwise)
• Generated migration files (these were always vibes)
• README files (the model probably wrote a better one than you would have)
• Any code written after 4pm on a Friday (this was always vibe coding; we just did not have a name for it)

7. Relationship to Existing Standards

RFV complements but does not replace existing review processes:

8. Future Work

• RFV-CI: automated vibe detection in CI pipelines. Heuristics include: suspiciously consistent formatting, comments that explain what the code does rather than why, and variable names that are inexplicably good.
• Vibe Score Badge: a repository-level badge showing the current vibe ratio. Green (under 0.3), amber (0.3 to 0.7), red (above 0.7), and a new colour yet to be named for repositories that are entirely vibe coded.
• Inter-team Vibe Audits: teams audit each other's vibe ratios. Gamification was considered and rejected on the grounds that it would make things worse.

9. Acknowledgements

This proposal was written by a human, me.

I would like to thank the following people and intangible objects:

• The em dash
• My lecturer at University who explained Database normalisation with a Dire Straits' album (Brothers in Arms)
• Claude Shannon

Submit RFVs to here https://github.com/Request-For-Vibes/rfv