MICHELLE BU: Hi everyone. I'm Michelle, and I lead API design at Stripe. I've been looking forward to this part of Sessions all year. The part where I get to talk to you, the developers that have shaped Stripe's products. Let's learn a bit about each other first. How many of you are brand new to building on Stripe? Welcome. And how many of you have been building on Stripe for one year? Keep your hands up for five. What about 10? What about since the very beginning? That's awesome. No matter how long you've been using Stripe, thank you for being here and thank you for being with us on this journey. As for me, I've been at Stripe since 2013. I actually joined as a new grad, as one of Stripe's first product engineers. And I joined because I knew I wanted to work on developer tools.

While I was in university, I spent a lot of time on side projects. But by far the most energizing work for me was working on open-source developer tools, building for and interacting with developers as my main user. I also loved giving talks to developers, in rooms like this one, much smaller, with a different audience, [and] different hair. I have gotten glasses since then as well. I've learned so much about building APIs since then from frontend APIs like Stripe Elements, to our Payment Intense APIs. And just as I've changed a lot since 2013, so has Stripe. And the way we've developed has changed a lot as well. But what hasn't changed is our commitment to building amazing developer experiences for all of you. And today, I'm excited to show you what we've been working on.

We'll start by talking about how we think about API design. And then, we'll show you some new tools that we've developed based on all of your feedback. And finally, I'll invite to the stage some amazing developers, so you can hear directly from the broader Stripe community.

What does it mean to be a developer today? Studies from Stack Overflow, DORA, and our own data, increasingly point towards developers wanting to become more efficient, and you want better ways to collaborate. In particular, developers want to maximize their flow state. For folks who aren't familiar with this concept, flow state is when you're performing an activity and you're fully immersed in a feeling of focus and joy. You're completely absorbed in what you're doing and your sense of time is transformed. We all know when we're in a flow state. You're plugged in, solving a problem, and you're solving problem after problem without interruption, like playing a video game that's actually just at the right level of difficulty. And the conditions to achieving flow state are well-known.

It's a combination of knowing what to do, being free from distractions and having a clear challenge, and the right set of skills and tools. And we've all experienced the opposite as well. Constant interruption that makes it impossible to focus and engage in that focus work. Paul Graham wrote about this in his famous essay, “Maker's Schedule, Manager's Schedule.” When you're operating on a maker's schedule, a single meeting can disrupt your entire afternoon by breaking it into pieces, each too small to do anything in. But we can't blame everything on the meetings. Sometimes our tools also get in our way. You might think of Stripe as having a reputation for a great developer experience. That's what we often hear from you. But it's important to know that while we appreciate that kind of feedback, we obsess over feedback like this. Just last week, our Checkout team jumped on a call with Jack from Outro, who tweeted a lot of very tough, but valuable feedback. Everyone take a moment to just read it.

It's not flattering. And we couldn't even fit the full tweet on the slide. Jack goes on to say, and I quote, “Want to know how to set up a basic subscription webhook? You're on your own. Want to switch a checkout UI to a custom form or elements? You're going to have to rebuild everything from scratch.” And it's true. While we don't get everything perfect, feedback like this helps us get better. We know that great API design and developer tooling can help reduce frustration and maximize the amount of time that you're in flow state. We'll cover both topics today, but let's start by exploring API design together.

When we think about the principles of great API design, that is, APIs that really stand the test of time. We actually take a lot of inspiration from video games. For example, Stripe Press published an entire book on the making of the video game classic “Prince of Persia.” It's a great read. One of my key takeaways from the book is how video games have designed so many mechanisms to gradually introduce concepts to players of all skill levels. One of my favorite mechanics is “Fog of War.” That's me. It's a game mechanic that helps new players looking at a map for the first time not become overwhelmed by its complexity.

As a video game completionist myself, I really appreciate when games obscure parts of the map that I haven't yet explored. Because rather than being overwhelmed with all the places I eventually need to go and all the things I need to do, I can keep track of exactly where I've already been and I can focus on fully exploring the sections of the map that I'm in before moving on to the next set of challenges. Okay, so how does this apply to APIs? Well, when we think about designing APIs, we think a lot about the design principle of gradual reveal. That is, we want to avoid forcing you to learn a bunch of new concepts, or read hundreds of pages of documentation up front, before you get your first lines of code running.

So let's imagine you're integrating with the Stripe API, perhaps with Connect, and the new flexible account configurations that you heard about at the keynote yesterday. With a simple call to POST v1 accounts, you as a platform can create accounts to represent your users. However, you couldn't always just get started with POST v1 accounts. Prior to flexible accounts, we had three different types of accounts that you had to choose from, and you had to specify a type to get your code working. This meant that you had to read hundreds of pages of documentation to understand which type to use in the first place. I see some of y'all nodding in the first row. You probably have been through these hundreds of pages of documentation.

None of us feel in flow in the sort of environment where you have 20 tabs open and you're clicking links and you're opening up new tabs. While the API request itself looks simple enough, it's just a single type enum value; it actually obscured a lot of complexity. And so this brings us to the second design principle we applied as we removed account types from the API: reduce dead ends. With types, you could build your entire integration on top of the type that you thought you wanted after reading all those docs, and then realize afterwards that that type implied other traits that you hadn't yet read about and you'd hit a dead end.

For example, if you wanted to customize how you monetize payments, as many platforms do, you might select type equals custom. But that also implies that you can't give your users access to our hosted or embedded Dashboards. Once you realize that, you have to backtrack all the way to the beginning and start over. So what we did to enable gradual reveal and reduce dead ends was decompose these types into specific granular configuration that you can layer into your integrations as you learn more about what you need. This design leads not only to less up-front reading and learning, but also fewer dead ends. If you suddenly realize that you don't want to build your very own dashboard and instead use Stripe Dashboards, add Stripe Dashboard type equals full, for a full Dashboard experience for your users.

A third principle we consistently lean on to help you maintain flow state is creating what we call “pits of success” in our API design. We believe the best integration experiences allow you to practically stumble into an integration that meets your needs. What do we mean by this? Well, we all know the feeling of running into an error and having to Google a bunch of things and look up documentation to figure out how to fix it. We want to make sure that this doesn't happen when you encounter an error on Stripe. So, we spend a lot of time ensuring that our error messages are actionable. So, even if you fall into an integration issue, there's a ladder right there waiting for you to get back on the trail. If you misspell the parameter, we don't just tell you that it's wrong, we actually tell you the right parameter name, so that you can fix it immediately.

And, if you specify a value that's incompatible with the other values that you're using, again, we don't just tell you that you can't do that. We tell you what combinations do work, so again, you can fix it right away and move on to the next task. This is what we call creating pits of success. Okay, great, so those error messages guided you to fixing all the integration issues with your integration, and now you have an account object configured exactly how you wanted it. There's one more thing I want to call out here. You finish your integration with Stripe, and you probably just want to sign off and get into a flow state with a new task that's on your list. The worst way to have that flow state disrupted is to have the infrastructure that you're using, that you just finished writing code for, break. And so this brings us to our final principle for today, which is “Don't break users.”

We care a lot about backwards compatibility and smooth migrations. As I mentioned earlier, we used to have these typed accounts, and, in fact, most of our existing users and plugins are still using type in their code. Some are even migrating to this API from type. And so, their systems might still expect a type property. We can't just break your code at will, even if we think these flexible configurations are much better. So, we solve compatibility problems like this by continuing to accept and return a type field, while also adding in these new account properties. I could talk for a long time about the details here, but the bottom line is these changes are always additive, and we're not going to break any integrations and you can opt in when you're ready to incrementally migrate.

That's a brief glimpse at API design principles. But what about everything else? How can we better support flow state through our holistic developer experience, which includes not just the API, but all the tools and docs around it?

Let's go back to our research. Following hundreds of user conversations, we learned that you want to use generative AI tools to create and debug code and to have more customized samples and docs. You also want better spaces to experiment, discover, and build faster. And finally, you want ways to quickly pull together teams on a shared problem. Building and operating the amazing products all of you work on is a multiplayer game. And so, to directly address your needs, today, we're announcing four new developer tools. Stripe for GitHub Copilot, Workbench, Sandboxes, and Event Destinations. I've been talking for a while, so instead of explaining them to you, why don't we actually put them to good use live on stage? Today, MG, from the fictional company, Hypernian, is in the audience. And he has a project that he needs to complete. You want to come up?

MICHAEL GLUKHOV: Thanks Michelle. I've actually had my hand up earlier, because I've been using Stripe for years.

MICHELLE BU: MG, why don't you tell us what you're going to build today?

MICHAEL GLUKHOV: Well, you heard about Hypernian in the keynote yesterday and today. We're a fictional software company with a subscriptions business. We build a suite of tools for creative professionals. I've actually been moonlighting on their development team, but I'll admit, it's been a while since I touched our Stripe integration. Today, I'm going to, oh. Sorry, I thought I said do not disturb. One second, it's my boss. Hello?

DAVID SINGLETON: MG, where are you? Anyway, don't answer. It doesn't matter. Look, we need a new checkout experience on our site. I just saw Link in the Stripe keynote and it looks like it's got amazing conversion numbers. I promised to show it to an investor in 15 minutes. Could you get that into—

MICHELLE BU: He just hung up, huh?

MICHAEL GLUKHOV: I guess there's no time like the present. Sounds like I'm building a checkout flow with all of you today. Let's put 15 minutes on the clock. There it is.

MICHELLE BU: Yeah! MG, I think I can help. Why don't we work on it together? I'll hang out here to the side and cheer you on. And of course, we've already enabled some of those new tools on your account.

MICHAEL GLUKHOV: Great. Let me show you what we have today. Here I am on Hypernian’s site. You can see the subscription options below.

MICHELLE BU: That's a lot.

MICHAEL GLUKHOV: It's a lot of creative tools. Let's take a look at the checkout form. I'm not proud of it, but it works. I can see why my boss wanted a revamp. This GeoCities vibe, it just isn't working anymore. But first, I need to update our website with the latest optimized checkout experience, and quickly. I'm going to jump into my editor, I'm going to open the Stripe Docs. Let's see what the latest integration options look like.

MICHELLE BU: MG, since you already have your editor open, you don't need to go into the docs. Why don't you click on that chat icon?

MICHAEL GLUKHOV: Oh wow. Neat! It looks like I can use GitHub's Copilot with Stripe, but right from my editor.

MICHELLE BU: That's right. We built Stripe's VS code extension to work with GitHub Copilot. We're bringing the power of LLMs and generative AI to help you build your Stripe integration. You can simply at mention the Stripe agent within Copilot and ask any question to learn how to best use our APIs. By bringing documentation and best practices right into your editor, you don't need to contact switch as often.

MICHAEL GLUKHOV: I mean, that sounds great for my flow state. First, let me try asking the Stripe agent. “How can I add a checkout page for subscriptions to my site?”

MICHELLE BU: As you can see, the LLM is generating a few suggestions. The Stripe agent is trained on our APIs, our documentation, best practices, knowledge of common errors, and a lot more. So you can learn how to integrate more conversationally without opening up all those docs.

MICHAEL GLUKHOV: Nice. I mean, it looks like embedded checkout is what I want, but Michelle, what do you think?

MICHELLE BU: Yeah, I think that's right. Why don't you click on that first suggestion? Embedded checkout was just shipped last year. It introduces the ability to embed Stripe's customizable checkout experience in your site. It includes the latest payment method and authorization optimizations. And best of all, it addresses a top user request to avoid redirecting customers to a separate checkout page and instead keeps them on your site.

MICHAEL GLUKHOV: I mean, that sounds perfect. Sounds like we can implement it. I just clicked on this first suggestion. And it's providing me some code that I can use. I mean, this is great because my backend uses an NextJS. So this code can slot right in. Let's take a look at the code though, it's an LLM-generated code, so I want to double check and make sure I understand how it's working. Let's see. So first, it's exposing a new server route and then we're responding to a post request. We're gathering the prices that we have configured. We're creating a new checkout session. The UI mode will set embedded Checkout. We're configuring the line items for that checkout with our prices. Then the mode is subscription, so it's going to do that, rather than create a subscription, rather than creating a payment. I mean, that looks good. Let's create the file.

MICHELLE BU: Yeah.

MICHAEL GLUKHOV: Great! There it is. Okay, let's take a look at what Stripe has for our frontend code.

MICHELLE BU: Yeah, of course you should check it, but isn't that amazing? The assistant can create whole new files and suggests major edits to existing files by understanding your code base.

MICHAEL GLUKHOV: So, it looks like the Stripe extension is suggesting that I use the React component for embedded Checkout. Let's update our frontend code. Our previous frontend code was thousands of lines and it had to hard-code every edge case, every payment method. It's going to feel really good to delete it. Great. Let's save this. Let's try to make a new subscription. I'm going to go on my development server. Let's go ahead and try to create a new subscription. Wow.

MICHELLE BU: There it is.

MICHAEL GLUKHOV: Embedded Checkout looks so much nicer than my old form. Blends right into the site. And that's our one-click checkout with Link. So we're speeding through the process and creating a subscription. And there we are.

Let's actually check the Dashboard now to see that subscription that I just created. I'm going to refresh… There's a subscription.

MICHELLE BU: Awesome. Why don't you click on “Inspect” at the bottom of that screen? This way, you can see more about the subscription. This is going to launch Workbench. Workbench is our new home for developers that helps you build, monitor, and debug your integration. No matter where you are in the Stripe Dashboard, you can peek behind the scenes with a debugging view with a single keystroke. Workbench proactively surfaces alerts and contextual insights to help you quickly identify bugs and resolve errors collaborate with teammates, and helps the edit build test loop stay shorter so you can stay focused.

MICHAEL GLUKHOV: Who doesn't love a new tool in the toolkit? It looks like Inspector is showing me the JSON representation for the subscription, but right from the Dashboard.

MICHELLE BU: And it also shows you related objects, like the customer, the payment method, and the invoice.

MICHAEL GLUKHOV: Yeah, and it looks like I can see the logs and the events for that subscription so I can understand how its state changed over time. I also see these icons in the bottom right. It looks like it's showing me recent API activity on this account.

MICHELLE BU: Yeah, and if you click on that, that'll take you to the overview, which shows you all your recent API activity along with failed requests. You can also grab your API keys there if you didn't already have them.

MICHAEL GLUKHOV: Great. Well we still have a few minutes left on the clock. And I know that our prior checkout code included a coupon code, and my boss really cared about it. So I want to update our checkout to automatically add a coupon code to all new subscriptions. There's a coupon API for that, right?

MICHELLE BU: There is. Have you used it before?

MICHAEL GLUKHOV: I did make a coupon earlier in the Dashboard to start experimenting with. Here, let me show you.

MICHELLE BU: Okay.

MICHAEL GLUKHOV: There it is.

MICHELLE BU: Why don't you grab that ID, pop up on your Inspector again… Right there, and then click that “Edit an API Explorer” button.

MICHAEL GLUKHOV: Oh wow.

MICHELLE BU: Yes, the API Explorer should help you build your API request so you can apply that coupon to your subscription. We can see the API Explorer alongside the Shell, which is a handy integrated command line environment that supports many of the same commands as the Stripe CLI.

MICHAEL GLUKHOV: Yeah, I love the CLI that Stripe has, I'm already used to it, so it's nice that I can use the Shell, but from the comfort of the Dashboard. And looking at the API Explorer, it looks like it includes all the API resources that I need. Let's start learning about how to apply this coupon to my subscription. Do we have a coupon parameter I can use?

MICHELLE BU: Yeah, as MG is hovering over each parameter, you can see that it's surfacing documentation, so he can start to understand how to apply the coupon. And he doesn't have to switch the API reference or any docs to figure out how.

MICHAEL GLUKHOV: There it is, yeah. Let me drop in that ID. Wow, it's actually building the command in the Shell as I'm using the API Explorer. And it looks like I can click “Print SDK requests” and it just gives me the code that I can then drop to my editor later when I'm ready. That's really cool. Okay, let's try running this.

MICHELLE BU: And when you hit “Run,” it will make an API request to v1 subscriptions with all the parameters that you just specified.

MICHAEL GLUKHOV: There's the coupon.

MICHELLE BU: Yeah.

MICHAEL GLUKHOV: Well that's enough for me to get started with coupons and subscriptions. I'm going to keep building here.

MICHELLE BU: Great.

MICHAEL GLUKHOV: Oh man, again. Okay, one sec. Hello?

DAVID SINGLETON: I hear you updated the website, cool. Anyway, I was thinking, we need to send a personalized welcome email to our new customers when they sign up for a subscript—

MICHELLE BU: Subscription.

MICHAEL GLUKHOV: Can do, boss. Sounds like a scope creep, am I right?

MICHELLE BU: Yeah, yeah.

MICHAEL GLUKHOV: Fortunately, we have this amazing, world-class design agency, Nilofer Design, and they can help me out with this while I figure out those coupons thing. I'd like to welcome Nilofer to the stage.

NILOFER RAIPURK: Hey, MG, sounds like you need some help. How about when a user starts a new subscription, we can update our cloud database and then send them a personalized welcome email? I do need access to test that all out, though.

MICHAEL GLUKHOV: Great, I'll add you to our Stripe account, but it would be also great if we could use our existing AWS infrastructure.

MICHELLE BU: Wait MG, given Nilofer doesn't actually work for Hypernian, it would be much safer if you invited her to a sandbox.

MICHAEL GLUKHOV: Yeah, I've already been using Sandboxes, but I didn't know that I could add Nilofer to just one Sandbox, and not our live account. Let's get you set up.

MICHELLE BU: Sandboxes is the next generation of test mode. Your Stripe account can have multiple testing environments. For example, you can create sandboxes for development, testing, and staging. Nilofer will be able to build out the integration without having access to Hypernian's confidential business data in live mode. Now that you're onboarded, why don't you click on Sandboxes in the top right?

NILOFER RAIPURK: All right. It looks like I've got access to the Dev sandbox that MG just added me to, or I have the option to create a new one. Looks like I can start from scratch, or use some of these templates to bootstrap my testing environment.

MICHELLE BU: Those sandbox templates are really useful. They'll help you get started with a few products, prices, customers and subscriptions. Basically, all the objects you need to get started exploring.

NILOFER RAIPURK: That sounds really helpful. But I think for now, I'll just stick with the Dev sandbox that MG added me to. I think this one actually has some test data in it already. If I check out Customers, there's several test customers in here already and looks like they have associated subscriptions too. Okay, I think I'm ready to get started with my events implementation. I'll pop open Workbench and head over to Shell and then I'll use the handy Stripe Listen command.

MICHELLE BU: So glad you were paying attention from earlier.

NILOFER RAIPURK: I was! All right. Stripe Listen is helpful because I can see events populate in Shell. It'll help me track state changes for API objects while I actually code.

MICHELLE BU: Are you already seeing events come in?

NILOFER RAIPURK: Yeah, that's actually really concerning. I haven't done anything yet. MG, is that you?

MICHAEL GLUKHOV: Oh yeah, sorry. I was just testing our welcome coupon.

MICHELLE BU: One of the great things about Sandboxes is that you can create isolated environments for each developer on your team. MG, why don't you go test in your own sandbox?

MICHAEL GLUKHOV: I'll go play in my own sandbox.

NILOFER RAIPURK: Okay, let's get back to business. Now, I can start setting up some webhooks so that we can automatically send a welcome email for every customer who signs up. It sounds like a simple task, but there are actually a lot of steps behind the scenes to get this to work with Hypernian's cloud infrastructure. I have to provision an instance and figure out how to expose a webhook endpoint for Stripe to reach. Then I need to validate that the event actually came from Stripe and figure out how to handle high availability once we ramp up usage. This sounds like it's going to be a ton of work.

MICHELLE BU: Wait, before you do that, your infrastructure is running on AWS, right?

NILOFER RAIPURK: Yeah.

MICHELLE BU: You can now use our Event Destinations feature to send your Stripe events directly into Amazon EventBridge. No need to set up a webhook endpoint anymore. By routing all your Stripe event traffic right into AWS, you get low latency no round trips in the public Internet, with the guarantee that all events were sent securely by Stripe. You can easily consume Stripe events in popular AWS tools like CloudWatch, SQS and Lambda. And you don't have to do any of the setup work that Nilofer just described. Event Destination supports Amazon EventBridge today with support for additional cloud providers on the roadmap. With that said, Nilofer, why don't you switch over to the Event Destinations tab?

NILOFER RAIPURK: All right, this looks interesting. Let me try creating a new Event Destination. I heard MG added in embedded checkout, so I know the event I'm interested in is the checkout session completed event. So I'll go ahead and select that. Looks like I can connect to Amazon EventBridge right there and I get asked to provide a few details about my Amazon account. I'll drop in my account ID. Select the region that my Amazon account is in. And I'll give it a cool name. All right. And in just a few steps, I've connected Stripe to my AWS infrastructure. I'm really excited about this, because now I have my Stripe events going directly to AWS and I can use some of my favorite tools.

MICHELLE BU: Can you show me some of those?

NILOFER RAIPURK: Yeah, I'm actually really familiar with step functions so that I can build no-code automations. I've built something like this before, so I'll just go ahead and pull 200 lines of JSON out my back pocket. And voila, I've got a workflow. So this workflow will listen for my Stripe event and then have an AI generate a personalized welcome email to go out to the user.

MICHELLE BU: That's a really cool workflow. Do you really trust an LLM to generate your welcome email?

NILOFER RAIPURK: Yeah, that's a fair point. I don't, so I've added in a step here that will have the email go to Slack. There, I can approve it before it actually goes out to a user. Now I can be 100% sure.

MICHELLE BU: That makes sense.

NILOFER RAIPURK: All right, MG, great news: Our automated emails are complete.

MICHAEL GLUKHOV: Great, my work is done too. And look, we still have a few minutes left on the clock.

DAVID SINGLETON: Hey MG, how [are] you doing? Figured you'd be here at Moscone.

MICHAEL GLUKHOV: You're here in person.

DAVID SINGLETON: So you had 15 minutes, you got two minutes left. Well done. Can you show us what you've done?

MICHAEL GLUKHOV: Yeah, we did great. Stripe's VS code extension recommended that we use embedded checkout as the fastest way to add Link support. And then, Workbench made it easy to inspect objects and understand how coupons work.

NILOFER RAIPURK: And then, MG added me to a sandbox, so I could add a new Event Destination and send my Stripe events directly to AWS to trigger a welcome email.

MICHAEL GLUKHOV: And most importantly, we both managed to keep our flow state somehow.

DAVID SINGLETON: No thanks to me.

MICHAEL GLUKHOV: All right, let's take a look. Let's try it out, yes. So, I'm signing up for a new subscription. And the coupon was applied.

DAVID SINGLETON: I like those. Those are important.

MICHAEL GLUKHOV: Link is going to speed us to the payment flow. Once we process the payment, create a subscription, an event will be dispatched to our Event Destination on AWS, where the step function will process the event, use a model to generate the welcome email, post a notification in Slack.

DAVID SINGLETON: That's right there.

MICHAEL GLUKHOV: And there it is. Awesome.

DAVID SINGLETON: Cool!

MICHAEL GLUKHOV: And then we can see the email, and we can hit the “Approve” button before we send it to the customer.

DAVID SINGLETON: Okay, well, 15 minutes was way too generous, even with my scope creep, so next time, we're going to give you 10 minutes. And folks, if it's not obvious, Hypernian is a fictional company. No boss should be this bad.

MICHELLE BU: Thank you, David. It's pretty remarkable what you can do in 15-ish minutes, with the right tools and a little AI. Can we have another round of applause for MG and Nilofer?

With Stripe's new set of developer tools, you'll be able to iterate with confidence, collaborate better, and maintain that crucial flow state. We really think these tools will help you and your team get more done with Stripe. Everything we showed you today was shaped by feedback from all of you. So with that lens, why don't we hear from a few great developers about the developer experience trends they're seeing? I'd like to welcome Shawn from Latent Space, Braden from Clerk, Miguel from RevenueCat, and Iulian from Atlassian.

As you've seen, Stripe serves a wide, global and diverse set of builders. We're thrilled to hear from a mix of these today, with Iulian, Miguel, Braden, and Shawn. Let's jump right into what you just saw: Stripe's developer tools. Can you provide some context on your relationship with Stripe and your initial reactions to the experiences you just saw?

SHAWN WANG: I can go first. I am on the Stripe Developer Advisory Board, and have been a happy Stripe customer for a while, primarily with Checkout, but also other billing experiences that I've worked with in past startups. And initial reactions [were] really great. I mean, how great was the demo, guys? It's amazing acting performance from DPS and the rest of the crew. I don't know how long that took to script and rehearse, but I've never actually seen… this is a product demo that is actually like an engaging skit. But also beyond that, I think this may have changed what Stripe looks like for me. Like that black screen popping up, I'm going to have that going up and down every single time now. It's just going to be fun to play with. I don't know, what do you guys think?

BRADEN SIDOTI: Yeah, I thought Workbench was amazing. Just having that kind of insight as you're building, that live like that was going to be a game changer for anonymous errors and logs and webhooks and all sorts of things.

MIGUEL CARRANZA: It was pretty amazing. I've been using Stripe pretty much since the beginning and we integrate with the thread in two different ways. We use it to bill our customers, but at the same way, our customers use Stripe to sell on the web and we specialize on the mobile platforms. And one thing that I found, I mean, I used to be an engineer, I don't write the code that much anymore. But one of the things I've always seen is how Stripe has evolved to add more things. I remember creating my own recording using Charges back in the day before Stripe Billing was a thing. And one of my main pieces of feedback, which I agree when I saw the tweet, was that there's so much surface area now that sometimes it's a little bit tricky. And even though the APIs are super clean, they get a little bit more clutter. But now with these tools, it's super easy to build anything. So it's very impressive.

MICHELLE BU: Yeah, I love that point. As the surface over the product grows, you need more of these tools to help you navigate it.

IULIAN TANASESC: Yeah. On our side, we've built a full commerce platform at Atlassian, powered by Stripe Billing at its core. And then we're also making use of Stripe payments. So the most exciting things I've seen were the EventBridge and the sandboxes. That's pretty neat. We're not using Checkout that much for now. But it was impressive.

MICHELLE BU: That's awesome. What are your top priorities when it comes to developer experience and tooling? And this is for any of you all who want to jump in on this one.

BRADEN SIDOTI: I guess I'll jump in. Ease of use and the right abstraction. Like when you draw the right box around a set of features and it just works, which is really hard to accomplish, it's pretty magical. And then also, as you mentioned, just having the... I forget what you called it, but having good error messages to point you in the right direction when you do—

MICHELLE BU: Pit of success.

BRADEN SIDOTI: Yeah, amazing.

MIGUEL CARRANZA: I can put in a couple things. One is, obviously the clean API design is important, but also documentation is super important. Engineers don't want to read the instruction manual. They want to go in straight and try to make it work, but sometimes you need to fall back to documentation and the documentation needs to be really good. But also, the testing environment is extremely important. Especially like, we work with the App Store and the Play Store. And something as simple as testing recurring revenue and recurring events coming is very difficult. Sometimes, they don't even have accelerated events, so you have to wait a month to see the result. And with test clocks and things like that, it's super easy to develop and feel confident that your implementation is good.

IULIAN TANASESC: On our side, I think getting to that first working, we're mostly doing API integration. So, getting to use the API and being able to test it out, it's super important. SDKs are extremely important to us. In order to be able to integrate our existing code base with the others. Being able to discover that working code and test it out, that's not usual development flow.

SHAWN WANG: Maybe one of the principles that I always think about also is related to elements of what you said, which is observability. Being able to see… your tools should talk back to you. And I could see that, as they were demoing that, you had really easy access to the last 24 hours of logs and stuff. And for many of us, SSHing in, and tailing logs is a normal thing, except that when we lose control of our servers to other vendors, then we no longer have that feature. I think giving developers back that control, and having them be able to see what is going on so that they can debug straight away is important.

MICHELLE BU: Cool. I'm really excited about this question. 'Cause there [are] two parts to this. So what trends are you excited about and engaged with today? And which trends are you skeptical of?

MIGUEL CARRANZA: I think AI is the answer for both, for me. Obviously, as you can see, it's super… I think it's the most effective tool for software development since the Internet, probably. But at the same time, it's very easy, especially… you get the access to what you were getting before, but so much faster and more personalized. But the problem is that sometimes you see things that look really good, but are not that good. And maybe a more senior engineer can see those things, but maybe a more junior engineer would trust the computer more than themselves and can even go through code review, and that's when it's dangerous. I think it's going to get better when those type of hallucinations and things like that get… It's a solvable problem, I hope. But that's what scares me sometimes, that you see a code that looks amazing and looks like it makes sense, and you end up trusting the computer more and it might not be that good.

MICHELLE BU: You're skeptical of our ability to use it in an accurate way?

MIGUEL CARRANZA: Over trusting the computer. Overly trusting, yeah.

SHAWN WANG: I went to Figma's conference last year. And I'm based in San Francisco, it's just tooling city, everyone is trying to figure out how to use AI to build tools. And I think their chief product officer was talking about how it lowers the floor and raises the ceiling. Meaning, if you're a total beginner, it gets you started very quickly. You don't have to learn Stripe's APIs, you can just type in natural language what you're trying to do and it gives you a good starting point. And if you're an expert, it takes away a lot of the drudgery for you. But it's kind of that middle point. And then, by the way, I'm stealing this from a friend, who just said this to me yesterday, shameless stealing. But if you don't exactly know what mistakes you're making, then AI's not going to help you there. And it's a very dangerous feeling of over competency versus your confidence.

Everyone's excited about AI, and I've pivoted my content creation and my conference in AI engineering. But one thing I'm skeptical of is one of the things here, which is, Copilot for Stripe, right? Should Stripe have its own extension? Should every company have its own extension inside of the VS code experience? Maybe not. And I'm not saying, obviously, you have a lot of customized experience, but should everyone do the Copilot thing? Or should there be a God Copilot? Because I want to integrate Stripe with Clerk, and how do I do that? Stripe's Copilot extension is not going to know Clerk, but maybe a Copilot that has pluggable modules with the Stripe and the Clerk modules would be able to talk to each other in a happy fashion. Where do we draw the lines of the attractions is what I'm thinking about and I don't know the answer.

MICHELLE BU: Interesting. Like an interoperable agent…

SHAWN WANG: I want to call it a package manager for knowledge. When you ship your SDKs, why not ship a pluggable knowledge bank that you can stick into your Copilot? Instead of building 100 different Copilots, why not have just one really good one that takes a standard format? I don't know.

BRADEN SIDOTI: I feel it takes a step back from AI in that you just want these tools to be more interoperable. And I think the AWS or EventBridge or event streaming to another service, where one thing produces an action and then you want something else to do something, is the interesting thing. And then AI is, right now at least, just a lightweight glue wrapper of sticking these things together. But it's obviously not even close to being ready to create any of those individual elements.

And I think there was something else interesting about AI, which I don't know how it'll play out, but does it reduce people's insight into wanting to learn or figure out the thing? Or are you just going to keep searching until it just works? Which I feel we've had experience with that, with Stack Overflow. Of people just copying stuff from Stack Overflow and hoping it works, and until it does, is AI just like a faster version of that? Because at the end of the day, you really want to use it as a tool to help yourself learn. And I think that's, in the demo, it showed that off really well of helping you explore Docs and learn things quicker. But it has to come back to you and helping you learn.

MICHELLE BU: And understanding what context you want to slot that into.

BRADEN SIDOTI: Yeah, yeah, yeah.

MICHELLE BU: Iulian, do you have anything you're excited about or skeptical of?

IULIAN TANASESC: Sure, I think the… Of course, AI is the hot topic on everyone's mind. I like the point of being able to offload more of the coding into Stripe. So how much of the actual business logic and everything can live in Stripe, as opposed to living in an internal system. That's absolutely exciting. Especially looking at, you didn't demo automations, but that's also something that I believe we're going to be a big user of. And on the skeptical part, it's basically what everyone said. It's easy to get the happy path going. It's nice, it's shiny. The devil is always in the details. And for complex use case like ours in Atlassian, where we have complex billing models, complex multiple sales channels, multiple products, it can get complicated pretty soon. Seeing how we can address more of that.

SHAWN WANG: I have a non-Stripe, non-work related one, if you're interested.

MICHELLE BU: Sure.

SHAWN WANG: I've been wearing on me a pendant, one of the AI wearables, if you can see it. Every conversation that we just had, everything that we just talked about, is transcribed and recorded. And I can take notes on it, and query it and never forget. So what does it mean to never forget? What does it mean to actually take down all to-dos and have it triaged by personal AI? I think that is going to be developed over the next five years. We're going to have to figure out our comfort level over conversations being recorded, of course. But the personal productivity gains from me having a personal assistant on me at all times, I think is very exciting. So what trends am I most engaged with? Personal AI.

MICHELLE BU: Is there any part of that you're skeptical of? Or are you just very excited about this trend?

SHAWN WANG: I'm skeptical of the privacy concerns, obviously. I think Rewind and Limitless, I think they are very valid and they've taken the most precautions that I've ever seen against that. And then beyond that, it's just the black mirror nature, what if sometimes you're meant to forget things? So I think we have to figure it out. But I do think I would like to be able to turn it on and now we don't have it. We're going from zero to one there. And having the option of saying, “Okay, when I'm working, turn this on, because I want to record everything I did. For me, not for my boss. Just literally just for me to know what I want to work on and what I forgot to work on.” I think it's a pure win there.

MICHELLE BU: Do you tell people when you're recording?

SHAWN WANG: I literally just got this today, so…

MICHELLE BU: Oh, okay.

SHAWN WANG: Trying to figure it out. I just told all of you.

MICHELLE BU: Figure out the norms of—

SHAWN WANG: Exactly. And in California, it's a two-party consent state, but...

MICHELLE BU: We all consent.

SHAWN WANG: When I had this, when I put this mic on, I already consented to everything being hot mic'd everywhere. I think that the most interesting tech is on the boundaries of legality and social acceptance. If you're interested in that kind of stuff, it's robots, it's personal AI, it's that kind of stuff as well. Don't forget, it's not just Copilots.

MICHELLE BU: Do y'all have any trends outside of the immediate conversation? You're excited?

BRADEN SIDOTI: I'm still trying to decide if I consented.

MIGUEL CARRANZA: I don't write code anymore and it looks like I won't be able to code anymore with this tool, so—

SHAWN WANG: Well it doesn't have to be AI, right? This is a broader developer experience topic.

MIGUEL CARRANZA: I know, I know. I really like them even though it's only, it looks like it's only available for Amazon right now. But the destination was a super cool thing too. Because it allows you to do a lot more things. It's nothing that you couldn't do before. But it requires a lot more work and it simplifies things. All those integrations between different systems and pretty more common interfaces for them to make them easier is super interesting for getting it faster.

MICHELLE BU: Let's give a round of applause for our panelists. Thank you all for coming.

Thank you to everyone for joining us on stage. And thanks to everyone here in the audience for watching today. You're all part of the Stripe community, and we actually act on your feedback. We want more of it. We're not going to let any of you guys sign off today without showing you how to become more involved. As we know, you've been to a lot of different conferences where people ask you to sign up to keep in touch and then they send you marketing spam. This is not that. We really are serious when we say we need your help. Today, we're announcing the Stripe Insiders program. By joining, you'll get access to future tools, like the ones we showed you today, and a chance to provide direct feedback to our most knowledgeable engineers and product managers.

And by joining, you get first access to the invite-only developer tools we showed you today: Stripe for GitHub Copilot, Sandboxes, and Event Destinations. And if you want to use Workbench, it's already available for anyone who wants to enable it in their Dashboard today. So, check out insiders.stripe.dev to learn more. That's it for today. After this, if you have any questions, MG and Nilofer will be available at the expo hall developer tools booth and I'll be at the API design booth. Please do stay here for our panel on the future of developer experience hosted by Sarah Guo. We can't wait to see where all of you take Stripe next.