How to build an AI team transition budget

An AI team transition does not fail because the model bill is too high. It fails because leaders budget for licenses, then discover they are paying two delivery systems at once: the old team keeps the product safe while the new process consumes senior attention, specialist availability, and a growing queue of reviews.

Treat the overlap as a temporary production program with its own cost model. Give it a narrow scope, a named owner, a weekly forecast, and an end date that depends on evidence. If you cannot state what the old model is still protecting, you do not have a parallel run. You have two teams doing overlapping work and hoping the payroll math improves later.

The goal is not to make every engineer use an agent immediately. The goal is to prove that a smaller AI-assisted delivery unit can take over a specific class of work without quietly borrowing unlimited support from the people you plan to remove from the cost base.

A parallel run must have one job

A parallel run should validate a replacement path for defined work, not duplicate the entire engineering organization. The old and new models can operate at the same time, but they should not both own the same issue from discovery through production.

I separate three arrangements that companies routinely blur together:

• Shadow work means the new team repeats or simulates work while the old path remains solely responsible for the result. This is useful for learning, but it is expensive because you intentionally create duplicate output.
• Parallel delivery means the new path owns a limited category of production work while the old path remains available for escalation and checks. This is the arrangement most startups need.
• Split ownership means both paths own the same product area with unclear boundaries. This produces duplicate decisions, incompatible changes, and arguments about who caused the delay.

Only parallel delivery gives you usable evidence about the future operating model. You can see whether an AI-assisted unit can take a defined ticket from ready to deployed, how much review it needs, and when it needs a specialist. Shadow work can teach a team how to use tools, but it cannot justify a headcount plan.

Write the scope in one paragraph. For example:

For six weeks, the AI-assisted unit owns customer-reported defects in the billing portal that do not change payment provider behavior, data retention, or authorization. The existing team owns incidents, production access, database changes, and any change that crosses those boundaries. A staff engineer approves merges, and the operations lead approves releases that affect production configuration.

That paragraph does more work than a ten-page adoption plan. It sets the workload, names the exclusions, and exposes the specialist coverage you need to budget.

The popular recommendation to give every developer a tool license on day one is wrong for a transition. It feels fair and looks fast, but it destroys the comparison. You cannot tell whether better output came from a new workflow, a new model, individual experimentation, or people working longer hours to prove the program works. Start with a unit that has a clear backlog and an accountable lead. Expand after you can explain the result.

Price the old team by protected capacity

The old delivery model is not free during the overlap just because its people remain on payroll. Its transition cost is the capacity you prevent it from using on normal product work.

Begin with each person's weekly available hours. Remove meetings, paid time off, on-call recovery, and the ordinary operational work that will not disappear during the transition. Then estimate how much of the remaining capacity stays reserved for the new unit. Do not estimate this as a vague percentage in a slide. Name the responsibility and the weekly hours.

A simple capacity table is enough:

Convert reserved hours to money using fully loaded hourly cost, not base salary. Fully loaded cost includes employer taxes, benefits, contractor overhead, and any regular allocation that the company pays to keep that role available. If you do not have exact numbers, use a consistent internal rate for the first forecast and replace it when finance provides better data. Fake precision is worse than a transparent assumption.

Use this formula for each role:

weekly protected-capacity cost = reserved transition hours × loaded hourly cost

Then add the cost across roles. The result is the actual price of keeping the old model on standby. It also shows where a transition will break. If the new unit needs twelve senior review hours every week, you have not removed a senior role from the model. You have moved that role from feature delivery into a gate.

There is a further distinction that matters: availability is not utilization. Your operations engineer may spend only one hour helping during a quiet week, but if the AI-assisted unit cannot release safely without that engineer being reachable, reserve the agreed coverage time in the budget. Pretending that availability costs nothing is how a forecast looks excellent until the first incident.

Do not charge every minute of the old team to the parallel run. Charge the incremental capacity that the transition protects or redirects. If the engineering lead would have reviewed the same class of change anyway, you need to compare the old review time with the new review time and budget the difference. If the lead now reviews every task because nobody trusts agent output, charge the full extra load.

Review time deserves its own cost center

Review becomes the hidden labor bill when a team moves drafting work to agents without changing the acceptance process. Faster pull requests do not create faster delivery if a small group of experienced engineers must reconstruct the reasoning behind every change.

Budget review as a separate line item from implementation. Track it in hours per merged change, then divide the work into categories that reveal what is happening. A five-minute review for a test update and a ninety-minute review for a cross-service change should not sit in one average.

Use four categories at first:

The ranges are planning assumptions, not promises. Measure your own baseline after the first week. If review takes longer than the estimate, ask why before you add reviewers. The answer usually falls into one of four buckets: the ticket was vague, the agent changed too much at once, the repository lacks tests, or the reviewer cannot see the evidence needed to accept the change.

GitHub's current billing documentation makes a useful operational point even if you do not use GitHub's tools: advanced AI interactions, agent work, and code review can consume metered usage, while the underlying cost varies by model and the work performed. In practice, that means code review has both a vendor cost and a human cost, and the human cost is often larger during a transition.

Set a review contract before the run begins. Reviewers should verify the acceptance criteria, the changed interfaces, automated test results, migration or rollback behavior, and security-sensitive boundaries. They should not rerun the entire implementation in their heads because the author used an agent. If they need to do that, the unit has not supplied enough evidence.

Require every AI-assisted pull request to contain a short evidence block:

## Change evidence
- Ticket acceptance criteria covered: AC-1, AC-2, AC-3
- Tests added or changed: billing_discount_spec, checkout_api_spec
- Manual check performed: staging checkout with existing customer account
- Risky boundaries touched: none
- Rollback: revert commit; no data migration

This is not paperwork for its own sake. It reduces the time a reviewer spends searching for intent and makes gaps visible. When the same evidence is absent repeatedly, fix the task template or the team habit. Do not ask reviewers to compensate indefinitely.

A useful weekly number is review ratio:

review ratio = total review hours / total implementation hours

If the new unit writes code in half the old time but the review ratio doubles, the apparent gain may be imaginary. The ratio should fall as the unit learns the codebase and improves task shaping. If it keeps rising, stop increasing the scope.

Tool spend needs a ceiling and an owner

Tool spend is manageable when each dollar has an owner, a workload, and a limit. It becomes unpredictable when one company account funds experiments across every repository and finance receives a single invoice after the behavior has already happened.

Build the tool budget from usage patterns, not seat count alone. Seats are the fixed portion. Metered model use, hosted agents, build minutes, test environments, observability events, and gateway infrastructure are the variable portion. The variable portion rises fastest when agents run broad searches, repeat failed attempts, or operate on tasks that no human scoped properly.

Create a budget row for each tool category:

A ceiling without a response rule is decoration. Set alerts at 50%, 75%, and 90% of the weekly variable budget. At 50%, the owner checks whether a repository or task type explains the increase. At 75%, restrict expensive model choices to approved work. At 90%, pause nonessential experiments until the next review. Do not wait for a monthly invoice when the entire point of a parallel run is fast correction.

GitHub documents pooled included AI credits for organization plans and supports budget controls for additional usage. That structure is convenient, but pooled allowance can conceal a costly repository or workflow because light users offset heavy users. Maintain your own mapping from tool use to team, repository, and work class.

For command-line agents, also cap the work an unattended run can attempt. Anthropic's Claude Code CLI documents both a planning permission mode and a --max-turns option for noninteractive work. Those controls are not a substitute for engineering judgment, but they provide a practical way to keep experimental automation from wandering through a task indefinitely.

For example, use a constrained job for repository analysis before you permit code changes:

claude -p --max-turns 4 --permission-mode plan \
  "Inspect the failing test output. Propose the smallest fix, list files that would change, and stop before editing."

The useful output shape is a short proposed plan, affected files, open questions, and a statement that no edit occurred. If the command returns a broad rewrite plan for a narrow test failure, the human should reshape the task rather than raise the turn limit.

Specialist coverage is insurance, not an afterthought

An AI-assisted unit can produce code quickly, but it cannot replace the person who understands why a production database cannot absorb a migration at noon or why a customer contract forbids a particular data flow. Budget specialists by decision rights, not by job title.

List the areas where the new unit cannot make the final call. Most startups have at least these boundaries:

• Production operations and rollback authority.
• Identity, permissions, secrets, and customer data handling.
• Data migration and retention rules.
• Financial logic, regulated behavior, or contractual commitments.
• Core architecture decisions that affect several services.

For each boundary, name one primary specialist and one backup. State the expected response window and the maximum planned hours per week. A person who is nominally available but cannot respond until next Thursday does not provide coverage for a Tuesday release.

The expensive failure is not a specialist spending two hours on a hard change. The expensive failure is the team avoiding the specialist, making an incorrect assumption, and then pulling that person into a production incident with no prepared context. I have watched teams call this speed because the pull request merged quickly. It is not speed. It is deferred work with a higher hourly rate.

Run a weekly exception review. Look at every escalation and ask two questions: did the specialist identify a real boundary that belongs in the standard workflow, or did the task arrive poorly prepared? The first answer produces a guardrail. The second produces a better ticket template, a repository guide, or a clearer owner.

Do not use specialists as permanent approval bottlenecks. If the same type of ordinary change requires security review every time, write a safe pattern that the delivery unit can follow. Keep human review for deviations from the pattern. This is how specialist coverage falls over time without creating careless autonomy.

Build the forecast one week at a time

A transition budget should forecast cash and capacity by week because the overlap changes faster than the annual plan. The first two weeks usually have more setup and review. The middle weeks reveal the real behavior. The final weeks should show the old model releasing capacity, or you are not transitioning.

Use this worksheet structure. It works in a spreadsheet, a finance model, or a plain table in your planning system.

Calculate the weekly total with this formula:

parallel-run cost = protected old-team capacity
                  + new-unit labor
                  + tool spend
                  + specialist reserve
                  + incident reserve

Then calculate a second number that management often avoids because it forces an honest comparison:

cost per accepted production change = parallel-run cost / accepted production changes

Do not use raw pull requests, lines changed, prompts sent, or tickets moved to "done" as the denominator. Count a change only after it meets the acceptance criteria and reaches the production state you defined. If the work class includes feature flags or staged releases, define that state before week one.

The incident reserve should be explicit. Set it using your own recent operational history and the blast radius of the chosen scope, not a generic percentage borrowed from a consulting slide. For a low-risk internal tool, it may be a small amount of operations availability. For a customer-facing billing change, the correct decision may be to exclude the work class entirely until the unit proves itself elsewhere.

Track variance every Friday:

variance = actual weekly cost - forecast weekly cost
variance percent = variance / forecast weekly cost

Write one sentence beside every material variance. Examples: "Review time exceeded plan because three tasks touched undocumented authorization rules" or "Model spend fell because the team used planning mode before implementation." A number without a reason cannot improve next week's forecast.

The forecast must show the release of old-team capacity. If week six carries the same protected hours as week one, either the scope is too hard, the new unit has not learned, or leadership has not allowed it to own the work. All three are legitimate findings. Hiding them only delays the decision.

A failure can look productive for several weeks

The most dangerous parallel run is the one that produces plenty of merged code while quietly consuming the people meant to be freed up. It can look impressive in a demo and still make the engineering organization more expensive.

Consider a common pattern. A startup assigns an AI-assisted pair to bug fixes across a customer-facing application. The pair closes many tickets in the first two weeks. Leadership sees shorter drafting time and approves a broader backlog.

Then the hidden costs arrive. The senior engineer reviews nearly every change because acceptance criteria vary by customer. The operations engineer helps with deployments because the unit has not learned the release process. A security lead appears late in the third week after a change touches permission checks. Several fixes are reverted because tests covered the happy path but not account state transitions.

The team announces that the agents need better prompts. That diagnosis is usually incomplete. The actual problem is that the work class was defined by ticket label, "bug," rather than by operational boundary. A bug in a static screen and a bug in authorization are both bugs only from the customer's perspective. They demand very different coverage.

Fix the setup by reclassifying work:

1. Separate low-risk defects from changes involving identity, money, data migration, or production configuration.
2. Give the new unit full ownership of the low-risk category, including test evidence and release preparation.
3. Require a short design note before the unit attempts an excluded category.
4. Track every escalation by category and reason.
5. Expand scope only after the new unit handles a sustained set of accepted changes without borrowing unplanned specialist time.

This produces a less exciting chart in the first week because the team works on fewer tasks. It produces a believable cost model by the fourth week. That is the chart you want before you change payroll.

Google's DORA research has made a related point about AI adoption: higher adoption does not automatically improve delivery performance, and small batches and testing discipline still matter. Use that as a warning against measuring transition success by generated output alone.

Exit criteria must be decided before the first experiment

End the parallel run when the new path meets stated operating criteria for its chosen scope and the old path no longer supplies hidden labor. Do not let a successful demo or an executive deadline make that decision for you.

Set criteria in four groups:

Avoid arbitrary targets copied from other companies. Your baseline matters more than an industry average. A team with a mature test suite may move faster than a team rebuilding basic release controls. A startup with customer-specific logic may need more product acceptance. The criteria should be strict enough to protect the company and simple enough to judge in a weekly meeting.

When you end the run, remove one old responsibility at a time. Stop mandatory review by the transition lead for the approved work class. Move release preparation to the new unit. Reduce the reserved operations window after the team demonstrates safe releases. Keep the escalation path and measurement dashboard for a while, because early success can hide a process that works only when the original experts hover nearby.

Do not declare victory because two engineers used agents to ship a feature quickly. Declare the transition complete when those engineers can keep shipping the defined work class, handle routine exceptions, show their evidence, stay inside cost limits, and wake the right specialist only when the system genuinely requires one.

If your company cannot build this forecast from its own tickets, time records, and invoices, that gap is worth fixing before you make a staffing decision. A Team & AI Audit can expose the protected capacity and delivery bottlenecks that a generic AI rollout plan will miss.