MICHELLE BU: Hello, and good morning everyone. There’s a reason this talk is my favorite part of Sessions every year. It’s not the big ships or the announcements—it’s all of you, and being with other builders.

I’m Michelle, I’ve been at Stripe for 12 years, and in that time I’ve learned more from developers like you than from anything we’ve shipped. We’ve had conversations over coffee in New York, reviewed code in Dublin, debated API naming in London, and online you’ve kept the Discord buzzing at all hours of the night and helped us find and squash bugs. That kind of shared context is extremely powerful, especially now. 2025 is such an exciting time to be a developer.

There’s so many new tools available to us and so many opportunities to build anything we can dream of. And we hear from you that it can be overwhelming. Many of you have told us that you’re juggling more responsibilities than ever before, from mastering these new AI capabilities to managing increasingly complicated infrastructure, all while you’re trying to ship quality code faster. Things feel complex to me, too. But today, we’re going to cover how we’re simplifying your experience with Stripe.

First, we know you want to spend more time building things that differentiate your business and less time implementing one-off processes. Second, you’ve told us you need Stripe to fit seamlessly into your existing tools and systems without writing and maintaining fragile glue code. And third, you need AI tools that automate the repetitive parts of being a developer while still leaving you in control of what matters, which is the creative problem solving that is why we became software developers in the first place.

So we’re going to dive into each of these areas, but in the spirit of learning together, I want to start with a behind-the-scenes look at something we’re doing internally at Stripe that touches on all three of these themes and is near and dear to me as an API designer. So the software industry is full of big claims and long-term bets. And everything you read today on the internet is about new AI moonshots. At Stripe, instead of moonshots, we think in terms of what we call roofshots. These are useful, achievable improvements that solve a clear problem today.

They’re not speculative bets or multiyear R&D projects—they’re focused, pragmatic changes that ship quickly and make your daily work easier. Moonshots paint such an exciting vision of the future, but roofshots move the needle now. And you can see the roof, and you can get there with just the ladder. So let me show you an AI roofshot that my team finds useful in our day-to-day work, one that helps Stripe scale our API development process.

Back in 2013, our API review process was just a few of us on couches in the office, bikeshedding field names over coffee, and having spirited debates about whether canceled is spelled with one L or two Ls. It’s one L. We could keep the whole API surface in our heads, we can name all the stars in the sky, but today, we manage over 500 API reviews a year, with more than 100 API reviewers across time zones. And our API has more than 550 different endpoints.

And each API review includes design decisions that shape your integration experience, sometimes for years. Now, you might think this is where I tell you that we’ve replaced all of our processes with AI. We haven’t. What we’ve learned is that AI isn’t about replacing human judgment, it’s about amplifying it. AI can’t replace those thoughtful design discussions about trade-offs, but LLMs are incredibly good at reducing cognitive load, especially when it comes to synthesizing a large amount of information and helping us find patterns across that information.

Let me show you. This is probably a familiar story to folks who have worked at any scaling company, but we have historical context all over the place. We have these Confluence archives of these historical hack pads that we used to use, including downtime for Confluence scheduled, not right now, which is good. We also have old Dropbox paper docs. We actually migrated off of Dropbox paper docs, so these documents are now archived and now migrated to Google Docs.

And then we have Google Docs themselves that capture our modern API reviews. And so we’ve actually used LLMs to distill all of that context into what we call an API archive explorer, which allows Stripes to easily find information about when certain fields were introduced and how they evolved over time. So if a Stripe engineer, for example, is building v2 of our Accounts APIs, they can see the full history of how we modeled everything on the account.

So we can see API reviews from API Review 149 when Accounts was first introduced in 2018 all the way to 3,328 in 2024. And so if I want to look at, let’s say, the business_profile field, again, I get that full history of the first review all the way to recent reviews over time. And each of these has a nice little LLM summary of the resolution and what was being changed in the API review.

So there’s no need for an engineer to manually search through old documents and emails, or to find that person from five years ago who has context on the change. We’re also working on an LLM-powered Slack bot that takes all of our decades of established API design patterns and takes a first stab at reviewing the API design. So before, our engineers had to constantly reference dozens of pages of documentation, or even memorize them, and keep up-to-date with the latest patterns to be effective API designers.

But now, they can get a first pass from a friendly bot, and it’s all within their existing Slack workflow, so there’s no need for them to learn a new tool or switch contexts. So in this example, the billing profile API review has missed quite a few required fields. It isn’t following the required format for object strings. So now, newer API designers joining Stripe can take this information and ensure their API review passes a first round of automated reviews before sending it to a human. Okay. So this just feels like a regular linter. What’s different or unique about it?

Well, first off, the LLM can handle the chaos of a human-written API design doc in Google Docs or any other editor that you can think of. There’s no structured input needed. And API design can be subjective. So even seasoned API designers get some nice suggestions—for example, making sure their list filters are rationalized and actually work well together so we don’t ship you something that doesn’t work. And our designers can now focus on the trickier aspects of the design, and of course, on actually writing code and building the API.

So why does this all matter? Because being able to consistently and thoughtfully maintain our design, and consistency is key to maintaining the quality of the Stripe product that you experience. And so your feedback, combined with the lessons we’ve learned building these roofshots to streamline our internal workflows, are what we’ll focus on today. Let’s start with how we’re making it easier for everyone in your organization to customize Stripe so you can write the code that matters to you.

When you think about internal business actions such as processing refunds, crediting customers, or routing reviews, they often have fairly simple logic to start. But as your business and team grows, the complexity of these workflows starts to grow as well. And usually what happens is that a nontechnical colleague needs help customizing some business workflow, and so it lands on your desk. And the requirements are clear. All of the code that you’re writing is only going to be used by one team, for one use case, for a few months. And then, of course, we’ll pay off all that tech debt as a fast follow in the future.

But we all know what happens next. Your one-off hacks suddenly become critical, and other teams start to rely on them. And now you’re maintaining something fragile, written under time pressure, with no margin for error. What if this didn’t happen? What if your team could build these flows without code and get better performance availability and reliability?

That’s exactly what Stripe Workflows enables. It’s a visual builder that lets you create, test, and run logic triggered by Stripe events. To show you how it works, I’d like to invite Tanya to the stage.

TANYA BOITEAU: Thanks. So Workflows allow you and your team, even nonengineers, to customize processes—all without writing a single line of code. Now, let’s see a demo to see this in action.

So I’ll start in the Dashboard, and I’ll navigate my way over to the visual builder in a sandbox. And this is where we’re actually going to build our workflow. So today, we’re going to build a fraud prevention workflow using Radar. And if you’re not familiar with Radar, it’s Stripe’s tools for fraud prevention. So this workflow will automatically handle Radar’s early fraud warning events, either by proactively refunding small charges or escalating larger ones for further review.

Now to get started, we have to choose a trigger, and this is what kicks off your workflow. This is what starts your workflow. And you can choose from just about every Stripe event. So for example, an invoice is created or deleted or finalized, a dispute is closed, because we’re using Radar, I’m actually going to choose Radar’s early fraud warning as our initial trigger. Now, early fraud warnings typically arrive before a dispute is formally filed.

That means that we have a chance to take an action before incurring a dispute fee or a chargeback. So now that we have our trigger, we need to decide what action to take next. I’m going to add a step and choose to add an action. And again, I’ll have access to just about every Stripe API action that I can choose from. But today I actually want to retrieve the charge associated with this particular fraud warning.

And now, this is where Workflows shine because you can dynamically reference data from previous steps. So I’m going to pull in the charge ID that was included from that early fraud warning, and we’re going to use that as part of the next steps—our decision logic. So let’s get to the actual conditional. I’m going to add a condition, and I’ll set a condition to check if the charge amount is less than or equal to $15.

And if it’s less than or equal to $15, just like I mentioned before, we want to proactively refund the customer. So we’re going to add an action, and we’ll decide to create a refund. Of course, we’re refunding the charge ID that was associated with that early fraud warning. Now, what happens if it’s greater than $15? Well, those are the ones we want to flag to someone to manually review.

So I’m going to add an email action. I’ll choose the team member to email. In this case, it’ll be me. I’ll include a little message there. And now, I’ve chosen $15 as the sort of decision, the cost of the decision, which way to go on my path, and that’s because that’s the cost of the dispute fee. So small charges are automatically refunded, and that means that that can save me costs up front, while still riskier ones are flagged for manual review.

We can add a couple more details to the email. So we’ve already got a note, but how about we include some data, how about the charge ID from that early fraud warning? Again, using that dynamic reference, I can include the charge ID, and we’ll pass that value in just like that. Now I’ll save these changes, and just like that, I’ve created a workflow that automatically handles early fraud warnings, either by proactively refunding small charges or escalating larger ones to someone on our team to manually review. So this helps reduce dispute fees and minimize fraud-related losses.

MICHELLE BU: Makes a lot of sense. Hey, Tanya, I have a question. Can a workflow get triggered twice for the same event? 

TANYA BOITEAU: Workflows handles idempotency for you, so we won’t do the same action twice. That means if we’ve already created a refund or we’ve emailed a team member, we won’t do that action again. 

MICHELLE BU: And can your workflow accidentally create an event that triggers itself? It feels like you can get into an infinite loop. 

TANYA BOITEAU: Great question. We handle recursion for you. So Workflows provides built-in recursion protection, meaning that if you accidentally retrigger the same workflow, we’ll stop it before it ends up causing you issues.

MICHELLE BU: So that all sounds fine when everything’s working well, but given this is all running on Stripe’s side, how do I troubleshoot and debug when things go wrong? 

TANYA BOITEAU: Yeah. And things definitely go wrong in the real world, so we’ve actually designed Workflows with that in mind, and then we’ve provided built-in observability. So let’s take a look at an active workflow. And I’ll go over, I will see my list of workflows. I will click on one that is active. And right here, you can see that you have got a list of workflow runs. 

So these are executions that have taken place along with the day, the time that it occurred, and the status. So I can see a number of these were successful, one failed, and immediately see the reason that that particular workflow run failed. I can choose to click into a particular run, and then I’ll get more granular information such as the execution flow of that particular workflow execution all the way to that point of failure.

MICHELLE BU: That’s awesome. Can I see more granular information like the logs or what API requests are being made? 

TANYA BOITEAU: Yeah. Absolutely. So you can also choose to click on any particular step, for example, the trigger, and I’ll see the trigger payload information. I can choose to click on any action or step and see both the inputs and the outputs of that particular API request, I can go down to this particular error. I’ll see error information. If I want to go deeper, I can also choose to drop into Workbench.

And Workbench is Stripe’s developer tool available in the Dashboard. So I can simply click on “View in Workbench” and immediately get more information related to the event, the request logs, API calls. Or for example, if I’m unfamiliar with a particular error, I can find the doc URL to go read more about this. 

MICHELLE BU: So teams using Workflows now no longer need to worry about retries, logging, or handling edge cases? 

TANYA BOITEAU: Exactly. 

MICHELLE BU: Great. Are there any features on your not-so-distant roadmap that you’re excited about? 

TANYA BOITEAU: Yeah, I think the most exciting one that I’m thinking about is the most frequently requested, which is for custom actions by our app partners. So for example, in that workflow, maybe you don’t want to send a note using the email action we’ve provided, but you’d prefer to use that—that’s recommended by your own organization. That’ll be coming soon. So if you build apps, you use apps, or you need custom actions, you can count on those being available very soon. 

MICHELLE BU: And since all anyone is asking about is AI these days, is AI or agentic action something you are considering? 

TANYA BOITEAU: Yeah. So I think we will start by making it easy to build workflows using natural language. So just describe what you want, no config. Then, we will start to take it a step further and we’ll look at adding agentic actions. Now, you can think of an agentic action as a smart step in your workflow where an AI-powered agent takes the lead. So it uses the built-in tools to decide and act on your behalf. 

MICHELLE BU: Awesome. Thank you, Tanya. 

TANYA BOITEAU: Thank you. 

MICHELLE BU: Stripe Workflows enables you to create custom no-code flows that streamline processes, allowing you to, again, concentrate on writing the code that truly differentiates your business. And I’m excited to see what you all will build with it. Before we move on, let’s zoom out. So far, we’ve shown you how we’re helping you work faster inside of Stripe. Better workflows, better automation—but most businesses don’t just run on Stripe. 

You run on dozens of systems, each with their own data models, logic, integration quirks, and connecting all these systems is usually your job. So what if Stripe didn’t just work better on its own, but worked better with everything else, simplifying things in the process? To share more on how we’re making that shift, I’d like to invite David Richardson, who leads our developer platform here at Stripe. David actually joined Stripe two years ago from AWS, where he led their serverless business, and he’s an expert in building platforms and ecosystems. Welcome, David

DAVID RICHARDSON: Thanks, Michelle. We know Stripe isn’t the only system you depend on. Most organizations use a lot of tools. Gartner reports the average company uses over 125 different software providers. Now in the past, you faced the choice—go all-in with Stripe for your entire financial stack, or write mountains of code to connect the different systems and providers together. 

That second path has always required a lot of development effort to write and maintain integrations, including all of the authorization, failure handling, monitoring, etc. What we’ve been sharing at Sessions today ultimately adds up to a big shift. We’re evolving towards a more modular and extensible Stripe that is easier for you to use with the systems your business depends upon. 

Let’s look at a few examples. So today, we launched our new payment orchestration product, which allows you to route payments to different providers, like Worldpay. And I know what you’re probably thinking—while this might seem competitive to our own payments product, the truth is organizations are already using multiple payment processors. We just believe that you shouldn’t have to write and manage the complex integration and payment routing code yourself. 

Stripe should do that for you. Another example of modularity is tax calculation. Many of you rely on Anrok or Sphere or Avalara to power your business, and you need them to work better with Stripe—again, without writing integration code. Now, with just a few clicks in the Stripe Dashboard, you can switch from Stripe’s built-in tax calculation engine to one of these providers. 

To show you how we’re making this possible, let’s walk through an example. Until now, calculating tax on Stripe transactions, such as the line items on an invoice, has only been possible with Stripe’s logic. But now, we’ve added a new concept we call an extension point. You can kind of think of it as a point in the flow of Stripe’s product logic that can accept an extension. It’s like a socket that you can plug an extension into. 

This lets an extension replace or modify the Stripe product logic. So in this case, we can plug one of the tax calculation extensions into the socket and it will change Stripe’s behavior at runtime. These extensions are powered by new additions to our extensibility platform. For many years now we’ve worked with partners who use the extensibility platform to publish hundreds of apps in the Stripe Marketplace. 

The platform has always made it easy to authorize third-party services and customize the UI of the Stripe Dashboard, all in service of making it easier for you to integrate Stripe with the other systems you depend upon. And now we’ve added support for three new kinds of extensions. The first is a remote function extension, which the tax apps are using to call out to their services for real-time tax calculation. We’ve also added workflow and script as new extension runtimes. 

A workflow is the underlying technology used in both our payment orchestration and workflow products. And as hopefully you saw in this morning’s product keynote, the script’s runtime now lets you customize Stripe’s billing engine. Soon, we’ll add more billing-related capabilities, letting you customize proration logic, how line items are grouped on an invoice, or even the underlying HTML of the invoice itself. We’re going to continue to expand what scripts can do.

In the future, you will be able to use TypeScript to not only customize Stripe Billing, but the rest of Stripe’s products. One of the key lessons I learned at AWS was a concept called primitives, not frameworks. And I’ve seen developers build amazing things when you give them a good set of composable primitives, rather than a rigid framework—so they can pick and choose the combinations that work best for their businesses.

And that’s what we’re doing at Stripe. We’re investing in a composable platform, so we can rapidly add more extension capabilities in the future. More extension points, like third-party actions in Workflows. Rich runtimes. New opportunities for you to mix and match and compose in ways that we haven’t imagined. So thank you for all of your feedback, and we can’t wait to see how you build on top of Stripe. 

MICHELLE BU: Awesome. Thank you, David. Stripe’s commitment to extensibility is a multiyear vision. What you see today with multiple payment providers and tax calculation engines is really just the beginning. We’re investing heavily and making it easier for you to customize and extend Stripe in whatever way makes sense for your business. We want to make it easier for you to use the software that you love with Stripe. So we’ve talked a lot about how Stripe is using AI, but what about how AI is changing what it means to be a developer? There’s no one closer to that future than Michael Truell. 

Michael is the CEO of Cursor, and if you’ve been watching the rest of the sessions, you may have noticed that we are big fans of Cursor. Cursor is an AI-assisted editor that developers have come to love not just for vibe coding, but have also worked in as a critical component of their end-to-end developer workflows. We use Cursor at Stripe as well, and we’ve seen that it’s multiplied developer productivity for teams that have adopted it. Let’s hear more from Michael himself. 

MICHELLE BU: All right. How many of you have used Cursor recently? 

MICHAEL TRUELL: Wow. 

MICHELLE BU: That’s awesome. And how many of you have gotten an email from Michael recently about your use of Cursor? Great. First question for you. Are those emails from you? 

MICHAEL TRUELL: They were written by me at one point, and then they’re—yeah, they’re a template edit. [Laughs]

MICHELLE BU: But you—

MICHAEL TRUELL: But not written by AI. 

MICHELLE BU: They’re not written by AI, right? 

MICHAEL TRUELL: Yes.

MICHELLE BU: So you wrote your bespoke words into those emails? 

MICHAEL TRUELL: Yes. Yes. 

MICHELLE BU: And then—yes.

MICHAEL TRUELL: Yes. 

MICHELLE BU: That makes a lot of sense. Cool. So looking ahead three years, we can see that AI is going to change the software industry. And on the spectrum of it’s a lot of hype to software will completely change, where do you think we’ll land? 

MICHAEL TRUELL: I think it’s going to be somewhere in, I think it’s going to be towards software is going to completely change. But I think it’s going to be a little bit different than the visions of how software changes that have percolated throughout the online chatter. 

In particular, we’re a company that definitely doesn’t think that the future of software is you’re just talking to some disembodied chatbot that builds—you know, writes all of your code for you. We think that, instead, right now, the state of AI is you have AI helping you as kind of like a helpful bot in a bunch of different places. One way these bots help you is they’re looking over your shoulder, predicting the next set of things you’re going to do within a code base, and noticing when you’re in the midst of an incremental refactor and helping you out with that. 

And then the other way that these helpful bots are helping you right now is you can go ask them a question about your code base, or ask them to make a small change throughout your code base. And both those two form factors of the helpful thing looking over your shoulder and also the helpful bot that you can ask to make a change throughout your code base, those are going to get a lot more powerful, they’re going to get a lot better. But then one change that we’re really interested in as the years go on, is we think that AI will also change the future of programming languages. 

And we think that the space of thinking about how you can evolve programming languages to be higher level and more productive, and a little bit less formal, and viewing LLMs as kind of a type of compiler or interpreter technology, is a really interesting space to play in, and we think that that will play a really big part in the future of software development as this tech matures. And I think at a high level, the job of a programmer has always been to kind of design the logic of a piece of software. 

And we think that going forward many, many, many, many years into the future, that will still be the role. It will just be the less fun parts of the job that can go away. You can kind of focus on really just getting your intent for what exactly you want into the computer. 

MICHELLE BU: Yeah. You used a term called low entropy work. Like, the bots will do a lot of the low entropy work. 

MICHAEL TRUELL: Yes.

MICHELLE BU: What do you mean by that? 

MICHAEL TRUELL: Yeah, I think that programming is this interesting form of text editing where sometimes the edits you’re making are really low entropy. I would contrast this with writing. 

And so one of the main AI form factors that exists right now in programming and across a bunch of other tools is autocomplete. Having something looking over your shoulder, predicting the next set of things you’re going to do. I think autocomplete is helpful in writing products, but I think that nonprogrammers kind of underestimate how useful autocomplete can be made for programmers, and what the ceiling on that is. And that’s because sometimes when you’re programming, you’re in this vast pool of logic, and you’re editing something over here. 

And you editing something over here breaks stuff over here, and it means that you have to go change stuff over here in one very predictable way. And so there are really some times when you’re programming where the next 10, 15 minutes of your work are entirely predictable. And so that’s kind of the low entropy side of that. 

MICHELLE BU: And so you see the bots taking on more of that low entropy predictable work?

MICHAEL TRUELL: Yes. 

MICHELLE BU: And then programming will become maybe more like writing in the future? 

MICHAEL TRUELL: Yes. I think that there will always be differences between it and writing. 

And I think that, some of the properties—I think a lot of the properties of programming languages, you will always want to have around for, like, written-down representations of the logic of a piece of software. For instance, syntax highlighting, I think, is really important for visually differentiating between things. Linting, I think, is a really, really, really important property. I think the naming of logic and the using—you know, taking a building block of a primitive piece of logic, naming it and then using it in a bunch of other places, I think that will always exist, too. 

MICHELLE BU: That makes a lot of sense. And since you’re at the forefront of understanding the changes that are to come in the industry, how are you thinking about hiring? What kinds of skills are you looking for as you’re hiring developers for Cursor? 

MICHAEL TRUELL: Well, we’re doing a lot of it, first. 

MICHELLE BU: Yeah. You’re still hiring lots of developers. 

MICHAEL TRUELL: Yeah. And it’s kind of crazy. I think that in this world, I think we’ve—I feel like people who have been programming for a very long time, who have been working in professional development for a very long time, have become inoculated to how slow things can move, especially when you have hundreds of people working on a development project, and you have tens of millions of lines of legacy code. 

And I think that on the hiring side of things, just how much more productive developers can be in this next phase, actually, for us, it makes hiring way more attractive. There are so many things we want to do, and each person is now much more productive, so the prospect of bringing them onto the team is that much more attractive. 

But on the hiring side of things, I think that mostly our process looks pretty similar to some of the best processes in bringing developers onto a company from the past five years. In particular, like many great companies in the past, we look for learning ability, I think, primarily over experience with one particular stack. And I think that with stacks changing so quickly, with things moving so quickly in AI, I think that that learning ability is even more important now than it has ever been before. 

One thing that’s funny, too, to note is for our engineering interviews, we actually don’t let people use AI for the hour-long interviews. Because I think that it’s two things. I think one kind of normal programming in a scoped-down technical problem is still just a great proxy for learning ability, for thinking ability. And then two is we run into lots of programmers that are fantastic, but they actually don’t use AI tools yet. 

MICHELLE BU: Right. 

MICHAEL TRUELL: And we don’t want to discriminate against those folks. We would much prefer to bring them onto the team and very quickly teach them how to use AI tools. And we’ve seen people flourish who started—

MICHELLE BU: Yeah. And that’s why we’re evaluating for that learning. So even if they don’t currently use these AI tools, they’re able to learn very quickly and they get ramped up?

MICHAEL TRUELL: Yes. Yes. Whereas if you were going to give those folks a one-hour programming problem, say everyone can use AI tools, and 50% of people don’t, then I think it would unfairly discriminate against those folks who don’t get to use them. 

MICHELLE BU: Yeah. That makes a lot of sense. And as you’ve seen those folks ramp up at Cursor, have there been any surprises in their learning process? 

MICHAEL TRUELL: Well I think that those people have been really helpful to, or one nice side effect of having those folks come join the team and ramp up and have no knowledge of AI tools is you get to hear the product insights that comes from a beginner’s mind using the tool. And so all of the things that seem surprising and counterintuitive and too complex, those are like pieces of gold that you want to mine from those people. 

And so that’s been helpful, and I think that especially on the complexity side of things, it’s been helpful to hear feedback from folks there. I think another thing that we try to beat the drum on when it comes to AI tooling in a professional development setting is you really want to scope down the task that you’re giving to the AI. And so one way to do that is a lot of professional developers still lean incredibly heavy on variants of autocomplete to do their work. 

And in Cursor, we’ve spent a bunch of time trying to push the ceiling on autocomplete, taking it past just characters after your cursor prediction to predicting the next whole diff around your cursor, the next sequence of diffs across multiple files. Making that increasingly understand your entire code base. But I think it’s been—we’ve definitely beat the drum on you should scope down the problems that you’re giving to the AI, and I think that one thing that’s been surprising in seeing some beginners use AI tools in a professional setting is sometimes they kind of go overboard. They go crazy. They try and one-shot PRs everywhere. 

MICHELLE BU: One-shot adding confetti to the app.

[Laughter]

MICHAEL TRUELL: Yeah. It’s something like that, or even much bigger, complicated changes. And then they kind of fall on their face, and then there’s this trough of disillusionment. And so I think that a lot of spinning people up on these tools is teaching them what the right happy medium is, where you’re using the AI, as much as you can, but not going overboard. And we would like to work that into the product much more, too, in the future. 

MICHELLE BU: Are you kind of, like, building these best practices over time? Like when you first started Cursor, did you think, oh, we can one-shot PRs all the time? 

MICHAEL TRUELL: Yes. So we totally did. And so I remember we got early access to GPT-4, actually. Before it was launched to the public. And there was a 48-hour period where it was like, oh, my god, AGI has been achieved. [Laughs] We were, like, trying to have it right. All these crazy, a bunch of crazy Rust and Go networking code, basically. And super, super impressed. It was very much the style of just asking the AI to do everything for you. 

And then very quickly, you kind of run into limits of that type of programming with the technology where it is right now. But, yeah. No, that happened for us, and then I think that one important part of our product development process has really, really, really been building for our team writ large. We just talked about the kind of building for folks who are spinning up on AI coding tools that join the team for the first time. But in general, you can’t really hide from yourself. 

And so if you have a company that’s filled with developers that are using your thing every day, and you have this newfangled feature that you think is great, it’s going to make people much more productive, and then no one in the company is using it? You can’t really hide from that. 

MICHELLE BU: What’s an example of something where you thought it would be really cool, but no one in the company has used it? 

MICHAEL TRUELL: So I think that there’s—sometimes it’s small incremental things that sound like they would be great at the whiteboard, but then when you try them, it falls short. An example of that would be making the context-building for Cursor slower, but more accurate. 

And so there have been, oftentimes, where we’ve tried different variants of that, sometimes successfully, but there have definitely been versions where we’ve added a second or two of latency to the app, and it’s just not worth it. 

MICHELLE BU: I see. Because people want to move fast. 

MICHAEL TRUELL: They want to move fast, yes. 

MICHELLE BU: They’d rather have fast, but inaccurate, AI. 

[Laughter]

MICHAEL TRUELL: Well, hopefully fast, but accurate. 

MICHELLE BU: Yes, eventually.

MICHAEL TRUELL: The best would be fast, but they can rock and move really quickly, and iterate with the AI. But that’s one example. 

And then there are other examples that are like whole crazy contraptions of, hey, perhaps the way you should be iterating with the agent is less of like call and response, chat back and forth, and maybe it’s you should be working together on some document to begin with. And so there have been specific versions of that idea that have sounded great, but then, you know, not actually been that useful internally. 

MICHELLE BU: Yeah. Are there any novel uses of Cursor that you’ve seen? 

MICHAEL TRUELL: I mean, there are tons. It’s a very, very horizontal tool.

And I think one of the side effects of the tool having grown so much to so many people with a small team is like—probably I’m not even aware of many, many of the awesome use cases or awesome ways people are using Cursor out in the world. And the ones that do cross our radar often, often surprise us. But you know, I think it’s everything from people being very conservative and sticking to the kind of scope-down everything in bits, to there are some people that are really pushing the boundaries of using AI to the fullest extent. One example of that internally is we have a designer who actually originally worked on Stripe Checkout—

MICHELLE BU: Yes. 

MICHAEL TRUELL: —way back in the day, who’s fantastic and is very, very AI-forward, a little bit technical. And he’s effectively built a web emulation of the original Macintosh kind of 1984 operating system. And it’s got its whole own file system, and it’s got 12 different apps on it. It has a fully working Minesweeper in it. It has its own AI code tool within the operating system, too, that he’s built. 

And all of that is from writing very, very, very little code. And he’s done it through, like, a complicated sequence of formatting the prompts and having kind of the right files, preserving context throughout the code base. 

MICHELLE BU: Interesting. That’s really awesome. And looking ahead, you’re thinking about building Cursor for the long term. You’ve mentioned this in many contexts. How do you think about creating the environment where you’re able to move really quickly, because this space requires that you move really quickly, but also build your company and your product for that long term? 

MICHAEL TRUELL: Yeah, it’s a great question. It’s one we think about a lot. And the reason we think about this is I think that the best tool in the space in a few years will look very different from Cursor, and it will be much more useful than Cursor. And the end goal for us is to evolve building software into something that’s way higher level and more productive. Again, kind of the low entropy work, the kind of toil involved in software should, as much as possible, be replaced with focusing on what matters. 

Which is the human having control over the logic of the software just inputting their intent into the computer. And like I said, that might flow through the future of programming languages. And so we want to make sure that we have space and bandwidth and the right environment to play with those ideas in addition to, you know, we have millions of people using Cursor, relying on it; lots of large organizations using Cursor and relying on it. And we want to continue to make the plotting improvements to make Cursor fantastic. 

And so for us, I mean, I think that’s still—we’re still trying to figure out how exactly to do this well. I think if you study kind of the aspirational examples that everyone’s familiar with, like the teams that create the iPod and the iPhone, I think one important element to that is taking a fantastic, really small group of people, and kind of separating them from the rest of the company to play with ideas in the kind of zero-to-one generative phase. And then I think it’s about being very careful around when you want to take an idea that’s ready and scale it up. 

But mostly that finding the exact right group of people who are autonomous, can learn quickly, are creative, and giving them kind of the space to run for a bit separate from the company I think is really important. And I think that actually, you know, another example of this that’s kind of very close to us is I think that I think this mirrored the way in which GitHub Copilot, from what I understand, was created within a large company. Where Copilot was the first AI coding product to market, still a big inspiration for our work. 

And as I understand it, the way that it came about was the leadership within GitHub at the time—which is no longer there—said, hey, we would like to figure out a way to take GPT-3, use it to make developers more productive, a tiger team of ICs was created, and they were just shielded from the rest of the company and given time and space to work on whatever they would like. And they had this winding, long-run experimental process where they started with trying to automate PRs end to end. They had some interesting ideas around bug finding. 

And then it took them actually a year to figure out the first version of the characters after your cursor ghost-texts to autocomplete that Copilot is. And I think that that’s an example that’s near and dear to us, and is aspirational, when we think about the next big jump to come into this space. 

MICHELLE BU: That’s cool. And how many engineers does Cursor have today? 

MICHAEL TRUELL: We have 55 engineers. 

MICHELLE BU: Fifty-five. And so you also have these small pods even within Cursor to kind of think about experimentation? 

MICHAEL TRUELL: Yeah. So we have a couple of small pods off to the side. 

Most of the team is working on there are just all of these ways that Cursor could get better that we know we really, really, really want to do. And it’s about working on those effectively together. 

MICHELLE BU: That’s awesome. And what are some things in your roadmap you’re excited about? 

MICHAEL TRUELL: So a couple of things. So one is excited for the agent within Cursor to be able to spin off into the background. And in the times when you want it to just go think for a couple of hours and then come back to you with 70% of the thing done—you should be able to do that. 

And so you should be able to very quickly switch between the background side of things and break out of the confines of your personal computer, and then the foreground, really quick iteration side of things, too. So excited about that. Excited for Cursor to get much better at understanding really large code bases, and to know this is something that we feel—actually, the engineering work we do inside of Cursor is very variable. And one of the code bases we work in is a large legacy code base with many millions of lines of code. And so excited for Cursor to understand large code bases much more. 

And then also excited for Cursor to hook into your execution environments more and more, and actually run its work, and react to the output of its work. And then there are a bunch of other improvements we’re excited for, especially on the speed side of things. 

MICHELLE BU: We’re also very excited for Cursor to work well on large code bases. 

MICHAEL TRUELL: Yes.

MICHELLE BU: One more question. So you’ve talked a lot in podcasts about how important it is for programming to be, like, fast and fun.

MICHAEL TRUELL: Um-hum.

MICHELLE BU: What is the most fun that you’ve had programming? 

MICHAEL TRUELL: Well, when I started programming, it was on games. So it was stuff like building mobile games with friends, building an ill-fated game engine in C++ and OpenGL, kind of trying to do everything from scratch. And then I think one of the most visible games that I worked on with friends was a game built for programmers called Halite. The idea here was we saw lots of people building bots to play chess and to play Go, and these human games that humans assigned importance to. 

And the problem with that act of building chess bots and Go bots was it wasn’t that fun. Like, they were interesting AI challenges, but they all worked very similarly, all these bots, where you would have a game tree of possible game states, and you would kind of try and go down the game tree as fast as possible to figure out, you know, if you played one move, does it look like if you actually play out all of the states like your opponent might play? Is that move going to be a good one? And then the hard thing about Go is, Go has this really large branching factor. And so it’s hard to go down that tree. 

And so you need AIs to help you prune the tree and figure out which paths to go down, and that’s kind of the genesis of AlphaGo and DeepMind’s work in beating humans in Go. We said, hey, we don’t want anyone to be building these game tree bots. Let’s just make the branching factor really, really, really large, and instead, you’re going to have to think critically about what you want the bot to do. And that was the genesis of Halite, which was a series of programming competitions where we designed original games for programmers to program for. And tens of thousands of people played it all around the world, and it ran for four years. 

And that was incredibly fun. And I think that also working on Cursor is a joy too, because you have this feedback loop of if you make the thing better, like the pane of glass that you’re working in, you feel it immediately. 

MICHELLE BU: That’s awesome. So you built games that were harder for AI to solve? 

MICHAEL TRUELL: Yes. Yes. In some ways, harder. Like, harder for the normal techniques people use to write bots to play games to solve. Just out of the box.

MICHELLE BU: That’s awesome. Let’s give it up for Michael. Thank you. Thank you, Michael. 

So we started off this talk by giving you a peek behind the scenes of our internal API development process. There’s another Stripe tradition I wanted to share. Every Friday at our company-wide fireside, we have a segment called “Tabs,” where Patrick [Collison] shares his browser tabs with cool projects that are happening around Stripe. He also tosses in market updates, good articles, whatever else he’s interested in that week. 

I thought we could do our own version of Tabs to close out this talk and leave you with a few more areas we’re building for but didn’t get time to touch on today. So this is a bit of a speed round. Usually, Patrick does tabs at 100 miles an hour, but I’ll do it at the speed limit. Don’t worry about following everything. The QR code on the screen will take you to a single blog post with everything we’re about to cover. So let’s get started. First off, AI Assistant in Stripe Docs. Now you can simply highlight any piece of text in Stripe’s documentation, and you can pull up our inline AI Assistant right on the page. 

You can ask clarifying questions or have a conversation about Stripe concepts with an LLM trained both on our docs and on our internal knowledge base. Next, our model context protocol server for LLMs. If you’re using Cursor or Claude for agentic coding, you can now add Stripe’s MCP server and give your LLM copilot both the ability to make Stripe API calls on your behalf, and a richer library of Stripe documentation. One command to take your Vibe coding with Stripe to the next level. 

And what if you’re building an agent yourself? Unlike a copilot, an agent can perform tasks and make decisions autonomously, and Stripe now has an agent SDK that offers Stripe tools for your own custom agents to use. For example, your agent can use these tools to accept funds in support workflows, or even cooler, if you’re an issuing user, you can actually issue your agent a credit card to spend from, then send them to a website to buy something for you. 

David talked earlier about Stripe Apps, but what features are actually new for Apps? Well, for the app developers here today, your apps can now feel truly native to the Stripe Dashboard. You can use our large mobile components, or show your app directly on detail pages for richer interactions. The line between Stripe and your app just got a lot blurrier in a good way. 

And for those building on iOS and Android, those same Connect-embedded components you know and love are now available for mobile apps. So now you can include fully localized user onboarding flows to your app with just a few lines of code. And, fun fact, our own mobile app onboarding experience was built in record time by a very small engineering team using these embedded components. 

For a decade, if you used multiple products such as Payments or Billing or Issuing and Connect, you’d have to manage a different record of your user for every single product you used. This meant managing multiple IDs and synchronizing data across all these records. Accounts v2 merges these separate APIs into a single API, meaning cleaner data, fewer duplicated records, and the ability to use your users’ balances for multiple use cases. If you want to learn more about Accounts v2, there’s actually a breakout being hosted by Katelyn and Rod from the Connect team in this room right after this. 

Back to web. You’ve always loved how simple it is to get started with Checkout, but as your business grows, it’s important to have the flexibility to customize your UI. And so you wanted Elements UI flexibility with Checkout’s simplicity and built-in features like A/B testing, and adaptive pricing, and one-click to turn on Stripe Tax. Today, you no longer have to choose. The Payment Element now works with the Checkout Sessions API, which provides you with the flexibility of our modular elements with the ease of integration of our Checkout Sessions APIs. 

And finally, one of our most requested features is now available in preview. You can now automatically share customers and payment methods across multiple business lines in your organization, all without writing any custom synchronization code. It looks like Bob here has payments with Acme Eats, Acme Deliveries, and Acme Rides. And Sandboxes now has support for organizations as well, so you can test the sharing experience end-to-end. 

That was a lot, and hopefully you got some good shots to follow up on later. So what have we covered today? Well, we’re making it easy for you to customize Stripe with new tools, like Workflows. We’re ensuring Stripe works in a much more integrated way with your existing tech stack. And we’ve heard from Michael and throughout the morning about how AI can amplify your team—all so that you can focus on the code that makes your business unique. Stripe’s best work comes from your feedback and your challenges shape our roadmap. Your workarounds become our features. 

And so this week isn’t just about what we’ve built, it’s about where we go next together. So please share your thoughts and feedback with us, and thank you for being the most important part of Stripe’s journey. Enjoy the rest of Sessions.