AI and Software Pricing: Should Faster Code Cost Clients Less?

A question I hear more often from clients now goes something like this: if AI writes a lot of the code, shouldn't the project cost less? It's a fair question. I use AI tools every day, and parts of my work are much faster than they were a couple of years ago. Scaffolding a dashboard, writing a first pass of an API, turning a design into components: tasks that used to take days can now take hours. So when a founder asks why a quote hasn't dropped by half, I don't think they're being unreasonable. I just think the honest answer is more interesting than yes or no.

It's also one of the bigger debates in technical services right now. Agency surveys this year describe a growing number of clients asking for lower prices because AI makes the work faster, and more vendors are experimenting with pricing tied to outcomes instead of hours. AI software pricing has stopped being a theoretical topic. It comes up in proposals, in discovery calls and in the first five minutes of negotiations.

There are three positions I hear most often, and each one has a real point.

The first is the buyer's view: faster work should cost less. If a vendor bills by the hour and AI cuts the hours, keeping the same price looks like charging for time that was never spent. Buyers also see what AI tools can do on their own. When a clickable prototype can be generated in an afternoon, a quote measured in months feels out of step. I think this view is right about one important thing. Hourly billing and AI don't fit well together, and vendors who keep billing hours while quietly working faster will lose trust once clients notice.

The second is the vendor's view: the price hasn't changed because the hard part hasn't changed. Code was never the whole cost. Discovery, architecture, integrations, security, testing, deployment and the long tail of edge cases still take time, and AI helps with many of them far less than it helps with writing code. There's some evidence for this. A 2025 randomized study by METR found that experienced open source developers took longer to finish tasks when using AI tools, even though they believed the tools had made them faster. The weakness of this view is that it can turn into an excuse. Some work really is cheaper now, and pretending otherwise won't hold up for long.

The third view is that the unit of pricing should change. Instead of selling hours, you sell a defined result: a working feature, a launched product, or a workflow that saves a team a measurable amount of time. Support platforms that charge per resolved ticket are the best known example. This aligns incentives well, but it depends on something many software projects don't have at the start, which is a clear and measurable definition of the outcome. Without that, outcome pricing becomes an argument about whether the outcome happened.

Where I've landed sits between the second and third positions, and it comes from how my own projects break down. When I look back at the AI products I've built for clients, the part AI sped up most was the part that was already predictable: screens, standard endpoints and boilerplate. The parts that decided whether a project succeeded barely moved. Working out which third party services a client could afford, making a healthcare product safe to put in front of patients, recovering cleanly when a long video job fails halfway through. That work is judgment, and judgment is still where most of the risk and most of the value sit.

So I price the scope, not the hours, and I'm open about where AI changes the numbers. My proposals now separate two kinds of work. The first is implementation that's well understood, where AI makes me noticeably faster and the client sees that in the price or in a shorter timeline. The second is discovery, integration, security and reliability, which I price for what it is, because rushing it is how projects fail after launch. Clients tend to accept this split quickly. It explains the number instead of defending it.

I disagree with one popular piece of advice here, which is that vendors should keep AI out of the conversation and simply charge for value. Clients already know these tools exist. If you don't explain how you use them, they'll assume the worst: either you're charging full price for generated code, or you're not using the tools at all and working slowly on purpose. Being specific about where AI helps and where it doesn't is one of the easiest ways I know to build trust in a proposal.

Speed is the other lever people underrate. Even when the total price doesn't drop much, getting a working product in front of users weeks earlier has real value for a startup. It means earlier feedback, earlier revenue and less money spent waiting. Sometimes the fairest way to share the benefit of AI isn't a smaller invoice. It's an earlier launch.

None of this settles the debate for every kind of work. A team selling large volumes of routine development will feel price pressure much more than someone selling architecture and integration. But for most client projects I've seen, the question isn't whether AI should make software cheaper. It's which parts it makes cheaper, and whether both sides can see that clearly.

If you sell software work, try rewriting your next proposal in two columns: work AI has made faster and work it hasn't. Put a price and a timeline on each, and explain the difference in a sentence or two. If you buy software work, ask your vendor for the same split. Either way, the conversation moves from a vague expectation of a discount to a specific agreement about value, and that's a much easier conversation to have.