The Vibe Quality Model · version 0.4.4
The model
A summary of the specification: the path from ad-hoc to professional work, what each level requires, and the rules that decide what counts as evidence.
§1 · Scope
Purpose and scope
VibeQM exists to make software built with AI agents professional: work of a quality that employers and customers can trust, with the evidence to show it. It applies to any software project in which AI coding agents write, review or change code. Its unit of assessment is a repository, or a team's set of repositories. It specifies outcomes and the evidence that shows them; it does not prescribe tools.
The model works through the agent. Its rules files, templates and prompts instruct the AI to follow professional practice and keep the records; hooks, checks and permissions enforce the rules that must not fail; an assessment reads the records and states the level they support. The developer's everyday work changes little.
- The staged rule
- A level counts only while every level below it is still met. A team cannot claim Level 4 while a Level 2 item is missing.
§2 · Levels
The five levels
| Level | What is true | Evidence to claim it |
|---|---|---|
| 1 · Unguided | Code is prompted, accepted and shipped when it runs. Quality depends on chance and on one person's attention. | None. Every project starts here. |
| 2 · Guarded | Every project has the basics: written requirements with acceptance criteria, a rules file, version control with tagged releases, a peer review of every push or pull request, automated verification on every change, a security review before every push, small changes (a high-risk change included), development kept apart from production, limited agent permissions, and a human owner for every change. | Each Level 2 item met, with evidence, including checks that have been seen to fail. |
| 3 · Standardized | One standard across projects, enforced by the system and audited: traceable requirements, peer review by risk, with the AI reviewer proven on planted faults; verification and validation through three environments; current platforms, release and incident practices; pinned models and a record of which model wrote each change. | The standard, an audit that can fail, critical rules enforced by hooks, checks or permissions, and the Level 3 documents. |
| 4 · Measured | Quality and delivery are measured against limits, with a baseline for each model version, including one signal written by people outside the team. The AI's right to merge is checked before every merge and stops automatically when a limit is crossed. | The measures with baselines and limits, records the agent's session cannot alter, an automatic stop seen to fire, and a record of acting on the numbers. |
| 5 · Self-Improving | Every escaped defect and incident receives a root-cause analysis and becomes a new rule, check, skill or permission. Improvements are tried against the measures before adoption. | A lessons log whose entries link to the change each made, and evidence that mistakes of the same kind stop recurring. |
Items that assume a live production service, such as three environments, monitoring or service-level objectives, apply where one exists. Other products, such as a library or a book, state an equally strict equivalent, or mark the item not applicable with the reason.
§3 · Evidence
The five evidence rules
- The agent's word is not evidence. Only records the system produced count: check logs, test output, history, review records. From Level 4, the records that grant autonomy are written by a hook or CI where the agent's session cannot change them, and each names the change it covers.
- A check counts only after it has been seen to fail. A check that has never refused anything may be wired to nothing.
- Peer review must be independent. A human peer review is by a person other than the author; an AI peer review is by a model from a different company, in a separate session. A model reviewing its own work is neither. From Level 3, an AI reviewer counts only after it has been seen to catch a set of planted faults.
- Risk decides the review. Each change has a risk class, and the class sets the minimum review before it lands.
- Traces over documents. A document shows that a standard exists; only traces, such as commits, logs and records, show that it was followed.
§4 · Risk
Risk classes
| Class | Examples | Minimum before the change lands |
|---|---|---|
| Low | Documentation, comments, styling, new tests that leave existing tests unchanged | Automated checks, plus the peer review every change receives from Level 2 |
| Standard | Everything not listed as low or high | Automated checks and a human or AI peer review |
| High | Login and permissions, payments, personal data, deleting data, security settings, deployment and infrastructure, new dependencies and agent plug-ins, the AI's own rules and permissions, any change that weakens or deletes a test | Automated checks and a peer review; from Level 3, a human and an AI peer review and a short threat model |
A high-risk change stays within the size limit (400 changed lines by default; a change is a commit on the main branch); a larger one is split. Risk classes are audited: an assessor re-sorts a sample of at least 20 changes, and if more than one in ten was classed too low, the audit fails and Level 4 self-merging is suspended.
§5 · Measures
The Level 4 measures
Quality measures
- Escaped defects per 100 merged changes, linked to their cause, cross-checked against change failure rate and the count of reverted changes
- New security findings, and the count still open
- Review time, always paired with review yield
- Churn: added lines changed or deleted again within 30 days
- One signal written by people outside the team: defects users report, support requests, customer acceptance results
Delivery and platform
- DORA's four delivery metrics: deployment frequency, lead time, change failure rate, time to restore (now "failed deployment recovery time")[2]
- Dependency freshness against a written update policy
- Service-level objectives in production
The measures are diagnostics, not targets: a number that becomes a target stops measuring what it was meant to. Each measure has a baseline for each model version, and a change of the reviewing model restarts the baselines that depend on review. After a model change, the previous limits apply, 20% stricter, until the new baseline has 50 changes or 30 days of data, whichever comes later, and for 90 days at most.
§6 · Practice areas
Twelve practice areas
| Area | Covers |
|---|---|
| Requirements | Requirements first, clarifying questions with options, acceptance criteria, traceability, non-functional requirements, diagrams |
| Context | Rules files, specifications, what the agent may read and touch |
| Change control | Version control, branches, small changes, risk classes, releases, parallel agents, rollback |
| Verification and validation | Tests, human and AI peer review, static analysis, planted faults, acceptance in staging |
| Environments and deployment | Development, staging and production; promotion by pipeline; no direct production changes |
| Provenance and model management | Which model wrote and reviewed each change; pinning; trials before switching; portability |
| Security and supply chain | Security review before push, scanning, threat models, secrets, data boundary, plug-ins, licensing, currency |
| Agent permissions and safety | Least access, sandboxes, irreversible actions, prompt injection |
| Operations | Monitoring, incident response, postmortems, backups |
| Measurement | The quality and delivery measures, freshness, service-level objectives |
| Learning | Lessons log, root-cause analysis, improvement trials, process review |
| Human ownership and training | An owner for every change, cognitive debt, training on the standard and tools |
§7 · Autonomy
Autonomy, as a consequence of quality
As a team proves its quality, the model states how much the AI may do on its own: a team earns more AI autonomy by proving quality, and the autonomy holds only while the evidence does. It follows from the levels; it is not their purpose. The step in parentheses is the closest match on Dan Shapiro's autonomy ladder for AI-assisted development.[1] The match is approximate: the ladder describes an individual's way of working; VibeQM describes a team's evidence.
| Level | The AI may | A person must |
|---|---|---|
| 1 · Unguided | Nothing is earned; treat its output as a draft (L1) | Read every change before it lands |
| 2 · Guarded | Edit on a separate branch while a person supervises, and run the checks (L2) | Own and approve every change, after the checks and a peer review |
| 3 · Standardized | Take a task to a finished, proposed change on its own (L3) | Approve every merge; give high-risk changes both a human and an AI peer review |
| 4 · Measured | Merge low-risk changes itself, after the checks and an automated AI peer review, while every Level 4 measure stays within its limit; a hook checks the change and the day's numbers before each merge (part of L4) | Approve every standard- and high-risk merge; clear a stop by recording an override with a lessons entry |
| 5 · Self-Improving | Merge low- and standard-risk changes under a written performance agreement, with an AI peer from another company reviewing every change and a kill switch that suspends it on any breach (L5, governed) | Own the agreement; review every high-risk change; restore autonomy after the kill switch fires; approve anything irreversible |
Irreversible actions need a person, at every level. The test: if the team cannot undo an action with a rollback it has actually practiced, a person approves it at the moment it happens. Deleting data, deploying to production, publishing a package, sending messages outside the team, spending money and changing credentials or the agent's own permissions are examples; the test decides.
Owner and approver are separate roles. The owner is the person accountable for a change, at every level. The approver lets it merge. From Level 4, for low-risk changes, the approver may be the system; the owner is always a person.
§8 · Before AI
How software quality was managed before AI
Before AI agents wrote code, software organizations already had ways to manage quality: process-maturity models, with levels a team climbs in order; quality-management standards, with documented and audited process; statistical quality methods, with measurement against limits and the search for root causes; and DORA's delivery metrics.[2]
All of them assume that people do the work. With AI, most of the work is done by a contributor that cannot be held accountable, changes when its model changes, and reports on its own work with equal confidence whether right or wrong. VibeQM is built for that situation, with what earlier approaches never needed: instructions that make the agent itself carry out professional practice, evidence rules that exclude the agent's own account, review by a model from a different company, baselines tied to the model version, and autonomy that follows the evidence. Related work includes the AI Codebase Maturity Model and AASD-OMM.[3]
§9 · Versions
Versioning
This page summarizes version 0.4.4 (17 October 2026). Each version is dated, and every change to the model is recorded with the decision behind it. The full specification, the assessor procedure and the documentation standard are published with each version, in the companion repository.
References
Sources
- Dan Shapiro, "The Five Levels: from Spicy Autocomplete to the Dark Factory", January 2026. ↩
- DORA (DevOps Research and Assessment), the software delivery metrics as defined at dora.dev, including the 2023 rename of time to restore service and the 2024 addition of deployment rework rate. ↩
- AI Codebase Maturity Model (ACMM), arXiv 2604.09388; AASD-OMM, Hacettepe University, February 2026. ↩