Beyond Code Generation: Where AI Creates Value Across the SDLC

AI has already changed how quickly software can be built. Until recently, much of the excitement was around using AI to create prototypes or small applications. Today, AI can take a new application much closer to production grade, speeding up the development process significantly.

But code generation is only one part of the software development lifecycle. From requirements and business analysis to technical design, development, testing, release, and ongoing maintenance, software moves through a much broader chain of activity before (and after) it reaches production.

That is why faster coding does not automatically translate into faster software delivery. BCG estimates that coding accounts for only 10–15% of the time from when an idea enters the queue until the product reaches customers. In BCG’s early GenAI pilots, developers generated code faster, but overall time-to-market changed little because constraints remained elsewhere in the lifecycle. McKinsey notes that coding assistance is becoming table stakes and as coding accelerates, bottlenecks begin appearing in other stages such as code review and product management.

For large enterprises, there is an additional reality. The bulk of the software work is not about building new applications from scratch. It is maintenance: supporting, changing and upgrading applications that have accumulated over years and are often deeply integrated with one another.

This is where the harder problem begins. AI can increasingly generate or translate code. But can it understand why an application works the way it does, what business process it supports, what other applications depend on it and what might break when something changes?

The constraint is no longer code generation

Current AI tools can translate or recreate code remarkably well. What they cannot reliably infer are all the boundary conditions around an application: business rules, dependencies and integrations that cannot always be understood from code alone.

That explains why many enterprises remain cautious about modernization. The concern is not simply whether AI can rewrite the code. It is whether the organization knows enough about the application ecosystem to change it without disrupting the business. Given that most enterprise applications are built across different generations of technology and carry years of business logic that may no longer be adequately documented, that context is harder to build.

We are seeing this problem firsthand with a financial-services organization.

The company has 12 key systems supporting different areas of banking. Some applications are written in a proprietary fourth-generation language, while others contain Java code that is 15 to 18 years old. The applications are running well, but maintaining them is expensive. The proprietary technology is difficult to support, specialist expertise is limited and all 12 systems are integrated with one another.

That interconnectedness makes modernization particularly difficult. Modernize one part without understanding the rest of the ecosystem, and something elsewhere may fall apart.

Traditional modernization proposals have estimated roughly 24 months to transform the estate. For the bank, that introduces another problem: how does it continue introducing features and responding to business requirements while a two-year transformation is underway?

We are solving this by first building the ontology and knowledge graph for the application ecosystem. That may itself require six to eight months because AI has to reconstruct context from incomplete documentation, non-standard code, and fragmented institutional knowledge. However, once that context has been captured, the organization has created an asset that can support both ongoing maintenance and future modernization.

Building the context AI needs

The objective is no longer simply to convert old code into new code. For AI to create value across the SDLC, particularly in complex enterprise environments, we need to reconstruct context and teach AI how the enterprise application actually works.

By bringing together code, documentation, architecture diagrams, process definitions and design artefacts, enterprises can begin building an ontology of an application – mapping the relationship between the technology and the business process it supports. A knowledge graph can then capture that context in a form AI can work with.

Once that layer exists, the possibilities expand significantly. AI can support maintenance of the existing application, assess dependencies before changes are made, and eventually enable forward engineering into newer languages or architectures.

Extending AI across the SDLC

This context layer also changes how organizations should think about AI personas across software delivery.

A Business Analyst agent can work with richer knowledge of existing processes and requirements. A Tech Designer can evaluate proposed architectures against known application dependencies. Sprint planning can incorporate the likely downstream implications of change rather than treating every requirement as an isolated ticket. Knowledge Assistants can provide engineers with application-specific answers instead of generic technical guidance.

The same context can strengthen Test Engineering by identifying scenarios around business rules and integration points that might otherwise be missed. DevSecOps and release-management agents can evaluate changes against known application relationships before code reaches production.

In other words, the opportunity is not a collection of isolated copilots. It is a connected AI layer spanning requirements, design, development, testing, release and maintenance.

From one application to reusable enterprise intelligence

The longer-term opportunity is even larger. Ontologies do not have to remain application-specific.

A loan-origination ontology, for example, could provide a reusable foundation across financial-services environments. The same principle could apply to processes such as purchase-order generation or invoicing in manufacturing and CPG. Enterprises would still bring their own data, systems and business rules, but they would not necessarily have to reconstruct the entire process context from the beginning.

The work around application context, ontology and knowledge graphs is still evolving. We are building these capabilities into K-Fabrik – our unified enterprise AI platform. This reusable platform can then be taken across customers rather than solving every AI use case independently.

For organizations whose code itself represents intellectual property, deployment architecture becomes equally important. A fintech, for instance, may not want proprietary source code flowing through public AI services. Running these capabilities within a resident AI environment (inside the enterprise boundary) can allow organizations to apply AI to sensitive application estates without relinquishing control of their code and data.

The next frontier in AI-enabled software engineering will therefore be determined by more than how quickly an AI assistant can generate code. The larger advantage will come from how well AI understands the systems, processes, and dependencies behind that code. Once enterprises can build and preserve that context, AI can move from accelerating individual development tasks to changing the economics of the entire software lifecycle.

Author:

Ashish Agarwal,
Vice President, ITC Infotech