Use cases
Where the model applies
Eight representative situations for teams and developers who build software with AI agents, at every level. Each shows the situation, what the model asks, what the team gains, and how little changes day to day. The levels are defined in the model. They are illustrative scenarios, not case studies.
Use case 1 · Level 2
From a prototype to a product customers can rely on
The situation
An independent developer has built an application largely by prompting an agent. It now has users and stores their data. Nothing blocks a broken change, and the agent can run any command on the machine.
What the model asks
The Level 2 basics: a rules file, checks that block a failing commit, secret scanning, deny rules that keep the agent away from credentials and destructive commands, a rule that the agent publishes to production only after the developer confirms, an AI peer review from another company, and a check seen to refuse a change: a planted fault, or a real failure that was then fixed.
What the team gains
A gate that refuses broken changes before they ship, credentials out of the agent's reach, and a second reader for a developer who would otherwise work alone.
What changes day to day: little. The agent follows the rules file and asks before it guesses; the hooks and the review run on their own.
The book: chapters 5, 6 and 19.
Use case 2 · Any level
Showing an employer or a client that the work is professional
The situation
An employer, a client or an internal audit asks how the team assures the quality of code written with AI. The team has good practices, but no single account of them that an outsider could examine.
What the model asks
A formal VibeQM assessment: two AI models from different companies follow the published procedure independently, the lower result stands, items the assessors cannot see need dated proof, and a named person countersigns. The report expires after a year or a change of main model.
What the team gains
A report in which every claim points to evidence a reader can open, a defined way to state the result ("VibeQM vX.Y.Z self-assessed: Level N", with the date and the assessor), and the exact list of what the next level requires.
What changes day to day: nothing during the work. The records the assessment reads are kept as the work happens.
The book: chapters 4 and 18.
Use case 3 · Level 3
A team where every project works differently
The situation
Each project, and each developer, uses AI agents in its own way. One repository has strict checks and another has none; a fix learned in one place never reaches the others.
What the model asks
One written standard across projects, readable by people and by agents; its critical rules enforced by hooks, checks or permissions; and an audit that can fail, showing every project follows it.
What the team gains
The same professional quality in every project, whoever works on it, and lessons that spread to all of them at once.
What changes day to day: each project's rules file points to the shared standard, so every agent session starts from it.
The book: chapters 7 and 17.
Use case 4 · Levels 2 to 4
Reviews that no longer catch anything
The situation
Agents produce large changes, and reviewers approve them after a glance. Defects reach the main branch that a careful reader would have caught, and the tests, written by the same agent, pass.
What the model asks
Small changes (a median of 400 changed lines or fewer per commit on the main branch, and no high-risk change above the limit); a peer review that is independent of the writing model, and from Level 3 an AI reviewer that has been seen to catch planted faults; planted faults and mutation testing to show the tests can fail; and, at Level 4, review yield measured alongside review time.
What the team gains
Reviews that people actually read, tests that are evidence, and a number that shows when review has turned into approval.
What changes day to day: changes get smaller, which the agent does when the rules file says so; review takes less time per change.
The book: chapters 6, 8 and 12.
Use case 5 · Levels 2 and 3
Working under contract or regulation
The situation
A team works under a contract or a regulation that limits where code and data may go. It wants to use agents, and must be able to show that it still meets its obligations.
What the model asks
A written data boundary stating which code and data may go to which AI company; no production credentials in the agent's reach; a person for every irreversible action; and a tailoring record for each deliberate departure from the standard.
What the team gains
AI adoption that fits the obligations the team already has, with every exception visible, dated and approved.
What changes day to day: little for most changes; the agent is limited to what the boundary allows, and irreversible steps wait for a person.
The book: chapters 14 and 17.
Use case 6 · Levels 3 and 4
Adopting a new model
The situation
A vendor releases a new model, and the team wants to move to it. Everything the team knows about its error rates was learned with the previous model.
What the model asks
Models pinned to exact versions; a trial on a slice of real work before the switch; a provenance record of which model wrote each change; and, after the switch, the previous limits tightened by 20% until the new model has its own baseline: 50 changes and 30 days of data, capped at 90 days.
What the team gains
A model change that is a decision made with data, and a regression that shows up in the measures instead of in production.
What changes day to day: nothing until the switch; the trial and the stricter limits are part of the process, not extra work.
The book: chapters 8 and 15.
Use case 7 · Level 3
Several agents working at once
The situation
A team runs several agents in parallel, one per task. Two of them edit the same files, and one quietly overwrites the other's work.
What the model asks
Each agent on its own branch or working tree; every branch through the same checks and review; and a person deciding the order when two agents change the same area, recorded as the team's branch policy for agents.
What the team gains
Parallel output without silent overwrites, and a history in which each agent's changes, and the model that wrote them, can be told apart.
What changes day to day: each agent gets its own branch, and a person decides the order only when two touch the same area.
The book: chapter 15.
Use case 8 · Level 3
An agent that reads untrusted content
The situation
An agent triages public issues for a project. It can read the private repository and reach the network. Any issue can contain text written to look like an instruction.
What the model asks
Defenses against prompt injection among the critical rules, enforced by the system: no agent that combines private data, untrusted content and a way to send data out; a network allow list; and a person for anything sent outside.
What the team gains
An agent that can do useful work on untrusted input without being able to pass private data to whoever wrote it.
What changes day to day: nothing for the people involved; the limits apply to the agent.
The book: chapter 14.