The first productivity problem that Ian Eshelman, Chief Technology Officer at Kobie Marketing, encountered with AI-assisted software development was not that the technology could not generate enough code, it was that engineers were struggling to review everything it produced.
Developers believed they were moving faster, but the increase in AI-generated output was creating a bottleneck further down the development process. Human reviewers could examine only so much code, undermining the productivity gains that appeared to be accumulating at the point of generation.
“The engineers thought they were actually running much faster when, in actuality, they were producing less because they were spending so much time generating review,” says Eshelman.
The experience exposes a central tension in enterprise AI adoption. Generating software faster does not automatically translate into delivering it faster. Code must still satisfy requirements, pass tests and meet security expectations. As generation becomes easier, verification can become the constraint.
For technology leaders, this complicates the conventional case for AI-led productivity. The question is no longer simply how much work a machine can perform, but how much additional value an organisation can extract from the work it produces.
For India’s global capability centres, where access to engineering talent has traditionally been a major consideration, the implications extend beyond the adoption of new tools. As AI takes on more implementation work, the value of an engineering team increasingly rests on its ability to define problems, make technical decisions and take responsibility for outcomes.
The productivity equation is changing
At Kobie, the initial response has been to prioritise the completeness of software over the speed at which individual components are produced.
Eshelman points to behaviour-driven design and test-first automation, established software engineering practices that have often proved difficult to implement consistently. AI is making it easier to build more comprehensive testing and regression capabilities into development, improving the company’s ability to assess changes before they are delivered.
“I think that’s our first horizon,” he says. “Instead of just building this component, fully building out this component in the same time, then we’ll start shrinking the time component that it takes to go build that over time.”
The distinction matters. If AI allows engineers to deliver a more thoroughly tested component within the time previously required to produce a less complete one, the benefit may be substantial even before development cycles become shorter.
Kobie measures the effort required to build features, including the hours needed to complete work that has been relatively sized. The company examines whether comparable tasks are becoming less effort-intensive, while recognising that measuring the business value created by that work remains more complicated.
Eshelman acknowledges that his assessment of AI’s impact has changed over the preceding six months and may change again. The technology’s benefits are still being evaluated, rather than reduced to a single productivity figure.
That uncertainty is important. It suggests that technology leaders need to distinguish between AI’s capacity to generate output and its demonstrated contribution to the performance of an engineering organisation.
Why more AI spending does not guarantee better results
The same measurement problem appears in the economics of AI itself.
Kobie tracks token consumption across developers to understand whether greater use of AI models translates into better engineering outcomes. Rather than imposing fixed limits on individual developers, the company is examining how usage relates to productivity at the individual and team levels.
Eshelman says the results do not show a consistent relationship between higher token consumption and proportionately greater value. Some developers consume substantially more tokens without delivering commensurate gains. Others derive useful benefits from more moderate usage.
DevOps presents a notable exception. Eshelman says Kobie has observed strong results from higher token usage in infrastructure automation, helping the company generate capabilities it did not previously have.
The difference illustrates why AI returns cannot be measured through consumption alone. The value depends on the work being performed, the capabilities unlocked and the outcomes achieved.
For engineering leaders, the challenge is to understand where AI is reducing effort, where it is improving quality and where it is enabling work that would otherwise have remained impractical. These are related but distinct benefits, and treating them as interchangeable risks overstating the productivity case.
Engineering talent beyond implementation
As AI changes the economics of development, it also changes what Kobie expects from its engineers.
Eshelman does not believe software engineers will disappear. Instead, he expects their responsibilities to shift as AI agents take on more of the implementation process.
“I think it changes what they do, but not necessarily who they are,” he says.
The emphasis moves towards deciding what should be built, defining requirements and determining how a solution should differentiate itself. Eshelman points to emerging AI engineering roles focused on building agents, alongside responsibilities centred on managing those agents.
This is where the implications for India’s GCCs become more pronounced. If implementation becomes increasingly automated, simply expanding the number of developers may not be sufficient to build a differentiated technology capability. Teams will also need the expertise to design systems, evaluate AI-generated work and make decisions about the problems worth solving.
Kobie’s India technology hub reflects this approach. The company established the hub in July and had approximately 50 people there at the time of the interaction, including AI engineers, data engineers and cloud engineers.
Eshelman says the intention is for teams in India to own design, architecture and implementation for their assigned technology domains, rather than merely execute work designed elsewhere.
The company is working towards an approximately equal split between the US and India within its technology organisation. Its operating model divides the loyalty platform into domains, with teams in each location accountable for their respective areas.
The distinction is between distributing work and distributing responsibility. In the latter model, a team is expected to own a domain rather than complete one part of a development process before handing it to another location.
As AI changes how software is produced, that form of ownership becomes particularly relevant. The value of a team increasingly depends on its accountability for the resulting system, not simply the volume of code it delivers.
Autonomy still needs accountability
There is another complication. AI agents capable of executing workflows require boundaries around what they can access and do.
Kobie uses a builder, checker and validator model in its development workflows. One agent builds, another checks whether the output works correctly, and a third verifies whether the requirements have been fulfilled.
The company is also restricting the information available to agents. Eshelman describes an internal Model Context Protocol server that removes personally identifiable information before passing information to an agent.
“We didn’t want to say, hey, give the agent the same ability that that human has,” he says.
The approach reflects the importance of separating an agent’s ability to perform a task from its authority to access information or make decisions. More autonomous execution does not remove the need for controls, validation or human judgement.
For technology leaders, these responsibilities are becoming part of the same engineering equation as productivity. Faster generation has limited value if the resulting system cannot be verified, governed and trusted.
The question confronting India’s GCCs is therefore not simply how quickly their engineers can build with AI. It is whether they can combine human judgement with automated execution to deliver more complete software, establish meaningful controls and own the outcomes.
AI may make writing code easier, but making the resulting technology reliable, useful and accountable remains an engineering challenge.