How Do You Price Software When AI Writes the Code?

Rethinking the economics of custom software development in an era where implementation is becoming cheaper, but understanding the problem remains essential.

There is an interesting question emerging in the software industry: How much should custom software cost when AI can write most of the code?

Imagine a customer asking you to develop a custom sales management system.

A few years ago, you would probably have estimated the project based on hundreds of development hours. You would calculate the time required for database design, business logic, user interfaces, reporting, testing, and deployment.

Today, with tools like Claude Code, Codex, and GitHub Copilot, an experienced developer can potentially produce much of that code in a fraction of the time.

So, naturally, the question arises: shouldn't the price of software decrease proportionally?

And if an AI agent can generate most of the application, why should a customer pay thousands of dollars for something that apparently costs little more than an AI subscription?

At first glance, the argument makes sense.

But I think we're measuring the wrong thing.

The Illusion of Nearly Free Software

Let's try a simple exercise.

Suppose you build a custom application using AI agents.

You pay a monthly subscription for your coding assistant. Perhaps you consume some additional tokens. You have a computer, electricity, and infrastructure expenses.

You could calculate the cost of your AI subscription, estimate the tokens consumed by the project, add electricity and machine depreciation, and arrive at a surprisingly small number.

Following that logic, a system that previously cost $20,000 might now appear to cost only a few hundred dollars to produce.

And technically, if we're only measuring the resources required to generate the code, that calculation might not be entirely wrong.

But is that really the cost of the software?

Or is that merely the cost of generating its code?

These are two very different things.

And I believe confusing them is one of the biggest mistakes we can make when discussing the economics of AI-assisted software development.

Our Job Was Never to Write Code

I've been developing software for more than two decades, and one thing has become increasingly clear to me:

Writing code was never the most important part of our job.

It was simply the most visible part.

Our actual job has always been to understand reality and translate some portion of it into a system that can operate reliably.

A customer comes to us with a problem. Sometimes they don't even know what the actual problem is.

They might say:

"We need a better sales system."

But what does that mean?

Perhaps their salespeople are losing opportunities because information is scattered across spreadsheets.

Perhaps their commission structure creates incentives that conflict with the company's goals.

Perhaps the sales process is perfectly fine, but inventory information arrives too late.

Perhaps the real problem isn't sales at all. It might be purchasing, logistics, accounting, or communication between departments.

The customer doesn't necessarily know.

And that's perfectly normal.

They understand their business from their perspective. We are supposed to help them understand how their processes can be represented, improved, and automated.

That requires much more than writing code.

It requires observation, questioning, interpretation, experience, and judgment.

And perhaps most importantly, it requires the ability to recognize a problem that hasn't been properly articulated yet.

Software Engineers as Interpreters of Reality

I like to think of software engineering as the process of digesting reality.

The real world is messy.

People don't always follow procedures. Business rules contain exceptions. Two departments can use the same word to mean completely different things.

Consider a simple example.

A sales manager might define a completed sale as an approved order.

The accounting department might consider it completed only when payment arrives.

The warehouse might consider it completed when the goods leave the building.

All three definitions can be correct within their respective contexts.

But a software system needs to represent these distinctions explicitly.

Someone has to discover them.

Someone has to ask the questions that nobody thought to ask.

Someone has to understand the consequences of choosing one representation over another.

And someone has to decide how much of that complexity belongs in the software.

That is engineering.

Code is the final expression of those decisions.

A database schema is not simply a collection of tables. It represents our understanding of how a particular part of reality is organized.

A business rule is not simply an if statement. It represents a decision about how an organization operates.

An application workflow is not simply a sequence of screens. It represents how people interact with a process.

When we build software, we are creating a model of reality.

And creating a useful model requires understanding the reality we're trying to represent.

AI Cannot Understand What It Cannot Observe

Today's coding agents are extraordinarily capable.

Given a well-defined problem, a repository, documentation, and a set of constraints, they can produce impressive results.

They can implement features, generate tests, refactor architectures, identify problems, and suggest solutions.

In many cases, they can perform these tasks faster than an experienced developer working manually.

But there is an important limitation.

An AI agent does not automatically have access to the reality of your customer's business.

It wasn't sitting in the meeting where the sales manager casually mentioned that the company makes exceptions for certain customers.

It didn't observe the warehouse employee using an unofficial spreadsheet because the existing system doesn't handle partial deliveries.

It doesn't know that the accounting team distrusts a particular report because of a mistake that happened five years ago.

And it cannot infer every important business constraint from a prompt that says:

"Build me a sales management system."

Of course, we can give agents more information.

We can provide documents, databases, interviews, process descriptions, and access to existing systems.

AI can even help analyze these materials, identify inconsistencies, and suggest questions we might not have considered.

And I expect these capabilities to improve significantly.

But the availability of AI does not magically make missing information exist.

Someone still needs to connect the system to reality.

Someone still needs to determine whether the information is correct, complete, and relevant.

Someone must decide what the system should actually do.

And someone must take responsibility for those decisions.

This is where expertise becomes essential.

What Actually Became Cheaper?

I believe AI has dramatically reduced the cost of implementation.

Tasks that once required hours of repetitive coding can now be completed in minutes.

A developer can explore several architectural approaches instead of spending days implementing the first one.

Prototypes are cheaper. Experiments are faster. Refactoring becomes less expensive.

This is an enormous improvement, and I don't think we should underestimate its importance.

But consider the complete process of delivering custom software:

1. Understanding the customer's business.
2. Discovering the actual problem.
3. Identifying constraints, exceptions, and hidden requirements.
4. Designing a suitable solution.
5. Implementing that solution.
6. Validating it against reality.
7. Deploying, maintaining, and evolving the system.

AI is changing the economics of all these activities, but not equally.

The fifth step has become dramatically faster.

The others can also benefit from AI, but they still depend heavily on access to information, expertise, communication, and judgment.

And there's another interesting consequence.

When implementation becomes faster, we can afford to spend more time exploring the problem.

Instead of rushing into development because implementation is expensive, we can experiment with different solutions, validate assumptions, and discard approaches that don't work.

In other words, AI doesn't just allow us to produce software faster.

It can allow us to engineer better solutions.

But only if we understand what we're trying to accomplish.

Reducing the cost of writing code does not eliminate the cost of understanding what needs to be written.

So How Should We Price Custom Software?

This brings us back to the original question.

If I can deliver in two weeks what previously required two months, should I charge the customer less?

I think the answer is often yes.

AI creates genuine efficiencies, and customers should benefit from them.

I don't believe we should pretend that a task still requires forty hours when it now takes four.

But I also don't believe we should calculate software prices by counting tokens.

There are three concepts that we need to distinguish:

• Production cost: What we spend delivering the system, including engineering time, AI tools, infrastructure, testing, and maintenance.
• Sales price: What we charge the customer, considering production cost, risk, competition, responsibility, and profit.
• Business value: The financial or operational benefit the software creates for the customer.

These three numbers are related, but they are not the same.

Imagine a custom sales system that eliminates hundreds of hours of administrative work every month, reduces costly mistakes, and gives management better visibility into operations.

Those benefits don't disappear because the code was generated quickly.

At the same time, the customer should not automatically pay the same price as before simply because the software has the same business value.

Competition matters.

If several companies can deliver comparable solutions faster and more cheaply, market prices will naturally change.

And I think that's healthy.

What needs to change is how we estimate and communicate the value of our work.

Instead of treating development hours as the primary measure of value, we should pay more attention to the complexity of the business problem, the expertise required to solve it, the uncertainty involved, and the responsibility we accept for the result.

A project with unclear requirements, complicated business rules, and significant operational risks may still require substantial engineering effort, even if an AI agent can generate its implementation in a few days.

Conversely, a straightforward application with well-understood requirements should probably become much cheaper.

The difference is not necessarily the amount of code.

The difference is the amount of understanding required to produce the right solution.

The Formula 1 Problem

I've made a similar argument before: owning a Formula 1 car doesn't make you a Formula 1 driver.

The car is an extraordinary machine.

It can perform at a level that would have been unimaginable decades ago.

But its capabilities don't automatically transfer to the person sitting behind the wheel.

You still need experience, judgment, an understanding of the environment, and the ability to make the right decisions.

AI coding agents are becoming extraordinary machines.

They give individual developers capabilities that previously required entire teams.

But having access to those capabilities doesn't automatically make someone a software engineer.

And being able to generate an application doesn't necessarily mean you understand the business problem that application is supposed to solve.

The tool changes what is possible.

Expertise determines what should be done with it.

An inexperienced developer with a powerful AI agent may produce thousands of lines of perfectly valid code.

But if the underlying assumptions are wrong, the result can still be a perfectly implemented solution to the wrong problem.

And that's something we've seen in software engineering long before AI existed.

AI simply allows us to make those mistakes much faster.

The Engineer and the Agent Are a Team

I don't see AI agents as something separate from the future of software engineering.

I see them as part of the engineering team.

In many cases, an agent can be faster than I am at implementation.

It may know libraries I haven't used, suggest alternatives I haven't considered, and find mistakes I might overlook.

That's valuable.

I don't need to compete with an agent over who can type code faster.

I need to use its capabilities to deliver better solutions.

The engineer brings context, experience, judgment, and responsibility.

The agent brings speed, computational capacity, and the ability to explore and implement solutions at a scale that was previously expensive.

Together, they can accomplish much more than either could independently.

And as agents become better at gathering information, asking questions, and interacting with real-world systems, this relationship will continue to evolve.

Perhaps agents will eventually participate directly in customer interviews, observe business processes, and identify requirements autonomously.

That would be a remarkable development.

But even then, understanding a business is not merely about collecting information.

It involves deciding which information matters, resolving conflicting objectives, balancing trade-offs, and accepting responsibility for the consequences.

Greater autonomy doesn't automatically eliminate the need for expertise.

It changes where that expertise is applied.

A New Economics of Software Engineering

I suspect the software industry is entering a period of uncomfortable price adjustments.

Some kinds of software will become dramatically cheaper.

Simple applications, prototypes, internal tools, and standardized business solutions will face increasing competition from AI-generated alternatives.

Some work that previously justified substantial development budgets will become difficult to sell at historical prices.

We shouldn't pretend otherwise.

But complex custom software is not simply a collection of source files.

It is a representation of a business, its rules, its constraints, and its decisions.

And the cost of producing that representation cannot be measured solely by the cost of generating code.

Perhaps the most important change AI is bringing to our profession is that it is forcing us to distinguish between programming and software engineering.

For years, the two were treated almost as synonyms because writing code consumed so much of our time.

Now that machines can do much of that work, the distinction is becoming impossible to ignore.

And I think that's a good thing.

It allows us to focus more on the parts of our profession that have always mattered most.

Understanding problems.

Designing solutions.

Making decisions.

Connecting technology to reality.

Final Thoughts

When someone asks me how much software should cost in the age of AI, I don't think the answer can be found in the price of a Claude Code subscription, the number of tokens consumed, or the electricity used by a computer.

Those are legitimate production expenses, but they are only a small part of the equation.

The real question is how much expertise, discovery, judgment, validation, and responsibility are required to transform a business problem into a working solution.

AI is making that transformation faster.

And in many cases, cheaper.

But faster doesn't mean effortless, and cheaper doesn't mean free.

We should embrace the efficiency AI brings, pass meaningful benefits to our customers, and reconsider pricing models that were built around the time required to manually produce code.

At the same time, we shouldn't confuse the cost of operating our tools with the value of the work those tools help us accomplish.

The cost of writing code may be approaching zero.

The cost of understanding reality is not.

And perhaps that's the most important lesson AI is teaching us about software engineering: our profession was never really about typing instructions into a computer.

It was about understanding the world well enough to tell a computer what to do.