I used to think AI meant we should charge much less for software development.
I had written code before AI coding tools became this useful. I remembered spending hours implementing something, testing it, breaking another part of the application and trying again.
Then I started seeing how much tools like Cursor and Claude could produce from a description.
From the business side, my reaction was straightforward: if the work takes less time, the price should come down.
That belief affected how I sold engineering work. I pushed for lower quotes because I wanted to win the client. Sometimes I underestimated the work and the experience of the engineer doing it.
What changed my mind was getting closer to the parts of a project that happen after the first implementation.
A payment integration made the gap obvious
I spent around two hours working through a Razorpay integration with AI assistance.
At first, the process sounded simple: a customer pays, the provider confirms the payment, and the application updates the order.
But I kept reaching questions I could not confidently answer:
- What happens when the same webhook arrives twice?
- What if payment succeeds but the database update fails?
- How do we verify the notification?
- What happens when two operations run at nearly the same time?
- What should be retried, and what might be duplicated?
AI helped me make progress. It also made it easy to produce an implementation before I fully understood the behavior that implementation needed.
That experience changed how I looked at an estimate. I needed to account for the investigation, testing and recovery work surrounding the code.
Buying an AI subscription did not resolve unclear ownership
I also saw a product owner start working through an existing codebase using a capable AI tool.
The tool could explain functions, suggest changes and generate code. Yet when a problem crossed several parts of the application, the owner still needed an engineer who understood the system.
A repository contains only part of that context.
There are deployment settings, background jobs, external services, database state and business rules. Some decisions are poorly documented. Some failures only become visible when those pieces interact.
I had been treating the speed of generating a change as an indication of how quickly someone could take responsibility for it.
Those estimates were incomplete.
Production problems changed what I valued
Our team has worked around a healthcare platform involving video consultations, transcription, AI processing and patient records.
A report such as “the AI feature stopped working” could lead to several different investigations: provider limits, failed background work, delayed results or records that had not moved into the expected state.
Problems with long transcription workloads required attention to queues, retries and recovery.
A separate investigation into unexpected AI spending involved comparing application activity with provider usage and checking the surrounding account activity.
Watching that work helped me appreciate the value of an engineer who knows where to investigate first, what evidence to collect and which assumptions to challenge.
I still expect clients to benefit from AI
I use AI regularly, and our team uses it throughout development.
I have seen it help with boilerplate, first implementations, documentation, understanding unfamiliar code and preparing tests for review.
When those tools reduce the effort needed for a defined piece of work, I think clients should benefit. An estimate should reflect how the team works today.
But I now ask more questions before judging whether a quote is reasonable:
- What behavior is included beyond the demonstration?
- Which failure cases will be tested?
- How will the system be deployed and observed?
- What happens when an external service fails?
- Who will understand and maintain the result?
My view is that AI can reduce development costs, while the amount saved depends on the work involved.
I am much less confident estimating that saving from the speed at which code appears on a screen.
For developers working with clients: how do you explain the work around implementation when someone expects AI to make the whole project cheap?
An edited version of my article, originally published on Aizaz Studio.
AI assisted with editing and structuring this version.
Top comments (1)
The economic trap here is treating code synthesis as the primary cost center of software delivery.
When the marginal cost of producing syntax drops toward zero, total system complexity usually expands because teams assemble features faster than they can audit concurrency hazards or idempotency boundaries. The payment example highlights that clients were never buying lines in a repository. They were purchasing an informal warranty against state corruption, duplicate ledger entries, and midnight outages.
Once generation becomes cheap, pricing stops tracking drafting time and starts resembling risk underwriting. The market value shifts entirely to absorbing liability when network timeouts and retry queues collide.