Daybreak - Indian IT’s AI coding boom has arrived. The cleanup engineers haven’t

Episode Date: April 22, 2026

A study gave 16 experienced developers the best AI coding tools available.They predicted they'd be 24% faster. They felt 20% faster. They were actually 19% slower — and still didn't believe it when told.That gap between belief and reality is now being deployed at enterprise scale.TCS, Infosys, Wipro, and Cognizant have committed to over 50,000 AI coding licences each. Bugs per developer are up 50%. Code is reaching production without any human review.And the senior engineers who could catch the mistakes are buried too deep in the flood to look up.Is India's IT sector selling a productivity story it hasn't actually earned yet?Tune in. With inputs from Mrunmayee Kulkarni. Daybreak is produced from the newsroom of The Ken, India’s first subscriber-only business news platform. Subscribe for more exclusive, deeply-reported, and analytical business stories.

In early 2025, 16 experienced developers sat together in a room to take part in a study. The study was being conducted by Meador, a research non-profit that proclaims itself to scientifically measure whether and when AI systems might threaten catastrophic harm to society. These 16 coders were given access to their own code bases and projects that they had been working on for years. They were given real tasks to complete in the same project, like fixing bugs, building, features, restructuring the code, you know, the usual. Half of them were given access to the best AI coding tools available at the time, like Cursor Pro and Claude's Sonnet 3.5 and 3.7. The other half worked without the tools. Before they began, the developers were asked to estimate how much faster they would be with

the tools than without. They said 24%. Once they finished, they felt that they'd been about 20% faster. But the study showed that they were actually 19% slower. This gap between the feeling and blind belief in productivity gains and the reality of it didn't happen in a vacuum. You see, by the time the study was published in July 2025, City, one of the largest banks in the world, had already rolled out GitHub co-pilot to its 40,000 strong developer workforce. SAP, the enterprise software had deployed an AI coding tool company-wide and was citing 20% faster code production. Also, Google CEO had told investors that over a quarter of new code deployed at Google was AI generated. Basically, the bet had already been placed on the belief, while the actual results

were only just coming to light. Now, you might say that AI coding tools have come a long way since then. In fact, this was before Claude Code, which is one of the most popular AI coding tools right now, even came into the picture. And you would be right. Even Meeter agrees that the results of the study are subject to change over time, considering how quickly AI develops. And another larger study that was published just this month showed that things have changed, just not necessarily for the better. Farrow's AI studied 22,000 developers across 4,000 teams and found that while developers were faster, companies themselves weren't seeing meaningful productivity gains. Developers were writing more code and closing more tasks, but the

AI-generated code was just getting bigger and buggyer, shifting the bottleneck to the review stage and canceling out any of the speed gained at the development stage. The industry calls is tech debt, the trade-off between short-term speed and long-term sustainability. And it's a debt that is only going to compound. Because think about it, the more junior developers are pushed to rely on AI before they've built the skills, the fewer senior developers there will be in the future who can actually review and debug what it produces. Meanwhile, Indian IT companies like InfoS, WIPRO, TCS and Cognizant are all placing their own bets on the deployment of AI coding tools in the workforce. InfoS claimed 20 to 25%

productivity gains on its own financial product and up to 40% on specific client-facing work. TCS, WIPRO, Info, Enfossus and Cognizant all signed a partnership with Microsoft to deploy over 50,000 co-pilot licenses across each of their operations. Clearly, the productivity story is just too compelling to resist. Even as the evidence for it is only, getting thinner. So what does this shift risk losing? Welcome to Daybreak, a business podcast from the Ken. I'm your host, Richard Wurgis, and every day of the week, my co-host, Nika Sharma and I will bring you one new story that is worth understanding and worth your time. Today is Wednesday, the 22nd of April.

In April last year, Toby Lutker, the CEO of Shopify, posted an internal memo on X after it had already leaked. The message said, reflexive AI usage is now a baseline expectation at Shopify. In practice, it meant that managers at the company who were hiring would have to first demonstrate why it was a job that AI could not do. The memo had come out after Lutker had first invited his engineers to tinker with AI tools. After it was clear that the invitation had been understood as too much of a suggestion, it became a director. It was even tied to the engineer's performance reviews. Other companies soon started following a similar model.

The point was no longer organic adoption. It was to push AI and the productivity promise whether the developers wanted it or not. Amazon took it a step further. In November last year, an internal memo established Key Row, which is Amazon's own AI coding agent, as the standard for all software engineers in the company. There was even a weekly usage target of 80% established for management to track. That's just a usage tracker, by the way.

Not an evaluation of the quality or even quantity of code. It's only a measure of how often employees used AI tools. My colleague, the Kenrapportem Ron Michael Carney, spoke to a supervisor who worked at Amazon. He told her about an incident where a senior developer went it to him. The developer said, and I quote, Kiro hallucinates API so much, and it tries to convince the coder that this is what they asked for. Why should we learn a new coding technique for something that needs so much verification? This developer was not the only one frustrated with this mandate.

Earlier this year, 1,500 engineers at Amazon's US headquarters signed a petition asking management to allow the use of Claude Code instead. Now, to be fair, there's no bad. ban per se on ClaudeCode at Amazon. But when the company announced that Kiro was its recommended tool, it also said that it would not be supporting the use of third-party tools. Remember how I said that the tech debt that's coming out of this shift is just compounding? Well, for Amazon, the recommendation to use Kiro came back to bite it soon enough. Twice, in fact. The first time, just a month after the memo in December 2025. AWS suffered a third. 13-hour interruption to its cost explorer service in a region of mainland China.

Financial Times reported that it was because some engineers had allowed Keiro to make some system changes. Now, as an agentic tool, it's supposed to take autonomous action based on human instruction. This time, the tool determined that the best way to solve a specific problem was to simply delete and recreate the environment. It could do this because it had inherited the engineers high-level permissions. Amazon denied these reports and placed the blame on the fact that the user's instructions were broader than they were supposed to be. The second incident was just last month. This time, it was a six-hour outage on Amazon's main e-commerce platform. Shoppers got drawn delivery estimates, approximately 1 million-plus website errors, and the company lost 1,000

orders. While the media attributed this outage to AI-Gen. bad code, Amazon insisted that that was not the case. It said that the reason was an engineer who followed inaccurate advice that an AI tool inferred from an outdated internal wiki. The internal response to these system failures is where things get interesting. Regardless of whether the mistakes were AI generated or a factor of engineers making mistakes through or because of AI, Amazon realized that changes needed to be made in the pipeline. It mandated two-person approval for major changes to critical systems,

and that senior engineers would need to sign off on all AI-assisted code written by junior staff. And this development in the pipeline is exactly what the Farrow study observed what's happening and why it was a problem. More on this in the next segment. The Farrow study has a name for what's happening. Acceleration Whiplash. The two-year-long study showed that, AI is entering a system that was built for human ability. And the output now is basically a flood

which the existing system just does not have a way to absorb. Now, I am going to be reciting a bunch of numbers, but bear with me because they really do illustrate how and why the existing system was not ready for this flood. As I mentioned earlier, the output gains are real. The number of tasks completed by individual developers is genuinely up. But the quality of the quality of the code generated is another story. Bugs per developer are up by more than 50%. To put that in context, it was just 9% in Farrow's own report last year. Plus, for every code submitted for review, the probability of a production incident,

which is basically things like outages, security failures or user-facing system failures, has more than tripled. The median time for review is up by more than 4.4.4. 100% and more than 30% of code is reaching production or going live without any human review at all. That's because reviewers simply cannot keep up with the sheer volume of the code being generated. Now, Faro's itself describes the production incident as an outage of security event that hits users after code goes live. The study data set covered major companies operating in finance, healthcare and infrastructure, and infrastructure. On the user end, outages in those companies and those sectors mean your bill payment

failing, your transaction processing twice, or a medical record system going down entirely. In my last episode on Anthropic, I had mentioned a recent article from the New York Times. It called the current situation a code overload. Considering that the median review time is more than 400%, it only stands to reason that companies need more senior engineer to reduce that time. NYT wrote that now companies are finding it difficult to hire enough application security engineers. These are the people who can monitor AI code for risks. The problem?

That there aren't that many engineers qualified for that role. In the world. Joe Sullivan, an advisor to Kustanoa Ventures, a Silicon Valley venture firm, told NYT that the reality is that there are not enough application security engineers on the planet. to satisfy what just American companies need. So with Indian companies going all in on adopting coding tools for themselves, what are they signing up for? Stay tuned. Since the AI Impact Summit this year,

the push for AI adoption has only gotten stronger in India. My colleague, Mirren Michael Carney, covered the change in her piece in February. Here's what she covered. For one, OpenAI expanded its partnership with the Tata group. TCS or Tata Consultancy Services, which is Tata's IT services arm, is building AI infrastructure and rolling out enterprise chat GPT internally. Meanwhile, even as Anthropic opened its first India office in Bangalore, it also tied up with Infisys. The idea is to deploy cloud models and AI agents into Infoises enterprise workflows. India has also emerged as one of the fastest growing markets for Microsoft's AI programmer called GitHub Go.

In December, the company had announced that more than 200,000 copilot licenses would be deployed across TCS, Infoys, WIPRO and Cognizant. As you can see, it's all a very top-down approach. Leadership teams decide which license to deploy and where based on what makes the most business sense to them. It's all about preserving existing partnerships, cutting costs and getting the best deal. The cost of that is the real productivity of the developers. Here's what Rn Mn Mn Mew observed. The problem is, developers prefer different tools from the ones they've been assigned. In fact, some are even ready to go back to no tools given the amount of time they have to spend

verifying AI generated code instead of simply writing it. Forget about tracing output levels. These tools have made their existing job more cumbersome. It doesn't end up mattering for companies because at the end of the day, adoption is much easier to track than real productivity. But it's likely to matter soon enough. With a shortage of developers who are actually qualified to comb through these large amounts of code and with newer coders never having built the skill in the first place,

soon enough there will be far too much code and far too few experts to fix it. A data engineer at a US-based startup told Runmay that new kids are learning to code with AI from day one. So, while they're good at generating average code, they're not as good at debugging. He explained that older engineers over time build an ability to suss out when something feels wrong. But for the junior staff, they'll always have AI generate the first draft.

They're unlikely to ever build the muscle. So they won't learn how to trace errors from first principles. And here's an example of what happens when someone's not trained to spot mistakes. Last year, engineers at e-commerce company Flipkart, who had been using GitHub co-pilot ended up with a wrong line of code. A senior programmer told Runmay that the bad code would automatically

empty customers' cards after they had added just five items. Lucky for Flipcard though, the same programmer caught the glitch just minutes before deployment. Considering the results from the Faro study, these aren't even anomalies. In a lot of ways, it's baked into how

LLMs work. Because there's also the fact that LLMs also work on the statistical average of what already exists, which means that the code you get from AI is well average, which is fine for recreating patterns or making one-size-fits-all code, but when you have multiple companies in the same sector fighting to stand out, differentiation is indispensable. There's a tangible gap between something that just works and something that's outstanding.

And that differentiation cannot come around if a strong, talented and proficient engineer isn't leading the charge assisted by AI or not. But if that same strong, talented and proficient engineer who makes the difference between average and outstanding systems is buried under millions of lines of code. If they are expected to catch and fix the mistakes made by others who never even learn to spot it themselves, it's unlikely that that creative edge in Spark is going to remain for very long. Because what also doesn't get talked about enough is that even these developers, those who are highly experienced, are increasingly relying on AI tools, which means that the skill set that is increasingly becoming

more important for the deployment of AI code is also slowly eroding. Luciano Nuijan, a lead developer, wrote a blog post wanting other developers to be cautious about making AI a key part of the workflow. He recounted how he had started relying on the AI tools provided by the software, his company because he had started to feel left behind. About a year later, he removed those tools from his workflow entirely. Why? Well, because while he was working on a personal project, when he didn't have access to his

company's provided tools, he realized that he had lost the instinct for tasks that used to be second nature for him. So this is what's at stake. The structural integrity of some of the most popular platforms we all use. and also the skill sets of the architects who prop it all up. It's an entirely solvable problem because you see, it's not like these developers are anti-AI. Even the 1500 Amazon petitioners were petitioning for Claude Code as an alternative. The problem lies in the fact that companies are prioritizing adoption to present nice looking numbers to shareholders and partners

and not the needs of their own engineers. So what is needed is a balance between quantity and quality and between mediocrity delivered quickly and real skill developed over time. Daybreak is produced from the newsroom of the Ken India's first subscriber-focused business news platform. What you're listening to is just a small sample of our subscriber-only offerings. A full subscription offers daily long-form feature stories, newsletters and a whole bunch of premium podcasts. To subscribe, head to the podcast. ken.com and click on the red subscribe button on the top of the Ken website.

Today's episode was hosted and produced by my colleague Rachel Vargis and edited by Rajiv Sien.