The Assay Office

§ IThe Rear-View Mirror

Every new medium begins as an imitation of the old one

The first automobiles were carriages with engines, built by carriage-makers, from carriage bodies, on carriage-shop tooling, some still carrying a socket for the buggy whip. Nobody decided a car needed one; it came with the panels. That is how new technology arrives: built from what’s already on hand, and what’s on hand is shaped like the old thing. The first car was a carriage minus the horse. Early cinema was filmed stage plays. Early television was radio with a camera pointed at it. The inherited form never announces itself as a decision. It persists until someone thinks to ask why it’s there. The pattern is reliable enough to have names: the horseless carriage phase, skeuomorphism applied to process rather than surface.

The automated software factory (orchestrated coding agents cast as product managers, developers, QA engineers, and scrum masters, holding standups and passing tickets) is this phase in progress. It automates the ceremony of human software development without asking which parts of that ceremony existed only because the participants were human. The interesting question is not how to run the old process faster. It is what process falls out when you derive one from scratch, under the new constraints.

§ IIWhat the Old Process Was For

A development process is a control system shaped by its constraints

The traditional software development lifecycle is not arbitrary. It is the institutional answer to roughly five facts about humans:

1. Writing code is expensive, so we maintain and patch rather than rewrite.
2. Human working memory is tiny, so we modularize for comprehension.
3. Human-to-human context transfer is lossy and slow, so we have roles, tickets, meetings, and documents: batching and serialization mechanisms.
4. Verification is expensive, so we substitute process for proof: review gates, QA sign-off, staged rollouts.
5. Attention is serial, so we have sprints, work-in-progress limits, and planning to schedule a scarce resource.

Agents invert nearly every one of these, and introduce constraints of their own. The new constraints are not all of the same kind, though. Some are durable, indifferent to any capability curve: Goodhart’s law (a measure that becomes a target stops measuring), the independence that trust requires, the irreversibility of external effects. Others are contingent engineering facts of the mid-2020s, like bounded context windows and the absence of tacit memory, and anything derived from them carries an expiration date. The derivation below tries to lean on the first kind and to flag where it is leaning on the second.

§ IIIThe Inversions

Code becomes a build artifact; the spec and the oracle become the source

When generation is nearly free, code stops being the asset. The durable artifacts move up a level, and there are two of them, not one. The distinction matters. The spec is the human statement of intent: fuzzy, contested, full of taste. The oracle is its mechanical projection, the subset of intent that has been made machine-checkable: tests, properties, simulators, formal contracts. The projection is lossy by construction. The oracle cannot capture taste and is not supposed to; it captures the floor below which no candidate implementation may fall, and the gap between spec and oracle is precisely where human judgment stays load-bearing. This is test-driven development’s rhythm with an inverted motivation: oracle-first not as discipline but as economics, because the oracle is the only thing that makes infinite cheap generation usable.

Verification becomes the bottleneck, and stays one. The obvious objection: the same models that make generation cheap can write tests too, so why doesn’t verification get cheap and the whole asymmetry collapse? Because the scarcity was never labor. Agents can and should draft oracles. What no generator can manufacture is independence: a warrant produced by the same process that produced the artifact is not a warrant. Trust has to be anchored outside the thing being trusted, in execution against reality, in adversarial procedure, in an accountable party. Generation is a capability; verification is partly an institution, and institutions get cheap far more slowly than capabilities. As for the regress (who verifies the oracle?), it terminates where it always has: not in a final verifier but in reality and liability. Production falsifies oracles; incidents amend them; and someone identifiable pays when the warrant was wrong. This does not collapse into testing-in-production: every change is still warranted against the current standard before it ships. What production improves is the standard itself, the way an underwriter prices against today’s actuarial tables and lets claims experience amend the tables, without anyone concluding that insurance is just paying out and seeing what happens. Oracles also make a smaller target than implementations: a property is shorter than the mechanisms that satisfy it, it is validated against the world over time rather than against opinion, and it accumulates monotonically.

So the whole system is designed to make verification mechanical. Every hour spent making correctness checkable (property tests, deterministic simulation, fault injection, executable invariants) multiplies the value of cheap generation. Human review of diffs cannot scale to machine-speed output and should not try; review-by-execution replaces review-by-reading. That swap has to answer an old objection. Edsger Dijkstra, arguing half a century ago that only mathematical proof could establish a program’s correctness, put the limit of testing in a sentence that still stings: “Testing shows the presence, not the absence of bugs.” He was right about the limit. Execution-based verification is a spectrum. It runs from example tests, through property-based testing and deterministic simulation with fault injection, up to formal contracts. The further along that spectrum a system sits, the stronger the claim it can support. But the output is never certainty. It is a bounded, stated claim, which is what a warrant is. And none of this is free in the other currency: verification at machine speed is bought with compute, and the cost center of software moves from salaries to the proving-ground bill. That is not an objection to the thesis; it is the thesis. The money pools where the scarcity is.

The unit of work changes from the ticket to the change-with-evidence: a self-contained bundle of specification delta, implementation, and proof that the implementation satisfies the oracle. Sprints batched work around human context-switching costs; an agent’s cost structure is context-loading, and its cadence is limited by only two latencies, verification time and human decision time. If this sounds like CI/CD promoted from gatekeeper to proving ground, that is exactly the claim. The pipeline is not the novelty; the inversion is what flows through it. The verification harness (the oracles and the machinery that runs them against candidate code, not the agent scaffolding that has lately borrowed the word) used to gate what humans wrote. Now it is the primary production loop, and code is the fluid.

Humans relocate to the boundaries: intent and irreversibility. What genuinely cannot be delegated is deciding what to want (product judgment, taste, the adjudication of trade-offs) and owning actions whose effects cannot be rolled back: deployments that touch money, users’ data, legal exposure. Everything reversible can run at machine speed with post-hoc audit. But reversibility is a property of effects, not of code, and it does not come free, because executing code is exactly how state gets mutated. A regenerated module deployed at machine speed can corrupt data before any audit catches it, unless the effect boundary has been engineered so that it can’t: sandboxes, shadow deployments, staged writes, append-only stores, snapshots. The machine-speed lane has to be built, and building it is part of the harness investment, not an afterthought. Where it hasn’t been built, there is no machine-speed lane, whatever the deploy tooling says. And one conservatism survives intact: you can regenerate code, but you cannot regenerate customer data. State and logic are entangled in real systems; a change in one usually drags a migration in the other. That is why the stateful core of a system moves cautiously even when everything around it is disposable. (“Humans relocate to the boundaries” names a system design, not a painless labor transition. What happens to the people whose work was the middle is a real question this essay does not answer.)

Architecture, too, reorganizes around the new producer. Modules are sized to be verifiable in isolation, with contracts strong enough that any module can be thrown away and regrown without touching its neighbors: blast radius of regeneration as a design criterion. Some human-era virtues weaken: the rule against duplicated code (“don’t repeat yourself”) was partly about human maintenance cost, and duplication is cheaper when regeneration is free. Interface rigor, meanwhile, matters more than ever. And because every agent session is day one (no tacit knowledge, no hallway conversations, no veteran who remembers why), the repository must carry all context. Decision records, invariants, and glossaries stop being documentation-for-later and become operational inputs to every task. A codebase that is not self-describing actively degrades under agent maintenance. (This paragraph leans hardest on the contingent constraints flagged above, context limits and absent memory. If those lift, the sizing rules relax; the demand for legible, versioned intent does not.)

Finally, production feeds back mechanically. An incident is not a postmortem document; it is a new oracle: a failing property added to the harness, after which the system regenerates until it passes. The observe–specify–verify loop closes without a ceremony in the middle.

§ IVRoles Without Identities

The functional decomposition survives; the organizational one does not

Does an agent-native process still need an orchestrator, implementors, and verifiers? Yes. But conflating those functions with old-world roles is exactly where the rear-view mirror sneaks back in.

Each function is forced by a constraint that has nothing to do with humans. The verifier must be separate from the implementor because of independence requirements: an agent that wrote the code is contaminated by its own interpretation of the specification (the reason authors cannot proofread their own writing), plus Goodhart’s law: anything the generator knows about the check, it will optimize against rather than satisfy. The split is not a job assignment; it is an information-hygiene constraint. Nor does model progress dissolve it. A generator smart enough to notice ambiguity in the spec should say so; collaboration on the spec is welcome, and the best generators will increasingly do the verifier’s thinking unprompted. But the verifier’s independence was never a patch for generator stupidity. It exists because the warrant is for third parties: “I checked my own work and it’s fine” does not become an audit when the speaker gets smarter. Trust is a property of procedure, not of capability.

The orchestrator is forced by bounded context: something must hold the whole-goal state, the decomposition, and the acceptance criteria, because no worker’s context can hold everything and still do the work. That is not management. It is a program counter plus custody of the specification.

The difference from human roles is identity. In a human organization, a role is a persistent person who accumulates private context, has incentives, needs communication protocols, and holds exactly one role because attention is serial. In an agent system, a role is a position in a dataflow graph: a prompt, a context payload, and a tool budget, instantiated per task and discarded. Nothing is “the QA agent.” There are verification positions, occupied by five throwaway instances with adversarial framings (possibly across several model families) per change. The role is fungible and N-wide; the worker’s identity is gone, and with it all the coordination machinery identities require. Identity does not vanish from the system; it migrates. It leaves the workers and reattaches to the institution that signs the warrant, which is where this essay is headed.

Model diversity helps decorrelate errors, and mixing model families is genuinely effective: different labs, different training mixes, measurably different failure modes. But two correlations survive it. All frontier models share priors about what plausible code looks like, trained as they are on overlapping corpora. And the framing correlates harder than the model: two different models handed the same misleading specification fail the same way, because the error was upstream of both. Adversarial framing (a verifier prompted to refute, not to confirm) and verification by execution buy more decorrelation than swapping vendors, because they break the shared-interpretation failure mode that model diversity cannot touch.

The orchestrator is where recapitulation is strongest today. The skeuomorphic version is a manager-agent that delegates by natural-language negotiation and checks in on its reports: a language model cosplaying middle management. The native version pushes as much orchestration as possible into deterministic code. The fan-out, the pipeline, the retries, and the gating thresholds are control flow, with model judgment invoked only at genuine decision points. Anywhere orchestration logic is expressible as a program, a program is strictly better: reproducible, auditable, immune to drift and sycophancy. The tell is not having an orchestrator; it is making the orchestrator a personality instead of a program.

The test for any proposed role: does it exist because of an information constraint (independence, bounded context, irreversibility gating), or because a human org chart had a box with that name? Orchestrator, implementor, and verifier pass. Scrum-master-agent does not. Stay suspicious of any agent whose job description is a noun rather than a position in the verification graph.

§ VThe Factory Was Never There

A second-order skeuomorphism

The factory metaphor deserves the same analysis, because it is not a neutral container; it smuggles in a constraint set of its own. The factory is the institutional answer to three conditions: production capital is expensive, so you amortize it through throughput; design cost must be spread over many identical units, so you standardize; and production is separated from use, so you make the artifact, ship it, and forget it.

Software violated this metaphor before agents arrived. A software engineer named Jack Reeves made the point in 1992: in software, manufacturing is compilation, which is essentially free, so all software work is design. A software factory was always a category error, a factory with no factory floor. The heavyweight lifecycle apparatus was our attempt to make design activity legible to factory-era management anyway. The agentic software factory is therefore a second-order skeuomorphism: an imitation of a metaphor that was already wrong.

Re-derive from the agent-era constraints and the factory dissolves along each of its three axes. Standardization loses one of its rationales, not all of them. Amortized design cost stops mattering when materializing software from a specification costs pennies. But that was never standardization’s only value: network effects, interoperability, shared security patching, and pooled operational knowledge still matter enormously. When a critical flaw surfaced in Log4j, a logging library embedded in half the world’s software, one disclosure and one patch protected millions of systems at once; that is an asset a million bespoke snowflakes forfeit. So the honest prediction is not bespoke-everything. It is bespoke at the edges, standardized at the interfaces: the long tail of internal, glue, and workflow software (most software by count) goes custom, while protocols, substrates, and audited shared components standardize harder than before, because a world of custom edges needs stronger contracts between them.

The design-time/run-time boundary erodes. If the generator is cheap enough to keep attached to the artifact, software stops being manufactured and starts being maintained metabolically: continuously re-derived against its invariants, the way an organism replaces its cells while the organism persists. A production incident is not a defect escaping the plant; it is the system meeting a condition its oracle did not cover, adding the oracle, and regrowing the affected tissue.

And production stops being an institution, but the firm does not evaporate. Factories are firms for the reason the economist Ronald Coase identified in 1937: not coordination in the loose sense, but the friction of contracting (negotiating, monitoring, enforcing). Agent coordination removes much of that friction. It does not remove the need for a counterparty who can sign and be sued; agents cannot legally bind themselves. So production coordination compresses into a recipe anyone can run, rented by the minute (nobody will have a software factory for the same reason nobody has a compilation department), while the firm contracts toward its irreducible Coasean core: the entity that can bear liability. Hold that thought.

The cleanest tell for factory-era thinking is what gets measured. Throughput of code (units produced, velocity, agent-hours utilized) measures the thing that is now free. The native metrics are verification latency, oracle coverage, and the cost of a warranted claim. Anyone bragging about how much code their factory produces is optimizing the buggy-whip socket.

§ VIWhat Stays Scarce

Institutions organize around scarcity

If the factory evaporates, what institution survives? Follow what remains scarce. Custody of intent and oracles: the accumulated, versioned, hard-won definition of what correct means for a domain. This is the durable capital, and notably the one place the factory metaphor is half right: a serious verification harness is expensive machinery, amortized across everything it checks. The capital equipment of the new era is the proving ground, not the assembly line. It is also the crown jewels and the highest-value attack surface: a poisoned oracle turns the generator into a machine that ships perfectly verified malice at machine speed. Securing the harness (its provenance, its integrity, who may amend it and how) is not an implementation detail. It is the central security problem of the whole arrangement. Custody of state: code can be regenerated; customer data cannot. Whoever holds the state holds the continuity. Custody of liability: someone must warrant the software, stand behind it when it moves money, touches patients, signs contracts. Here is the firm’s irreducible core again, now with a job description. Generation can be commoditized. Accountability cannot, because accountability is precisely the thing that must attach to a persistent identity. This is also where regulated domains will move last, and should: where the process is legally the product (aviation, medicine, finance), continuously regenerated code is inadmissible until warrant regimes are renegotiated, and that renegotiation is institutional work, not engineering work.

Put those together and the surviving institution is not a mint. It is an assay office. It does not make the coins; anyone can make coins when minting is free. It certifies them, keeps the reference standards, and stakes its name on the verdict. The Trial of the Pyx has run for over seven centuries: coins drawn at random from production, sealed in a box, and tested against reference plates by an independent jury. Take the analogy for exactly what the Trial is, and no more. It is not an exhaustive proof; it is a statistical sampling audit of a low-dimensional property, backed by independence and real consequences. And the disanalogy with software runs deeper than dimension. Gold purity is continuous, so a random sample licenses an inference about the whole batch; software fails discontinuously, flawless for ten million inputs and catastrophic on the next. That is why the sampling in a software assay cannot be random draws over behavior. It is adversarial exploration of the state space (fault injection, deterministic simulation hunting rare interleavings, verifiers prompted to refute), sampling weighted toward where the cliffs are. What survives the disanalogy is the institutional form. Software warrants will look like the Pyx rather than like mathematics: sampled, scoped to declared invariants, probabilistic, and priced. Closer to underwriting than to proof. An assay office that claims certainty is a fraud. One that states its confidence, names its scope, and stakes something on the verdict is an institution. The mint produces; the assay warrants. When production is free, the value pools entirely at the warrant.

§ VIIKeeping, Not Making

So what are we doing? Growing organisms?

Half right, and the wrong half is instructive. Metaphors are how humans compress a constraint set for coordination, and every metaphor imports its source domain’s constraints, which is the very failure mode this essay diagnoses. The disciplined move is to test candidates against the actual constraint structure: cheap regeneration, legible and versioned intent, adversarial verification, accumulated oracles, humans at the intent boundary, warranted claims at irreversible edges.

Organism nails the artifact’s lifecycle: homeostasis, regeneration against invariants, the immune system as a genuinely good model of adversarial verification, with its diverse detectors and memory of past attacks. But it fails the two constraints that matter most. Organisms have no legible intent: the genome is the least readable specification imaginable. And organisms carry no warranty; nothing stands behind an organism’s behavior, which is disqualifying for software that moves money. Gardening fixes the human’s position (the gardener owns intent while growth is delegated; Alan Kay, the computing pioneer, was urging us to grow software rather than build it decades ago), but gardens inherit the organism’s illegibility and add no accountability.

The candidate people miss, perhaps because it is not picturesque, is a body of law. The objection writes itself: law is slow, ruinously expensive, ambiguous, and captured by incumbents, surely the last thing software should aspire to. But those are the performance characteristics of law’s human implementation, in which every adjudication is rationed by scarce expert attention. The metaphor is not offered for law’s throughput. It is offered for its trust architecture, which is separable from its speed: intent that is explicit and versioned (statutes, amendments, a documented history of why each rule exists); oracles that accumulate monotonically (every hard case becomes precedent, exactly as every incident should become a permanent test); institutionalized adversarial verification (generate-versus-refute before an independent judge); and liability carried natively (rulings are warranted claims that identifiable institutions stand behind). That architecture, run at machine speed instead of through a human priesthood, is the interesting object. The rejoinder writes itself too: this has been tried, in the blockchain era’s “code is law” smart contracts, and it failed conspicuously. But smart contracts did not run law at machine speed; they deleted the law’s load-bearing part. They mechanized enforcement while abolishing adjudication: no judge, no equity, no adversarial procedure, no institution standing behind the outcome, just literal execution of the statute-as-bytecode, bugs included. That failure confirms the design constraint rather than refuting it. The trust architecture is the whole assembly (versioned intent and adversarial adjudication and a warrantor), and automating one component while discarding the others is the buggy-whip mistake run in reverse. One pathology does carry over, though, and deserves the anxiety: capture. Oracles, like statutes, can be written by the incumbents they are supposed to constrain. Who may amend the oracle is a governance question, not a technical one, and pretending the metaphor doesn’t import it would be cheating. Jurisprudence remains what a centuries-old, continuously tested, intent-legible living system actually looks like in human experience: not manufactured, not an organism, but a third thing, a maintained body of binding commitments. Double-entry bookkeeping belongs to the same family: a living record whose invariant is checked continuously, audited adversarially, and warranted by someone whose name is on the attestation.

So the verb changes before the noun does. Factory-era software was something you make. Agent-era software is something you keep: the way you keep books, keep a covenant, keep the law. The deliverable stops being an artifact and becomes a standing promise: this system satisfies these invariants, continuously, and someone warrants that. Production is just the metabolic process by which the promise stays kept.

Forced to a single image: a cultivated organism under audit. Organism for the artifact, cultivation for the human role, audit for the institutional shell, each metaphor deployed locally where its constraints match, none allowed to govern the whole. Because the whole is genuinely new, and the mature move, eventually, is to let it be new. The horseless-carriage era ended when people just said car.

One prediction, offered as a rhyme rather than a law: eras name their software practice after whatever institution manages the scarce thing. When production was scarce, we said factory, shipping, engineering. When trust is the scarce thing, the vocabulary will come from the professions that always managed scarce trust: audit, actuarial work, jurisprudence, assay. Less we shipped v2.4; more the system is in good standing. Which suggests the people best prepared for agent-native software may not be the ones who studied manufacturing optimization at all. They are the ones who understand how to keep a promise legible, verified, and warranted for longer than any individual keeper stays around.