Jason A. Hoffman

Part 8 in the series. Previously: [Zen of Unix Tools], [The Disintermediation Principle], [Keeping AI in the Critical Path].

In August 2011, Marc Andreessen argued that software companies would displace incumbents across much of the economy. The essay captured an important shift, but the companies it named did not all become durable winners.

Groupon, Zynga, LivingSocial, Foursquare, and Flickr followed different paths, and none became the general example the essay’s thesis did.

Infrastructure companies proved durable because applications continued to depend on operating systems, databases, networks, cloud compute, and hardware.

That does not make application software temporary. Systems of record, transaction processing, authorization, workflow, and user interfaces remain necessary even when a model changes how people interact with them.

Models reduce the cost of writing and adapting some application logic. They do not make the rest of the application disappear.

What an Enterprise Application Actually Is

An enterprise application usually combines at least four functions: an authoritative record, deterministic transactions, policy enforcement, and an interface for completing work. Salesforce, contract-management systems, and ERPs also contain configured business rules, fields, reports, and workflows. Those configurations can become expensive to change after the business or implementation team moves on.

Some rules express durable invariants and should remain deterministic. Others encode a judgment that must change with current evidence. Problems arise when the system does not distinguish the two.

Where models lower the cost

A model can search and synthesize records, draft an analysis, generate code for review, or request a bounded tool. Those capabilities reduce the amount of prebuilt interface and report logic needed for some tasks.

A model with governed access to pipeline data can answer questions that previously required a fixed report. It still needs definitions for stages, permissions, source quality, and the business rule being applied. The model does not automatically know that the rule changed, and its answer is not an authoritative transaction.

For several recent analytical tasks, the smallest useful design was governed document access plus Python for numerical checks. That pattern replaced a custom report, not the source system or its controls.

Model features inside spreadsheets, documents, and presentation tools share a pattern: existing records and interfaces remain, while a model adds a flexible way to query or transform them.

MCP Apps can also let tools return interactive resources to a compatible host. This may reduce the cost of building a separate interface for a bounded task. Compatibility, accessibility, state management, and product-specific behavior still determine whether one resource works across hosts.

The practical design is to keep authoritative records and transactions in deterministic systems, expose the minimum governed capabilities needed by the task, and use a model where language or open-ended analysis adds value. An interactive MCP resource can supply a task-specific view, but an application remains responsible for identity, state, authorization, error handling, and operation.

Existing tools may remain valuable because people understand them, organizations govern them, and they encode decades of behavior. New model-native interfaces will compete with and complement those tools; protocol design alone does not decide which interface persists.

The Marginal Cost Argument

Models can make a first implementation much cheaper to generate. Generation is only one part of cost. Requirements, data cleanup, integration, verification, migration, security, training, operation, and maintenance remain, and some become more important when software is produced quickly.

A model may generate persistent automation or a deterministic workflow, but people still have to specify, test, deploy, monitor, and retire it. A conversation can initiate that lifecycle; it does not collapse it.

The marginal cost of drafting routine application logic is falling toward the cost of inference and review. The marginal cost of verified, operated software does not approach zero while errors, state, and external effects remain costly.

What Survives

Databases, operating systems, networks, compute, and model services persist. So do schemas, identity, authorization, transaction semantics, durable state, observability, recovery, and interfaces for recurring work.

MCP servers can expose narrow capabilities, but they are not necessarily thin. A safe database tool may need query restrictions, tenant isolation, pagination, timeouts, audit records, and result limits. Those controls are business and security logic, and a model cannot be trusted to enforce them on itself.

On-demand generation will pressure prices for generic reports and workflows. Customers may still pay for trusted records, integrated controls, support, compliance, collaboration, and accountable operation. Pricing will follow the value and risk transferred, not only the amount of code generated.

What should remain deterministic

Keep rules in code when they define an invariant rather than a judgment: a payment must balance, a user may access only an authorized tenant, an inventory count cannot fall below a physical commitment, or a regulated record must be retained. A better model should not reinterpret those rules on each call.

Use models where the task benefits from language, retrieval, comparison, or formulation under ambiguity. Connect the two through a narrow tool whose code validates inputs and effects. A stronger model may improve the analysis, while stable contracts prevent it from changing the underlying transaction semantics.

Hard real-time systems cannot wait for remote inference in their execution path. Regulated and safety-critical systems also require validated behavior, traceable changes, controlled releases, and accountable operators. These are structural requirements, not mere institutional hesitation. A model may help write or review the code, but model generation does not waive the evidence required to deploy it.

Recurring workflows may also justify a conventional interface because users need predictable state, accessibility, low latency, offline behavior, or a shared view. The right boundary follows the task rather than a general forecast that models will absorb every application.

What This Means

Models will commoditize some generic application logic and make custom analysis available to smaller teams. They will also increase demand for governed data, deterministic tools, evaluations, and operational controls. The durable enterprise product will combine those elements with model capabilities where the model improves the work. It will not assume that generated reasoning can replace the application responsibilities that make the result trustworthy.