Is AI Actually Cheaper? Our CEO and CTO Disagree

Most articles about AI and development costs are written by someone with one opinion. This one is not.

Alex is our CTO. I am the CEO. We look at the same projects, the same clients and the same invoices, and we do not agree on whether AI has made software development cheaper. Rather than pick a side, here are both arguments as we actually make them to each other.

Alex's position starts with his own bill.

He pays twenty dollars a month for Cursor. That is it. He does not call external APIs, he does not run his own infrastructure for this, and he has never hit a ceiling that made him look for something more powerful. For the work he does, the subscription covers it.

Inside that, he does something most people skip: he uses different models for different jobs. One model for planning the change, a different one for implementing it. The planning model thinks; the implementation model executes against that plan. He rates the results highly enough that he has not gone looking for alternatives.

His second argument is about bugs, and it is a fair one. Bugs are a normal part of writing software. They were normal before AI and they are normal now. Holding AI-generated code to a standard of perfection that human-written code has never met is not analysis, it is bias.

He also has a case that is hard to argue with. Code written with an AI tool had broken in a way that reading it did not explain. He fixed it with the same tool, with a prompt, without opening the file himself. Something was broken with AI and repaired with AI, and the total human time involved was minutes.

He is careful about what that proves. Not that the tool is magic. That he knew what to ask it. Where someone else writes build me a reports feature, he specifies which reports, which tables, what gets pulled, and that the result arrives with tests. The prompt is where the engineering went.

His broader point: on early-stage work, a prototype or a proof of concept, the speed is worth more than the polish. You are trying to find out whether the thing should exist at all. Applying production discipline to a throwaway build is its own kind of waste.

My position starts with a number that did not change.

AI did not make our hourly rate cheaper, and it did not make anyone else's either. Engineers cost what they cost. What changed is how much gets done inside one of those hours: more tasks close per working hour, projects launch faster, and the same scope is delivered in less time.

That is where the real saving sits, and almost nobody looks at it. Buyers negotiate the rate, because the rate is the number on the page. The rate is not where AI shows up. Duration is. A team that ships the same product in two months instead of four has saved you far more than a team that shaved ten dollars off an hourly figure and then took the long route.

We made that trade deliberately, and we are fine with it. A client who launches early comes back with the next thing, and clients who come back are the entire business model in staff augmentation.

What I am less relaxed about is the assumption underneath the question. "You use AI, so it should be cheaper" treats the tool as the thing being bought. It is not. Anyone can buy the same subscription we use, today, for twenty dollars. What cannot be bought for twenty dollars is the engineer who knows when the output is wrong, and the process that catches it before it reaches your users.

On tokens: we have never had a project where they were worth counting. The spend has always been small enough that billing a client for it would be more administrative work than the money is worth. Anyone telling you tokenomics is the main cost line in a normal development project is selling something.

For all the disagreement, there is one point neither of us argues with. It is Alex's, and it is the strongest technical argument in this article.

The AI is a tool in the hands of whoever is holding it. It does what it was configured to do, and nothing it was not asked for. Ask for a feature and you get a feature. You do not get tests, you do not get a module structure, and you do not get anyone thinking about how the next person will extend it, because none of that was in the request.

That is not the tool being stupid. That is the request being incomplete. If a feature ships with no test coverage, the missing instruction was yours.

What you get by default is everything in one file. Not because it cannot do better: ask for tests and you get tests, and it will sometimes suggest them itself as a follow-up. But left alone it takes the shortest path, happily, forever, because from its side nothing is wrong. The same is true of the security questions a senior engineer asks by reflex. They do not get asked unless somebody asks them.

What happens next is the interesting part. That file grows. It reaches a size where a human being genuinely cannot maintain it. Not "would rather not." Cannot. And then a second cost appears: the AI itself starts burning tokens just to read the thing. Every request has to swallow the whole bloated file before it can do anything. The tool that made the mess now pays a tax to work inside it, on work that never needed to exist.

So the bill does arrive. Not in the subscription, and not in the token line. In the architecture, months later, when someone has to unpick a codebase nobody designed.

That is the honest version of "AI is cheaper." It is cheaper if someone set the rules before the first prompt.

"You use AI, so it should cost less" is now a normal thing to hear in a sales conversation.

Our answer is Alex's, and it is short. AI produces code. It does not produce an engineering approach, a development cycle, or anybody who is accountable when what shipped turns out to be wrong. Those are people, and people cost money.

The rest of it is in the paragraphs above. The discount already happened. It landed in the calendar rather than on the line you were looking at.

Both of us, because we are answering different questions.

Alex is answering "does this save time and money on the work itself." The answer is obviously yes. Twenty dollars a month, hours saved every week, a broken project fixed with a prompt. Arguing with that is arguing with a receipt.

I am answering "where does the saving actually show up, and what has to be true for it to survive." It shows up in duration, not in rate. And it survives only where someone set the rules before the first prompt.

That is the part both of us agree on, and it is the part that decides whether AI made your project cheaper or just faster to break. The code is cheap to create and expensive to own. The teams that keep the benefit are the ones who defined patterns up front, kept review in the process, and made a person accountable for what ships.

The tool is cheap. The discipline around it is what you are really paying for, and it is the only part of this that a subscription cannot give you.

Our engineers use AI daily, inside a process that sets the patterns before the first prompt and reviews what comes out of it. That is the part the subscription does not include. 70,000 hours delivered, clients in six countries.

Two or three matched profiles inside 48 hours, monthly terms, and if the fit is wrong in the first week we replace the engineer.

We work mainly in Ruby on Rails, React, Next.js, JavaScript, Java, Golang, iOS, Flutter and Rust.

Talk to us about a senior engineer