AI Bubble or Expectation Decay?

Subtitle: As intelligence becomes cheaper, delivery becomes more expensive

This article continues the discussion from the previous one: the last piece looked at intelligence becoming a cheap raw material; this one asks what happens when the raw material keeps getting cheaper, while our ability to turn it into reliable outcomes fails to keep pace.

A few days ago, I passed by a subway station and remembered something small.

Several years back, a planning map was posted here.

The map said there would be a station here in the future.

Within a month or two of the announcement, nearby housing prices rose.

Shop rents followed.

Everyone believed the station would come.

Then construction took years.

Work stopped midway, the route changed, and the barriers stayed up.

Prices that had risen gradually fell back.

Some couldn’t hold on and sold their properties.

Later, the subway opened.

Now this station sees heavy traffic every day.

In other words, the initial judgment that “there will be a station here” was correct.

Only one thing was wrong: how long it would take.

The planning map was easy to understand the day it was posted.

But how many years it would take to build a subway line wasn’t written on the map.

It suddenly occurred to me—might today’s AI be experiencing something similar?

I. Valuation Prices Not Value, But the Speed at Which Value Arrives

The previous article left a question.

If token production capacity keeps growing faster than processing capacity, what happens?

My answer now is brief.

Prices will rise first, then deflate.

Because what a price contains has never been “how much this thing is ultimately worth.”

It contains “how soon this thing will be worth that much.”

This needs to be stated more precisely.

A price naturally contains both “how large it can ultimately become” and “how long it will take to get there.”

When the long-term direction hasn’t been disproven yet, what gets recalculated most often is time.

How cheap tokens are, how powerful models are—neither determines this speed.

What determines it is the processing layer.

Whether anyone can stably turn these raw materials into deliverable outcomes.

This is what determines when money comes in.

Raw material production capacity can multiply several times a year.

Processing capability cannot.

It must be refined industry by industry, and each industry’s work is different.

So the two sides diverge.

However long capability lags behind capacity, prices must be recalculated for that time gap.

This isn’t about sentiment or speculation.

Even if every market participant were perfectly rational,

as long as progress on the raw material side is more visible than on the processing side, prices will easily run ahead.

II. One Side’s Numbers Are Visible Weekly, the Other Takes Years to Know

The previous section explained how this time gap emerges.

Another question remains: why does it get amplified to this degree?

Because the two sides are not equally visible.

On the raw material side, everything is visible.

How much a million tokens cost;

How long the context window can be;

How many points the benchmark score increased;

How many models were released this month.

Each is a public figure, and nearly all change weekly.

On the processing side, none of what you want to know has numbers.

Of a hundred tasks, how many were actually delivered;

How many times did humans need to take over;

How long before invested money is recouped;

How much must a company’s processes change to accommodate this.

These things take six months, a year to see clearly.

And they’re scattered across thousands of disconnected industries.

A company claims its Agent is more reliable.

What you can verify today is basically just a demo.

So capital flows more easily toward what can be seen and quantified.

This needs clarification to avoid being read as “all valuations are wrong.”

This isn’t the market making mistakes.

Anyone pricing with numbers on only one side would price the same way.

What can be seen gets priced.

What cannot be seen must be waited for.

Thus the question “Is AI a bubble?” becomes insufficient.

III. When Prices Fall, Which Assumption Was Actually Disproven?

First, we need to dismantle a commonly confused dichotomy.

Bubbles and expectation decay are not mutually exclusive.

A long-term direction ultimately proving correct doesn’t mean there was no bubble along the way.

The internet eventually did transform commerce, media, advertising, and human connection, but that doesn’t mean every company, business model, or price at the time was right.

I simply want to isolate the “time” component within prices.

A price contains at least three things:

How large this thing can ultimately become;

How high the probability of success is;

How long it will take to get there.

Even if long-term value hasn’t changed and success probability hasn’t dropped to zero, simply changing “realize in three years” to “realize in eight years” can make today’s price very different.

So when prices fall, the real question worth asking isn’t:

“Did the bubble burst?”

But rather:

Which assumption was actually disproven?

If what was disproven is the destination, then the long-term judgment was wrong.

If what was disproven is the success probability, then risk is being repriced.

If the destination is still there, demand is still occurring, only the time needed to reach the destination is longer than originally expected, then I call this portion:

Expectation decay.

It’s not the antonym of bubble.

It’s the process of prices recalculating the speed of value realization.

On paper, they sometimes look nearly identical.

Prices are falling;

No one’s telling the story anymore;

Fundraising gets harder;

Companies that were recruiting aggressively last year start layoffs this year.

So they’re easy to confuse.

But for people actually building things, the truly important distinction still exists.

A disproven long-term judgment means reconsidering why you’re still here.

A delayed timeline means switching to a different time scale.

IV. If a Theory Explains Everything, It Explains Nothing

At this point, a more troublesome question emerges.

How do you prove this is merely slow, not wrong?

If anything that hasn’t materialized can be explained away as “wait longer,” then expectation decay isn’t an analytical framework—it’s just consolation.

So it must be falsifiable.

Just looking at “whether more people are using it” isn’t enough.

What should actually be observed is whether cheap tokens are increasingly and stably becoming outcomes.

Whether the number of users is still increasing;

Whether the industries being entered are still increasing;

Whether people willing to pay continuously are increasing;

Whether human intervention required to complete the same task is decreasing;

Whether the cost per unit outcome is declining;

Whether things that could only be demonstrated are beginning to enter stable production processes.

If tokens keep getting cheaper, usage scope continues expanding, and these indicators are also gradually improving, then processing capacity is simply catching up to raw material capacity.

The timeline may have been wrong, but the long-term judgment hasn’t been disproven.

But if tokens have become nearly free, usage still mainly stays at experimentation, human handoff rates don’t decline long-term, customers can’t calculate ROI, and price drops fail to generate new demand—

Then we can no longer say “it’s just slower.”

That means at least one more fundamental assumption has a problem.

So what really matters isn’t how many tokens are used.

But rather:

Whether outcomes are being produced more cheaply and reliably.

This distinction is worth making carefully, because the cost of getting it wrong is asymmetric.

Mistaking a wrong long-term judgment for merely a timing issue means overinvesting for a long time.

Conversely, if long-term demand is still growing, processing capacity is gradually improving, but you leave because of short-term price and sentiment retreats,

you may miss another phase:

Things start becoming cheap, no one’s competing anymore, yet real demand is slowly approaching.

And that’s typically an excellent construction window.

V. Many Internet Long-Term Judgments Eventually Proved Correct, But Realization Paths and Timelines Were Badly Wrong

This reminds me of the internet.

Many macro judgments from that era did eventually prove correct.

Things would be bought online;

Media would move online;

Advertising would be redone;

People would connect online.

The scale that eventually formed even exceeded many early imaginations.

But this doesn’t mean every judgment at the time was correct.

Companies could be wrong.

Business models could be wrong.

Technology choices could be wrong.

Prices could certainly be wrong.

Macro direction being correct doesn’t equal micro bets being correct.

What’s truly interesting is that even though massive numbers of micro bets failed, those long-term demands didn’t disappear with them.

People increasingly bought things online.

The internet still entered more and more industries.

What got re-estimated was largely the path and speed at which these changes occurred.

Long-term judgments held.

That doesn’t mean there was no bubble in between.

It only demonstrates one thing:

Prices can be wrong, timelines can be wrong, yet a longer-term direction may still continue forward.

VI. After the Tide Receded, Enthusiasm Disappeared but Construction Didn’t Stop

The most counterintuitive aspect of those years wasn’t how many companies died.

It was that after so many companies died, things kept getting built.

Fiber continued being laid;

Broadband continued entering homes;

Data centers continued being built;

Web infrastructure continued maturing;

Search became increasingly useful;

Paying online became increasingly convenient;

Delivery became increasingly fast;

Then cloud emerged.

Most of these transitioned from “excess” to “just enough” during those years.

And on the day they became sufficient, almost no one was talking about them.

The future arriving slower than expected doesn’t mean the future won’t arrive.

VII. What Becomes Cheap Enables Things That Previously Couldn’t Work

There’s another layer in the above that I initially didn’t notice.

Excess things become extremely cheap during downturns.

And cheapness itself generates new business.

When bandwidth was expensive, no one could create a site where everyone freely watched videos.

Not because they couldn’t imagine it, but because the math didn’t work.

After bandwidth dropped to nearly free, it first became a financially viable business.

Back to that subway station.

During the years the barriers stayed up, rents in that area were cheap.

So small shops that normally couldn’t afford to open did.

Later when the subway opened and rents rose back, some of those shops survived and others moved away.

But that they could open at all was enabled by the barriers.

So downturns aren’t just about waiting.

They simultaneously rewrite what’s possible above them.

This can be tested today.

See whether, after something drops in price, approaches emerge that only work because it’s cheap.

This has already happened with reasoning.

A system that needs to run many times repeatedly, failing and trying again,

wouldn’t even be mentioned when tokens were expensive.

Now it’s a financially viable approach.

Though this analogy only partially holds for compute.

Fiber laid years ago is still fiber.

Compute isn’t.

Today’s best cards will be a generation behind in a few years, while electricity keeps getting billed.

So “excess capacity will await demand” holds for fiber.

For compute, it requires a discount.

Compared to GPUs, what’s more durable is power access, land, facilities, networking, and cooling infrastructure.

GPUs themselves depreciate rapidly and get displaced by new generations.

VIII. What Continues Being Built in Downturns Is What Cannot Be Dispensed With

Suppose AI also experiences a retreat.

Fundraising is no longer frenzied;

No one talks about “AGI next year” anymore;

Everyone starts asking: is this money well spent?

Then what’s truly worth asking isn’t who the next star company is.

But rather: what must keep being built even when no one’s excited anymore?

The criterion is actually quite straightforward.

Boom periods reward what can produce impressive demos.

Downturns reward what cannot be dispensed with.

This needs clarification: indispensable doesn’t equal unsexy.

Many unsexy things are genuinely useless.

The criterion isn’t “boring,” it’s “remove it—does everything above still work?”

Counting by this criterion, I see three groups.

Cheap: Compute / Inference

Can run: Protocol / Context / Runtime / Execution

Dare to use: Identity / Audit / Evaluation

An important shift appears here.

As timelines get extended, how industries evaluate a technology also changes.

During boom periods, the most important questions typically are:

Can it be built?

Can models get even stronger?

Can demos get even more impressive?

But when expectations begin decaying and money starts recalculating, questions gradually become:

Can the same intelligence be used more cheaply?

Can it recover after failure?

Can it require less human takeover?

Can the same task be repeated a thousand times with consistent results?

In other words, the bottleneck shifts from “producing intelligence” to “processing intelligence.”

Models solve whether raw materials are good enough.

What the processing layer must solve is:

How to turn these raw materials stably, cheaply, and repeatably into results.

Starting here, Runtime becomes important.

IX. Runtime Reduces Construction Cost, Not Intelligence Ceiling

The previous section mentioned three groups.

Now let’s discuss what’s happening with one of them.

Returning from industry to what’s in hand.

Because among those items above, runtime is actively occurring.

Recently, the typical shape of an Agent could be written in one line.

Prompt + Model + Tools + a loop.

In this form, every Agent must redo the same batch of things itself.

Manage sessions;

Store state;

Call tools;

Run sandboxes;

Manage permissions;

Retry and recover after failure.

I’ve written these myself, so the experience is particularly concrete.

They have nothing to do with the problem I actually want to solve.

But I must write every line myself, and often write them poorly.

Because I won’t devote my best attention to them.

Here’s a test anyone can do today.

Open your own Agent project and see how much code actually has nothing to do with your business.

The parts every team is repeatedly writing

are probably the parts runtime will eventually absorb.

This situation resembles early programs written directly against bare metal.

Each application bundled drivers, managed its own memory, handled its own interrupts.

That phase didn’t end because applications got smarter.

It ended because operating systems emerged.

Multiple threads are now simultaneously extracting common parts from applications.

Some name this layer specifically as harness;

Some build it as an Agent SDK, packaged into a Coding Agent’s core;

Some explicitly diagram control flow and state;

Some transform sandboxes from a feature into something purchasable separately.

Technical choices differ greatly, yet directions are highly aligned.

Session, state, tools, sandbox, permissions, recovery—moving out of applications, becoming runtime.

This transformation deserves a name.

Web Application became a category because browsers and HTTP took over the common parts.

Application developers no longer manage retransmission or fonts.

iOS Application, Android Application—same thing.

If these common capabilities continue being extracted from individual Agent projects, then what’s collectively called Agent today may gradually split into two layers in the future.

Below is an increasingly standardized runtime environment.

Above is what truly differs in each application—business logic, craft, and processes.

If this abstraction ultimately holds, then what’s called Agent today may in the future more resemble an ordinary software category.

I’ll tentatively call it:

Agent Application.

It doesn’t emerge because models suddenly got smarter.

But because problems that every team originally had to solve themselves are beginning to be taken over by a common layer.

Why does this matter?

Back to the refinery from the previous article.

Runtime to Agent Application is what utilities are to processing units.

Heat supply, power supply, catalyst circulation, safety interlocks.

Every refinery requires them.

But a refinery’s real differentiation ultimately lies in its own craft and products.

Once utilities standardize, the threshold for building a new refinery changes.

From “build everything yourself” to “configure a set of processes.”

Runtime’s significance isn’t making Agents stronger—it’s making building a refinery cheaper.

This also explains why downturns actually favor maturation of common layers like runtime.

During boom periods, no one wants to build this layer.

Extracting common layers produces no demo effect.

And when every team believes it’s about to win the entire market,

using someone else’s foundation feels like voluntarily surrendering an advantage.

Only when growth slows, costs get seriously recalculated, and repetitive work becomes glaring—

does extracting common parts become something everyone can calculate clearly.

Boom period question: can it be built?

Downturn question: can it be built cheaply and repeatedly?

The latter is what industrialization means.

X. Not Everyone Needs to Build an Oil Field

Back to the initial question.

If the next phase truly lacks these things, what can ordinary developers do?

Some layers are genuinely inaccessible.

Foundation Models, chips, hyperscale compute—these layers require absurd amounts of capital.

Few people will participate, and this landscape won’t change within visible timeframes.

But the internet was the same back then.

And value creation never came only from those building CPUs, laying fiber, or writing operating systems.

After infrastructure matures, the truly massive industry comes from people building on top of it.

Another point worth adding.

These two types of work differ in nature, and skills don’t transfer.

Building oil fields requires capital and frontier research.

Building refineries requires craft, experience, and understanding of specific industries.

The latter’s threshold is not low.

It just doesn’t manifest as compute and parameters.

It manifests as whether you genuinely know how to get work done in a particular field.

So my question becomes very specific.

My concern isn’t how to produce better tokens.

But rather, after cheap intelligence becomes a basic production material,

is there a method to stably process it into reliable results?

AI has already proven intelligence can be industrially produced.

The next phase must prove:

Can intelligence be industrially processed?

XI. My Small Refinery Still Behind Barriers

Finally, a personal matter, because everything above grew from it.

Its starting point was a prompt.

You are an INTJ developer.
Read code and think first.
Provide specific plans and impact scope.
Execute only after user confirmation.

The motivation then was singular: I wanted it to be less impulsive.

Later it grew phases itself.

Investigation first;

Investigation must provide evidence;

Evidence enables planning;

Plans decompose into tasks;

Tasks must be verified after execution;

Completion requires verification.

It gradually became this sequence:

Goal → Evidence → Plan → Task → Execution → Verification → Outcome

I later tentatively called this controlled development flow CDF.

What truly surprised me wasn’t that it became complex.

But the nature of the process itself.

Engineering systems mature by transforming human virtues into system constraints.

“Caution” initially was a personality trait.

Then it became a process step.

Eventually, it became a step the system won’t let you skip.

Writing this far, I finally understood something.

I always thought I was writing a Prompt.

Later thought I was writing a process.

But it’s probably neither Prompt nor Runtime.

It more resembles an embryonic Agent Application.

I don’t need to build an oil field.

I just want to finish building one very small refinery first.

It’s still behind barriers right now.