A factory that never sleeps should still know when not to run
Fiodar Ryzhykau argues the engineer's new job is building a round-the-clock software factory, then warns that continuous availability is not continuous useful work, and proposes measuring accepted outcomes per unit of human attention.
Source: The New Engineering Job: Building a Software Factory That Never Sleeps
Fiodar Ryzhykau describes three stages: the engineer writes the code, the engineer drives agents session by session, and the engineer builds a persistent factory that keeps working after the laptop closes. In the third stage the next morning starts "from where their software factory reached," and the job becomes judging outcomes and improving the system for the next cycle.
He lists what that factory needs beyond coding agents: layered context, an execution engine that knows which tasks need a human, independent verification, and a feedback loop that turns every rejected design or corrected test into a better instruction, check, or eval. A factory that generates code fast but can't verify it, he writes, "is simply manufacturing uncertainty at scale." He also warns that several agents agreeing with each other proves little when their failures are correlated.
The useful turn is his section on not running all the time. An agent that spends the night opening speculative pull requests and failing tests "may actually decrease engineering productivity." His proposed yardstick is accepted, reliable outcomes divided by total human attention, with review, corrections, escalations, and rework counted in the denominator.
Why it matters for code review
This is the case for always-on agent pipelines with its own limit built in. Overnight momentum only compounds if every run lands as work a reviewer can accept quickly. Counting PRs rewards the opposite. Putting review and rework time in the denominator makes the morning review queue part of the factory's cost rather than something left outside it.