GCCs in India are moving from service delivery to product building; developers need to follow

For years, global capability centres, or GCCs, the India-based arms of multinational companies that handle everything from engineering to finance to customer support, were seen mainly as cost centers, extensions of a parent company built to deliver technology, not shape it. 

That framing no longer holds, said Kewyn George, an AI and GCC leader, speaking at DevSparks Chennai 2026 about how India's GCCs are becoming hubs for products, platforms, and innovation, not just delivery.

George's session, titled ‘From code to business impact: What are GCCs really building in India?’, centered on developers as the group driving this shift, and what it demands of them.

How GCCs are using AI

George pointed to three changes under way across GCCs. The first is automation: he estimated that 50-60% of GCCs are automating repetitive, high-volume work such as service desk tickets, tasks that once required constant human handling. 

The second is ownership. Rather than building a small piece of a global product, some GCCs now develop entire systems end to end, George said, citing an example of a GCC that owns the full development of a credit management system for a banking client.

The third is the accelerated hiring of AI engineering talent, though George said what these teams should actually build with that talent remains unclear for many organizations.

Much of this activity, he said, is driven by FOMO, both multinational companies competing to set up GCCs in India, and GCCs racing not to be left behind on AI.

Some of that urgency has produced real results: George pointed to companies running two distinct kinds of AI use cases, ones that directly touch revenue, where the return is visible, and ones aimed at internal productivity.

What GCCs should keep in mind

George's central caution was what he called the "pilot graveyard": hackathon wins and proofs of concept celebrated once and never checked on again. "It's imperative that people at GCCs think about longevity while taking an incubated idea to a solution. That's the biggest gap."

An idea that looks strong in a controlled pilot, he argued, still has to be tested against real, ongoing use, shifting business needs, and whether people stay excited about it once the novelty wears off. A strong pilot doesn't guarantee that.

He linked this to a common pattern at GCCs: teams build what they think is the right product first, then try to sell the business on adopting it, backwards, in his view. Instead, he said, engineers should be talking directly to business and customer teams and spotting problems themselves, rather than sitting back and waiting to be handed a formal requirement.

What this means for developers

That shift in what GCCs are building changes what they need from the developers building it. George said those developers don't share a common starting point and fall into three distinct generations. First, those trained on legacy systems like mainframes, second, those who came up through Java and similar languages; and last, a newer generation entering the workforce having learned to code directly with AI tools. 

That third group worries him. "These people will completely lose their logical thinking and systems thinking," he said. What carries over from one technology shift to the next, he argued, isn't fluency with any single tool; it's the underlying ability to solve problems.

That distinction, he said, is why knowing how to prompt an AI system well isn't enough on its own. George illustrated it with an interview he had conducted for an AI architect role. After the candidate confidently ran a complex prompt, George asked him a basic follow-up: "Explain to me what's happening behind the prompt. What is the system doing?" 

For George, that gap between operating a tool and understanding it is what separates a real AI engineer from a developer who has simply learned to use AI well. Knowing how to code, or how to build an app with AI's help, isn't the same as being an AI engineer, he argued.

On concrete skills, George laid out five areas he expects to matter most. The first is AI engineering itself, requiring product knowledge, process knowledge, business knowledge, and technical knowledge together, not technical skill alone. 

The second is AI configuration engineering, customizing large language models to an organization's specific needs. The third is AI infrastructure, the systems these models run on. 

Alongside these, he said, governance, risk, and compliance, along with cybersecurity, are also scaling fast as GCCs expand their AI use, and will account for a growing share of hiring.

George closed with a caution about entry-level hiring. With routine tasks increasingly automated, he estimated that only around 30% of engineering graduates are likely to be absorbed into strong roles at GCCs in the near term, with the rest needing significantly more preparation, starting well before their first job, to compete.