AWS uses Agentic AI to pay down technical debt

Earlier this week, I declared that to realize meaningful ROI from agent development, the technology industry needs to consider enterprise-wide use cases, rather than focusing on the current fad of individual productivity agents. An article has been published. This isn’t all that surprising. There’s an argument to be made that investing in enterprise-grade applications, if done well, will yield greater economic benefits for the company.

At this week’s Amazon Web Services re:Invent conference, customers are sharing best practices in their transition to agenttic computing. However, these customers are typically leaders in their market segments who are considered innovators. What about companies that are large but not necessarily innovative? Or companies that want to innovate but are held back by mountains of legacy technology and technical debt?

AWS seems to be thinking a lot about these companies.

Legacy apps are a serious business problem

First, it’s important to understand the reality these companies face. Despite the rise in CSP adoption of AI and machine learning solutions, the majority of IT spending remains on-premises. On-premises is pegged at approximately 55% to 60% of total IT spending. Some analysts predict that due to the growth of AI, the share of CSP will exceed 50% this decade. Whether or not it reaches this number, CSP clearly has a lot of room to grow. But you also need to understand that the last 50% of opportunities are much more difficult to achieve than the first 50%.

Several key industry statistics back this up. At the recent TBM 2024 conference, McKinsey said that 75% of all IT costs come from servicing legacy workloads. This amount is consistent with other estimates. For example, IBM Consulting recently stated that 70% of enterprise workloads require modernization. Compounding this problem is that IT outsourcing and the evolution of the IT workforce have made it difficult to maintain a heavy base like legacy applications. All of this means that while AI and other technologies are innovating rapidly, many companies don’t have enough capital or skills to effectively leverage them. If these legacy apps are not addressed, opportunities for innovation will be further reduced in the future.

It’s clear from many conversations and what we saw at re:Invent this week that AWS is keenly aware of this reality. In fact, AWS, the world’s largest CSP, understands that it competes not only with other CSPs, but also with enterprises that choose to keep workloads, especially legacy workloads, within the confines of their own datacenters. .

AI tools need to go beyond code translation and incorporate change management processes

With Generative AI Developer Assistant making headlines this summer, many vendors were talking about transcoding. Common examples were upgrading from Java XX to Java 17, or upgrading from .NET to Java. Again, these features improve productivity for individual developers, but what is needed is something more aligned with a software development lifecycle approach.

That’s why AWS recently announced a new set of agent transformation features in its Q Developer product aimed at helping you drive high-impact software transformation projects. Q Developer now goes beyond the typical integrated development environment and considers the entire lifecycle. For example, what happens if your application’s documentation is so bad that the developer who originally joined the project is no longer on the team? You may need to In addition to recompiling your code, you may also need to incorporate code reviews and unit tests into your process. This is the kind of challenge that AWS officials are clearly thinking hard about.

The agent development style is about more than just performing a single task. Q Developer’s functionality aligns well with how I defined agents in the article I published in September. Rather than a single agent asking a single LLM to perform a task, Q’s smaller transformation agents can collaborate and autonomously enlist other agents and LLMs as needed. This is possible thanks to Q Developer’s integration with Amazon Bedrock, and these key agent features allow you to complete much more complex tasks and processes.

The cloud is a solid infrastructure foundation

The challenge with this type of conversion is that beyond the scope of upgrades between versions, the project becomes more complex. Again, Q Developer addresses this complexity with this new agent approach. Let’s start with challenges that are an order of magnitude more complex, such as migrating from .NET to Java. Such projects may require decisions that have significant long-term cost implications. In this example, Q Developer goes beyond converting the .NET code and considers many other infrastructure improvements that can be made depending on your application. For example, could you leverage serverless computing for some components to reduce costs? In addition to migrating the code, why not migrate the underlying data to a new database such as MongoDB or Postgres? ?

AWS also announced that this approach will also be used for more complex infrastructure migrations. This includes moving from VMware to containers or from monolithic COBOL-based mainframes to distributed stateless architectures. These are all features that Q Developer currently has or is on the roadmap. AWS uses an agent approach to take a more holistic, architecture-driven view of some of the most demanding migration tasks. This should not only reduce the time required for these tasks, but also improve the long-term operation of migrated workloads.

These new agent capabilities can create exciting opportunities for transformation, but they all require a reliable and secure global infrastructure. Fortunately, AWS knows a thing or two about its infrastructure.

Creating operational processes

One of the historical challenges of this type of lift-and-shift project is that it is a one-time, ad-hoc event. This poses a major problem for those trying to justify their efforts to executives. First, the ROI case is typically built on future cost avoidance, which is often difficult to measure given the number of years it will take to realize cost savings. Second, once a project is initially completed, there is always the fear that the work will be considered “done” and not be picked up again until the next big upgrade event.

The advantage of using generative AI is that once a project is automated and completed for the first time, the agent can be called multiple times to keep the application up to date. You can also expect each update to become easier to perform as the time between future upgrades gets shorter.

But you might not just need to go through the same process next time. Once you have a reliable path to keeping things up to date, you can offload a significant amount of work to non-development resources. A great example of this potential is the web interface for Q Developer’s transformation capabilities, which is designed for use by DevOps staff. For example, future lightweight scans may only require in-place upgrades and CVEs. In that case, updates can be scheduled and performed with minimal human intervention, rather than using a labor-intensive approach for initial migration efforts.

AWS brings mature AI-driven thinking to classic problems

This is the type of AI productivity that has a huge impact on IT budgets. My observation is that technology companies like AWS are beginning to understand that for generative AI to deliver demonstrable value, a shift in thinking about business impact is required.

The good news is that there is now an opportunity and way to do just that. Through Q Developer, AWS is finally creating enterprise-specific “factories” that automate IT transformation. In many ways, this degree of modularity and automation is similar to how cloud service providers like AWS achieve high scale with their cloud infrastructure. Now they’re taking that idea to their customers’ pre-cloud apps.

It’s not IT Nirvana, but it’s a big step forward

While this sounds great, we recommend that you need to be firmly grounded in some practical realities before adopting this approach. These migration projects have historically been difficult to execute, and AI won’t magically make them “easy.” Keeping this in mind may save you some pain and risk. Here are some important considerations.

1. Time and effort will not be reduced to zero. Numerous demonstrations position AI as a way to reduce working hours to seconds and, in some cases, enable jobs to be redefined or eliminated. But a better way to think about this kind of transformation is to compress years into months. Despite the potential huge benefits brought by AI, there’s a good chance that solving problems and rolling out new services will still require a lot of heavy lifting.
2. You will always have some legacy. I have experience migrating legacy software myself, and sometimes I find that some of the code I still need simply works best on the old infrastructure. Therefore, when rebuilding, it may not be practical to completely eradicate the legacy codebase. But we can probably still get pretty far.
3. Consider your sources and motivations. Agent applications are exciting, and despite all the possibilities they represent, what we see today is still something of an installed base capture exercise. For application platforms, the goal is to incrementally increase revenue per user or simply add more users. For Q Developer, there is a huge opportunity to transform and optimize enterprise applications, potentially resulting in significant cost savings, but the deployment target is still the AWS Cloud. This in itself is not a bad thing. A reminder that all long-term costs and trade-offs must be considered when choosing a solution.

For companies struggling with high technical debt and legacy overhead, agent capabilities like Q Developer can be very attractive. And the biggest benefits may come from adopting a mindset of continuous health rather than a singular focus on getting healthy that fades over time.