How to measure the review burden created by coding agents

Review timing from first read through final disposition

The timer begins when a reviewer opens the change and ends when the task reaches an accepted, held, or rejected state. The record should separate reading, local setup, reproduction, requested repair, second review, and deployment checks. This makes a five-minute patch with a difficult handback visibly different from a five-minute patch whose test evidence is complete.

Review comments alone are incomplete because they miss work done in a terminal, a staging environment, or a private conversation. A lightweight task receipt can capture the starting commit, commands run, results observed, reviewer minutes, repair rounds, and defects found later. The receipt belongs beside the task so a second reviewer can inspect the same evidence.

Task-class and complexity-band comparisons

The repository owner should compare tasks within the same class and complexity band. Documentation edits, isolated test repairs, feature work, and cross-service migrations have different review shapes. Blending them into one average lets a high volume of trivial work hide the cost of a few risky changes. The pilot should report both the median and the outliers, then preserve the actual task receipts behind the summary.

Google's DORA research reports that AI-assisted development outcomes depend on existing workflows and platforms. A poor test suite, unclear ownership, or slow environment can make review expensive regardless of how quickly an agent writes code, so the pilot records those constraints instead of assigning every delay to the model.

Supported, held, and excluded task classes

The outcome can approve low-burden task classes, hold classes whose reproduction still depends on one person, and exclude work where the cost of verifying the change exceeds the available review capacity. The boundaries should remain versioned because a better test, clearer instruction, or changed agent can alter the result later.

Coding Agent Repository Pilot records review and repair work during a supervised pilot operated by Reality Contact, LLC. The customer decides what level of review is acceptable and remains responsible for every merge and production release.

Where the service stops

Reality Contact, LLC configures and measures the supervised pilot, but does not approve production changes, replace the buyer's security or legal review, manage employees, or allow an agent to merge outside the written controls. The buyer reviews the evidence, decides which task classes the repository controls support, and retains responsibility for accounts, permissions, merges, and deployment. This is technical implementation and review support; it does not replace the customer's security, legal, employment, procurement, or production-change review. We do not promise productivity, defect reduction, autonomous operation, successful deployment, or approval of any task class.