What AI Has Truly Revealed

AI has made software development faster.

That much is probably beyond dispute.

At least when it comes to writing code, tasks that once took several days can now often be completed in a matter of hours. For a small application, it is no longer unusual to describe the requirements, have an AI write the code, run it, fix it, and reach a working result in a surprisingly short amount of time.

But does that mean the value of software development itself has diminished?

I suspect the answer is slightly different.

What AI may actually have revealed is that we were never paying all that much for the act of writing code itself in the first place.

No One Pays You Simply for Drawing a Manga Manuscript

Manga provides a useful analogy.

An artist creates a manuscript.

It may take several months to complete, or it may take only a few hours. But the time spent drawing it does not, by itself, create monetary value.

To put it bluntly, if you spend three months drawing a manga that nobody commissioned, nobody suddenly owes you three months' worth of compensation.

You take it to an editor.
Someone recognizes its value.
It gets published.
It reaches readers.

Only then does money appear in the form of a manuscript fee or royalties.

The value of a manga, therefore, is not determined by how difficult it was to create.

A manuscript completed in three hours may be far more successful in the market than one that took three months.

What determines its value is not the amount of labor invested in production.

What matters is how well the work fits the market.

Software, I believe, has always been fundamentally similar.

Writing Code Is Not the Business

Whether we are talking about a service or an application, its value is ultimately determined by how well it is accepted by the market.

A product is not valuable simply because it contains a million lines of code.

Nor is it valuable because it required a hundred person-months to build.

Conversely, something created by one person in a few days can be extremely valuable if it solves a problem for millions of people.

This was already true long before AI.

For many years, however, the software industry made development effort and business value appear closely connected.

That was largely because software required enormous amounts of human labor and time to produce.

As a result, the statement,

"This will take ten person-months."

began to sound almost equivalent to,

"This is expensive and valuable work."

AI is beginning to separate those two ideas.

As implementation costs fall sharply, an obvious fact becomes visible: something was never valuable merely because it was difficult to build.

What Does Faster Development Actually Improve?

So what is the business value of making development faster with AI?

I believe the answer depends heavily on the stage of the product lifecycle.

In a greenfield business, AI-driven speed can be extraordinarily valuable.

The reason is simple: it allows you to run more trials and make more errors.

If building a service takes six months, you may only be able to test two or three ideas in a year.

If a prototype can be built in a week, you can test dozens of hypotheses.

Will users accept UI A?
Can pricing model B work?
Do customers actually need this feature?
Does a market for this service exist at all?

These questions can be tested much more quickly.

In a new business, therefore, the major value of AI-driven development speed may not be that it directly increases the probability of success. Rather, it reduces the cost of failure and increases the number of experiments you can afford to run.

That is extremely powerful.

The Situation Changes Once a Product Has Succeeded

But what happens when a service has already been accepted by the market?

It has users.
It generates revenue.
Existing business operations now depend on it.

At that stage, the most important goal is no longer necessarily to build more features.

Increasingly, the challenge becomes how to change the system without breaking it.

If a service has one million users and AI makes development ten times faster, I am not convinced that adding features ten times faster is something we should actually want.

Every change carries risk.

Specifications become more complex.
The support surface grows.
Users have more things to learn.
The testing surface expands.
Operational exceptions multiply.

For a successful product, the ability to make more changes is not automatically equivalent to greater value.

This is where the role of AI may change.

For example, AI can be used for:

• understanding existing code,
• expanding test coverage,
• migrating away from obsolete libraries,
• refactoring,
• investigating failures,
• organizing documentation, and
• eliminating technical debt that has accumulated over many years.

For a mature service, I suspect these may be more natural applications of AI.

In other words, for greenfield development:

AI → lower experimentation cost → more trial and error

While for mature products:

AI → lower maintenance, investigation and modification costs → healthier products

These are fundamentally different value propositions.

If we introduce AI into a mature product organization and simply say,

"Now that we have AI, let's double development velocity."

we may be applying the tool in a way that does not match the product lifecycle.

And then, just as organizations sometimes adopt Scrum only to end up with "Scrum, but...", we begin to see "Codex, but..." and "Claude Code, but..."

The problem is not necessarily the tool.

The problem is that the metric improved by the tool does not match the problem the organization actually needed to solve.

Software Development Has Always Contained Two Different Worlds

AI has also created another interesting change.

Software organizations have always contained at least two fundamentally different kinds of knowledge.

One is technical knowledge about how to build software.

The other is domain knowledge about the business in which that software operates.

For convenience, I will call the former the "technical side" and the latter the "domain side."

In my experience, the best development leaders have not necessarily been the strongest programmers.

More often, they have been people who deeply understood what the product was supposed to do, who used it, and what actually mattered to the business.

This is hardly surprising.

No matter how sophisticated the technology may be, a product will fail if it solves a problem users do not have.

The difficulty is that, in some organizations, the technical side and the domain side are heavily separated, both organizationally and culturally.

That creates an interesting conflict.

From the domain side, the question is:

"Why can't you do something this simple?"

From their point of view, the requested behavior really does look simple.

From the technical side, the question becomes:

"Why can't they understand such a simple technical reason?"

Compatibility with existing systems.
Data structures.
Transactions.
Backward compatibility.
Security.
Performance.
Historical constraints.

The technical side can see all the reasons why a seemingly simple change may not actually be simple.

Both sides can therefore be correct within the world they can see.

The problem is that they are looking at different worlds.

This conflict has existed for decades.

AI Has Changed the Balance of Power Inside Organizations

AI has changed this relationship significantly.

The side that has gained particularly strong leverage is the domain side.

In the past, they might be told:

"This will take three person-months."
"We don't have the engineering capacity this quarter."
"It's technically difficult."

And at that point, they had little choice but to accept the answer.

Was the task genuinely difficult?
Was it merely a low priority?
Was the problem caused by legacy architecture?
Did the engineering team simply not want to do it?

The domain side had very little ability to tell the difference.

Today, however, they can say:

"Then let's ask AI to build it."

And sometimes, a working prototype really does appear overnight.

Of course, that prototype is not automatically a commercial product.

Security, quality assurance, operational design and many other concerns still remain.

But the domain side can now independently determine whether the idea is at least technically plausible.

I believe this is a bigger change than simply "democratizing programming."

AI has partially destroyed an information asymmetry that existed inside software organizations.

The technical side once held most of the negotiating power over what could and could not be built. The domain side is now beginning to acquire some of that power for itself.

This may explain why, in some organizations, domain experts embrace AI enthusiastically while engineers regard it with considerably more caution.

And some of the claims made by the domain side are, in fact, correct.

There are many things that genuinely can be built much faster with AI.

Some problems that were once described in terms of person-months are turning out to have been, at least in part, implementation-cost problems.

But "Can Be Built" and "Can Be Sold" Are Not the Same Thing

This brings us back to the manga analogy.

You may learn to draw manga much faster.

That does not mean the manga will sell.

The same is true of software.

AI may allow us to build an application in a single day.

That is remarkable.

But the following are all different things:

• being able to build something,
• being able to publish it,
• having people actually use it,
• being able to sell it as a product, and
• being willing to provide it as a company and accept responsibility for it.

In commercial software, a company is not responsible merely for a pile of source code.

The software must work correctly.
Important data must not be lost.
Dangerous mistakes must be prevented.
Security problems must not be ignored.
Failures must be handled.
Changes to external APIs must be followed.
Customer questions must be answered.
And, if necessary, the product must be maintained for years.

Ultimately, someone has to make the judgment:

"This is in a state where we can responsibly provide it to customers."

That is responsibility.

And I suspect that a substantial portion of what customers pay for in commercial software has always been payment for that responsibility.

What Were Developers Actually Being Paid For?

As AI rapidly reduces the cost of writing code, this question is becoming easier to see.

Were developers being paid simply because they could write code?

Of course, coding was part of the job.

But I do not think it was ever the essence of the job.

Developers decide what should be built.
They decide how it should be built.
They decide how much testing is enough.
They decide what not to build.
They decide whether a change is safe.
They decide when something is ready to release.
When something fails, they identify the cause.
And when necessary, they fix it.

Above all, they accept responsibility for what they create.

Perhaps that is what they were being paid for all along.

The price of implementation work will probably continue to fall as AI improves.

But I do not believe that means the value of software development itself will disappear.

If anything, the opposite may be true.

AI is beginning to expose where the real value in software development was located all along.

It was not simply in writing code.

It was not in producing more things.

It was in identifying something the market actually needs,
turning it into something that can responsibly be released into the world,
and accepting responsibility for the result.

What AI has truly revealed may, in the end, be something surprisingly old-fashioned.

Written by T.Wakimura
August 2026