Software Has No Value

Eastman Kodak and its U.S. subsidiaries filed for Chapter 11 in 2012.¹ Digital photography removed film from taking a picture. The useful part of the Kodak story is that businesses built around a bottleneck lose their footing when it disappears.

AI coding has that shape. I think software has no value on its own. A program is valuable in proportion to the problem it eliminates. What buyers have also paid for is the scarcity of the people who can create one. That is the premium AI is compressing.

Software will remain useful. More of it will get made. The question is what buyers will still pay a company to provide. A company whose price rests on being one of the few groups able to turn a request into code has a problem. A company that solves a hard, shared problem still has work to do.

The Price Was Labor

For a long time, a buyer who needed a custom program had little practical choice. They hired engineers, hired a vendor, or changed their process to fit a product someone else had already built. The difficulty of producing working software set the floor under all three options.

That difficulty was real. Reliable software takes design, implementation, testing, operations, and usually a frustrating amount of revision. A subscription can pay for support, distribution, data, and trust. It can also carry a scarcity premium. The customer needs a problem gone, while the vendor is one of the few parties equipped to turn that need into a program.

Those are different things, even when they share an invoice. The problem may be worth a great deal. The artifact is only one way to reach it.

AI changes the artifact’s cost curve first. A person can describe a narrow tool, see a version of it, correct it, and keep going without first learning a programming language. Andrej Karpathy gave that style of work a name, vibe coding, in 2025. The name is useful because it describes the loop: ask, inspect, correct, run.

The result will often be rough. That is fine for work that was never going to justify a procurement process. A tracker for one team, a report that exists for one meeting, a small integration around a peculiar workflow: these were always real problems. They were often too small to earn their own product.

Personal Software Before AI

The spreadsheet gave people a small programming surface for their own budgets, forecasts, schedules, and one-off models. Microsoft Research calls Excel the world’s most widely used programming language and says its formula authors outnumber the programmers using C, C++, C#, Java, and Python combined by an order of magnitude.²

That claim is useful for what it leaves out. Excel did not replace professional software. It made a huge range of small programs cheap enough to build for yourself. Many spreadsheets are not marketed, maintained as products, or designed for a broad audience. They solve a local problem and then sit in a folder until the next time they are needed.

AI gives that pattern a much larger surface. The person with the problem can ask for a database view, an internal dashboard, a document processor, or a narrow workflow, then revise it by describing what is wrong. They may never call themselves a developer. The program may never become a product. It can still remove a real source of work.

That already changes product design. When a model can write a narrow tool around the product a customer bought, the useful question becomes where that code should run. Your users already run AI-generated code makes the case for treating that as a product decision rather than an exception.

Scale Is a Product Decision

Some software needs to be shared widely. A network, a marketplace, a payment system, and a system of record gain value from common infrastructure, reliable operations, and consistent rules. AI does not make those requirements disappear.

Other software serves a smaller group with an unusually specific need. A team may need a tool for one process, one data shape, and one season of work. Building that tool as a conventional product means finding a market, carrying support obligations, and making it generic enough to sell again. Building it for the group that needs it is a different proposition. It can be good enough for its narrow job, then change or disappear when the job does.

That distinction matters more as code gets cheaper. Scale remains expensive when scale is part of the problem. It can be needless overhead when the problem belongs to five people.

The low cost of producing a tool does not lower the cost of trusting it with real data. A team-specific application still needs an identity, a boundary, and a clear account of what it may touch. A sandbox for user code is the infrastructure answer: give the new software a useful place to run without giving it the keys to everything else.

Where Value Goes

Lowering the cost of code changes the allocation of attention. Less of the work is typing an implementation from scratch. More of it is deciding which problem is worth solving, setting the constraints, checking the result, and knowing whether it should survive past this week. I made the same argument about knowledge work in The Knowledge Rancher. When generation becomes cheap, judgment carries more of the load.

Shared systems still need reliability, security, distribution, integration, and people who understand the domain well enough to decide what should be built. Models and the platforms around them are part of the same shift, with their own operational and product work to do.

The pressure lands on software sold mainly as a finished artifact. A standard workflow, offered at a recurring price because the customer could not build it, has a different future when the customer can produce a close version for themselves. The vendor can still win, but it has to win on the parts the customer cannot cheaply recreate: trusted data, a network, operational competence, a deep workflow, or a real distribution advantage.

The distinction is simple. Demand for software is demand for problems to go away. It does not guarantee a company can charge a scarcity rent for the code involved.

Footnotes

1. Eastman Kodak Company’s 2012 Form 10-K records the January 19, 2012 Chapter 11 filing by Kodak and its U.S. subsidiaries. ↩

2. Andy Gordon and Simon Peyton Jones, Microsoft Research, “LAMBDA: The ultimate Excel worksheet function” (2021). ↩