A twelve-minute write step pushes twenty minutes of review onto somebody else's day

Take the post's minutes and turn them into a ratio. Its 2024 change cost four hours of writing and twenty minutes of somebody else's review ^[6], so each minute of writing generated about five seconds of review demand ^[1]. At a twelve-minute write step ^[7], each minute of writing generates about a minute and forty seconds ^[2]. Review demand per minute spent writing goes up twentyfold ^[3]. The post says the minutes are illustrative for a mid-sized change, and that the ratio is what the teams it has talked to describe ^[9].

The queue in its example is a six-person team with review capacity fixed at forty a day, producing four hundred changes, shipping forty, leaving three hundred and sixty waiting ^[10]. Clear that backlog at forty reviews a day and it takes nine working days, and only if nobody writes anything else ^[4]. The post says engineers respond by stopping, by rubber-stamping each other, or by merging their own work at six in the evening when nobody is looking, and that all three appear in the incident log within a month ^[11].

Its own figures do not agree with each other. Four hours to twelve minutes is a twentyfold cut in the write step, while the claimed output gain is five to fifteen times as many changes ^[6]. Either steering costs more than the twelve minutes, or most of an engineer's day was never the write step.

Macroscope, which sponsored Fireship this week, says its review tool auto-approves forty percent of pull requests across its customers, and the post flags that as a vendor claim from a sponsor segment ^[14]. Suppose the rate transfers. Forty human reviews a day would then cover the remaining sixty percent, putting throughput near sixty-seven changes a day against four hundred produced ^[5]. For the forty percent to hold on your repository, your pull requests have to resemble their customers': the same proportion of dependency bumps and generated files, judged against the same risk tolerance.

The post's objection to auto-approval is about accountability. When a change breaks production somebody approved it, and that somebody has a name, a manager and a memory of what they were told; an auto-approval has a log line ^[16]. "You can automate the reading of a diff; you cannot automate the standing-behind of one," it wrote ^[15].

None of this is measured. The post does not publish data behind the tenfold generation figure or the five-to-fifteen range, and attributes both to teams it has talked to ^[1][8][9]. Two numbers a team can pull from its own Git host would settle it for that team: median hours a change waits before a human opens it, and the share of merges approved by someone other than the author. detail.dev, quoted in the post, says agents with the right guardrails execute migrations and language rewrites in complex codebases that would have been a quarter's work two years ago ^[3], and Theo Browne argued this week that an engineer who cannot tell this year's frontier models from last year's has a prompting problem ^[4]. The post's own summary of the result is that the individual is faster while the system ships the same amount of finished software with worse review ^[12].