13 Aug 2026 · The software factory practice
Where the engineer's hours go
When agents write the code, the engineer's job becomes judgment — and judgment deserves the same flow state that writing code once had. How the factory visualizes change so a person can decide without reading raw diffs, and what the harness measures about where the hours actually move.
The job changed faster than the desk did
In a software factory, the engineer's job is judgment. Agents carry the volume — the scaffolding, the migrations, the fourth integration probe of the month — and the engineer decides: whether the plan is right, whether the change is safe, whether the codebase is getting easier or harder to work in. We have written about why that judgment cannot be automated. This note is about something more practical: the desk it happens at.
The desk has not kept up. Most review tooling still assumes the reader is another implementer — it presents a change as raw diff, and asks the judge to reconstruct intent from two thousand lines. Engineering culture spent two decades defending flow state for the person writing code: the headphones, the uninterrupted block, the fear of the tap on the shoulder. The person judging code gets none of that protection. Every decision begins with archaeology, and archaeology is where flow goes to die.
Artifacts built for the deciding mind
The factory's answer is to make the artifact carry the burden instead of the reader. Every stage of a task produces something a person can hold whole: the implementation plan as a reviewable document before any code exists, the change with its evidence attached, the one question that actually needs a human answer. The code is visualized — what changed, where it sits in the system, what the tests prove — so the engineer reads meaning, not lines.
The decisions themselves live in the artifact too. When the engineer redirects a plan or accepts a change, that ruling is recorded where it was made, with its reason — so approving is one motion, not a context switch into a ticket system. A person stays in the judging seat for hours this way. That is flow state, relocated to where the job now is.
The hours, measured
Because both stages of every task — the co-planning and the implementation — run through one harness, the harness can report something most engineering organisations only guess at: where each engineer's hours actually go, split across planning, observing and validating. The split is not a surveillance artifact; it is the engagement's honesty meter. It shows whether the factory is spending people on judgment or still spending them on volume.
The shape we run engagements toward is consistent. Implementing time is high in the first weeks and falls steadily as the agents absorb the mechanical share. Validating time holds — a person still walks every change — until agentic end-to-end tests arrive and the evidence starts assembling itself, and then it falls too. Planning is the line that rises, until it is the dominant share of the engineer's week. That crossover is the point of the whole system: the expensive mind moved to the decisions.
Why the client sees this trail
A client buying agent-built software is entitled to one pointed question: what exactly are the humans adding? The factory answers it with the record rather than a slide. The co-planning trail shows every place an engineer redirected an agent's proposal before it was built. The hours split shows the same people moving up the work, not out of it. When the planning line crosses the implementing line, that is human judgment becoming the product — visible, measured, and priced honestly.