Software as Electricity

This paper relies on a small vocabulary that recurs throughout the series. Three terms are load-bearing here and are defined briefly below; their fuller treatment lives in the companion papers.

The attestation layer is the institutional structure that converts machine-produced software into software a human or institution is willing to stake a signature on. It comprises the specification corpus that anchors what the system is supposed to do, the deterministic verification toolchain that checks produced code against that corpus, and the licensed human roles whose signatures carry liability when verification is not enough. The companion paper The Attestation Layer: Spec-Mediated Verification for the Age of Agent-Produced Software develops the transitional shape of this layer, and The Attestation Layer: Architecture Specification gives its full architectural definition. In this paper, the attestation layer is treated as the surviving substrate that remains after the rest of the software industry dissolves.

Wanabai is the name used in the white paper Wanabai: Software as Electricity for the steady-state economy in which software is delivered as a metered utility through protocol sockets, produced and verified by an autonomous closed loop, and operated by general agents on behalf of humans who never see a line of code. The Wanabai endpoint is where this paper points: the architecture sections describe its production layer, the role sections describe its surviving human professions, and the strategic sections describe how to position for it.

The closed loop is the production architecture this paper develops in full. It is the steady-state replacement for the human-mediated build-test-review-release pipeline of the 2020s: a single continuously-running process that fuses specification synthesis, implementation, deterministic verification, sandbox deployment, adversarial outcome testing, and auto-promotion to production into one cycle with no human gate on the main path. The Closed Loop section below specifies its stages; the Exception-Handler Model section specifies the narrow places where humans re-enter.

The remaining vocabulary of the series — the corpus, the harness, the attestor, constitutional auditor, spec authors, configuration attestors, quality engineers, HITL/HOTL (human-in-the-loop / human-out-of-the-loop), refined-token majors, general-agent routing layer, exception-handler model, legacy archaeologist, production-trust gap, Naur theory, domain-expert-as-author — is used as introduced in the companion papers and elaborated in context where it first appears below.

The attestation layer — the trust infrastructure that becomes critical when software production cost approaches zero — is typically described with a human reviewer at the specification stage: Natural Language → LLM Inference → Specification Artifact [human reviews this] → Deterministic Verification → Pass/Fail. The human reads the small, inspectable spec; the deterministic toolchain below verifies that produced code satisfies the spec. The specification is the non-stochastic anchor that breaks the regress of LLM-judging-LLM and externalizes the Naur-sense theory of the system. The historical thesis, the production-trust gap, and the proposal that the specification becomes the durable artifact while code becomes disposable output — all of this is correct, and this paper builds on it.

But that description carries two assumptions that do not defend themselves once followed to their endpoint, and both break under pressure.

Assumption 1: The human review of the spec is a stable chokepoint. The chokepoint assumes the human can keep up with the spec production rate. As production cost approaches zero, spec production rate approaches infinity. Any gated human chokepoint becomes the new bottleneck, and the economics of the entire pipeline collapse back to human throughput — the exact problem the attestation layer was supposed to solve. A chokepoint that cannot scale with the rest of the pipeline is a transitional architecture, not a steady-state one.

Assumption 2: Build and verify are separate stages. A pipeline that specifies, implements, and verifies as distinct sequential steps inherits its separation from human workflow — humans build, then test, then review, in phases because context switching is expensive for humans. When every step runs on commodity compute with no human between them, the sequential separation is organizational, not technical. In the limit, build and verify merge into a single continuously-running process where every spec change triggers immediate re-derivation, immediate re-verification, immediate re-deployment to ephemeral sandboxes, immediate outcome testing, and immediate auto-promotion to production if the outcome matches intent. There is no “version.” There is no “release.” There is only the loop.

This paper relaxes both assumptions and follows the consequences. The consequences are more radical than the transitional architecture anticipates, and they reshape not just the architecture of software production but the structure of the software industry itself.

The steady-state architecture is a single closed loop that runs continuously across the entire lifetime of a system. It has no beginning and no end; it has a current state and a set of pending changes, and it metabolizes the changes into new states as fast as they arrive.

The Loop

A change request enters the loop as natural language or a protocol-delivered payload from outside the system. From there, the loop moves through a fixed sequence of stages, each carried out by a specific class of actor.

• Intake receives the external change request. The actor is whatever produced it — another agent, a domain expert, a regulatory feed.

• Specification Synthesis is an LLM step. A specifier agent emits a formal spec delta — new properties, contracts, invariants, or TLA+ fragments — that captures the intent of the request in machine-checkable form.

• Consistency Check is a deterministic step. The spec delta is checked against the accumulated spec corpus for contradictions with existing invariants.

• Canonical Resolution is a deterministic step. If contradictions are detected, canonical rules — priority hierarchies, conflict resolution heuristics — attempt to resolve them automatically.

• Exception Escalation is a human step, and a rare one. If canonical rules cannot resolve a contradiction, the change is routed to a human exception handler with full context.

• Implementation Synthesis is an LLM step. A coder agent produces or modifies code to satisfy the updated spec corpus.

• Deterministic Verification is a deterministic step. Code is checked against the spec corpus using the full verification toolchain — property tests, contracts, TLA+, Dafny where applicable.

• Sandbox Deployment is a deterministic step. The updated system is deployed to an ephemeral production-equivalent environment.

• Adversarial Outcome Testing is an LLM step. Adversarial agents exercise the system against declared intent, not just declared spec, and compare observed outcomes to expected outcomes.

• Outcome Exception Escalation is a human step, and a rare one. If observed outcome satisfies the spec but diverges from declared intent, the change is routed to a human exception handler.

• Auto-Promotion is a deterministic step. If all checks pass, the change is promoted to production with no human gate.

• Production Observation is a continuous deterministic-plus-adversarial step. Trace verification runs against the spec corpus, and drift detection runs against intent baselines.

The loop runs continuously. Changes arrive at whatever rate they arrive, and the loop metabolizes them at whatever rate the compute and model inference allow. In the steady state, latency from intake to production is minutes, not days. There are no releases. There is no staging freeze. There is no on-call rotation for deployments because deployments are not events.

The deepest consequence of the closed loop is that software stops being a product and becomes a utility, in the literal economic sense of the word. This is not a metaphor reaching for vividness; it is a structural prediction about what software is after the transition completes.

The Utility Pattern

Before electrification, every factory owned its own power source — a steam engine, later one large electric motor driving a central shaft. Power was a capital asset that belonged to the factory and was operated by factory employees. After electrification, factories stopped owning their power and started consuming it as a utility delivered through a standardized socket. The power plant was somewhere else. The wires were owned by someone else. The generation, transmission, and billing were someone else’s problem. The factory consumed kilowatt-hours through an interface and paid a meter reading.

Software in 2032 follows the same arc. Today, every company either owns its software (internal development) or rents it with operational responsibility (SaaS). Either way, there is a product called “the software” that has a name, a version, a UI, an operator, a support team, and a relationship to the customer that mediates through all of these. By 2032, the company consumes capabilities through a protocol socket and pays a meter reading. The capability is produced, verified, maintained, and evolved by an autonomous loop somewhere else. The company does not know which model wrote which line of code. It does not care. It cares whether the meter reading is accurate and whether the capability does what was asked.

What Becomes True Under the Utility Model

• No UI for most software. The primary consumer of the capability is another agent, not a human. Agents consume protocol endpoints, not interfaces. UIs persist only where the human is the direct operator — creative tools, embodied interfaces, regulated audit surfaces, human-to-human communication — and this is a small fraction of today’s software by count.

• No product identity. There is no “the software.” There are capabilities, addressed by protocol names, with no branding in the consumer-facing sense. Brand lives at the attestation layer (who signs for the capability) and at the agent layer (which agent routes to which capability), not at the software itself.

• No releases, no versions. The loop runs continuously. What exists is the current state of the spec corpus and whatever implementation currently satisfies it. Version history exists as a spec diff, not as a software release artifact.

• Consumption-based billing as the default. Because every capability is metered through protocol calls, every capability is naturally consumption-billed. The subscription SaaS model, which existed to amortize the cost of a rented product with a UI, becomes economically unnatural.

• The “software company” as a distinct category dissolves. There is no stable business unit whose only output is software, because software is no longer a product you sell; it is a utility you produce, and producing a utility profitably requires being deeply embedded in the industry that consumes it. The companies that produce the accounting capability are accounting firms (or capital-backed extensions of them), not software vendors selling to accounting firms.

If software has no UI and is consumed through a protocol, then something has to translate human intent into protocol calls and translate protocol results back into human-legible answers. That something is the general agent — the 2032 descendant of Claude, ChatGPT, Gemini, and whatever replaces them.

The Three-Layer Stack

Humans interact with general agents. General agents operate software via protocol (MCP or successor). Software executes deterministically and returns results. The agent reasons over the results and synthesizes an answer for the human. Three layers; only the top is human-facing.

This is not a prediction of the far future. The architecture is already emerging in 2026 with MCP, with Claude Code, with ChatGPT’s tool use, with Gemini’s function calling. The load-bearing claim is about the endpoint: in the steady state, this is the only interface most software has. There is no alternative path for a human to reach most capabilities. The general agent is the entire distribution channel.

The New Oligopoly

The container-ship analogy for interface standardization applies here with a sharpening: the protocol standardization (MCP and successors) is a commodity, because the protocol is open and anyone can implement it. The scarce, valuable layer is the routing decision — when a user asks a general agent to do something, which capability does the agent call? That decision is worth everything.

Whoever builds the dominant general agents owns the routing layer. The routing layer is more concentrated than search, more concentrated than app stores, more concentrated than any prior distribution channel in software history, because there are vastly fewer general agents than there were search engines or app stores, and switching costs between general agents are high (context, memory, trust, tool configuration). The 2032 general agent market is probably three to five players globally, and the routing power they collectively hold is probably the single most valuable position in the software economy.

This is the one part of the stack that does not get automated away. Every other layer — production, verification, even most exception handling — continues to automate over time. The general agent itself, and the companies that build it, sit at the top of the stack and extract rent from everything below.

The transitional architecture places the human at a chokepoint: every spec passes through human review before implementation. The closed-loop architecture replaces the chokepoint with an exception handler: the loop runs autonomously, and humans are invoked only when the automated systems detect a situation they cannot resolve. This is a fundamentally different economic shape, and it produces fundamentally different jobs.

The Three Exception Classes

All human work in the steady state falls into one of three exception classes. Each class defines a distinct role, a distinct skill set, and a distinct compensation structure.

Spec contradiction exceptions. A new spec delta contradicts the accumulated invariants of the existing spec corpus, and canonical resolution rules cannot determine which intent takes precedence. These are the brownfield consistency failures developed in the Brownfield Problem section. The role that handles them is a domain expert with formal-methods literacy who can read both the new intent and the accumulated corpus and decide which should win. This job is closest in spirit to a senior architect today, but the skill mix is different: less coding, more specification reading, more domain judgment, more ability to navigate large formal corpora.

Outcome mismatch exceptions. The deployed system satisfies the formal spec but the observed outcome diverges from the declared intent — the software does what was specified but not what was wanted. This is the validation problem in Boehm’s sense — “are we building the right product?” — surfaced here as an observability signal rather than a pre-deployment gate. The role that handles it is the attestor: a professionally licensed role whose signature certifies that the observed behavior matches (or fails to match) the intended outcome, and who stakes personal reputation and legal liability on that signature. This is the highest-compensated role in the steady-state economy. It is a regulated profession by 2030. The attestor’s signature is what distinguishes this exception handling from mere human oversight — the signature is load-bearing in court, in insurance, and in the customer’s decision to rely on the software at all.

Novel situation exceptions. The system encounters a state space it has no canonical rule for and no precedent in the spec corpus — a genuinely new situation that requires human judgment to resolve. These exceptions are rare in stable domains and common in fast-changing ones (emerging regulation, novel product categories, unprecedented market conditions). The role that handles them is a domain strategist who does not need formal-methods literacy but does need deep domain knowledge and authority to establish new canonical rules on behalf of the organization.

What Exception-Handling Does Not Include

The exception-handler model is deliberately narrow. It does not include: writing code (automated), designing specs (automated, with exception escalation only when contradictions arise), testing code (automated), deploying code (automated), monitoring code (automated), operating code in production (general agents), or supporting end users (general agents). The human work that survives in the steady state is tightly bounded to judgment calls that the automated systems cannot make — calls that require either professional liability, deep domain expertise, or the authority to establish new canonical rules.

This is a much smaller human footprint than a transitional spec-review architecture requires. A spec reviewer is a full-time job that scales with the production rate. An exception handler is an on-call rotation that scales with the exception rate, which is several orders of magnitude smaller. The total human labor absorbed by the steady-state software economy is probably 10-20% of the 2026 level, distributed very differently across skills and compensation bands.

The hardest technical problem in the closed-loop architecture — the one that determines whether the loop actually closes or thrashes endlessly on contradictions — is brownfield consistency. It deserves its own section because every other part of the argument assumes it is solvable, and it is not obvious that it is.

The Problem Stated

A mature system has a spec corpus built up over years: thousands of properties, hundreds of contracts, dozens of TLA+ models, a constantly accumulating body of invariants that encode the system’s theory in the Naur sense. A new change request arrives and is translated into a spec delta. The delta may be locally consistent — it makes sense in isolation — while being globally inconsistent with the existing corpus in ways that are not obvious from the delta alone. The contradiction may be direct (spec N+1 asserts X, spec 42 asserts ¬X) or it may be implied (spec N+1 combined with the implications of specs 17, 203, and 891 creates an unsatisfiable constraint set).

Detecting these contradictions is a hard problem. SMT solvers handle small cases but do not scale to corpora with thousands of interacting constraints. Incremental proof techniques help but do not close the gap. The theoretical worst case is undecidable.

The Pragmatic Approach

The pragmatic architecture does not attempt to solve the general case. It does the following: (a) maintains the spec corpus in a form amenable to SMT checking of local neighborhoods around the delta; (b) runs the delta through a priority hierarchy of canonical rules that resolve common contradiction classes automatically (for example, “newer business intent beats older technical convenience, but newer business intent does not beat established regulatory constraints”); (c) routes unresolved contradictions to the exception handler with full context, including the specific invariants involved, the resolution attempts made, and the historical provenance of the conflicting specs. The exception handler is a domain expert, and the exception itself is a decision the domain expert is qualified to make.

The Legacy Archaeologist

The brownfield problem creates a large, one-time job category that absorbs a significant fraction of senior developers between roughly 2028 and 2033: the legacy archaeologist. This is the person who takes an existing codebase — built by humans, poorly specified, partially documented, full of implicit invariants nobody ever wrote down — and produces the spec corpus that lets the closed loop run on it. This is a deeply technical job that requires reading code fluently, reconstructing the theory the original developers held in their heads (and have mostly left the company with), and translating that theory into formal invariants that the automated loop can enforce going forward. It is archaeology in the literal sense: reconstructing lost context from fragmentary evidence.

Legacy archaeologists are the bridge workforce of the transition. The job exists because most software in 2026 is brownfield and will be for a decade, and every brownfield system needs its theory extracted before it can be fed to a closed loop. The job evaporates in the mid-2030s because by then either the system has been successfully migrated to the closed-loop architecture or it has been decommissioned. For a mid-career developer with deep knowledge of a specific legacy system, this is the single highest-leverage career bet in the transition: the supply of people who can do this work is small, the demand is enormous, and the window is open for about five years.

The steady-state architecture developed in this paper is not a near-term target. It lands on the leading edge somewhere inside the Chokepoint Dissolution and Utility Emergence phases, roughly 2028-2035, and consolidates through Industry Dissolution into the late 2030s. The full 7-phase timeline — with economic context for each phase, leading-versus-trailing-edge dynamics, and the HITL-to-HOTL framing that ties the phases together — is developed in Out of the Loop’s 15-Year Thought Experiment section. What matters for the rest of this paper is only the shape: the transitional spec-review architecture occupies the earlier phases, this paper’s closed-loop architecture occupies the later ones, and the identity “software developer” dissolves several years before the industry that employed them does.

Three populations face different structural positions in the transition, and the closed-loop architecture developed above has distinct consequences for each. This section names the architectural position of each audience and the single action the architecture most directly implies; the fuller stakeholder analysis — market sizing, survival positions, the full role taxonomy, and the longer-horizon action windows — is developed in Out of the Loop’s Predictions by Stakeholder section.

Non-Software Companies (Producers of Goods and Services)

Structurally, these firms are the beneficiaries of the architecture. The closed loop runs on a spec corpus, and domain knowledge is what produces a correct spec corpus; non-software firms own the domain knowledge the post-transition stack needs most. Architectural action in 2026: hire the first domain-expert-with-spec-literacy now, before the role has a standard title, so the firm has internal capacity to author its own spec corpus rather than continuing to rent its operational logic back from SaaS vendors. See Out of the Loop’s Predictions by Stakeholder section (Software Consumers) for the full buy-versus-build framing and the divergence argument.

Software Services Firms (Dev Shops, Consultancies, Studios)

Structurally, these firms are the most exposed. The closed loop eliminates the billable-developer-hour as a unit of value, because the main production path has no human in it. The architecture offers a small number of surviving structural positions — attestation brand, vertical specialist, harness operator, and the education layer that trains the new producer class — and each requires a different workforce and capital commitment. Architectural action in 2026: pick one of those positions within twelve months and begin retraining the workforce accordingly; the old model does not survive the loop closing. Out of the Loop’s Predictions by Stakeholder section (Software Producers) develops the four positions in full, including market sizing and the question of whether the education layer is venture-capturable.

Individual Developers

Structurally, the individual developer faces the sharpest bifurcation. The roles that sit inside the production loop — generic full-stack, backend CRUD, dashboard frontend, generic manual QA and devops, anything that competes on coding throughput — are the roles the architecture removes. The roles that survive sit outside the loop as exception handlers (spec-contradiction handlers, outcome-mismatch attestors, novel-situation domain strategists) or as specialized production, bridge, or craft roles (formal-methods specialist, adversarial security specialist, agent engineer, protocol designer, creative-tool specialist, legacy archaeologist, harness operator). Architectural action in 2026: pick a position outside the loop this year and commit to acquiring the specific skills; do the work in public, because the 2029 titles are being defined now. Out of the Loop’s Predictions by Stakeholder section (Software Practitioners) develops the full role taxonomy, the compensation structure, and the positions that die.

The closed-loop architecture has one structural implication for who produces software that is worth naming directly: when the durable artifact is the spec corpus rather than the code, and when the loop around the corpus is commoditized, the skill that remains scarce is authoring the corpus. That skill lives in the domain, not in software. A doctor, accountant, structural engineer, derivatives trader, agronomist, radiologist, tax strategist, industrial chemist, or urban planner who acquires specification literacy becomes a direct producer of software in their own industry, with no software-industry intermediary — because the architecture no longer has one in the main path. This is the architectural reason the new producer class is drawn from domain experts rather than developers: the loop accepts a spec corpus as input, and only the domain expert can author the corpus correctly.

The historical precedent for this pattern — the Gutenberg press creating a new author class drawn from people whose expertise was previously under-utilized — and the market sizing for the global population of domain experts who will occupy this position, along with the identification of the education layer that trains them as the largest underserved market in the transition, are developed in Out of the Loop’s Historical Precedents section (the printing-press precedent) and its Predictions by Stakeholder section (the education-layer position for software producers).

The closed-loop architecture creates a small, high-status, high-compensation professional class whose structure has no direct precedent in the software industry but has precise precedents in older professions.

The Architect-Inspector Hybrid

The closest historical analogy is the licensed architect in building construction, updated for a world where the contractor is automated. A licensed architect signs drawings and stakes professional liability on the claim that a building built per those drawings will stand up and satisfy code. A building inspector verifies, independently, that what got built matches what was drawn. In the closed-loop architecture, the harness is the contractor (commoditized, automated, not a profession), the specification is the drawing, and the attestor is an architect-inspector hybrid: they verify that the spec captures intent (validation), and they sign their name to the claim that the deployed system satisfies it (attestation). Professional liability is real. Signatures are load-bearing in court.

This is exactly what distinguishes attestation from judgment. A machine can judge whether code satisfies a property — that is just verification, and it is automated by the deterministic toolchain in the main loop. What a machine cannot do is stand behind that judgment with a signature that a court, an insurance company, and a customer will treat as load-bearing. The signature is not the judgment; it is the commitment that the judging party will personally bear the consequences if the judgment is wrong. That commitment requires an accountable human or institution — someone with reputation to lose, liability to absorb, and standing in the relevant professional and legal system. Attestation is the name of that institutional act. It is what the attestation layer is for.

Licensure and the Liability Question

I predict professional licensure for attestors emerges in regulated sectors (healthcare, finance, aviation, pharmaceuticals, critical infrastructure) by 2030 and generalizes to most of the economy by 2035. The driving force is not regulation per se but liability: when software fails in the post-transition world, someone has to be legally responsible, and “the harness produced it” is not a defense any court will accept. Courts will demand a name. Insurance companies will demand a licensed name. Once that demand solidifies, the licensure regime follows, because licensure is how every prior liability-sensitive profession — medicine, law, accounting, engineering, architecture — stabilized around a small, trained, accountable workforce.

The attestor profession in 2035 probably looks like the CPA profession in 1935: a recently-created regulatory construct, professionalized in response to a structural transformation, staffed by a small number of people with very high trust, very high compensation, and very high personal stakes.

The closed-loop architecture produces a short list of architecture-specific strategic moves — moves whose leverage comes from the shape of the loop itself rather than from the macro economy around it. The broader stakeholder strategy — how non-software firms, services firms, and individual developers should position across the full transition, and how the two concentrated rent layers (inference-compute and general-agent routing) shape the economic landscape around the loop — is consolidated in Out of the Loop’s Strategic Implications by Stakeholder section and its Token Economy section. What follows is only the subset that comes directly from closing the build-verify loop.

Build legacy archaeology capacity for the 2028-2033 window. The loop runs on a spec corpus. Most software in 2026 does not have one. The bridge workforce that extracts formal specs from brownfield systems is an architectural requirement for the loop to reach existing codebases at all, and the window is explicitly time-bounded — demand peaks while brownfield migration is active, collapses once the migration is behind.

Own the harness as commodity infrastructure. The loop is the harness in running form. Someone operates the commodity production infrastructure — the verifier pipeline, the ephemeral sandboxes, the adversarial test ensemble. Margin-compressed, Postgres-shaped, durable.

Specialize in adversarial testing and agent security. The loop ships directly to production after deterministic verification plus adversarial outcome testing, with no human gate in between. The adversarial layer is the last non-human check, and its quality is load-bearing for the whole architecture. Demand for this specialization is structural to the loop, not a macro trend.

Shape the protocol standard that general agents use to operate the loop’s output. The closed loop produces capabilities that have no UI; the standard that exposes those capabilities to general agents is what every transaction crosses. Whoever defines the interface captures value from every call through it.

Do not compete on coding throughput. The loop is throughput. Competing with the automated production path is structurally the weakest position available. This is the single most load-bearing architectural implication for individual career choice, because it is the one the architecture itself most directly imposes.

The closed-loop architecture is not a solution to the validation problem. It is a relocation of it.

The transitional architecture places validation at the spec review gate: a human reads the spec and decides whether it captures intent before implementation proceeds. The closed-loop architecture eliminates that gate and places validation at the outcome exception handler: the system ships, runs in production-equivalent sandbox, is exercised by adversarial agents, and the observed outcome is compared to declared intent. When the comparison fails, a human is invoked.

The problem: the comparison can fail silently. If the declared intent was shallow or wrong to begin with, the adversarial agent tests against a shallow or wrong baseline, and the system is promoted to production under the false confidence that its outcomes match its intent. The validation gap has not been closed; it has been moved from a place where a human could catch it (pre-deployment spec review) to a place where no human is watching (automated outcome comparison against an automated baseline).

The only defense against this failure mode is adversarial diversity at the outcome-testing stage: many agents with different priors, different training, different adversarial strategies, exercising the system against many interpretations of intent, surfacing any divergence for human review. This works when it works. When the entire adversarial ensemble shares a blind spot — because they were all trained on similar data, or because the intent was genuinely ambiguous in a way no amount of testing could resolve — the failure is invisible and the system ships broken.

This is the deepest unsolved problem in the closed-loop architecture. It is not clear it has a technical solution. It may require a human role not captured in the exception-handler model: an attestor over the verification infrastructure itself, whose job is to sign their name to the claim that the outcome-comparison baselines and the adversarial test ensemble are themselves sound. This is meta-attestation — attestation of the attestation layer — and it is closest in spirit to an internal auditor in accounting, whose entire function is to stake professional liability on the claim that the other auditors are doing their jobs correctly. The companion paper Wanabai: Software as Electricity names this role the constitutional auditor, and identifies it as the most consequential human position in the post-transition economy precisely because it is the place where the regress bottoms out: at some point, the soundness of the verification infrastructure has to rest on a signature that is not itself verified by more infrastructure, and the person who signs that signature is the last load-bearing human in the system.

The questions below are specific to the closed-loop architecture developed in this paper. Broader open questions about market concentration at the two rent layers, the institutional mechanism for the constitutional auditor, the capturability of the education layer, the timeline for non-English-speaking economies, the political response to rent concentration, the stability of the open-source harness commons, and the integrity of the verification loop under self-improvement are enumerated in Out of the Loop’s Open Questions section and are not repeated here.

Is the closed loop stable on brownfield systems? The architecture assumes canonical rules can resolve most spec contradictions automatically and the residual exception rate is manageable. Empirical validation is needed on real legacy systems of non-trivial size. If the exception rate is too high, the loop thrashes and the closed-loop architecture fails to materialize on the predicted timeline.

Does protocol standardization actually democratize distribution at the loop’s output interface, or does it reinforce the general agent oligopoly? Open protocols usually democratize. But if distribution is controlled at the agent-routing layer rather than at the protocol layer, an open capability-protocol may paradoxically entrench concentration rather than dissolve it. This is the opposite of the container-ship lesson applied to the specific interface the loop produces, and it deserves serious analysis within the architecture rather than only at the macro level.

What happens to the legacy archaeologist role in the mid-2030s? The bridge workforce evaporates when the bridge is crossed. What do legacy archaeologists do next? Some become attestors; some become domain experts in their now-migrated systems; some retire. The transition of this architecturally-defined bridge workforce is a smaller-scale version of the broader developer transition and may offer lessons about how the larger transition terminates.

The transitional architecture that builders in 2026 should construct over the next three to five years — an architecture with a human chokepoint at spec review, a separation of build from verify, and a gradual migration toward formal specification as the durable artifact — is described at greater length in the companion paper The Attestation Layer: Spec-Mediated Verification for the Age of Agent-Produced Software. That architecture is the transitional shape. It is correct for its moment and it will be built, because it is the only architecture that fits the current skill distribution, the current tolerance for automation, and the current regulatory environment.

This paper describes where that transitional architecture is headed once the chokepoints dissolve, the build and verify loops merge, and software becomes a utility consumed through protocol sockets by general agents on behalf of humans who never see a line of code. If production cost approaches zero, the chokepoint cannot hold. If the chokepoint cannot hold, the loop closes. If the loop closes, software stops being a product. If software stops being a product, the industry that sold it as a product dissolves. What remains, at the bottom of all of it, is the attestation layer: the institutional structure that converts machine-produced software into software a human or institution is willing to stake a signature on. The layer has a thousand automated components and a very small number of humans, and those humans are paid accordingly.

The right posture for builders in 2026 is to build the transitional architecture while reasoning about the steady-state consequences. Construct the transitional shape for today; position institutionally for the endpoint. The people who do only the first become obsolete by 2030. The people who do only the second build futures that do not yet have infrastructure to stand on. The people who do both build the bridge and cross it.

• Boehm, B. (1981). Software Engineering Economics. Prentice Hall.

• Brooks, F. P. (2010). The Design of Design. Addison-Wesley.

• Chandler, A. D. (1977). The Visible Hand: The Managerial Revolution in American Business. Harvard University Press.

• Claessen, K. & Hughes, J. (2000). QuickCheck: A Lightweight Tool for Random Testing of Haskell Programs. ICFP ’00, 268-279.

• Eisenstein, E. L. (1979). The Printing Press as an Agent of Change. Cambridge University Press.

• Hickey, R. (2012). The Value of Values. JaxConf.

• Hughes, T. P. (1983). Networks of Power: Electrification in Western Society, 1880-1930. Johns Hopkins University Press.

• Jackson, D. (2006). Software Abstractions: Logic, Language, and Analysis. MIT Press.

• Lamport, L. (1978). Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM.

• Lamport, L. (2002). Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers. Addison-Wesley.

• Leino, K. R. M. (2010). Dafny: An Automatic Program Verifier for Functional Correctness. LPAR-16, 348-370.

• Meyer, B. (1986). Design by Contract. Technical Report TR-EI-12/CO, Interactive Software Engineering.

• Model Context Protocol Specification (2024). Anthropic.

• NASSCOM (2024). Technology Sector in India: Strategic Review 2024. National Association of Software and Service Companies.

• Naur, P. (1985). Programming as Theory Building. Microprocessing and Microprogramming, 15(5), 253-261.

• Newcombe, C., Rath, T., Zhang, F., Munteanu, B., Brooker, M. & Deardeuff, M. (2015). How Amazon Web Services Uses Formal Methods. Communications of the ACM, 58(4), 66-73.

• Parnas, D. L. (1972). On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM, 15(12), 1053-1058.