Accelerate development with Amazon CodeCatalyst

Hey, good evening. Thanks for joining us today over here. It's a bit of a haul. So thanks for trucking it over here.

Hey, you tell us that you want to build and deploy applications more quickly and safer on AWS. But today that it requires too much undifferentiated work. In addition to too much complexity, this includes everything from understanding code bases to setting up local dev environments to ensuring that you've used all the right set of services for the application that you actually want to build.

In order for all organizations to achieve a faster software development life cycle and increase safety of deployments, we need to do a better job of removing that undifferentiated work and complexity.

Last year at Re:Invent, Harry and I introduced Amazon CodeCatalyst to help you solve some of these problems. This year, we're back again to talk about how we have some new and exciting features as well as how we're reimagining the software development life cycle using generative AI.

My name is Doug Clawson. I'm a product manager with Amazon CodeCatalyst inside of our Next Generation Developer Experiences organization.

Harry, can you introduce yourself as well?

Yeah, sure. So my name is Harry Mauer and I'm the general manager for DevOps services at AWS.

Before we dive too deeply into all the cool gen AI stuff that we're going to show you today, I just want to talk a little bit about CodeCatalyst and where the product is.

So, as Doug mentioned last year at Re:Invent, we launched CodeCatalyst in preview and then earlier this year, around April timeframe, we made it generally available for everyone to use.

So what we're trying to do with CodeCatalyst for those that aren't familiar is we want to try to create the best place for you and your team to plan, create, build, test and deploy applications to AWS - so the whole software development life cycle to AWS.

To do that, we bring all the tools that your team needs to go from idea to production into one seamless experience that's managed by AWS and it's deeply integrated with the cloud.

So Coy has a ton of features, right? We include everything from issue boards to help you better manage and plan your work to source control management tools that help developers better collaborate on code changes and do code reviews.

We also include managed dev environments so that developers can quickly get up and running debugging code without having to install anything on their desktop.

And of course, CoCo comes with really sophisticated and powerful CI/CD tools that make it super easy for you to automate the building, testing and deploying of your applications to AWS.

And in addition to all the features that we already have, we're really excited this week to introduce a whole slew of new features, including the generative AI stuff we're going to talk about later today.

So one of the first things I want to talk about that we launched today, earlier, actually earlier this week is a new enterprise pricing tier. And I think you're thinking, oh, this, how, why are you announcing this? How's that a feature?

Well, we did something cool in the enterprise pricing. It starts at $20 a user. But as you add users to your enterprise pricing plan, we automatically increase the number of allotted compute minutes, dev hours and network transfer limits that you have.

This is unlike other tools in the market and it makes sure that your teams have all the resources it needs to do the work that they need to do without incurring any unexpected costs or overages.

In addition to make it easy to cost effectively scale your teams on CodeCatalyst, we also want to make it really easy for you to manage your teams as they grow in size and complexity, right?

So we're incredibly excited to announce that we now have SSO integration through AWS Identity Center. So you can manage the your users inside CodeCatalyst like you manage users across the wide spectrum of all the other services that you have inside your organization, using your existing IdP and credentials.

In addition to that, we added a concept called Teams for you to better manage how people work together on projects, introduce new security roles and integration with VPC so you can better secure your build and test environments.

So these are all things that customers have been asking for throughout the year and we were able to deliver them this week here at Re:Invent.

As I mentioned before, we have really sophisticated workflows and capabilities inside of CodeCatalyst. Throughout the year, we continue to make them better. And this week at Re:Invent, we're introducing six new workflow actions including a Terraform deployment action for those customers that are using Terraform to deploy to AWS.

And in addition to that, we also introduced a new SDK that really makes it easy for you to automate the running of your workflows from processes and services outside of CodeCatalyst. So you can integrate CoCo into your existing processes and dev services.

But one of the things I'm really excited to talk about and we don't have a lot of time because we're gonna talk about the gen AI stuff too - is the new improvements that we made to our Project Blueprints.

So Project Blueprints are a unique feature inside of CodeCatalyst. When we launched them last year at Re:Invent, we explained how we use them to make it easy for you to get started the right way on AWS.

Project Blueprints are more than just a template repo, they're actually a fully functioning TypeScript application that will scaffold everything that you need for your projects.

And one of the first things that customers asked was, how can I create my own blueprints?

So this morning, we introduced support for custom blueprints as well as project life cycle management through blueprints, which is a really neat way of ensuring that your projects stay consistent with best practices as they evolve.

Like I said, there's a ton to talk about in these blueprint features and we're actually gonna have a separate session, I believe it's DOP101-210 on Thursday, and we'll do a deep dive into all these capabilities and features and walk you through how you and your platform engineers inside your organization can use blueprints to better ensure best practices are enforced across your projects.

But the thing we're most excited about and the thing we really want to talk about today is how we're leveraging the power of AI inside of CodeCatalyst to transform how we believe software is gonna be developed.

So, in addition to all those other features that I mentioned today, we're really proud to announce integration with Amazon Q into CodeCatalyst.

For those that haven't heard the news about Q, Amazon Q is an interactive and personalized generative AI powered assistant that provides AWS customers expert guidance when building and operating and maintaining applications on AWS.

Amazon Q is gonna be available across a wide array of services - so it'll be available inside the console, it'll be available in popular IDEs as well as the documentation and of course in CodeCatalyst, which we'll show you here today.

Like everything we're doing in the AI space, we integrated Q in a responsible way so that you can confidently start using the features today with your teams.

Admins get to decide completely who has access to these features. And Q is secure and private so that we ensure that your data never leaves the confines of your AWS account.

We actually have three features inside of CoCo House that we launched today in preview that harness the power of Q including a new Feature Development capability which completely reimagines how software can be developed with AI.

Developers can now take an idea and turn it into runnable, mergeable PR code just by assigning work to Q inside CodeCatalyst.

So you just invite it to your project, assign an issue to it and you can work back and forth with it to automatically create the code and generate the new features that you want, which Doug will show you here in a couple of minutes.

In addition to that, we also use the power of Q to make some general quality of life, quality of life improvements including summarizing and explaining things in natural language.

These features are available today in preview in US West 2.

Rather than to keep talking about them, why don't I hand this off to Doug so we can actually show you them in action?

Sure thing, thanks Harry. I got the exciting part to show you - the Feature Development capability.

Oh, sorry, developers spend over 60% of their time authoring new code in a process very much like I'm showing here.

The Feature Development capability, as Harry said, allows you to work with Q to take a CodeCatalyst issue from idea all the way to pull request.

It starts when you create an issue inside of CodeCatalyst and assign it to Q.

Q then takes over - summarizes your code, develops an approach to the problem to implement, authors the code, creates a pull request, and then monitors any workflows you'd have running on that pull request and tries to help you fix those issues.

Most recently for me, the coolest part of this is when the workflow monitor helped me save a bunch of time when I was trying to debug why my CodeGuru step of my workflow, you'll see an example here in a second, wasn't working - it was failing.

Instead of me debugging it, Q was able to figure out that it was a permissions problem on the role that I had associated with this particular CodeCatalyst account. It didn't have permissions to run CodeGuru.

Show of hands - am I the only one that struggles with IAM policies and permissions and security? Good, not just me.

In less than two minutes, Q was able to tell me what the problem was - it didn't have permissions - and then how to fix it.

There are also multiple points in this process when you're working with Q where if you want to interact and nudge it in a slightly different direction, you can do that as well. You can do that on both the approach as well as the pull request. And I'll show you that in just a little bit.

Let me jump into a demo and show you what it looks like...

Alright, before we get started, let's create a new project in CodeCatalyst. There's a couple of ways I could do this - I could bring my own code, I could start from scratch - I'm gonna use one of the blueprints here that Harry talked about.

This one's the "Modern 3-Tier Web Application", the infamous Mythical Misfits application.

Clicking on it opens the README file. I can see the architecture that's used. I can see the right roles and policies I need to set up.

Apparently I didn't read the README file, but it tells me right here what I needed to do to run this application.

Go ahead and hit Next. I'll give it a project name. I'm going to associate an AWS account and then I'm going to associate a role, a development role, to get Amazon CodeCatalyst permissions into that account to deploy the application.

Yeah, I also have a few more settings I could change if I wanted to, things like compute types or hosting types. I'm gonna leave those alone and we'll create the project and you'll see here in just about 3 or 4 seconds I'm going to have a complete up and running application that's ready for me to work on.

Like Harry said, we have a left hand navigation bar that shows you everything you got with this application. So I have an issues management board. This is your typical Jira-style. We're going to spend some time here today. This is how we interact with Q.

We also have a whole section on code where we have our source repos, our pull requests, and our dev environments. We have one repo here called "misfits" - opening that up, you see the repo, right? I've got folders for source and test, see a CDK stacks folder in there.

And then it also comes with workflows. In this case, it came with two - both an application deployment workflow which deploys the application into the account, and an on pull request workflow.

The application deployment pipeline is already running because we made a push in the main, which is the trigger to cause it to run. So it's currently building and then it's going to deploy the application, the Mythical Misfits, into my account.

We also have that on pull request workflow that will work across any branch that gets created and run a workflow on the pull request so that you can be sure that the code that's moving in is going through your pull request workflow and it's confirmed.

So at this point, I've seen what it gave me, but I'd be, I'd be wanting to understand, ok, what is the architecture of this code? Hopefully it's well commented so that I can look through and understand what it looks like, right?

This is an area that Q is, we've seen, is very helpful - is helping you understand what you already have.

So in this case, all I have to do is create a new issue. I'm going to give the issue a title and ask it to summarize the CDK stacks that are used in this application.

I'll give it a couple of additional requirements here - to create a new README file. I'll tell it where to put it in that CDK stacks folder. So the other developers after me will get to use the same.

Alright. And again, I could assign this to myself or assign it to someone else to go work on. But in this case, we'll assign it to Amazon Q and we'll hit Create Issue.

Now, at this point, the issue has been created. It's in the to do list. Q has been assigned the issue, as we see with the Q icon down there. Q will interact with us on this issue by creating comments and writing comments into this issue. So we get a whole history of what happened with it and opening it up.

We see a workflow here that it's gonna work through and we see it's asking us a couple of questions. The first one is, do we want to go into an interactive mode? We'll talk about that more later. We're not going to do it now. It's also asking, does it have permission to change any of the workflow files? Again, we don't want it to do that and we'll confirm the source repo was the misfits. And we'll confirm now at this point Q will start working through the flow. It's described here. It's reading the repository, it's generating a background. It's going to generate an approach to the problem. We'll wait for that to happen.

Full disclosure. I did speed this up a tiny bit and this is also a good way to learn, right? The background is going to be very specific to our ask. So in this case, it's going to talk about the CDK stacks. The approach is going to be very specific to what we're asking it to go do, which is create that README file populate it with the CDK stacks, information, put it into the repo. So again, this is also a good way to learn. So those look good. I was gonna scroll back up and we'll let you finish.

And now with a little bit of magic here, I'll fast forward this. I think this one's a total of six minutes. I'm gonna have APR created assigned to me because I was the issue creator. So I can click on that PR that's been linked back to the issue and we can go take a look at what you did.

So here's our PR again, I'm the approver because I created the issue. We have our on pull request workflow. If you look at the upper right hand corner, it's all currently running. We could wait for the output of that if we wanted to and then we can go look at the actual changes. So here we go. We got a README file change inside the CDK stack folder and we have details about the stacks. So that looks good to me. I could approve this, merge it. And then we've got our documentation for the CDK stacks done.

Another area that we've noticed Q has been very helpful in is helping us understand technologies, maybe that we don't quite understand. Um in this case, I want to make sure I add all the automation I want to have up front so that any of the code that's making into my main line branch is actually a code that I want, I want to be there, right? And it's, it's meeting my standards. Currently, this project's only me. So I want to get that automation put in up front.

So this is our current on PR workflow. It runs that single step for the CodeGuru. I want to add a lender to it. I could do that a couple of ways I could edit the AML file, I could have done it visually. But in this case, let's use Q again to help us uh add a l to that workflow.

So again, we'll create another issue. We'll give it a title of adding ESLint to the on pull request workflow. Again, a couple more requirements to be specific about what we want. We're asking for a build action and how to run it and we'll assign this one to Q as well and we'll work through the same flow with Q that we just did.

So it's going to go through the same flow waiting for us. Uh we won't do interactive mode again. In this case, we do need to give it permissions for the workflow since we're asking it to change the workflow. So we'll do. No. Yes. And then we'll confirm the repository which is still misfits and Q will began working through the same flow it did before read the repository of the background, the approach code and then ultimately link a pull request this one. If i remember, right. it's going to take a total of four minutes for it to go through the process link that poll request, make me the approver on the poll request.

Let's jump in and see what it did. What's really cool about this example is because we changed the on pull request workflow in this branch. The uh the the pull request workflow that's running is the new one. So instead of looking at the code changes because maybe I don't know the yaml, I can jump into the workflow and see if it worked. And we can see we did get another step. So that looks great.

In CodeCatalyst, we have a visual way to look at all of these log files that are happening and looking at what this particular action is doing. So I'm skipping through this pretty quickly here. Um and we get down to, we see the linting step failed when it tried to run NPM, run lint. So to see that log file and to see why it failed, we can open that up or write and Code Catalyst. And we see we have some linking problems.

So the winter worked, we just have a variable we didn't use and we have three V bind key directives which appears to be a view uh specific thing. So this looks good. Um and the workflow is running as we expected, the lender is running and we just have lending problems. So I'm gonna go ahead and approve and merge this back in so that any of the other uh future branches are gonna get this workflow so we can ensure that we're not introducing new lent errors.

So I'll prove that, then I'll merge it and then I'm going to go back to that PR workflow that had the linting errors. And let's see if we can get you to help us fix one of those errors. So I'm going to go back to that copy and paste the error out. It told us a line number, it told us a file name again. Another true story. I don't know what this error means in view. I still don't, i could have looked it up if i wanted to. I didn't. Um maybe one of you guys can help me afterwards and tell me what a V bind directive key means.

So I'll just copy the air out and then we'll go create another issue and we will create a title. I think i said fix splinter warning. And then I'm going to give it to say fix the lender warning. I give it the file name. I gave it the line number. I'm going to give it the error. I'll sign it to Q create issue.

We're going to go through the exact same flow again. So we will say we're gonna go no, no on this one. So no interactive mode don't need to change the work flow. So we'll say no as well and still the misfits source repo. So we'll confirm this one and if memory serves me right. I think this one takes three minutes to get a workflow. And so I'll fast forward this a bit for us all.

Um the other thing that i could have done, i didn't, but i could have gone and looked at the background and the approach and i likely would have been able to understand what this error was right? Instead of going to try to google it, q would have told me what it was.

All right. So i got my workflow. Uh i got the pr let's jump into that workflow again on this pr and we're expecting to still have one warning and two errors. Um we've noticed one thing with q, if you give it a bunch of different things to work on, sometimes it doesn't quite grasp all the changes it needs to make. And so i just picked one. I didn't try all three of them. It could have worked and we see it worked.

So we got um one warning now and two errors, we still have a couple of v vine directives. Um so this is good so i could now approve this change and merge it back in. So i've shown you now a couple of examples of future development capability. One helping you understand the things that you already have another one of understanding or helping you work towards things maybe technologies that you don't quite understand and helping you learn them as well as getting those fixes in gonna go next.

So before i jump into the next demo, um where i show you interactive mode, i want to talk about some tips and tricks that we've learned as we've been working with q first. As you saw here, i gave it some detailed prompts, the prompts matter if you give it a vague prompt, expect a vague response. If you already know what you want, just like if you're working with someone else, just tell it what you want, right? If you already have those requirements, just say so second, the iteration can be really helpful and sometimes even fun to learn something new like i mentioned on the view and if i would have iterated with it, uh you can iterate on both the approach to the problem as well as the pull request on the pull request. You'd add in line comments on the code and say i want this something different hit, create a revision. It will generate the code again.

Also keep in mind the model doesn't have access to the internet. So it may not know about the latest and greatest APIs. If something would have just changed, it may not know that it also doesn't know about obscure programming languages. Um my favorite being whitespace. If you've got any whitespace fans out there, i apologize. It doesn't know it.

And finally as you've seen the capabilities comprised of two main phases, we have a planning phase and we have a code generation phase. And while customers and our own developers have been extracting value from both of those, we've heard that the planning phase and we've seen the planning phase is more mature than the code generation phase. However, they've also said that if the coding phase doesn't complete a finished product, that the planning phase was able to give them the mental model for what they needed to do. Also, if the code only say 80% correct, it's still a step in the right direction of getting you towards that working solution. And you can either iterate with q by again putting those in line comments or jumping into one of those cloud based dev environments that harry mentioned and you can make the fix yourself.

I'm gonna show you one more demo of the feature development capability uh and we'll do iteration mode this time. This one takes a little bit or i'm sorry, interactive mode

This one takes a little bit more understanding of what the application is. So as I promised, let's go back to those application deployment pipelines and let's see what this application is building for us.

We have two runs - one from when we created the project, one from when we merged the on poll request. So this is building and deploying the application. We can click on the "View App" and it opens it up.

Now, remember this is a modern three tier web application blueprint. The three tier is a front end, it has a back end or an API layer, and then it has a DynamoDB back end or sorry, a database with a Python wrapper around it. In that database, we have these 12 misfits. They all have their certain characteristics, whether they're good or evil or lawful or chaotic. They have an age and a name. You can filter them and then there's a "View All" button that brings them all back to the screen.

I'd like to make a change now where I change it so that the misfits when they're put on the screen are sorted by age. And I could just like most applications, I could do this multiple ways, right? I could change the API layer or I could change the database wrapper layer.

We're going to give you a little bit more of a vague prompt this time and tell it we wanted to change the "get all misfits" API to return them sorted by age. So we open up this issue and this time we will go into the interactive mode which will force Q to stop after it creates the approach and then it will wait for us to approve it before it starts generating code.

So as Q works through, we've got our background, we've got our first approach ready in less than a minute and this approach is changing both the API layer and the data access layer. And you'll notice Q is also smart enough to update the unit tests.

We actually want to just change the API layer. So we're going to tell it "Make the changes directly in the API. No need to worry about the data access layer."

So we provide that feedback. Q will then go through again and generate another approach and wait for our approval. So this new approach is now changing just the API layer which is great. But on the testing side, it's changing unit tests for both the database wrapper as well as the API.

So we're going to tell it "Don't change the model tests either." So we provide that feedback and then Q in the end goes through and creates another approach. And now we've got it down to suggesting the approach being two files - both the API layer file and then the unit test file that goes with it.

So this change looks great. We're going to go ahead and approve and proceed. So clicking proceed here tells Q that it's now ready to go generate code. I think this one takes a total of six minutes. The PR is linked, I'm the approver.

Another cool thing about this example is, you know, all developers have their certain spacing tabs or spaces. Q has preferences as well. I apologize for all those empty lines we're working on making that better. We can see the "get_misfits" got added has a sort function with it. Now, that looks perfect, looks great.

And then this is where you went a bit off script. It's actually a good change. It changed one of the unit test files that's putting the table together before it gets tested and it randomizes all of the input and then it also changed the back end, the database wrapper as well instead of the API layer.

So we could fix that as well. So at this point, it's not perfect. It's not exactly what I wanted. I could make individual comments in this code and tell it to do something different and then hit that "Create Revision" button in the middle. But instead I'm gonna jump into a dev environment really quickly and show you how quickly I can change it as well.

So one other thing it did is it put a random import statement, import random (pun intended there, I guess) in the middle of the Python file, which I'd rather have my imports at the top. So I can jump into a dev environment. I could have used VS Code or the JetBrains IDEs. I'm gonna use Cloud9 - nothing to install locally.

I can navigate to that unit test file which is called "table_mock". I can pull that random import in the middle of the function out, put it at the top just to be precise. This code is coming from the PR that this is working off the branch that we were in when we clicked "Create Dev Environment" on that PR, right? This Q code.

Yep. So we put the import up there. I could have fixed some spacing, but just for expedience here, I'll give it a comment, commit it, and then push it back into that repo. Like we say, sometimes it's easier just to do it yourself. This is the "do it yourself" mode.

Once I commit this change back and push it back to the repo, I can come back to CodeCatalyst. When I refresh the screen, I'm going to get a rev on that pull request which is going to have my new changes in it.

Now, at this point, I could continue to rev it. I could continue to work with Q, I could give it inline comments, hit that "Create Revision" button up at the top, the preview feature tag, and Q would then regenerate another approach to it so we can continue to iterate even on the pull request if we want to.

So now I've shown you a lot of things in the Future Development capability. I've shown you how it can help you understand what you already have and summarize things you already have and even create README files to help other developers. I've shown you how it can help with things around technologies maybe that you aren't quite familiar with and you want to learn more about. Q is very good at helping you there as well.

And then the last example here I showed you how if you don't give it a very specific prompt and maybe you want to iterate on something, you can iterate towards a better solution as well and even jump in and take it the last mile if you want to yourself very simply.

So with that, we're really excited about the Future Development capability and we're excited to see how you use it as well and please give us feedback on it.

We also have a couple more features. Harry, will you talk about some of the explanation and summarizations?

Yeah, sure. So, I mean, that, that was amazing and I think we can talk more a little bit more about that. I mean, we really do think that the power of Q inside of CodeCatalyst really can transform how you develop software, right?

Um, you know, Doug was just going back and forth - it's interacting with an AI. It's the AI doing that, it's building that code for you, right? It's building those workflows, it's doing the work of a developer for you on your team. And that's just the beginning, right? So we see really transformational capabilities by leveraging Amazon Q inside of CodeCatalyst.

But in addition to these really transformational things, we also knew that Q could really add some quality of life improvements to everyday tasks that developers do. And we see a long string of these things that we're gonna be releasing throughout the year that's gonna help you just improve your everyday developer life.

Two of the ones I'll talk about today - one is helping you more concisely write your pull request descriptions, right? So how many times have we been out there? We made a ton of changes. We go to push our changes up. Now, we've got to explain it all in the PR and sometimes that takes 5, 10, 20 minutes, maybe it even takes longer than actually writing the code, right?

So that's a problem that we all face multiple times a day, multiple times a week. Just think about the amount of time that we could save if we could have Amazon Q do that for you. And so we did that - right today in preview, you can go to CodeCatalyst and automatically generate pull request summaries just by clicking a button and I'll show you a demo of that in a second.

In addition to pull request summaries, now you're gonna jump into someone else's PR and you're gonna need to figure out, you're asked to approve and merge that, and you need to figure out what's going on. And sometimes that can be a lot of back and forth comments, a lot of back and forth work by you and others inside of that PR. And we're often faced with the problem of like "How, where do I - so much is going on here? Where do I even get started?" A lot of times I'll just go to Slack - somebody tell me, tell me what's happening here.

Well, wouldn't it be nice if we could have Q automatically summarize the comments as well? And so we did that. So another quick quality of life improvement that's available today in preview is automatic comment summary in the PR. Let me just show you how these work.

Excuse me. So here I have a clone of our Boto core repo, which is a low level library we use to create the Python SDK in AWS. The changes have some, you'll see as we go through the PRs here, the changes have a number of scope changes that the SDK is making.

And so the first thing I'm gonna do is, you know, select the destination branch and then my source branch. And you can see here, I'm gonna be making quite a few changes, right? There's changes to the scope parameters, there's some warning updates that I'm adding here, there's some new creation files and some new tests. It's a pretty big change, right?

So how am I gonna elegantly summarize this for the person who has to go through and approve this and do the actual merge? So let me show you how we can use Q to make this really easy.

So at the top of all the PR pages, now you'll see this new "Write the PR summary with Q" preview feature. All you have to do is click the button. You will go through all of your changes in your PR and create a summary of all the changes so that anybody who needs to look at this PR can automatically know everything that you did.

It actually does a way better job than I would do writing the summary here. And so this is a quick, simple thing, right? We can just go through, see this, we can edit it to if we wanted to, if it wasn't quite the right change. But think about this - you know, this is something that we do multiple times a day, multiple times a week. These are potentially hours of savings that you can have now just by using Q with inside your pull request.

So, like I said, in addition to generating these summarizations of all the changes he made, let's talk about the situation where you're going to jump into a PR and actually have to be the one approving it or understand what's happening.

So let's pick up, is it running? It is not, it is now sorry, I didn't hit the button so we can pick up where we left off with that same PR. This time, I'm gonna show you all the back and forth and the changes that have, that have happened. And you can see on the Changes tab, there's quite a few changes, right? There's changes across, there's multiple changes within files, there's many files that were changed.

If you look at the file explorer on the left, you can see all the comments that were left in line in all the different files. And if you're faced with this situation, it's a lot of hunting and pecking and understanding again, probably something that you're gonna go to Slack somebody about.

But instead of doing that, now we can use Amazon Q directly inside of our pull request to also summarize all the comments the same way we summarize the changes. So just click a button and then Q will go through and look at all of the changes or comments that were made across those changes, automatically generate a summary for you. And this provides a really great waypoint for you to start working on that PR.

So these two changes combined together are already saving developers on our team a ton of time. These are the, you know, we, we were really excited about all of the Future Development work and we really think that's going to be transformational. But when I asked the developers the most benefit they get right now, it's these little quality of life things that really make a huge improvement when they're building code inside a CodeCatalyst.

OK? So we showed you a lot, we did a lot of demos, but the proof is in the pudding and we want you all to go try it for yourselves, right? So we showed you how you can create new features using Q, how you can create new workflows, how you can debug issues, how you can automatically summarize your pull request changes and your comments and all of those things are available today in preview.

So during the preview, Amazon Q and CodeCatalyst will be provided for no extra charge. And after the preview, it will be included in the Amazon Q Builder package. For the feature development capabilities that Doug showed you, those are available in our Standard and Enterprise tiers - the Standard tier spaces get up to 15 generated PRs a month and the Enterprise customers will get up to 20 generated PRs per user per month with a max of 300 PRs in each of the Enterprise spaces.

Please keep in mind these are in preview and they're available only in US West 2. So if you're gonna go to CodeCatalyst and create a space, make sure you do it in US West 2.

So now it's your turn. Like I said, there's a ton of stuff here. We want you to try it out. We want your feedback so that we can continue to improve and refine the experience. There's a huge feedback button in the product, please click it often and give us your comments.

And thanks for joining. If you have any questions, Doug and I will be available at the side of the podium and I hope you all have a great show. Thanks for being here.