When one person on a team uses AI, it is a productivity story. When everyone does, it is an operating problem. Drafts multiply, review does not, and the question "who is finishing this?" has no answer. This playbook is a small operating model for that situation. Four practices, in order of how much they matter.
The new bottleneck
Before AI, a team's capacity was limited by how fast people could produce first versions. Now first versions are close to free, and capacity is limited by how fast people can turn them into finished work: review, integration, verification, decisions. Sonar's 2026 State of Code survey of 1,149 professional developers puts numbers on it: 42% of committed code is already AI-generated or assisted, 96% of developers do not fully trust that code, yet only 48% always verify it before committing. Sonar's own name for the result is "the verification bottleneck". Personal speed went up. Shared confidence did not.
The same survey found developers now rank "reviewing and validating AI-generated code" as the single most important skill for the AI era. Translated for a team: the scarce resource is no longer people who can start; it is people who can finish and sign off, and a process that gets the work to them.
Practice 1: One owner per outcome
Every piece of AI-assisted work has exactly one accountable person. Not the person who wrote the prompt, necessarily. The person who will say "this is finished" and mean it. Write the name down at the start, where the work is.
This sounds obvious and is almost never done. The generated draft arrives in a channel, three people comment, two suggest changes, one says "looks good", and it ships with nobody having owned it. When it goes wrong, the model gets the blame, which is another way of saying nobody does.
Rule: if a piece of work has no owner, it does not enter the workflow. It stays an output.
Practice 2: A definition of done before the work, a gate before shipping
Two moments, both short, both mandatory for anything that leaves the team.
Define: before any human work begins, the owner writes five to eight observable lines describing finished. "Facts sourced. Voice per guide. Legal has seen the claims. Under 400 words. Live on staging." This is the standard the AI output will be measured against, and it turns the invisible gap into a visible task list.
Approve: before shipping, a named person checks the work against that definition and records a decision: approved, or changes requested with reasons. Not a thumbs-up emoji. A record.
Teams resist this because it looks like process. It is the smallest process that produces accountability, and it replaces the much larger implicit process of "hope someone looked at it".
Practice 3: Keep provenance
For every piece of AI-assisted work, capture at the start: what tool produced the output, from what prompt, on what date, and which output was chosen. Then, as people work, keep their changes attached to that origin.
This has three payoffs. It answers the disclosure question honestly and instantly when a client, platform or policy asks how AI was used. It makes review faster, because reviewers can see the human delta rather than re-reading everything. And it is how the team learns: after ten pieces of work you can see which prompts and tools produced output that needed the least finishing.
Provenance is also the practical form of an AI policy. Most policies live in a PDF nobody reads. Capture-at-start and approve-before-ship, applied to every piece of work, is the policy, applied.
Practice 4: Turn what worked into a template
The third AI-assisted landing page should not start from zero. Once a piece of work ships well, save its shape: the definition of done, the task list, the review checks, the roles. New work of the same kind inherits it. Over time the team builds a small library of after-AI workflows, one per kind of work it does often.
This is where the speed comes back. The first piece of work in a new category is slow because the gap is unknown. The tenth is fast because the gap is a template.
The model in one view
| Without the model | With the model |
|---|---|
| Draft appears in a channel; several people comment | Work is opened with one owner and the AI source attached |
| "Finished" is a feeling, judged differently by each person | Finished is five to eight observable lines, written first |
| Review is a read-through; "looks good" ships it | Review is a check against the definition; a named approval is recorded |
| Nobody can say how AI was used in last month's work | Provenance is captured at start; disclosure is one click |
| Every new piece of work re-invents its process | Shipped workflows become templates for the next |
Where to start
- Pick one kind of work the team does often with AI. Landing pages, feature PRs, social posts, client concepts.
- Run the next three through the four practices: owner, define, provenance, approve.
- Save the third one as the template.
- Then widen. The habits transfer across kinds of work because the stages are the same.
How this was made: written by the After AI Work team from running this model on our own work. Figures from Sonar's 2026 State of Code Developer Survey (fieldwork October 2025, published January 2026). AI tools helped draft the comparison table; each row was rewritten and checked by a person.