Thirty minutes a day, and none of it from letting the agent write Swift

The arithmetic is worth doing before the argument. Thirty minutes per engineer per day is 2.5 hours a week ^[17], and about 6 percent of an eight-hour day ^[18]. Real, and also the same size as the failure mode sitting next to it: the author says that early on, letting agents touch too much at once meant spending the saved time re-reviewing their output ^[13]. A workflow that recovers 6 percent and leaks 6 percent nets zero, which is why the trust boundary matters more than the model choice.

The mechanism holds up better than most claims in this category because of what it selects for. Review is two jobs stacked: mechanical verification (does it build, are edge cases handled, did someone forget to localize a string, is naming consistent with the module) and judgment about whether the abstraction is right and whether it bites in six months ^[6]. The mechanical half is cheap to falsify. A finding that names a file, a line and a concrete failure scenario can be confirmed or dismissed in seconds, and the author drops any finding without one, which he says is the difference between useful output and readability noise ^[9]. The judgment half cannot be checked at all until the bill arrives. So the agents are pointed only where their output can be verified faster than it can be produced.

Generated code inverts that property. The reviewer has to reconstruct an intent no human ever held, in a language where the model's average is worse because there is less Swift in the training data than JavaScript or Python ^[4]. The claim is not that the model cannot write Swift; it is that reading it line by line to a standard you would sign is not obviously faster than writing it ^[4]. The author calls free generation the part that works least well and matters least ^[3], which is the opposite of how these tools are sold.

Under all of it is a proxy problem, not a capability problem. The first workflow he deployed closed tickets fast and made the burndown look good while shipping work that missed what the customer needed, because "ticket closed" was the only signal it had ^[1]. An agent with a prompt but no encoded intent optimizes the nearest measurable proxy and does it confidently ^[14]. He set his metric of record, review-cycle time held against review quality, only after the agents were already running, and calls that his biggest process mistake ^[10]. Architectural calls stayed with humans throughout: module boundaries, offline-first, when to break MVVM, when not to rewrite ^[11]. On a Williams-Sonoma build he stood up a modular SwiftUI codebase so two shopping apps could share it, and says the agents scaled the wiring underneath that decision rather than making it ^[12].

One caution on the number. It is his own measurement on one iOS team, with the review mechanics written up in a separate post ^[2][16]. He opens by noting that most writing about agent workflows comes from people selling the platform and describes the architecture diagram rather than the Tuesday ^[15]. That is the right standard, and it applies to the 30 minutes too.