Who Gets the Productivity Gain?

A few weeks ago I wrote that AI had brought my excitement back. I have not changed my mind: it is all still there. But I left one part out: the excitement is what I feel when I am building something. The trouble starts when I have to write a quote.

A software module I would have estimated at ten days a year ago now probably takes six, and I know it the moment I start writing the document. Then I get to the price field and I stop, because it is the only place where that difference has to turn into a number.

So who do those four days belong to?

Let me be upfront: no studies, no numbers, and no answer at the end. Just the view of someone who writes estimates every week and has been stuck on the same thought for months: in our industry everyone talks about AI tools, and almost nobody talks about the price field.

The four days that do not exist

What I know for sure is that those ten days were never a measurement. They were a bet.

They were not just time spent writing code. They included the time to figure out what was actually needed, which is never what the email says. The time to argue over the specs. The time to integrate with the ERP nobody has documented in eight years, whose only expert has since retired. And a buffer, never spelled out in the quote, for everything you do not know yet when a client asks for an estimate.

AI shortened exactly one of those items: writing the code, which, to be fair, is also the most fun to talk about and the one that cost me the least.

Everything else is unchanged. Clients change their minds just as fast as they did a year ago. Production credentials still take forever to arrive. Code review is still there too, and contrary to what you might expect, reviewing code written by an agent is far more demanding: figuring out whether it went down the wrong path takes longer than it used to.

Coding time dropped by forty percent, and for a moment I naively believed the whole project would shrink by the same amount. It does not work that way: of the four days saved, one is real, maybe two. The rest was never work to begin with. It was uncertainty, and uncertainty has not dropped one bit.

The math that does not add up

There is one more piece of the puzzle, more insidious and harder to explain.

If the price drops in proportion to the days, it drops much more than costs have. Salaries have not dropped. Rent has not dropped. Holidays, training, the months when a project slips and people sit idle: none of that shrank along with the days. And the day I save is not a day I stop paying for: it is a day I have to fill with other work, which somebody has to sell first.

The paradox I run into every time I write a quote is that a tool meant to make me more efficient ends up doing the exact opposite to the bottom line: the discount that feels most honest, the one proportional to the days, pushes the price toward cost and squeezes the margin. And the fair compromise, the halfway option that looks like the decent thing to do, still leaves me with a thinner margin than I had before AI.

Anyone in my line of work has probably already run the numbers, and can check for themselves whether they are in the same spot.

Where the gain ends up

The one useful thing I took away from these months is that the gain does not vanish. It ends up in one of five places, and the first four are all reasonable.

It can go to the client as a lower price. It can stay with the company as margin, which is the road anyone would take without thinking too hard.

It can go into the product: same price, but now it includes proper tests, documentation, accessibility and all the things that get cut first to hit the deadline and regretted six months later. Or it can go into time: same price, but delivery in three weeks instead of six. This one is, in my view, the most interesting of the lot and the most overlooked: for some clients an earlier delivery is worth far more than a discount. And it has one more advantage: an early delivery ends there, while a discount becomes the starting point of the next negotiation.

And then there is the fifth, the most likely and the one nobody would want: up in smoke. Extra meetings because “there is time now”, rework on code nobody really looked at, specs that quietly drift because “it takes less anyway”, estimates cut, and the same old rush on the shoulders of whoever writes the code. The fifth road becomes the default the moment you do not deliberately choose one of the other four.

Of all these options, the one idea that stuck with me is this: do not cut the price, cut the time.

All these roads, though, share the same blind spot: they only consider me and the client, and leave out the people who actually produce the gain, namely the team. If I compress the estimates and keep the price, the gain skips right past them. I am talking about the developer who now wraps up in two days what took a week a year ago, the very person making that higher margin possible. If the whole benefit stays on the company’s books, they do not see a single euro of it, or a single hour less of work. And developers notice, long before the clients do: they know exactly how long things take now compared to a year ago, something nobody looking only at the price on the invoice can know.

I do not have a formula for how to share that gain with the team: I do not know whether it should be a bonus, more flexible hours, time for training or for the refactor we have been postponing for two years, or something else I have not thought of yet. But I do know one thing: if the share that reaches the team is zero, the productivity gain has a short shelf life, because the people who make it possible will sooner or later stop being willing to.

In black and white

When the company started using AI in earnest, the first thing I did was reread our contracts.

At first, saying nothing seemed to make sense. For a while I told myself silence was a neutral position: if the contract does not say we use these tools, it does not say we cannot either. Then I realized that makes no sense. Silence is not neutral: it is a decision postponed, and sooner or later it comes back like a boomerang. So today our contracts state explicitly that we use AI tools in development. The client knows before signing rather than finding out later.

The second thing is boundaries: which of the client’s material can go into these tools and which cannot. Source code, confidential documents and production data are three different things, but in day-to-day practice they get treated as one. Production data, to start with, never goes in. For everything else, the simplest rule I have found is this: company accounts only, never personal ones.

The difference is not a formality. With a company account, the company picks the tool and controls how it is used, negotiates terms that rule out training models on client data, and is accountable for what goes through it. With a personal account, nobody knows what was shared, with whom, or under what terms, and nobody can check. It is a basic rule, but it is the one that actually protects both the client and the company.

When it sinks in for the client

Even though the client already knows from the contract, when the topic actually comes up there are three possible reactions, and I have seen all three.

There is the technical client, who uses the same tools I do and wants a discount, and has good arguments for it. With them the conversation only holds up if I steer it toward risk and warranty, because on hours they are right.

There is the enterprise client, a public body or a multinational, who does not ask for a discount: they ask for the policy, the DPA and an endless list of other documents. Showing up with all that paperwork ready is worth more than any discount, and it wins tenders that others lose over a missing attachment.

And then there is the client who feels cheated. Here the problem is not AI: it is that they worked it out on their own instead of hearing it from me. From a stray comment left in the code, from a document that does not sound like me, from somebody talking a second too long on a call. Saying it early and clearly always costs less than letting it sink in later.

When objections come up, the line I use is always the same:

Our estimates already account for the tools we use. The price reflects the outcome and the risk we take on, not the hours we put in.

There is no right road

After months of headaches and second thoughts, what I think I have figured out is that the gain should neither be handed to the client as a discount nor quietly kept as margin: it should be decided together with the client. And there are only three places to do that: the quote, the contract and the conversation itself. Anyone who has changed nothing in any of the three over the past year has already picked the fifth road, sending the margin up in smoke, without noticing. I have sorted out two of the three, the contract and the conversation. The quote I am still figuring out.

The reason is that a single right road, valid for everyone, probably does not exist: it depends on the relationship with the client, the type of client, the contract, and how much I trust my estimates, which I am still recalibrating for AI tools as I write this.

So, in the end: the excitement is all still there. And so is the quote, open on my screen, cursor blinking in the price field. Sooner or later I will have to decide. But not today.