For example, a team has six application-review hours available this week after existing commitments, and four proposed AI-assisted changes each need two hours of review, including revisions. Only three fit the weekly allocation, and only two may start concurrently under the team’s work-in-progress limit, with review hours reserved before implementation starts.
The fourth change must wait, shrink in scope, or receive additional qualified review time. The third waits for a concurrency slot, and its place depends on how much review time the first two actually consume.
Expand access by change category
I would expand access by change category, with a named reviewer pool and an explicit allocation, rather than grant unrestricted use and wait for the queue to reveal the constraint. A useful tool can produce more proposals than a team can assess. Even a faster review process can lack the specialist needed to evaluate an authorization change.
The same capacity constraint applies to human-written changes. Account for any additional volume the AI adoption plan expects to introduce, rather than treating tool access as a commitment to accept every resulting proposal.
Use a review-capacity budget
Copy this table into the adoption proposal. Its values continue the opening example, rather than prescribing staffing ratios. The six application-review hours form one shared allocation across all categories requiring application review.
| Change category | Qualified reviewer pool | Available review allocation | Local work-in-progress limit | Queue owner | Overload action |
|---|---|---|---|---|---|
| Bounded application changes outside designated sensitive areas | Named application maintainers | Draws from the shared 6 application-review hours this week | 2 concurrent changes | Application lead | Defer the next change until hours and a slot are available |
| Authentication or authorization changes | Application maintainer plus designated security reviewer | Draws from the same 6 application-review hours, plus 2 security-review hours this week | 1 concurrent change | Security review coordinator | Stop admitting this category until both pools have capacity |
| Database migrations | Service maintainer plus designated database reviewer | Any application review draws from the same 6 hours; no additional database-review allocation this week | 0 additional changes | Service owner | Defer, or explicitly fund and schedule qualified review |
The security row exposes a different bottleneck. If an authorization change reserves two application-review hours and both security-review hours, four application-review hours remain. A second authorization change still cannot start: it needs security capacity too. Even after the first change finishes and releases its concurrency slot, the second remains blocked if the security hours have been spent.
Define “admitted” as accepted into active implementation or review under this policy. Reserve estimated review hours in every required pool at admission, before implementation starts. Otherwise, implementation can accumulate and later arrive at review as an urgent release commitment.
Use four accounting rules:
- Count net availability. Subtract existing review commitments, on-call duties, leave, and other allocated work. Do not count the same person’s hours in multiple pools.
- Reserve the full review estimate. Include understanding the change, checking evidence, requesting revisions, and reassessing them. Every required pool must have enough uncommitted hours.
- Reconcile reservations against actual effort. Replace reserved estimates with actual hours as work progresses. Return unused hours to the weekly balance; charge overruns against it.
- Track slots separately. Finishing a change releases a concurrency slot, not the hours already spent reviewing it. Choose work-in-progress limits locally, based on change size, uncertainty, and reviewer availability.
A free slot does not create review hours.
For the opening application changes, admitting the first two reserves four hours and leaves two uncommitted. The third waits for a slot. If the first two each take three hours instead of two, their overruns consume the remaining allocation. The third stays deferred until additional hours are explicitly allocated or a new period’s allocation becomes available.
Give the queue owner authority to act on overload
The queue owner maintains the budget and makes admission decisions. The author remains responsible for the proposal and its evidence. Qualified reviewers remain responsible for their assigned approvals.
Queue ownership should not silently confer technical approval authority. A coordinator can identify that security review is required without being qualified to perform it.
Apply these admission and overload rules:
- Admit when qualified reviewers, uncommitted hours, and a work-in-progress slot are available. Name the reviewers and record the reservation.
- Defer when a required pool lacks hours or a slot. Record which capacity must become available.
- Narrow permitted tool use when a category requires expertise the team cannot provide. Exclude that category until qualified review is arranged.
- Fund additional capacity by naming which existing commitment will lose reviewer time. Reallocate qualified staff time, develop expertise, or obtain appropriate review support before expanding admission.
- Reassess when admitted work grows beyond its category or estimate. Pause further admission, reclassify the change, and reserve the additional reviewer hours.
For urgent work, explicitly displace a lower-priority commitment and record who authorized the trade-off. Calling a change urgent does not create a reviewer.
Keep evidence and approval requirements independent of capacity
The capacity budget decides when work enters. The release policy decides what must be demonstrated before it ships.
AI-assisted changes need a named human owner and the same applicable verification and approval requirements as other changes. Set those requirements according to the change’s consequences and uncertainty; capacity pressure must not weaken them.
Alongside the capacity record, keep a compact evidence checklist:
- Owner: Who will explain and revise the change?
- Behavior: What should change, and which components are affected?
- Evidence: What do relevant tests demonstrate, and what gaps remain?
- Operations: Which operational or rollback assessments are required?
Generated tests or explanations can contribute evidence, but reviewers still need to assess whether that evidence addresses intended behavior and relevant failure modes.
Classify the actual change. A small permissions edit can require specialist review even when its diff is short.
Adjust admission using observed review demand
Track estimated versus actual review effort, time blocked on a specific reviewer pool, and changes reclassified after admission. Use those signals to adjust future allocations and concurrency limits.
Do not treat a short queue or faster completion as evidence of correctness or better review. Those measures describe flow, not whether the evidence was sufficient.
Triage the next three proposals in five minutes
List the next three AI-assisted changes your team wants to undertake. For each, record the category, required reviewer pools, known available hours, concurrency slot, and overload action in the budget.
Mark unknown availability or review effort as unresolved. Defer proposals with a known capacity shortfall or no qualified reviewer.
This is a five-minute triage, not completed capacity planning. Before admitting work, confirm reviewer availability, agree on estimates, and reserve the hours. Revise those reservations as actual effort becomes visible.