Why Genpact is warning about AI driving the mass-generation of technical debt

If you have been working in the tech sector for any time, you’ll be familiar with the concept of technical debt where you build up the cost of re-work in the future, by choosing an easy, sub-optimal approach now. 

The concept has increasingly been bothering me as I listen to claims being made around gen AI models for coders. Models are so easy to use and so fast to generate code, and yet, I wonder, will we soon be regretting the model generated code being created today?

 I turned to Rajesh Padmakumaran, VP of AI Transformation and Services at Genpact to pick his brains on the matter. After all he has worked for many years on customer application development and maintenance, building software using Java and other technologies. And he is currently building gen AI assets to help app developers.

Modernizing code with Claude

Padmakumaran explains how he has been using Claude with his team to help modernize systems:

We started with CoPilot on Open AI but Claude has a big content model and provides better results. We don’t use it for coding purposes but Claude can analyse and create scripts out of legacy apps such as Cobol to see what lies in the stack. We have undertaken two large projects – a database migration and a Cobol based migration for a bank, a system that was written in 1991 that was .Net based

We ran a small proof of concept on 800 lines of Cobol to understand the application. However, the real app had 10,000 lines and at that scale LLMs (Large Language Model) start to hallucinate, and will make assumptions about what words mean. It didn’t understand the app. Because the proof of concept was successful, we thought using an LLM might be the right response. So, we gave it to a subject matter expert to work with. Up to 5,000 lines of code was its limit before problems started to occur. We realised that to solve the problem we needed to explain in the prompts what the app did.

Padmakumaran says that the solution was to get a subject matter expert to group the code into sections and explain the functionality of each logical section. This is because the language model needs to be grounded with the processing, providing structured prompts to ascertain which line of code the model is referring to as its source. Another LLM is used to judge and score accuracy and generates a framework on top of the model.

Padmakumaran continues:

The model is the same, it is simply the pre-processing step that has changed to make sure the inputs are entered in the right way. Prompts are reusable to address code datasets. The framework is reusable and deals with 20-30% of the work in a project.

Over the last six months our work has been biased towards Claude because it is better on context. Some clients have OpenAI, but even so the framework remains the same and the same skills are employed. To be successful a model needs discipline and a framework.

I asked if theTrump 2.0 Administration’s classification of Claude as a supply chain risk to national security was causing issues, but Padmakumaran said that there had been no pushback amongst clients about using Claude so far.

Making the case for Spec-Driven Development

Back to the question of technical debt. Padmakumaran is a big advocate of Spec-Driven Development (SDD) with Claude Code as the approach, treating specifications as first-class engineering artifacts. Instead of asking AI to infer how the system should be built, teams define that explicitly before any code is generated. This is because AI hallucinations will happen if intent is implicit and so AI-assisted development needs to be anchored in deterministic specs and enforced through the CI/CD pipeline. In this way the pipeline is not just checking that the code compiles, it can also verify that the AI is honoring the intent of the code.

Padmakumaran explains:

There is still a problem in terms of developer experience – you need to be short and concise in explaining what needs to be done. Think about the developer experience as every tool now has an AI assistant, so as we have tool sprawl, we have AI assistant sprawl. Everything needs to be grounded to context so you should not just give developers tools. For example, there are different ways of using Claude using different prompts. Discipline needs to be applied across a team using the tool – this legwork still needs to be done.

At the governance layer for each tech product, you should use the same tool grounded in the same repository so that the LLM can judge by checking the pipeline itself like a traditional governance mechanism.

Developers need to ask why does my code look different to your code? The specs need to be written properly and the variables need to be defined. Are developers following the CI/CD pipeline? Otherwise, you are developing a big maintenance issue for the future. You need to define code and use pipeline validation. You need standard naming conventions to be applied for the architecture.

My take

Much of the AI governance discussion focuses on models, policies, and access control. As Padmakumaran explains, for engineering teams, the more immediate risk is simpler: unchecked AI can mass-produce technical debt. So, while AI can generate code at extraordinary speed, it is essential that engineers continue to define what good looks like.

He believes that Spec-Driven Development is how we preserve the responsibility in an AI-first world to make intent explicit before asking machines to execute it. I think we should all be taking heed.