Separate code production from software ownership

A useful prototype creates visible progress. It can also hide most of the work that begins when other people depend on it.

Model custom software in six buckets:

  1. Discovery and workflow definition: deciding what the software should do, where its authority begins and ends, and which exceptions matter.
  2. Initial code and configuration: producing the interface, business logic, integrations, and infrastructure configuration.
  3. Verification and productionization: reviewing access, secrets, data, dependencies, tests, deployment, monitoring, and recovery.
  4. Recurring operation and support: paying infrastructure bills, responding to incidents, supporting users, applying updates, and verifying backups.
  5. Changes and migrations: adapting the application when the workflow, dependency, identity system, regulation, or platform changes.
  6. Exit, replacement, or retirement: exporting data, transferring credentials and knowledge, disabling access, and safely shutting down or replacing the system.

AI may change every bucket, but it does not remove any bucket merely because it produced the first version quickly.

Treat current productivity evidence as conditional

The 2025 DORA report describes AI as an amplifier of an organization's existing strengths and weaknesses. That is a more useful strategic frame than assuming one universal productivity multiplier. Teams with strong tests, delivery practices, documentation, and feedback can apply faster production differently from teams without those controls.

A METR randomized study found that 16 experienced open-source developers working on mature repositories completed the studied early-2025 tasks more slowly with the allowed AI tools, despite believing they were faster. The result is important because it separates perceived speed from measured speed. It is not a timeless estimate for every developer, codebase, or AI system.

METR later said its next experiment required a design change because wider AI adoption created selection effects, and it considered it likely that developers were receiving greater speedups in early 2026 than in its early-2025 estimate. That update is exactly why an investment thesis should state the tool generation, work type, team, and measurement period behind a productivity claim.

The defensible conclusion is modest: code-production economics are changing quickly, and self-reported speed is insufficient evidence of lower lifecycle cost.

Use a lifecycle ownership model

The accompanying cost-model CSV does not contain market rates. It forces each model to use the same inputs:

  • one-time cash cost;
  • recurring monthly cash cost;
  • expected annual human hours;
  • a loaded hourly cost for that human work;
  • the evidence or assumption behind each input; and
  • an uncertainty note.

For each bucket:

year-one cost =
  one-time cost
  + 12 × monthly cost
  + annual human hours × loaded hourly cost

For a three-year comparison, extend recurring costs and explicitly place expected migration or exit work in the period where it occurs. Do not hide uncertain incident or change costs inside a zero.

The model's purpose is not precise forecasting. It makes disagreements useful. One person may expect four support hours per month while another expects twenty. Recording both assumptions reveals the thesis that needs testing.

Measure operational work instead of calling it maintenance

Google's SRE guidance defines toil as recurring operational work with characteristics such as being manual, repetitive, reactive, and scaling with service growth. Even small applications can generate account requests, dependency updates, release work, alerts, restore checks, and user questions.

That work can be:

  • accepted and performed by the business;
  • automated;
  • transferred to a vendor under a clear service agreement;
  • reduced by simplifying the system; or
  • avoided by choosing an established product.

It cannot be assumed away. A business model that lowers initial build cost but leaves every operational task with the customer may create software that is cheap to acquire and expensive to depend on.

The NIST Secure Software Development Framework also places protection, review, vulnerability response, and retained evidence throughout the development lifecycle. AI-generated code is not exempt from those responsibilities.

Test three different economic theses

Thesis 1: Code becomes the scarce asset

This thesis says faster code generation produces more proprietary software and therefore more value.

Its weakness is that code may become more abundant than workflow understanding, trusted distribution, operational responsibility, or customer adoption. The thesis needs evidence that the resulting code is difficult to substitute and that customers value owning it.

Thesis 2: Workflow knowledge becomes the scarce asset

This thesis says the winning company understands a narrow operational problem well enough to produce a better system and improve it with real use.

It is stronger when the workflow contains unusual exceptions, local knowledge, or integrations that broad software handles poorly. It is weaker when an established product already serves the workflow acceptably.

Thesis 3: Accountable operation becomes the scarce asset

This thesis says creation becomes easier while dependable ownership remains hard. Value moves toward services and platforms that verify, release, observe, repair, recover, and transfer software without taking away the customer's control.

Record what would change the conclusion

For any AI-software thesis, keep an assumption ledger:

Assumption Current evidence Confidence Disconfirming event
Initial build time falls Named experiment or project data Low / medium / high Measured cycle time does not improve
Verification effort does not rise Review and defect data Low / medium / high Escaped defects or review time increase
Operation can be standardized Support and incident records Low / medium / high Every app requires unique manual care
Customers value ownership Interviews and buying behavior Low / medium / high Buyers consistently prefer vendor-hosted convenience
The workflow is underserved Product evaluation and user research Low / medium / high Existing software solves the material job

A strategic claim becomes useful when it can fail. “AI will make software cheaper” is too broad to test. “For this workflow and operating model, three-year ownership cost falls because these four recurring responsibilities are standardized” is a thesis that evidence can support or reject.

Frequently asked questions

Does this mean AI coding tools have no economic value?

No. It means their value should be measured in a defined workflow and across the software lifecycle. Faster exploration, lower prototype cost, or improved developer experience can be valuable even when they do not immediately reduce total ownership cost.

Is managed owned software always better than SaaS?

No. Established SaaS is often the better decision when it meets the workflow, security, integration, and ownership requirements. Managed owned software is a distinct operating model, not a universal destination.

Why include exit cost before the software exists?

Because data export, credential transfer, documentation, and replacement become more expensive when they were never designed. Exit assumptions also reveal whether “ownership” is operationally meaningful or only a contract word.