Software overload: operating systems when applications can be built on demand

A director asks for a temporary tool to explain an unexpected infrastructure bill. An agent produces a dashboard, joins usage data, and schedules a daily investigation. Another team generates a similar tool. A third creates an agent that changes capacity. All three work in isolation. Together, they introduce duplicate queries, conflicting actions, persistent credentials, and infrastructure whose owner nobody can name.

This is the question examined here: what happens when software creation grows faster than the capacity to operate it? The horizon is November 2026–November 2028. The premise is conditional: useful software becomes cheaper and faster to generate. It does not require all models to become equally capable, all applications to be generated, or generation to become literally instantaneous.

Abstract

Software overload is defined here as an organizational condition in which the arrival and persistence of executable capabilities exceed the capacity to verify, coordinate, maintain, and retire them. Recent research supports investigating this condition but does not establish its prevalence or inevitability. This paper combines a focused review of primary studies and engineering reports with queueing and demand-sensitivity models. It proposes separating disposable generated workflows from durable business state and specifies an evaluation protocol. The central result is analytical: lower creation cost alone cannot establish lower operating cost or a stable verification backlog. Outcomes depend on demand elasticity, capability lifetime, verification capacity, and reuse. Those variables can be measured and changed.

1. Method and evidence boundary

This is a conceptual research perspective and engineering proposal, not a systematic review or an empirical productivity study. Sources were selected for relevance to AI-assisted software creation, organizational delivery, agent execution, and security. Preference was given to original studies, official engineering reports, and institutional guidance. The evidence cutoff is 1 November 2026; the newest guidance considered was issued on 29 October.

The review distinguishes controlled experiments, self-report surveys, observational associations, single-company engineering accounts, and normative guidance. They answer different questions. Findings are not pooled into a combined productivity estimate. Vendor reports can reveal mechanisms without demonstrating typical outcomes across the industry. Publication dates do not necessarily identify when observations were collected.

The contributions are an operational definition, two explanatory models, and a proposed architecture with falsifiable evaluation criteria. The architecture has not been implemented or evaluated for this paper. The numerical examples are calculations from declared assumptions, not observations of customer systems.

2. What recent findings establish

The first three entries are documented in METR’s original study ↗, its experiment-design update ↗, and its early-2026 survey ↗. Stronger tools, different populations, task selection, and measurement design can change the answer. A 2025 result should neither be erased nor presented as a current universal verdict.

DORA’s March analysis ↗ and Atlassian’s October commentary ↗ suggest that gains at one activity can coexist with friction elsewhere. The inference here is narrower than “AI causes overload”: measure the entire path from a request to an accepted, operated outcome.

Anthropic’s account ↗ provides a concrete mechanism: increased automated activity can require changes in supporting infrastructure. It does not imply every company needs a new version-control system. NIST’s AI Agent Standards Initiative ↗ likewise identifies interoperability and secure interaction as material concerns. Neither source validates the architecture proposed below.

3. The unit of analysis is an executable capability

Counting repositories misses much of the problem. A generated SQL job, spreadsheet macro, scheduled agent, serverless function, or temporary dashboard can consume resources and change state without becoming a conventional application.

An executable capability is therefore the unit of analysis: a versioned artifact or composition of tools that reads data, produces an operational result, or requests a state change. Its identity includes its artifact digest, purpose, owner, permissions, dependencies, intended lifetime, and side-effect scope. An invocation is not necessarily a new capability; a changed implementation or materially changed permission set is a new version.

A disposable capability has an explicit end condition and can stop executing without losing required business state. Disposable does not mean untraceable. Results, approvals, costs, and financial effects may require retention after its runtime disappears.

Overload has four observable dimensions: unresolved verification work, redundant capability stock, incompatible concurrent actions, and unsupported continuing obligations. More software is not itself overload. If accepted outcomes increase while those burdens remain controlled, the organization is expanding productive capacity.

4. Creation speed can destabilize verification

Let lambda be the rate at which candidates enter a verification boundary and mu its effective acceptance capacity. In a simple single-server queue, utilization is rho = lambda / mu. A stationary queue is unavailable when arrivals meet or exceed service capacity under the model’s assumptions.

For a stable M/M/1 queue, expected waiting before service is:

rho = lambda / mu
Wq = rho / (mu - lambda), for lambda < mu

This model assumes Poisson arrivals, independent exponential service times, one server, and a stable workload mix. Real reviews can be bursty, correlated, prioritized, and spread across reviewers. It is an explanatory sensitivity model, not a fitted forecast; a production study may need multi-class queues or discrete-event simulation.

At a capacity of 20 candidates per hour, 10 arrivals per hour yield an expected three-minute wait. Eighteen arrivals yield 27 minutes. At 20 or more, the stable formula no longer applies. The observation is nonlinear: faster creation near a downstream limit can sharply increase waiting even when individual candidates become easier to produce.

Research perspective / explanatory model

A faster generator can move the bottleneck

FIG 01

Play flow

Automated verification can increase mu; validated reuse can reduce lambda. Neither effect should be assumed constant. An agent reviewing its own work may repeat the same misunderstanding. Different model names do not establish independent failure modes. Acceptance needs externally specified requirements and observable outcomes, not just a generator’s declaration that its tests passed.

The metric is accepted outcome throughput at maintained quality. Lines generated, applications produced, and changes merged are incomplete proxies. Conversely, longer queues do not prove net harm if the organization delivers substantially more valuable outcomes with acceptable delay.

5. Lower unit cost can increase total spend

Let N0 be baseline active capabilities and c0 their average operating cost per period. Suppose average operating cost falls by a factor m, to c0/m, and active capability demand responds as N = N0 × m^epsilon. The resulting total-cost ratio is:

C / C0 = m^(epsilon - 1)
C0 = N0 * c0

This is a conditional scenario equation, not an estimated economic law. It applies to a declared reduction in operating cost, not automatically to cheaper code generation. If development cost alone falls, runtime cost may not decrease. Full lifecycle cost also includes generation, verification, integration, maintenance, incident response, and retirement.

For 100 active capabilities at $20 per month, baseline runtime expense is $2,000. A fourfold reduction to $5 produces $1,000 at assumed elasticity 0.5, $2,000 at elasticity 1, and $4,000 at elasticity 1.5. These scenarios assume constant quality and workload mix and exclude shared-platform overhead.

Research perspective / explanatory model

Cheaper capabilities, different spending outcomes

FIG 02

A complementary stable-flow relationship is active stock approximately equal to activation rate multiplied by mean active lifetime. Tenfold activations paired with one-tenth the lifetime need not increase the active stock. Reuse and retirement can matter as much as generation speed. Expiring a runtime does not automatically eliminate retained data, minimum service charges, or financial commitments.

FinOps should attribute lifecycle cost to purpose and outcome. A failed capability still consumes resources. A reused result may be cheaper than another successful run. Lower cost per token is one input; it does not establish lower cost per business outcome.

6. Proposed architecture: temporary software, durable obligations

The durable plane contains authoritative records, identity, approved domain APIs, and policy versions. The capability plane contains generated workflows, interfaces, and adapters. The execution plane binds a specific artifact to a verified caller, permitted resources, budget, and end condition.

A temporary billing investigator can assemble explanations from authoritative records. It must not become a second ledger simply because its generator found a convenient way to store balances locally. Data authority remains stable even when interfaces change every hour.

Research perspective / explanatory model

Temporary software needs a durable execution contract

FIG 03

A proposed minimum capability record is:

capability_id, version, artifact_digest, purpose_id, owner_id
principal_scope, resource_scope, allowed_actions
input_contract_version, dependency_manifest_digest
policy_version, evaluation_bundle_id, approval_reference
budget_limit, expires_at, cancellation_state
run_id, idempotency_scope, result_manifest, lineage_reference

This is a design contract, not an established standard. Registry search finds reuse candidates, but similarity cannot prove compatibility. Validate semantics, input freshness, authorization, schemas, and side effects before reuse. Similar prompts can require different financial or privacy treatment.

Before execution, immutable artifacts and dependency manifests enter isolation. Caller identity is resolved outside generated code. A broker issues scoped, short-lived credentials and constrains network destinations, actions, concurrency, and resources. Actions are checked at execution time, including after tool outputs introduce untrusted content. Passing preflight does not grant permanent authorization.

For writes, domain APIs enforce invariants inside the transaction that changes state. Plans may be stale between reading and acting. Version checks, idempotency keys, leases, and conflict detection reduce that gap. High-impact operations use existing approval paths; low-risk reads should not inherit unnecessary manual gates.

Budget enforcement also has a boundary. A pre-call estimate cannot prevent every cost already committed to an external provider. Reserve bounded estimated cost before dispatch, reconcile actual usage, cap outstanding concurrency, and document maximum overshoot. Token limits do not cover database scans, egress, external API fees, or abandoned storage.

The Canadian Cyber Centre’s 29 October 2026 guidance ↗ recommends isolation, visibility, least privilege, qualified review, and supply-chain scrutiny. Those practices inform the proposed execution boundary. They are guidance, not experimental evidence that this implementation works.

Retirement requires its own transaction and reconciliation. Cancel scheduled invocations, stop new credential issuance, wait for or explicitly cancel in-flight work, preserve required results, revoke remaining authority, and verify resource deletion. An owner’s “resolved” label does not establish successful cleanup. Shared assets and legally retained data must survive when appropriate.

7. Worked failure: two successful agents, one broken objective

A fictional service has a latency objective and an infrastructure budget. One agent identifies idle replicas and proposes scaling down. Another sees increasing latency and proposes scaling up. Each can be locally correct relative to its observation window. Independent execution can cause oscillation, repeated deployments, or misleading savings claims.

The broker records the same resource scope and desired-state version for both proposals. An existing service controller remains the owner of replica count. The agents propose changes against a common workload snapshot; incompatible writes are serialized or rejected. Passing two independent code tests does not resolve conflicting objectives.

A bounded trial compares cost per successful request and latency against the agreed baseline. If latency fails, expansion stops and the controller restores an approved configuration. The audit trail preserves attempted changes and incurred costs. Reversing a deployment does not reverse charges or requests already served.

Similarly, a generated investigator may propose a credit after detecting a duplicate charge. A controlled adjustment API must verify source-line identity, customer scope, amount, tax treatment, and authorization. Issued invoices remain immutable. The 25-layer billing architecture ↗ supplies durable financial boundaries; generated software operates around those boundaries as a consumer and proposer.

This coordination problem survives even if generated code becomes flawless. Better models reduce implementation defects without automatically resolving contradictory objectives, ambiguous ownership, or competing resource claims.

8. A falsifiable evaluation program

Compare three conditions: generation within an isolated sandbox; generation with conventional CI and review; and generation with CI plus capability discovery, scoped execution, and lifecycle controls. The least-controlled condition must never expose customer or financial systems to uncontrolled writes.

Start with seeded synthetic services and hidden acceptance requirements. Include repeated requests that should reuse prior work, conflicting changes, revoked permissions, missing dependencies, expired jobs, and late data. Keep model versions, task budgets, and compute allowances comparable. Count abandoned and unsuccessful tasks rather than studying only successful deployments.

Then preregister a cluster crossover or stepped rollout across consenting teams. Randomize sequence where practical, model learning and carryover, and stratify by task complexity and risk. Determine sample size from pilot variance and a minimum meaningful effect. An arbitrary team count cannot establish statistical power.

• H1 — verification pressure: increased candidate arrivals without increased effective acceptance capacity raise queue age and rework, conditional on task mix.
• H2 — lifecycle economics: validated reuse and expiration reduce cost per accepted outcome relative to conventional delivery, including platform overhead and retained obligations.
• H3 — coordinated authority: transaction-level controls reduce conflicting or unauthorized side effects without an unacceptable reduction in legitimate completion.

Primary outcomes are accepted tasks per elapsed day, independently measured quality, end-to-end cost per accepted outcome, and harmful side effects. Secondary measures include reviewer time, duplicate capabilities, queue age, resource-hours after expiration, cleanup success, and ownership coverage. Measure human effort and automated verification cost separately.

Report uncertainty intervals and the full denominator of assigned tasks. Cluster observations by team where appropriate. Blind evaluators to conditions when feasible. Predefine missing-data treatment, incident stopping rules, and severity categories. Do not multiply evaluator agreement rates as though correlated judgments were independent.

The proposal would be weakened if controls added overhead without improving quality-adjusted throughput, reuse returned stale results, or expiration removed resources still needed. A null result is informative. Faster generation and improved verification might keep queues stable, contradicting a strong overload prediction.

9. The next two years: three trajectories

One scenario is abundant prototypes but constrained production adoption, with data access and integration still limiting execution. Another is managed expansion: stable APIs, strong evaluation, and shorter lifetimes support substantially more software without proportionate burden. The third is unmanaged proliferation, where persistent jobs and conflicting agents accumulate faster than coordination and cleanup.

These are alternatives for November 2026–November 2028, not probabilities. Monitor activation-to-retirement ratios, cost per accepted task, review queue age, and conflicting-action frequency to distinguish them. Artifact count alone cannot establish overload.

The initial product opportunity is narrow: give generated workflows an owner, execution boundary, cost record, and end condition. Validate it with teams already creating many internal tools. A universal control platform is premature before demonstrating a useful operating decision and repeatable adoption.

Existing identity systems, registries, CI, sandboxes, schedulers, policy engines, and telemetry supply many components. Value would come from a reliable end-to-end contract, not a claim that those components are new. Open interfaces and exportable evidence matter: the layer intended to simplify software should not become another opaque dependency.

10. Limitations and conclusion

The evidence is heterogeneous, incomplete, and partly vendor-authored. No source reviewed establishes that all LLMs will deliver reliable software instantly, that overload is widespread, or that a particular architecture will prevent it. Self-reported productivity, repository throughput, and business value are not interchangeable. Queueing and elasticity assumptions require calibration before forecasting.

Hard real-time control adds another boundary. Rapid generation does not establish worst-case execution time, physical safety, predictable scheduling, or regulatory suitability. Critical control and financial state transitions need qualified, predictable components even when surrounding software is generated quickly.

The defensible conclusion is conditional: when creation becomes abundant, lifecycle capacity becomes a first-class design variable. Evaluate generation, verification, execution, and retirement as one system. The question is whether that system can deliver more accepted business outcomes while preserving correctness and reducing continuing obligations. The answer requires evidence; this paper provides models and a test plan for obtaining it.

Research referenced

• METR, Early-2025 AI and Experienced Open-Source Developer Productivity, 10 July 2025 ↗. Randomized study, interpreted within its population and tool period.
• METR, Changing our Developer Productivity Experiment Design, 24 February 2026 ↗. Follow-up measurement limitations.
• METR, Self-Reported Impact of Early-2026 AI, 11 May 2026 ↗. Value versus speed and self-report uncertainty.
• DORA, Balancing AI tensions, 10 March 2026 ↗. Organizational and verification context.
• Atlassian, AI is making developers faster, 20 October 2026 ↗. Commentary on its developer-experience survey.
• Anthropic, Redesigning source control, October 2026 ↗. Single-company engineering account.
• NIST, AI Agent Standards Initiative, 17 February 2026 ↗. Interoperability and security direction.
• Canadian Centre for Cyber Security, Managing security risks in vibe coding, 29 October 2026 ↗. Institutional guidance.

Reproducibility materials

Download the model CSV ↗ and Python calculation and figure source ↗. The script declares all scenario assumptions and uses no external dataset. Its CSV and SVG are analytical outputs, not empirical measurements. The proposed runtime has not been implemented or evaluated in this paper.