AI Leadership Insights: David Pessis on Developers Using GenAI

Hello and welcome to the latest edition of the Techstrong AI video series. I'm your host, Mike Bazar. Today we're with David Pessis, who's director for Gen AI for Amazon Q and Quick Site Business.

Is that right? You got it. Excellent.

There we go. And we're talking about how Amazon's internal developers are using Gen AI and Q specifically to kind of well make their life easier, build software faster, and maybe am generally less. David, welcome to the show.

Thank you. A pleasure to be here. Your teams have been using this technology longer than anybody else, I'm sure they've had exposure to it before it was even formally launched.

Um, what have you guys seen now? I mean, as you look back from what your initial expectations were, what are you seeing among your developers? What kind of productivity gains are there and what do you know now that you wish you knew that?

Yeah, you know, it's, it's been an interesting journey. Uh, in the beginning. Our engineers, you know, we like to eat our own dog food, right?

And so as we're developing building these products, our engineers are using these products to make sure that they're actually adding value and helping them be more productive. We started off with a Q developer, which is our tool to enable developers write code, build code, um, update code faster and more recently, what we're gonna talk about here today is Q Business. Q Business is a generative AI powered assistant that allows you to load, load very sophisticated technical documentation, um, large amounts of documentation, and allow the engineers to quickly get insights into that data, uh, much faster than they would be able to otherwise.

And a lot of the time, that is the thing that trips everybody up. It's that the requirements docs are somewhat off or skewed in a way that somebody didn't understand. And there's a lot of back and forth and time that gets wasted and frankly just that reduces the time to actually writing the code or creating the code that's driving the application.

So how much of what we need to think about here when, when it comes to Gen AI might might be beyond just code writing? Yeah, so what happens is when you think about an organization like AWS, we have a lot of products and a lot of these products are built on top of each other, right? That naturally happens and there's a lot of really awesome documentation across a lot of these teams.

It's impossible for these teams to have perfect communication with each other. And it's, when you get to these larger organizations, it's becomes, you know, a little more difficult to share information. But now what we did was we curated the best of the best technical documentation across every single organization in AWS.

We loaded them into Q business so that they were indexed. And now any engineer within AWS can ask a question, you know, about any service internally and immediately get answers. And so instead of finding that principal engineer on the other side of the world that knows the details of this, of this API, the engineer can ask that question and instantly get an answer to that question.

Uh, we feel that we have field it around a million questions from engineers over the last couple months. Um, saving, you know, the estimates are now 450,000 hours of dev time just by engineers instantly be being able to get answers to those questions in A way. Sounds like you've captured the institutional knowledge and you're not dependent upon one developer being around who may at some point have left the company or may be on vacation or at a little late game or whatever it is.

But does that kinda reduce the cognitive load for everybody involved? Because I'm not standing around waiting for somebody to answer my question and that somebody may resent the question in the first place 'cause they got other things to do. You know, it re it absolutely reduces the cognitive load.

The other thing that you see happen is you have, when you have a, a really strong engineer, everybody's always going to that engineer, how do I do this? How do I do that? And so when you have a workforce like ours that's, you know, distributed across many regions around the world, um, that dependency on that single engineer also becomes much easier.

So the pressure is off of that engineer to talk to everybody. They're more efficient and everybody else is more efficient because they can kind of capture that knowledge that's inside of that that was inside of that engineer's brain. I would also say that, um, I think what, you know, you asked earlier in this discussion, what have we learned?

And really curating the best of the best documentation and making sure you're putting the best stuff, uh, in Q business, um, really helps deliver better results. And so that curation that we did, finding the best documentation across all of these areas and across these products, has really enabled us to build a really successful product to impact our engineer's productivity. I mean, when you think about it, we kind of punish engineers for being great at their job.

'cause then we make them the ones that everybody wants to talk to and then they can't actually go on and do anything else. Yeah, Yeah. Right.

That's it, that's exactly right. The the best engineers that asked a lot of questions, uh, that's just how it goes. And hopefully this helps or this helps everyone.

Again, it helps the best engineers actually do more coding and do the things that they love and helps the newer people ramping up get access to data that they could frankly never get access to before. And it this quickly and this efficiently. Has it become, or will it become easier to also understand like if I change something and I change it in the documentation, can I understand the dependencies that might exist that I would not otherwise be aware of?

And I might get some sort of alert that says, well of course we can do that, but just realize that these 12 things downstream may change. Yeah. So, so what happens is when you ask a question, so that document will go in the system, it will get indexed, but when you ask a question q business will know, um, which documents to weigh more based on recency, potentially based on who's the person to upload the document.

But when I get that answer, it'll say, Hey, you know, this is, this is version one of the API heads up. Here's version two of the API. It'll actually link both, both of those documents.

It'll actually give the developer the insights that they need to see both versions. Now the reason that's important is because of things like backwards compatibility, right? You don't want to eliminate that older documentation 'cause people might be on that, but might still be using that version of the API.

And so you need both, but you want the the assistant to be smart enough so that the end user knows that, Hey, there's version A, version B, B is the more recent one. Make sure you using this, but also be careful with version A. And that's how we solve a lot of these.

And those references are built into the response given to, to the developer as they ask questions. Will it also become simpler to stay current on different versions of things? So if I have, you know, the latest version of Java, I'm be much more inclined to upgrade something because it won't be as big a heavy a lift as it might otherwise have been in the past.

And this is part of the reason why we have so many older versions of things that are less secure than we like, just because it was too big a heavy lift to modernize it. That's exactly right. And so the pace at which we are able to update our code bases, uh, you know, you saw there was the article previously on queue developer on how I, I can't remember the exact number off the top of my head, but it was like 70,000 people hours updating code to the latest versions of Java.

And that is so important, right? To get us to these later versions that are more secure, that are safer, less divergence in code bases, uh, makes us just frankly more efficient and able to move even faster. And so this cumulative effect of getting all these code bases up to date, um, better code, more efficient code, more consistent code across applications, mm-Hmm.

How smart will all this get? I mean, in my mind we're starting to see the rise of these various types of AI agents, but um, how would that all get orchestrated across a complex set of tasks? I mean, if I look inside a queue, it seems like we're heading in that direction, but how do the other agents all know about each other and how do they tell us about what each one is doing?

Yeah, you know, I think that it's very interesting times. Uh, it's a very, very early in this journey and I think this agent, this agent based architecture where agents are talking to each other, uh, multiple agents might be writing code, but then going to read the documentation of current architecture and going to continue to write code and find bugs. Uh, I think it's just the beginning.

I think that orchestration layer is gonna be critical. Um, how do you make it so that our customers can feel safe and feel secure when these agents are potentially writing code and adjusting code? Uh, I think it's early.

I think that, um, the way that you make these, the key to making this successful is these agents need to be able to talk to each other in a way that's safe and secure. That's super, super important, right? Like one agent can make changes to things that it doesn't have access to.

And the way we're designing our systems from the ground up, um, safety and security first is super important. And so that kind of lays the foundation, uh, for us to actually be able to build these systems and orchestrate these agents to build code. But again, it's just the beginning.

Mike, How have you seen the developers and software engineers respond to all of this? 'cause early on, at least, there was always a lot of concern or conversation about my job's going away, somebody's moving my cheese and you know, all kinds of bad things are gonna happen. But as you get into it, where where are they fighting their joint?

Yeah. You know, one of the things that, you know, this is the say that I like, is you're not gonna lose your job degenerative ai. You're gonna lose your job to the person next to you using generative AI and what we believe is gonna happen.

It, it's gonna make you much more efficient. It's gonna make you better at your job. It's gonna help you get things done that are boring and monotonous that developers don't like to do.

Such as writing documentation, looking up documentation, writing test cases. The Gen AI is gonna just help them be more productive and more efficient so that most engineers can focus on the stuff that they love when it's building new capabilities and building new features. And so again, we think it's a product productivity gainer, a force multiplier.

And I think is the more and more engineers use these tools to help them be more productive. They're seeing that and it's just being, it's the way that they do business, right? You think about the late nineties, right?

The internet became the way that you did business and the way that you built software. And today it's the same thing. Like you're going to use generative AI to build software and it's gonna make you better and more efficient at your job, Right?

And a lot of that comes back to there's a lot of aspects of being a developer or a software engineer where it's just not fun. It's a lot of maintenance work, it's a lot of technical debt. It's, uh, working through various updates to, to-do lists and all that stuff kind of gets in the way.

So I mean, are we gonna get to the point now where maybe not only are we writing code faster, but we're better at solving the problems? 'cause we're gonna have more time to actually think about it. Yeah.

You know, some of the, some of the ways you'll hear people talk about it is, you know, the, the gen AI is your, is your body to bounce ideas off of, right? And now you can have thousands of these things to bounce ideas off of. And so I do think that again, it's gonna help eliminate the toil in your everyday job and help you do the things that you're really passionate about.

Um, and you're gonna have a buddy to brainstorm with and work with and help you write code and help solve these problems in ways that I also think we can't imagine yet. And so it's super exciting. You know, I think the combination of things like Q Developer to help you write code and update code and secure your code and Q business to help you get access to knowledge that you never, that not that you never could before, but you allow you to get access to knowledge faster than you ever could before and more efficiently than you ever could before.

It's gonna change the way software is developed for a very long time. So what is your best advice to folks about how to introduce all this into their organization? And do I just kinda like throw it over the wall and let 'em test and experiment?

Or is there a more rational kind of thought pattern or plan than I should be following? I think if you, if you look back, you know, late 23, early 24 even by the way that feels like in Gen AI years, that's like 50 years ago. But what people were doing was to what you just said, opening it up and just dumping and get, dumping it on their organization and say, Hey, go figure it out.

Go play with it. And, and that wasn't a good strategy. Uh, part of it was resistance to using these tools and part of it was just like, you know, it's hard.

You're, these tools are really changing behavior and it's changing the way that people actually work. And so we suggest this kind of three things. Number one, you need a strong leader within the organization that actually wants to do this.

And so that you need that strong top-down leadership. That's hey, and it's, you know, we call it a sponsor. Make sure you have a strong sponsor.

Number two is you gotta start small, you know, find a specific problem or a specific engineering organization or a specific topic you might wanna solve and do that first and get 10 to 20 power users in the room. And let's just say it's Q business, right? And you wanted to do architecture for a specific product.

Get those 20 engineers in the room, get them below in their best documentation and get out all the kinks, make sure this thing is working, uh, get some success. And then that's when you begin to begin expanding throughout the organization. But start small, get some wings.

Figure out how to change the behavior, figure out how it's making you better at your job before you go big. It's not if you build it, they will come. You gotta lean in right now and actually set the organization up for success.

Alright folks, you heard it here. It's important to play, but you gotta have a plan ultimately otherwise, um, you'll, it'll just get lost in the cycles because people will be going doing all kinds of things that may not be all that productive or they may be just spinning their wheels one way or another. I think it was Ben Franklin said something about, um, you know, failing the plan is planning to fail.

Yeah, that's exactly Still true in the land of ai. Hey David, thanks for being on the show. Thank you so much for the time.

Thank you all for watching the latest episode of the Textron AI video series. You can find this episode and others on our website. We invite you to check them all out till then, we'll see you next time.