Time to first review quadrupled in the activity spike after Flux's customer adopted AI assistants

The added wait before anyone picks up a change is 19.2 hours ^[23]. If a working day is eight hours, a change that used to sit for most of one day now sits for a bit over three ^[29]. Four times the wait does not mean four times the work: Beals says the figure is not a measure of the reviewers' labor cost ^[7].

The number also comes from an activity spike inside the window, not from the three-month average ^[6]. For it to mean anything on another team, the baseline has to be built the same way, and LDS's recommendation is to write down the start point, the end point, the repositories and the exclusions first, then keep them consistent ^[16]. For the baseline, Beals points teams at their own previous 12 weeks and away from industry averages ^[17]. The test he and Julian describe applies to assistants used for software, data pipelines or ML services: follow what happens after code is generated, and establish whether any freed capacity reaches useful work ^[28].

Where the clock stops changes the answer. DORA defines change lead time from a code commit to production deployment, so a team whose measure ends at PR merge is timing a shorter interval ^[15].

Before reading anything into the comparison, Beals lists what else could have moved: staffing, work mix, holidays, automated dependency updates, release cadence, and whether scanner rules or repository coverage changed ^[18]. A static-analysis finding is a signal to investigate; a confirmed production incident is something else ^[9]. On the rise in fixes he leaves the direction of causality open, because the burst of changes may have introduced the problems, or finding the problems may have prompted the burst of repair ^[11]. "It's strong enough to act on. It isn't proof," Beals said ^[13].

Seventy dollars per engineer a month for subscriptions and API usage works out to $16,800 a year across the 20-engineer example ^[25][24]. Julian keeps setup, continuing integration work, review, rework and incident handling separate from that invoice ^[20]. The example leaves those hours unpriced. "Review deserves more attention than it gets," Julian told LDS ^[21].

DORA's current guidance already includes deployment rework rate and change fail rate, and advises interpreting metrics in the context of an application or service ^[14]. Against that, the interview is no evidence that established delivery measures ignore rework ^[26]. A chart showing more fixes after adoption cannot on its own establish that the assistant created the defects, since a migration, a change in release practices or different work assignments would show up the same way ^[27]. What the customer case adds is one observational comparison, useful for deciding what to investigate ^[19]. Settling what the tool caused is beyond it. Flux's account is company-reported, and LDS did not verify it independently ^[3].