Indian IT services have a pattern worth understanding before we talk about productivity numbers.
We picked up COBOL when the US had stopped teaching it. Y2K was not a crisis for Indian engineers — it was an entry point into global markets. We rode the dot-com era, survived the bust, scaled through BPO, excelled at cloud, did serious work in machine learning and data science, and handled the blockchain wave with enough pragmatism to come out mostly intact. Through all of it, Indian IT stocks were among the top performers on the market.
After 2023-24, every single IT stock is on a discount.
This time is different — not because the technology is more capable, but because the pace of change has broken the usual adaptation timeline. Every previous shift took eight to ten years to stabilise. Companies had time to retool, retrain, and build new practices before the next wave arrived. Gen AI is not stabilising. Nobody can predict the market twelve months from now, let alone three years. Companies that were planning transformation programmes are now in survival mode — not because the work has disappeared, but because the sentiment has.
The problem is the gap between AI marketing and AI reality
AI tools are genuinely brilliant for one thing: demonstrating an idea. A well-structured Claude Code prompt can produce a working proof of concept in two to two and a half hours that three to four engineers would have taken two months to build. Eight engineer-months compressed into an afternoon. That is not an exaggeration.
That compression is real. It is also what is creating the current problem.
The demo lands, the client sees it, and a set of beliefs locks in that are very difficult to dislodge later:
The customer believes that two in-house engineers with AI tools can handle everything their existing team was doing, at a fraction of the cost. The POC made it look that way.
The CEO is reading reports from analyst firms and press releases from competitors claiming five to ten times productivity improvements. He is now asking his delivery manager to match those numbers.
The development team is the one actually dealing with the consequences. They are not building fresh POCs. They are maintaining systems where vibe coding has drifted the code that was approved two sprint before and now regression bugs are causing failures in production. The problems are real and slow to fix.
Delivery managers feel all three of these simultaneously.
Accepting the reality before calculating anything
Coding agents are here, they are useful, and they will keep getting more capable with every release. Denial is not a strategy.
The right move is to accept what they are good at, understand where the gains actually come from, and set numbers that can be defended — not numbers that sound impressive in a presentation and become credibility problems six months into delivery.
Where the productivity gains actually come from
To calculate a realistic number, start with how effort is distributed in a traditional SDLC.
In large enterprises, coding accounts for roughly 30 to 40 percent of total effort. In SMEs it sits closer to 50 percent. That is the portion where agents can make the most direct impact — and even there, the gain is not uniform across all types of coding work.
Testing accounts for 20 to 30 percent of total effort in a well-run project. Of that, a significant share — roughly half on sizeable projects — is writing automation tests, test data generation, and regression suite maintenance. Agents can accelerate this meaningfully.
The caveat worth keeping in mind: as coding effort shrinks, the weight of system design, low-level design, database design, and validation gates increases. These are not areas where agents currently replace human judgment. The effort does not disappear — it shifts. A productivity gain calculation that does not account for this shift will produce a number that looks good in a spreadsheet and fails in delivery.
Accounting for the shift in coding effort, the partial gain in testing, and the increased weight of design and validation, the realistic productivity improvement available from agentic coding — after six months of structured adoption with a proper framework — sits at 20 to 25 percentage points of total SDLC effort in the first year.
That is not the number you will read in a vendor report. It is the number that holds up after a project completes.
The scenario table
The numbers below assume six months of team training and an established agentic SDLC framework. They are ranges, not guarantees. The conditions column is what determines where in the range you land.
| Scenario | Realistic gain | What determines the outcome |
|---|---|---|
| Greenfield, cloud, GitHub, experienced lead, documented requirements | 40–60% reduction in delivery time | Everything is configured for agents to work without friction |
| Greenfield, average team, some setup needed | 20–35% reduction | Realistic target for most new projects |
| Brownfield, good documentation, flexible codebase | 15–25% reduction | Documentation quality is the ceiling |
| Brownfield, poor documentation, strict no-modification policy | 0–10%, sometimes negative | Setup cost can exceed the gain entirely |
| Regulated environment, heavy compliance requirements | Measure in months, not percentage | Compliance verification absorbs most of the time saved in coding |
| New POC, customer wants to validate an idea | 500–1000% or more | This is the demo scenario — not a delivery benchmark |
That last row is important. The POC number is real. It is also what creates the expectation problem, because clients see the POC and assume the same multiplier applies to the full delivery. It does not. POCs have no compliance requirements, no integration with existing systems, no regression test suites, and no production operations. Full delivery has all of those.
What to tell your CEO
A commitment of 20 to 30 percent improvement in overall delivery time is defensible for a well-prepared greenfield project in the first year of structured agentic coding adoption. If the project is brownfield or the team is new to these tools, 15 percent is a more honest starting point.
Do not commit to more than this until you have completed projects to benchmark against internally. Vendor reports measure individual developer throughput in controlled conditions. Your CEO will be measuring delivery dates, defect rates, and client satisfaction.
Those are different measurements. The commitment should reflect what you can actually control.
A note on the five to ten times claim
When a competitor claims five to ten times productivity, they are almost certainly measuring lines of code written, tasks closed, or pull requests merged per developer. These numbers go up with agents — sometimes dramatically. What does not automatically go up is the speed at which working, tested, compliant software reaches production.
More code, more PRs, more bugs, same delivery speed. The coding step accelerated. The review and testing steps, which were already constraints, got worse.
Indian IT has adapted to every major technology wave for four decades. This one will be no different — but the adaptation requires honesty about what the tools actually do, not just what the marketing says they do.
If you want to have a first hand experience of the Agentic AI SDLC framework then, the Idea Lab is a practical place to start. For a direct conversation about applying an agentic SDLC framework to a specific project, reach out.
Top comments (0)