Output is the cheapest input a builder has now
The fastest way to build a commodity is to let an agent build it well.
The harness is the durable asset: model capability commoditizes, and the evaluation pipeline and organizational context around it do not. I have been building on that premise rather than writing about it. Then I measured the harness itself, and the thesis held at the category level while telling me nothing useful about my own directory tree.
Many builders spend weeks rebuilding capability that platform vendors will most likely ship for free, and they feel productive the entire time. Each task is scoped and each task completes. Nothing in that loop reports that the work is table stakes.
When a builder writes the code themselves, the cost signal is built in. They feel the third afternoon on retry logic and something objects. That objection is not discipline; it is fatigue doing useful work. Remove the typing and the fatigue goes with it, and the objection never fires.
The agent is not at fault, and that is the part worth sitting with. It builds what it is asked to build. Where it fails, the failure is legible and gets fixed on the next pass. Nothing in a well scoped task says this is table stakes, a vendor will hand it over in a quarter. That judgement was always the builder's; it turns out to be the first thing that atrophies once output stops being the bottleneck.
So the check has to become deliberate, because nothing in the workflow will raise it. It is also cheap, because the answer is already sitting in version control.
The differentiator has to be named precisely enough to partition a filesystem by it. Not "the harness." The specific mechanism a competent team working from the same brief would fail to reproduce. If that line cannot be drawn through the directory tree, that is the finding, and the exercise can stop there.
Then the agent that wrote the code gets asked which side of the line its recent commits fell on. Lines count as well as commits.
On the harness I am building, nineteen of the last sixty commits touched mechanical layers and three touched the differentiator. The line counts are more lopsided than the commit counts: roughly ten thousand lines of loop machinery and routing against the ninety one lines that make up the entire pluggability contract. Attention drift is worse by volume than by frequency, which means commit count on its own understates it.
The objection lands immediately: the loop machinery matters. It does, and the partition was never important versus unimportant. A component can be load-bearing and commodity at the same time; almost nobody writes their own database anymore, and that is not a judgement about how much databases matter. The test is reproducibility under vendor roadmap pressure. Retry with backoff, tool dispatch, streaming, context packing, structured output coercion: the platform vendors are converging on all of it, and most have shipped some of it already. The failure taxonomy for a specific domain, recovery policy written out of production incidents, verification gates and the thresholds someone argued about, the special cases that exist only because something broke once: little of that shows up on a vendor roadmap, because it is org-specific by construction.
Both kinds live inside the same ten thousand lines. That is why the number looks damning and why the damning reading is wrong. The finding is not that the machinery was wasted. The finding is that nobody had ever sorted it, so the ratio that matters is unknown rather than bad.
One honest concession about the ninety one lines: the contract is small because it was hard to get right, not because it was easy to build. It is cheap to read and expensive to have arrived at. That is a different scarcity from volume, and it is the one worth defending.
The ratio is worth reading without arguing. The instinct will be to explain why each piece of plumbing was necessary, and some of it was. It measures where attention went while nobody was watching it go.
Output is the cheapest input a builder has now. Aim is the expensive one; it is the part of the work that did not get automated.
