AI-assisted development: review the workload around the code

When evaluating AI-assisted development, include the work needed to review, test and maintain the output. The following is a proposed team review process for understanding that workload. It does not turn code-review statistics into a diagnosis, an attrition forecast or a measured claim about the effects of AI across the industry.

Choose a workflow and a question

Start with a specific application or service and a defined type of change. Ask a practical question, such as whether reviewing generated test code leaves enough time for checking its assumptions. Record the tools, release process and responsibilities involved before selecting a metric.

DORA's guidance for software leaders treats software delivery performance as a team measure and recommends following the same application over time. Use that scope for the review rather than turning individual commit counts into a ranking of engineers.

Record the work around a change

For a small, agreed sample of changes, document the work from initial implementation through review and release. An optional worksheet can include:

• The task and its acceptance criteria.
• Where an AI tool was used, if the team has a reliable way to record this.
• Time spent checking assumptions, reading dependencies and revising the proposed change.
• Waiting time for review, access, test environments or a decision.
• Defects, follow-up work and unresolved questions found after release.

Define the fields together and record unknowns as unknowns. Keep active review time separate from elapsed time in a queue. Note changes in task scope or staffing that would complicate a comparison. Avoid collecting private prompts or unrelated individual activity when the question can be answered with less information.

Use delivery metrics alongside the conversation

DORA's delivery-metrics guide describes throughput and instability measures, including change lead time and change fail rate. It also warns against relying on a single metric or comparing applications with very different contexts.

Choose measures relevant to the question, then discuss individual examples with the people doing the work. Ask which checks required concentration, what information was missing and whether responsibilities were clear. Treat a longer review as something to understand, not automatic evidence of poor performance or fatigue.

Keep workload review separate from health assessment

WHO describes burn-out in ICD-11 as an occupational phenomenon associated with chronic workplace stress that has not been successfully managed. Its description does not establish a threshold in pull-request edits, application switching or generated lines of code.

Do not label a colleague as burned out from repository activity. Provide a way to raise workload concerns outside a performance dashboard, and direct health concerns to appropriate professional support. The purpose of the proposed review is to discuss and change working arrangements, not assess a person's health from software telemetry.

Test one change and document the limits

Agree on a change the team wants to try: a smaller review batch, clearer acceptance criteria, protected review time or different use of an assistant. Set a review date and record what stayed comparable and what changed.

At that review, examine the observations and the team's experience together. Decide whether to keep, adjust or stop the change. Report the scope actually observed, including missing data and competing explanations. A useful local decision does not need to be presented as a proven industry-wide solution or a guarantee against resignation.