In this conversation, Rachel Stephens is joined by Srini Iragavarapu, Director of Software Development for Amazon Q Developer, to discuss the evolution of AI agents in software development. Srini explains how Amazon Q Developer leverages generative AI and large language models to assist developers across the entire software lifecycle — from code generation to testing, documentation, and even large-scale code transformations — while keeping developers in full control. They also explore how these tools are transforming developer productivity, onboarding, and problem-solving.

This is a RedMonk video, sponsored by Amazon.

Transcript:

Rachel Stephens: Hi, everyone. I’m Rachel Stephens, and I’m delighted today to be joined by Srini Iragavarapu. He is the Director of Software Development for Amazon Q Developer. And today we’re going to be talking about the evolution of AI agents.

I think this is a really exciting conversation because I think we’ve seen a lot of change just in the way that developer tools in and around AI assistants and coding agents have changed just in the last few years.

So I think we’ve moved from a place where we just kind of had autocomplete assistants to kind of prompt assistants now to AI agents. And Srini has kind of been on the front line of all of this and is going to walk us through all of this.

Srini, do you want to just kind of give us a quick intro on what you’re doing and then we’ll dive into some topics? 

Srini Iragavarapu: Thank you very much, Rachel, for having me.

I’m very excited to be chatting with you and your audience about, you know, Amazon Q Developer, how we’ve evolved into a software development lifecycle generative AI assistant over the last few years.

And also be, you know, looking forward to talking about how our developers are actually using Q Developer and giving us the feedback and where the flywheel is built as well. 

Rachel: Yeah. Do you want to give people, just in case they’re not familiar with it, just a quick overview on what Amazon Q Developer is?

Srini: Yeah. Amazon Q Developer is a generative AI based software assistant. It helps not just in the coding aspects of software engineering, but the entire stages of software development lifecycle as well.

All the way from designing your applications within the IDE or the command line interface. Amazon Q Developer is also integrated into GitHub and GitLab for your CI, CD and DevSecOps tasks.

And Amazon Q Developer also operates within the AWS management console as well. So, to be able to operate your compute, to be able to deploy instances and manage all your cloud compute as well.

So, it is a complete lifecycle of software development lifecycle. And that is what Amazon Q Developer is packaged. And it provides various interaction points using generative AI that is based on Bedrock and large language models.

Rachel: So, I kind of started to lay this out, but I am really excited to just talk with you because I think you’ve been on the front lines of seeing how things have evolved in this space.

So, let’s talk just as someone who has been in this area of product development. How do you see the relationship changing between traditional coding skills and AI-assisted development?

How has that evolved? And particularly, models and tools have both become more sophisticated. The relationship between them has changed. How have you seen that change over the last few years?

Srini: If you really think about it, how engineers and software engineers actually program and build applications and maintain and manage applications has always changed consistently.

Going back when I was an undergrad, I did learn how to code in punch cards. Not that I ever had to do production-based punch card development, but I did actually learn how to do punch cards.

I understood binary programming language and then building UX-based applications was a different tooling set that we had. Over time, the tools for developers to be able to get there faster and build more creative applications to actually solve the problems for customers has evolved.

With the advent of AI, especially generative AI and large language models over the last few years, all the way from very small, I keep saying at one point or time, the large language model, which is a few years ago has become now a small large language model because the models have become much bigger in the last few years.

And the models also have a lot of other capabilities. There is reasoning capabilities, them being able to think and actually have a conversation with us. Once these LLMs became available, in our case, for Amazon QDeveloper, all of these LLMs are behind Bedrock.

Bedrock is the generative AI platform, independent of Amazon QDeveloper, where any customer can actually go build a generative AI application. And in Bedrock, we have multiple models.

You know, models from Meta. LLMA model is available. DeepSeq model is available. Anthropics, Sonnet models are available. And Amazon’s own Nova models are available. Now, what we were able to do when we started this journey was, to your point, started with inline coding assistant.

As you’re coding, think of it as IntelliSense. There was a point of time where developers were coding in pure, you know, terminals, or they were actually coding in Notepad or Sublime text editors, right?

VIM and text editors of sorts. Then came IntelliSense, where the code completions would be happening where the developers didn’t have to remember the function names based on class names. Now, you push that forward with LLMs.

What essentially started happening is inline code completions became a thing a few years ago. So you would be coding based on the context of your repo. Amazon QDeveloper would actually give you recommendations of the next few lines, either single line or multi-line completions, and the developers would accept them.

Now, the models are a lot more powerful. What that essentially means is you’re not only finishing code inline, you’re actually having them do tasks for you. And this is where agents come into play.

And you’re actually able to have conversations with the agent, in this case, and Amazon QDeveloper. So with Q, you can actually talk to it. You can ask it questions like, can you explain the repo?

You can ask it questions like, can you check my test coverage and update tests? And it will actually go through the whole journey of how to, you know, looking at your repo within VS Code or JetBrains or any of the IDEs, and actually build the code for you.

This is where the human in the loop, which is the developer, comes in. And they’re able to understand the code that is being generated and decide if they want to use it. And then go back and forth.

This is where the recent term around vibe coding started happening as well, where you’re vibing with. And when I keep saying vibing something, you know, I always picture me listening to Brian Adams on the back or Linkin Park songs on the back with my headphones on and the music happening.

And you’re actually talking to the Q agent as a peer programmer. Or just like how you talk to, you know, your peer who’s a software engineer or a paid programmer and then go through that journey. That’s the advent of how all of this has happened and where we are at this point of time.

Rachel: Yes. So very much the person is still part of the process of figuring out what code they want to include, how they’re thinking about it. And you see it as a human in the loop process still. 

Srini: Absolutely.

The creative aspects, I think what this is enabling is bringing out all the creative aspects of the developer. Now, instead of having to do mundane, boring tasks, and we can talk about them as to what, you know, where automation has helped and where these agents have been doing it to.

The developers can actually start thinking of what is a custom problem that I’m trying to solve? And how do I use Q to be able to solve these? 

Rachel: We probably, I probably should have started with this.

So one of my favorite definitions that I heard somebody say for what is an agent and the what is an agent definition that I like is 100 LLM calls in a trench coat.

But in terms of how do you help people understand agents in the context of like the kind of the developer context? Because I think sometimes when we’re just trying to help people understand this, a lot of people approach it from a different mindset.

Srini: As an action movie buff myself, when I think agent, I’m always thinking, you know, there is an agent that is actually tasked to doing things. What this essentially means is these agents are goal seeking and task oriented and essentially result oriented too.

So you provide them with a task and say, here is what I want you to do. Go do it for me. And if you want more information, ask me for it. Tell me what you’re doing.

And as you’re doing it, I’m going to give you guidance and tips so that I can steer you in the right way so that my goal of whatever that is, is complete. That is an agent. In fact, in real life, set aside, you know, LLMs or generative AI or Amazon Q developer, the agent, real estate agent that we have is the somebody that you say, I want to buy a house.

I want, here is my price range. Here is what my interests are, me and my wife and my family want. And this is what, and you have a conversation with them until you go end up buying a home. That’s essentially an agent.

The same thing here is happening too, where these agents, the software developer agents, in our case, Amazon Q developer has agents like test agent, review agent, documentation generation agent.

What these agents are specialized where you tell them to do something. In this case, you would say, update my tests as a starting point. And then the agent will look at what code do you have?

Do you have any tests or not? What programming language is it? If you should update the existing tests, you should fix the existing tests. What test coverage? And there is an iterative way of going back and forth with the user.

In this case, the developer and asking at the end, the outcome is your repo has better test coverage with more tests. And accurate based on the code as well.

That is just an example of how these agents work. 

Rachel: Gotcha. So if I were trying to summarize how you’re talking about agent interactions, it’s for a developer to be using this, you’re kind of giving it an outcome that you’re desiring.

And the agent is kind of going after it. And you’re seeing the result at the end, but you’re not having to go after each individual step and tell it the process.

Is that the right way to think about it? 

Srini: Yes. But just to add, the developer is in full control where you can actually ask it to say, walk me through how you’re doing this.

Rachel: Okay. 

Srini: Right. If you look at, there is a CLI, command line interface, version of QDeveloper 2 for terminal. In the Q, when you install that on your terminal and you use QDeveloper, and you start having this conversation with the agentic chat, it will keep asking you to say yes.

So yes, no, trust with all the, you know, that’s the options we provide to the user. You say, do you want me to continue? Do you want me to do that? So it keeps asking you. One option as you, as a developer has is to say, you know what, don’t keep asking me every step of the way.

I trust you to do the right thing. And then I’ll come back and tell you how to fix yourself. There is that way as well. So there is that iterative way of doing this. As an example, I’ll flip it to the other extreme. There is a transformation agent that we have.

What this transformation agent does, as the name implies, it is actually transforming your code from one version to another. In this case, we have Java upgrade transformation agent. So it can take any older version of Java to the latest version of Java 17 and Java 21.

And you say, hey, transformation agent, here is the set of repos that I have. Can you go upgrade and update all of my repos to the latest version? And it can actually do that with or without, depending on what inputs you give it.

It will actually complete the job and come back to you. 

Rachel: Very cool. So compared to previous generations of how a developer would have interacted with an AI assistant, it would have been a lot of prompting at each step.

And now it’s more checks at each step. But the agent is making kind of reasoning decisions along the way. And the developer gets to kind of be the checkpoint. Is that the right way to think about it? 

Srini: Because these models, the large language models, whether you’re using the Sonnet 3.7 in our case that we use in a lot of places, or you’re using Nova models or other bedrock-based models, they have reasoning capabilities.

What essentially goes back is not only are they answering a question, but they’re thinking about the answer and then fixing themselves and continuing to do that too. As you prompted to do, you know, continue doing as well.

Rachel: Gotcha. Wonderful. Can you give me, besides the example you just gave, do you have other examples of complex agent architectures that you all are building out in terms of how to think about prompting and tools that you all are building?

Srini: The three that I give you, and I’ll give you anecdotal real-life examples of how this is happening as well. Amazon, I’m like, you know, it’s a software shop in itself. We have, you know, thousands of developers internally building applications for our customers.

And we use a lot of Java. I’m like, there is, you know, we use a lot of other programming languages as well, but Java is one of it. So we actually used the Java transformation agent to update our own software internally and for external production applications as well to get to what upgrading the software.

What happened is we were able to deploy 30,000 production applications updated through using the software agent, the transformation agent.

And this is, I mean, like if you put it in pure math terms and the math we calculate, that’s around 4,500 years of software engineering savings. And $260 million of analyzed savings as well, one, because of the engineering savings, plus because you updated to the later version of the software.

What the next time they have, they’re, you know, performant and less buggy as well. Traditionally, what would happen is a team would take their code base and say, assign a small group of engineers to upgrade the software, spend a few weeks or a month to be able to do this or even longer.

They would manually go through the upgrade process and then test it out and deploy and then go there. Instead, in this case, the first step, which is a very boring task, who would want to be sitting and updating software?

No creative software engineer would want to do that. All of that has been automated for them. That agent can actually now update the software and then you as an engineering team or you as an engineer can figure out if you’re okay with all the changes, provide guidance and then finish back.

That’s one. The documentation agent is an interesting one that a lot of my developers in my own team actually leverage it as well because, you know, code churns really fast. Keeping the documentation updated and current to match the code is always a challenge for everybody.

In fact, that’s kind of where most of the software engineering teams would come in and say my documentation and my code, they’re not in sync because we have never updated them. The documentation agent can actually what it can do is if you can look your repo and you can ask it to say update my readme file.

If it doesn’t exist, it will create one. Otherwise, it will update the readme file. It creates a knowledge graph of sorts of your entire repo, uses the large language models and then updates the readme.md file.

And that’s one example of how we’ve been doing it, too. And we’ve seen a lot of customers go through, you know, using some of these agents and agent chat in the recent past. 

Rachel: So you mentioned SONNET before, you mentioned the LLMs kind of being underpinning of the agents.

And I think one of the things that we’ve noticed in the industry is the lines between the models and the agents have blurred. And before, the agents had to be really specifically designed. And then as the models have become more capable, they’ve been able to kind of pick some of that up.

How do you envision software development practices changing as both of these tools continue to develop and change over the next few years? 

Srini: There’s, I’ll answer this in two pieces.

One is you rightly called out how the LLMs and the agents, you know, the lines are getting blurry because the models are becoming more capable and they have the art of reasoning in them.

So where the nuance comes in is the tools that you provide to these agents so that they can pick up as the LLM is leveraged. You can actually say, you know, use one tool versus the other.

Semantic searches could be one tool that you provided and it looks at your code base. So there is various tools. I’m like, this is where now people started talking about MCPs and model context, you know, protocols and how you’re providing them as tools to these models.

So think of it as there is LLMs that can just answer and have reasoning capabilities and these agents that are built with specific tasks in mind where you’re feeding it the context and you’re feeding it the tools so that you can actually reason around it as well.

And that’s where the specialized agents are coming in. I’m like, in this case, we’re only talking about developer agents. There could be, you know, agents that are for shopping. In fact, you know, or you can have it in your health industry too.

You could build bunch on bedrock and you say, I have a doctor and I have a nurse agent where it actually diagnoses the first cut of the version. And all of that is possible because you’re providing with tools and the context as well.

So that line is good. I think it gets interesting to the examples that I gave you. I’m like, you know, SmugMug is one customer that has been using Amazon Q developer for the, you know, data science and engineering teams as well.

They’ve actually measured that their productivity went up by 100% compared to the prior workflows, you know, for data modeling because they’re able to do this. For me, the simplest one that I keep coming back to is with the changes that are happening and the tools that are being available through Q developer, the developers are actually getting to do what really matters most for their end users and customers.

I think the creative aspects, the problem solving aspects of what we’ve all been wanting to do for a long time. I’m like, since my day one of undergrad, problem solving has been the most important thing.

We are still continuing to problem solve it, but how fast we are able to solve it and how we are solving is what is changing with the adoption of these tools. 

Rachel: And that actually leads me right into my next question, which is, what do you think, so as the tooling changes, what do you think stays the same for the developers in terms of what essential skills continue to be the skills that developers need to have?

Like in our quiver, like what is a skill that continues to be like the core essential developer skill, even as AI becomes part of our tool chain? 

Srini: I’ll go back to some of the leadership principles that Amazon has.

The customer obsession, bias for action, you know, delivering results and getting things done. These are things that are not changing. They continue to exist. What we’re essentially doing is leveraging these tools.

I’m like, you know, as I mentioned earlier, all of these, you can automate these tools too. You can also say, I’ll configure it in GitLab and GitHub’s going forward where you start reviewing my code and updating my tests, essentially where we’re going.

But the human, the engineer or the developer is always in the loop for them to be able to interact with these agents and tools. So what is essentially happening is, one, you have to learn how to use these tools, you know, in your arsenal, the toolkit that you have, that you’re able to use them, just like every other tool that you’d use.

I mean, it’s not that this is any different. But the goal of why you’re using these tools, essentially, you’re going to say, I want to deploy an application for, you know, my customer or fix a bug set of bugs for my customers so that they, you know, problems are resolved.

That entire workflow also exists to be same. How fast you’re able to do that and the tasks that you’re providing. Again, I’ll go back to if the code were in an older version of Java or if the doc readme file doesn’t exist and I have to understand the code base earlier, what would happen is I would talk to a bunch of people in the team, tribal knowledge, or I would spend all the time to go through the code base to understand it.

Instead, in here, you could just ask Q developer, can you explain my code base? That’s a great starting point. It saved you a few hours right there. And so now you get to start fixing the actual set of issues or adding functionality and going through.

So the customer obsession, getting things done for the customers, that doesn’t change. Problem solving doesn’t change. What it changes is how fast you’re able to do this and how you’re able to do this as well.

Rachel: Yeah. Speaking of speed, though, like I feel like the AI market for a lot of people is churning a lot, like the number of new tools and new vendors that are coming into the market can sometimes feel overwhelming, especially if it is not your entire job to keep up with it.

Do you have any ideas or ways that you recommend people kind of learn all of these new skills or keep up with what’s happening in the space? So as you’re trying to be someone who keeps up with this market, how do you learn all this?

Srini: This is a good question. In fact, my own team and the developers actually go through some of this as well, even for a team that is, you know, at the cutting edge and forefront of building all of this too. As there is going to be a lot of such options and tools around, I would recommend and suggest identifying the trustworthy partners that you have to be able to follow them.

In this case, I’ll just come back to how AWS is set up. Independent of, you know, generative AI or LLM or Amazon Q developers, something that is almost guaranteed, this is in our DNA, we constantly do this all the time, is our focus for IP, our focus for responsible AI, our focus for availability, our focus for quality.

None of this is negotiable. And this has got nothing to do with Amazon Q developer or LLMs or Bedrock and all this. Even if you’re using S3 or Dynamo, we’ve stuck to that, you know, as our core ethos, that is one something that we have it ingrained in there as well.

The reason I bring that up is if you keep a few things constant, in this case, AWS being your trustworthy partner, Amazon Q developer that is a trustworthy partner, and then you’re starting to rely on these tools and you keep up with the changes that are happening, right?

Yes, you’re right. Models are changing. Bedrock will end up having a few more models than what we have today. By the time I’m sure this particular video recording is posted, there’s probably a bunch of changes that would have happened to the tooling and it’s already outdated.

Depends on how fast we do this. But staying with the trustworthy partners and keep leveraging them in your daily workflow. The other thing that we have also taken a stance initially, and we continue to do so, is we will build the solutions where the developers are.

Let’s say I’m a developer and I’m going to say, I don’t care for IDEs, VS Code or JetBrains. I actually do a lot of my work in the terminal. And there are developers like that. Absolutely, that is.

Or some people will say, I actually don’t use the terminal. I love Visual Studio Code and I want to be able to do this. Or somebody says, we use GitLab or we use GitHub, not other things around. What we are doing and focusing on is bringing Q developer to those entry points.

So that the barrier to entry or for you to keep up from learning a completely different thing altogether, which beats your workflow, like which kind of breaks your workflow, is something that we’re not doing yet.

We want to be able to integrate in your workflow where possible as well. 

Rachel: Yeah, I think a lot of people are trying to figure out just what the integration points are and how this all fits together and where it all comes in and definitely just what the ROI is on it.

Because I think a lot of people dove in headfirst a couple of years ago and then are trying to figure out what it all comes together at now. So it’s a process for people for sure. So I think and then I guess maybe that’s actually our closing question is just talking about that value.

So as you’re maybe the organization or the developers within that organization and you’re trying to think about just that value question of trying to maximize your value from your AI investments and from the tools that you are working on, how can you think about maximizing your value from your AI tools and from your engineers that are using them to make sure that you are both doing right by your engineers and also getting the most out of your AI tools?

How can you make that all come together in a good way? 

Srini: I’ll probably give you there is an anecdotal set, which I’ll use anecdotes from my own team. And then there is also some quantifiable metrics that have been published by customers, not necessarily as folks who have been using this for a while and actually started doing this as well.

The anecdotal part, a few months ago, this was I think last year, we had a set of new developers join the team. Traditionally, what we do when new developers join the team is you provide them with a bunch of documentation, onboarding buddy, and then give them time to ramp up on everything.

Assign them with small tasks and then get them going. It takes around, you know, depends on the engineer or the level of experience they have. But assuming a college kid joining, you know, the team, it takes them anywhere from two to four weeks to get onboarded.

That’s a general standard. What we have observed last year sometime was onboarding of these developers was actually happening a lot faster. They were able to resolve and fix issues a lot, lot faster.

That got us intrigued. And I was like, wait, is this something that, you know, we hired really different kind of people or something else happening? After probing, what really happened is they embraced the AI tools here.

I’m like Amazon Q developer in this case for their onboarding purposes. In fact, the wide coding has started happening there itself. And after talking to these three or four developers, it quickly became evident that they were actually, you know, I understand the code base faster.

I don’t have to rely on somebody’s time and I’m not getting blocked on it. I’m able to, you know, debug issues faster. So that sort of, you know, use cases started happening as well. The second anecdote that I have on my own team is how fast developers are actually churning proof of concepts and POCs and prototypes and their own custom applications for themselves as well.

It used to take while and take time versus, in fact, there was one developer who said, I was reading a PDF in my Mac. The Mac PDF reader isn’t something that I was comfortable with because apparently doesn’t have bookmarks or whatever.

He spent half an hour with Q developer and built a PDF reader himself. And he shared that PDF reader with everybody saying, hey, anybody wants to use it? I don’t know anybody used it though, but he continues to use it as a use case. There are, there is that.

I’m like the, another, yet another example I’ll give you is the, the Amazon Q developer plugin for JetBrains, which is written in Kotlin, actually has Q developer code that it has.

So the developers who are building this plugins are leveraging Q developer to generate code and, you know, build features as well. So these are anecdotes. This is how they’re embracing it. And the, you know, the productivity is improving and this time to deployment and time to resolution is going faster as well to be able to do this.

Some of the examples, like, you know, as an example, Deloitte saw like 40% increase in their development speed and 70% reduction in unit testing of a project because of, you know, adoption of Q developer as well.

ADP as a company went from weeks to days for documenting their entire project. SmugMug, I kind of gave you an example. Amazon itself used Q developer internally for the 4,500 year savings as well.

So each team and company is also measuring their improvements and productivity. And it means different things. I’m like anybody who’s gone through the Dora metrics or space metrics understand.

Developer productivity means different things for different teams and cultures and organizations. So we’re able to measure them, the speed to deployment, time to resolution, onboarding developers, the first merge request happens, the speed at which the first merge request is happening, how many iterations of the code reviews are happening.

All of these are measurable and that’s where most of the impact is being seen. 

Rachel: Those are really great examples. And even though they’re anecdotes, I think they’re really powerful anecdotes.

So thank you so much for sharing. Well, Srini, it has been absolutely delightful to chat with you about this. And I think it’s been a wonderful and enlightening conversation. And I appreciate your time. 

Srini: Thank you very much. Wonderful chatting with you. Really appreciate it.