A personal reflection on the hidden costs of using AI in development — from the subscription you don't fully use, to the thousands of dollars burned on requirements that never make it to production.
A few months ago I started using Claude intensively on a personal project. I began with the 20-dollar-a-month plan and, as you'd expect, within a few weeks I was hitting limits. The caps came fast and kept cutting into my workflow. So I upgraded to the 100-dollar Max plan.
The initial spike: when everything seems to justify itself
When you start a project from scratch, there's a huge amount of "mechanical" work: configuration, scaffolding, base code, folder structure, first integrations, authentication boilerplate, models, migrations. That's the kind of work where AI really shines, because you can throw concrete tasks at it one after another without pause.
In that phase, the credits from the new plan were being used to the max. Productivity went up, progress felt real, and paying more seemed like the obvious choice.
But then the second phase arrived. And that's where I started to see the problem.
The bottleneck is me
As the project advanced, the blocker stopped being the AI's speed and started being me. I'm the one who defines the requirements. I'm the one thinking about what feature to add, how it should behave, what edge cases to consider. And that takes time. Time to read, to think, to test, to change my mind.
The result: I spend days when I'm not even using 50% of the credits I'm paying for. I'm paying for capacity I don't consume.
This reminded me of a fairly well-known concept in reactive programming: backpressure in streams. Backpressure happens when the producer sends data faster than the consumer can process it. In my case, the AI is the producer (it can generate code almost instantly) and I'm the consumer (I need time to define the next step).
The gym trap
There comes a point in every project where the number of requirements starts to drop. The architecture is in place, the core functionality exists, and what's left are details, refinements, and edge cases. At that point, keeping a high-tier subscription stops being worth it.
It's the same logic as a gym membership: you pay for a full month but only go two or three times. It's not that the gym is bad — your actual usage just doesn't justify the price.
We can imagine this same process inside companies. In an enterprise, by the time the Product Manager hands down a requirement, the dev understands it, discusses it, implements it, and reviews it, hours and sometimes days have gone by — and AI credits are just sitting there, waiting.
The new cost of cancelled projects
Something that happens in development: you start a feature, you make some progress, and halfway through the requirements change or the project gets cancelled outright. Before, the cost of that was mostly time. The dev got paid their salary anyway, but you could pivot without a direct financial hit.
Today it's different.
Picture this scenario: a developer is assigned a new requirement and, thanks to AI, instead of taking three months they ship it in two weeks. But in those two weeks they burned 3,000 or 4,000 dollars in credits. And it turns out that a month later the product changes direction and that code gets discarded. Before, you'd lose development time. Now you lose development time plus money in credits that you can't get back.
The worst part is that speed invites you to skip the analysis. If you produce fast, you spend less time asking yourself whether it's actually worth producing. And because everything feels instant, no one stops to ask whether the requirement was properly framed in the first place.
Speed hides errors that you pay for later
The last point, and maybe the most uncomfortable: AI generates code fast, but it also generates more errors. Not because AI is bad, but because the requirements we hand it are rarely 100% polished.
When you developed something manually, there was a natural process of rethinking the problem as you coded. You'd sit down to write a function and halfway through you'd realize something was missing, that an edge case wasn't covered, that there was a better way to model the problem. That process is valuable. It's where you find things that weren't in the requirements document.
With AI, that space to re-analyze the same problem multiple times gets compressed or disappears. You define a requirement, the AI ships functional code, the tests pass. And why do the tests pass? Because they cover exactly what you said they had to cover. The edge cases you didn't even think of don't show up in the tests either.
It happened to me on this project. When I sat down to review everything I'd generated 100% with AI, I found things that "worked" but had security issues, unhandled edge cases, and fragile logic in places that looked trivial. And tracing all of that when there are many features at once is really hard.
And here's the expensive part: you end up using the same AI, spending more credits, to review and fix the code that same AI generated. Ten thousand lines that then need two thousand more AI calls to audit, correct and validate.
My take
If I put it all together, in my personal experience I saw at least four clear ways to lose money with AI in development:
- Human backpressure: you pay for capacity you can't consume because you are the bottleneck.
- The gym trap: the high-tier subscription stops being worth it when requirements drop, but you keep paying for it.
- More expensive cancellations: projects that get scrapped mid-way now take thousands of dollars in consumed credits with them, not just time.
- Speed without analysis: you generate more code, with more errors, and end up spending more credits reviewing and fixing what the AI itself produced.
These days, many companies are adjusting their business models to be more efficient in their use of AI, especially with the rising costs we're seeing right now.
I'd love to hear other people's experiences.
Top comments (0)