Michael Truel (4:05)

The company, did they know before they joined?

Patrick Collison (4:07)

No, no, they learned really quickly. And then you have smart people learn languages really quickly, so I don't think that's really a reason not to use a non mainstream language. The company didn't work, I think for unrelated reasons. I think just the idea wasn't that strong. But we also chose Ruby for Stripe, so I don't know, I think maybe the gains were not quite as large as I hoped.

Michael Truel (4:25)

And was your small talk enthusiasm shared by the acquirers of the startup? And what was the dynamic? Was there this blissfully ignorant management that foisted this Smalltalk code base on a bunch of unsuspecting developers that were then kind of like piling it over or. Yeah. What was the dynamic between the programmers, management? What happened to that Smalltalk code base?

Patrick Collison (4:45)

Yeah, yeah, yeah.

Michael Truel (4:45)

Does it still live on somewhere?

Patrick Collison (4:47)

I wish. And I'm 99% sure the answer is no. The company that acquired us was mainly a talent acquisition, so the code base itself was less relevant.

Michael Truel (5:00)

Okay. And it was immediately sort of just gone.

Patrick Collison (5:02)

Yeah, okay, gotcha.

Michael Truel (5:03)

I've also heard that one of your earliest programming projects was working on an AI bot written in Lisp, and it was something like it was a client for msn.

Patrick Collison (5:15)

I know where you found that, but that is true.

Michael Truel (5:17)

And I heard that you got kind of nerdsnight by the idea of trying to get it to pass the Turing Test.

Patrick Collison (5:21)

Yes.

Michael Truel (5:22)

And I'm curious, what did you miss? Why didn't you make chatgpt? And, well, maybe a little bit more seriously, how did it work? And what was the state of neural networks at the time? And did you consider using any antecedents to the technology we use today?

Patrick Collison (5:36)

Yeah, so that was the project. It was a little critter that used MSN messenger, which was all the rage at the time. I guess that's like maybe a specific kind of sedimentary layer in the chronology of different instant messaging solutions and probably dates me quite precisely. And it was a really simple Bayesian next word predictor. Like, there was nothing really that sophisticated there to the hint there was anything sophisticated. It was maybe that it used like the training data was the conversations itself had on MSN messenger rather than kind of general text corpa. And it worked reasonably well and better versions looked a couple of words ahead and what have you. I mean, it never really passed the Turing Test where people have actual suspicion they're trying to exercise this discernment, but it certainly passed some weaker versions of the Turing Test where they were unsuspecting and people ended up having quite lengthy conversations with it. And that was part of how I discovered Lisp. And I remember Paradigms of AI Programming by Peter Norvig being a really formative book and had all sorts of interesting approaches there. It didn't have anything on neural networks, I'm almost sure. I mean, I'd read some Marvin Minsky stuff, Society of the Mind or whatever, on neural nets, but I never really seriously looked at them. And I actually experimented a lot with genetic algorithms. They were, I guess, more practical on your own computer. It takes a lot of computer training and all that. So I experiment a lot with genetic algorithms. And actually I use VORAK at the keyboard layout because it's more comfortable to type on than qwerty, but. But as does John, my brother. So no one can ever use our computers. But I wrote a genetic, I don't know, optimizer to figure out what the optimal keyboard layout was. And it turns out it is in fact basically Vortak using a genetic approach. So I went deep down that rabbit hole, but I never really played with neural networks. And I guess that's why that. But probably 70 other reasons is why, you know, I did not create ChatGPT.

Michael Truel (7:38)

There is an old video of you being interviewed, I think after selling octomattiq where you're asked about smalltalk. That's where I found kind of that weird fact. I think at the time people asked you why and one of the things you said was, I mean, you liked some features about smalltalk Lisp style languages and you predicted, and I think that this was circa maybe 2008 or something like that, that the mainline C style programming languages would increasingly borrow ideas from these older programming languages. And that kind of has been the case in the JavaScript Python ecosystems. Do you think that there are any underrated ideas buried away in kind of older, more esoteric programming languages that should be borrowed by the mainline?

Patrick Collison (8:15)

Yeah, it's been interesting how a lot of the ideas have been borrowed by the JavaScript ecosystem. And in a strange way, like through the Web Inspector, where you have this, I mean, that's one of the richest runtimes in some sense that people have general exposure to. I don't think JavaScript has first class stack frames. Maybe there's some weird extension or something where you can get that, but ECMAScript doesn't have that. I'm pretty sure first class stack frames actually let you do a lot of other things for kind of obvious reasons. So maybe that's kind of too specific. I mean, I think the idea of, and maybe this is what cursor becomes. I think the basic idea of as development environment and not just text editor is really the right idea. And that's the thing I want to see a return to. That's the thing that the Lisp machines had and genera. That's the thing that to some extent Mathematica has. That's the thing that smalltalk has. And I think it's just such a mistake that we have ended up with development environments where there is such a separation between the runtime, the text editing and the environment in which the code, I mean the runtime and the place where the code runs can be the same or different, but there are kind of three maybe slightly conceptually different things. And in those three environments they can all coexist in the same place. And I find like, I mean, still to this day I use Mathematica a lot, not because I'm doing some particularly arcane symbolic mathematics, but because it's just a more efficient development environment. Now that's maybe a bit less true with LLMs, because the Mathematica does not support cursor style prompted development. But that I think is the core idea that I wish others would borrow. And VSCode has been a step to some extent slightly in that direction. I think we could take it way further and it'd be really. I mean, what I'd love to see, for example, is when I hover over a line of code, I would like to see profiling information about just the runtime characteristics of that code or that function or whatever. I would like to see logging and error information overlaid. When I hover over a variable, I would like to see how the most common values that it takes on in production, these kinds of just rich, deep integrations.

Michael Truel (10:37)

Are you a fan of inventing on principle and this talks?

Patrick Collison (10:39)

Yes, yes. I think Brett leans too much. I mean, a huge fan of Brett. He's such an incredible.

Michael Truel (10:46)

Have you been to Dynamic Land?

Patrick Collison (10:47)

Yes.

Podcast Narrator (10:48)

Okay.

Patrick Collison (10:48)

Yep. And have supported it. So, huge fan of Brett. The place that I've maybe differed or at least that just resonates with me, you know, somewhat less, is Brett is really into this idea of obviously of graphical and visual representations for phenomena. And I think that works very well in certain domains, like the kinds of dynamical systems that he has demonstrated some of the ideas with. I think it's often very hard to find such useful spatial continuous representations for arbitrary systems, like for various parts of Stripe. I'm not quite sure what that would be and I'm not sure even if we could find us exactly how useful it would be. Maybe it's just me. I reason much more kind of symbolically and sort of lexically than I do visually and graphically. It might just be personal preference, but I don't know. The kind of paradigm breaking that he's been engaged in, I think is hugely admirable. Are you going to make a truly integrated development environment?

Michael Truel (11:53)

So we are playing with ideas around letting the AI increasingly take time into the background to run as code and react to the output. And we think that this should all work well together. We focused a ton on inflow, speed and control and we think that that's really, really important for AI, is to give programmers the control over everything, have them understand everything the AI is producing, also to give them really, really fast iteration loops. Programmers hate waiting for things, but in some cases we think it's now becoming possible to go tell the AI to think for a bit and then come back to you and have the API be a little bit more like the API with another human being. And we think you want that all to work well together. So the AI can come back to you with 70% of something and then you can bring it into the foreground really quickly, work with it, and then spin it back off to the background. And as part of having the AI spend a bunch of time thinking in the background, to make that thinking useful, you kind of needed to run the code and then react to it. Or else it's just kind of staring at the thing that it wrote and thinking more.

Patrick Collison (12:51)

Maybe I'm supposed to be the one answering the questions rather than asking them. But do you think in five years the main thing that I'm looking at in cursor will be code or something else?

Michael Truel (13:06)

I think it might be something else. I think that there are big, big, big simplification. But kind of when you're defining what a piece of software is, there's like the logic component, which is what engineers spend a lot of time on, of designing exactly how the software works. There's also for end user applications and things that have GUIs, there's like this visual component. And I think that there is, you know, maybe it's going to be us, maybe it can be someone else. There is a future version of the world where the way you interact with AI is a little bit less like, you know, it's a human helper that you're delegating work to or looking over your shoulder, predicting the next set of things you're going to do. And instead it's a little bit more of an advance in compiler or interpreter technology. And it could lead you to a world where programming languages actually change and they can start to get a little bit less formal, they can start to get a little bit higher level, they can start to be a little bit more about what you want and a little bit less about how you do it. And I think that it won't look like a Google Doc necessarily. I think that there are things you want to keep around from programming, like the naming of logic somewhere and then using that in a bunch of other places. I think that there's also this other element too of the visuals of what a piece of software looks like. And I think maybe us, maybe some other tool, but I think there's a world where kind of direction manipulation of the UI starts to play a little bit more into it. But these are kind of far flung experimental ideas

Patrick Collison (14:24)

in general, I will say, and it's not terrible, but I feel like it's interesting to me that we haven't experimented in some sense that much with the paradigm of programming. Over the past 20 years. And many of the things we're discussing here are from the 80s or the 70s, and there are way more developers obviously now than there ever have been in the past. But in some sense the sort of the aperture of experimentation there feels like it's really not that wide. And again, the JavaScript ecosystem and a couple of others have done some cool things and there's been a lot of experimentation at the language level with Rust and Go and everything else, but at the kind of the development environment level, I don't know why it is, but maybe it's just too hard and complicated now, but there's been less than I would have expected.

Michael Truel (15:09)

Yeah, I agree. And I think may this help something we're working on.

Patrick Collison (15:16)

Maybe this explains Cursory's success to some extent, where you guys are the first people to really take it seriously in quite a while.

Michael Truel (15:23)

Well, I mean, yeah, I think we also benefit a lot from the why now? Of like there's now this great new color to paint with or set of colors to paint with. I think also there's just a ton of lock in with programming languages around both the neurons in your head of like programming languages are kind of complex UI for programmers to define exactly how the computer should function. And so people learn languages and people don't like to learn that many things. And then there's also the lock in of you have a lot of logic sitting around in one language and you need to maintain that. And I actually think that that's a pretty interesting or one of our hopes is that as AI programming gets better and better and better, one of the downsides of working on professional applications with hundreds of people dealing with many millions of lines of logic is the weight of the code base really starts to weigh on you. And so the feeling of being in a net new code base where it's just everything feels effortless, goes away, everything's a chore. You have to change one thing here, break something else here, and it becomes kind of this big ball of mud. And making that effortless, reducing the kind of weight of an existing set of logic, I think is one of the areas in which AI can make programming better.

Patrick Collison (16:28)

Someone said on Twitter today. Maybe it was Andrej Karpathy, but maybe I'm misattributing that and made too many things to do with vibe coding get attributed to Andre, like to Churchill or Einstein or something, but I think about him. But this person, whoever it was, was making the observation that it's one thing to be prompting the creation of Code. But another place where AI could conceivably do a lot to help is, is in the beautification and the refactoring of code bases. And you can imagine that you're producing all this a little bit ungainly, not quite correctly factored, detritus at the front. And you have this. And then nocturnally this thing comes up behind you and makes it all beautifully factored. And the only CS class I ever took was this class from Jerry Sussman on basically focused on, I mean, he called it large scale symbolic systems. But really what he was trying to focus on was the idea of creating code bases and environments and abstractions that were easy to modify. And there were no assignments in the class where you'd write something from scratch. Every assignment was about modifying an existing system and thinking about how could you design things in such a way that those modifications become. And they might be quite deep. Modifications become straightforward. And I think that's a lovely idea. Obviously in practice it's often very difficult to do that given all the exigencies and pressures of the things you want to ship today and next week and so forth. But if you could have an AI, like often when you're writing this stuff, you realize, well, I really should be doing it the beautiful way, but I'm not. Maybe we could have an AI coming up behind us too at Chainlink.

Michael Truel (18:04)

Yes, yes, maybe soon. One thing that happens to a lot of developers or a lot of people come to development because they care about building things, they want to make things happen on the computer screen. And so then that leads them to coding. And then something that happens to a big group of developers is they eventually realize the software they want to create is too big, that they can't write all of the code themselves and they have to go to humans to help them write the code. And so maybe they then become an engineering manager, director, whatever it is, maybe they start a company and then most of the work becomes not typing code, it becomes coordinating amongst people. Do you think that there are any ideas from programming that are helpful for the act of programming amongst the organization to get a group of people to build software together?

Patrick Collison (18:46)

Interesting. I think taking APIs and data models really seriously, if I was to do everything at Stripe again, I mean, there's a million small things that you would do differently and even some kind of big things. But the thing that I think we could maybe foreseeably and beneficially done differently would be to have spent even more time than we did on APIs and data models and part of the reason is, I guess, Conway's law effect of how both of those things end up shaping the organization. So I guess if you don't deeply internalize that, then maybe you have less control over the organizational dynamics than you might otherwise like to have. But also, I think it ends up shaping not only. I mean, the weak version of Conway's law is that it shapes your organization. I think the strong version is that it substantially shapes your strategy and just your business outcomes. And this isn't exactly maybe a version of that. But I often reflect on how the iOS software ecosystem, for a very long time, and plausibly still today, was so much more vibrant and kind of vital and successful than the Android app ecosystem. And there's a lot of things that are different across those two ecosystems. There are now way more Android devices in use, I believe, than iOS devices. But I think much of the fact that app developers tended to prefer building their apps on iOS and releasing their apps first on iOS, and maybe the iOS version being better than the Android version or whatever, is because the frameworks and the abstractions for iOS were just originally better than the Android ones. But I think that's a case where the right API design, the right abstraction design ended up having just quite significant business ramifications. And I think there's kind of a sense that maybe it's not worth dwelling on these things because everything in technology changes so rapidly and whatever assumptions you make, they'll be obsolete in two years or something. I think in practice, that's not true, and that the right API design and the right abstraction to the right data models can really endure. And for the first versions of iOS, many of the classes that one used were prefixed with NS. NS, of course, standing for NextStep. Right. And so that's a case where the API design survived for two decades or more. And in the case of Stripe, stripe is now 15 years old. And there are lots of things that we designed 15 years ago that are still in use today, which is kind of good and bad in the sense that they endured, but also we are still. We are still under the living with their faults. Exactly. And so anyway, that's maybe the thing that I would. That's the first thing that comes to mind.

Michael Truel (21:44)

In fact, on that final note, I was talking with an engineering leader at kind of a preeminent, successful Silicon Valley private company, and they were talking about how their code base is largely in Scala. And they said that they like to think of kind of the beginnings of the startup as this big bang moment where These tired, overworked, maybe over caffeinated founding team members are willy nilly making these initial technical decisions that then dictate the lives of hundreds of professional engineers in the future. And that scholar choice was one of them. And they sort of live with the faults of that now. But what are those kind of what were the consequential, it could be good or bad initial conditions of the Stripe Big Bang that you guys still live with right now?

Patrick Collison (22:31)

I mean, I think that metaphor is. Well, it sounds true to me is the first thing I'd say. I mean, maybe there's a little bit of kind of survivorship bias where like the actual statement is the early decisions that we made that we never changed are decisions that we lived with, but there's a kind of tautology there or something. And there are certainly design decisions we made pretty early on that are not true today. So early versions of the Stripe dashboard or something were built extraordinarily differently to the Dashboard today. And the converse is also true. So initially we decided to use MongoDB at Stripe and we decided to use Ruby at Stripe, and those are still quite foundational technologies at Stripe. And we had to build a lot of infrastructure in order to make MongoDB as fault tolerant and as distributed and as durable and as reliable and everything as we needed it to be. And as it now is like we had Stripe's critical API availability last year was 99.99986%, which is 44 seconds of unavailability through the all year, which is we others don't publish statistics that are kind of granular, but we believe that is the best in the industry. So everything that our storage team has built and many other teams, it ended up really working there. But that was a quite important critical decision, initial decision and Ruby similarly. I guess companies sometimes change languages along the way, but I feel like the initial language chosen tends to have.

Michael Truel (24:16)

I heard there were debates in Stripe about one of. Actually one of our co founders interned at Stripe early on or not early on in Stripe's history, early on in kind of our collective personal history. And he remembers there being documents upon documents about a potential Java migration.

Patrick Collison (24:34)

Yeah, so that partly happened as in we have rewritten a bunch of key services in Java. So some services for which, I don't know, throughput in particular is really important. And if you torture Ruby enough and maybe rewrite parts of some hot Paths in C or something, you can get it to be pretty fast. But you're often fighting against the allocator and various Parts of even just like Ruby, strings are not that efficient and stuff. So we've rewritten certain services in Java and now we use both.

Michael Truel (25:14)

Did you consider anything other than Mongo? And why did you pick Mongo early on? And what was the RFC process, RFP process, decision making process? For that it was just me and

Patrick Collison (25:25)

John, so we were sitting on the couch. Yeah, fine.

Michael Truel (25:30)

Did they get through to you with a blog? Was it just the reputation of Mongo at the time and open source communities, something else?

Patrick Collison (25:38)

I think it was. So I wrote a data store for our prior company, an object based data store, and I didn't really like SQL. I thought it was there was too much of a translational kind of mismatch between the domain of the application and that which SQL natively makes expressible. And so with SQL, obviously you have to collapse down into a relatively restricted set of primitive forms, whereas in your application you might have a concept of, I don't know, let's say in the case of Stripe, of money, that doesn't exactly comport with how the particular SQL database you're using happens to represent money or whatever the case might be. I just had this principled objection to SQL and not endorsing this or saying it was good. But as this interview shows, I suppose I had all sorts of strange notions about technology. And with Stripe we wanted to be more mainstream and a little bit less heterodox in our technology choices than our prior company. And so instead of using Smalltalk, okay, we weren't going to go to Java, but we went to Ruby, which at least on a relative basis seemed more mainstream. And similarly, rather than write our own object database, we went relatively more mainstream and used Mongo, which still give a lot of flexibility by virtue of being a kind of object data store. So that was fine. Everything I've said might disqualify me from ever making technology choices for another company.

Michael Truel (27:15)

But would you do anything differently about Stripe V2?

Patrick Collison (27:20)

We haven't talked that much about it publicly yet, and the answer might be a bit like there's the Xu Enlai quote, Deng Xiaoping about the French Revolution. It's too soon to judge. And so back in 2022, I believe to this discussion about data models and abstractions, we realized that a couple of the core abstractions in Stripe were just not the right long term abstractions and we had to fix that. And so we designed a bunch of V2 APIs. Fortunately, we had contemplated the possibility of this early at Stripe, so most of the rest uris that people are familiar with in Stripe are prefixed with V1. They've been prefixed with V1 from 2010. And so then in 2022 we decided, okay, we might increment the the namespace. So we designed those new APIs. They've started to ship this year.

Michael Truel (28:28)

Congratulations.

Patrick Collison (28:29)

Thank you. And we're extremely excited about the functionality that it's going to enable. And without going into the arcana of it, they will enable things like historically we have drawn distinctions and represented separately things like end customers, things like sub accounts, things like recipients for different kinds of payments. And we're unifying all of those into being into the same kind of entity representation, which is on some level clearly the right answer and makes a lot of will and is already changing the businesses of some of our customers because they can enable their users to do various things without having to re enter details or maybe to bring the same account across different countries or whatever the case might be. Anyway, it's been a long journey and the reason it was a long journey is, I guess, because it's not that useful to just define these APIs in isolation. If we just wanted to define them in isolation, that's a pretty easy thing to do. The thing that's difficult is to make them interoperable with all the existing things at Stripe and to build translation layers and so forth. And then to figure out with our customers what a sensible upgrade path might look like, because we control our code base, but we don't control theirs. And so it's going to be, I don't want to exaggerate it, but in certain respects at least, it feels a bit more like an instruction set migration for, you know, a chip architecture or something, where the instruction set by itself is easy, but it's all the kind of coexistence questions that become hard. But it started to ship this year and we're excited about it. I mean, I guess your question was maybe what lessons we've learned from it

Michael Truel (30:23)

and maybe do you think there's anything bigger to draw out of that on either projects that are rewrites or thinking about these kind of decades long abstractions? And how do you do that?

Patrick Collison (30:33)

Well, my trite answer to that is to unify everything you can plausibly unify.

Michael Truel (30:43)

How did you test design ideas for V2?

Patrick Collison (30:46)

Well, the people designing it. Well, I'll give you one other lesson and then I'll answer that question. And then just the other lesson, just maybe Bitton Chi.

Michael Truel (30:52)

And also is there some chief API designer who's the mastermind? And it's one person, it's not some sort of working group.

Patrick Collison (30:59)

There is a working group, there are working groups, but there is also a singular person who understands and is more than anyone else responsible for the whole. And I think that's necessary. My other kind of trite expectation would be to make anything that plausibly could be an N by M relationship to support that. Because if you only support 1 to n or n to 1 or whatever, and even if it's non obvious how it could possibly be N to N, just inevitably you'll end up needing that and you'll think, well, you could never have a company that's owned by two different companies or something. But it turns out that sort of every permutation in the space is in fact eventually explored as to how to do that. Well, I really feel like it's these new APIs. We think they're the. Well, you asked the question how do we know they're the right APIs? Partly from showing early versions of them to customers, partly because the people who designed them had spent many, many years in the witnessing and living with the shortcomings of the prior versions. So we were kind of coming with strong opinions, but even the strong opinions one can sometimes predict wrongly or extrapolate wrongly or over engineer something or whatever. So I think the cycles of customer validation, customer feedback are, are extremely important. I think it's also very important we did a lot of this to literally write the integrations that would exist in the new world. Because I think Java is maybe an example of yes, it fixes a bunch of problems with memory management or whatever that existed with C or C and antecedents, but at the cost of a lot of prolixity and overhead. And in order to kind of safeguard ourselves against inadvertently over engineering things, we forced ourselves to write a lot of API code, specifically describing how we would implement various business models and flows and so forth just to make sure that when you look at it it feels right. But I don't want to endorse our approaches too strongly just yet. I mean I'm feeling very optimistic, but we're I don't know what fraction but 60, 70% done or something, but not like 100%. And so I don't want to prematurely declare any victory.

Michael Truel (33:30)

How do you, Patrick Collison, use AI?

Patrick Collison (33:33)

Well, the main ways are the predictable ones. Where I use LLM chat tools a lot I use them for mainly for answering kind of factual or empirical questions I'm curious about. So for deep research style questions, I don't Always use deep research. And now that the LLMs are getting better at tool use and just navigating the web themselves, you don't need deep research as much. But for answering empirical or factual questions. I wish they were useful for writing, but I, I usually end up dissatisfied with the writing that they produce. So I don't use them very much for that and even for editing or grading my own writing.

Michael Truel (34:24)

I mean, have you seen any improvements as the models have progressed in the writing? And I agree. Also it's surprisingly generic.

Patrick Collison (34:30)

Yes.

Michael Truel (34:31)

And I'm trying to prompt it to not be generic and inserting names of people who. And it just doesn't work. And so I have been disappointed the times when I've given it.

Patrick Collison (34:40)

People tell me that the base model models are better at this and it's the sort of normification of RLHF that puts it in some kind of attractor basin. I have not succeeded in using them effectively there. People say that Claude is better and O3 is better than earlier OpenAI models. And on a relative basis that might be true. I don't want to sound, you know, self laudatory here and suggesting that I'm, you know, some particularly talented writer. I don't think I am. It's just like my personal style differs from the personal style, so to speak, of the models and you know, in some self centered way I, when I write I want to use my personal style. So anyway I use them for the factual stuff a lot and I find them like terrific for that. And even when I'm reading a book I'll sometimes activate. I've been recently using grok's voice mode and I'll just passively ask questions while I'm reading and GROK is just listening in the background and the answers are very helpful. And then I obviously use LLMs for writing code and typically mediated through cursor.

Michael Truel (35:55)

So we are interviewing you, Patrick Collison, as kind of the most. If you had to pick the archetype of a software industrialist, I feel like you would be kind of straight out of central casting for a number of reasons. One is that you are running a large software company, a successful large software company. Two is you started as a programmer and then moved to running the company. And then three is the company also builds things for developers. And so it's kind of the intersection of many circles in the Venn diagram. And so it's helpful to hear about discussing kind of experiences with Stripe. We are also interviewing Patrick Collison, the moonlighting economist and student of the world. And so are progress studies doomed now that AI is here? Is there any need for them?

Patrick Collison (36:47)

Well, I was going to say I think the need for progress studies has increased, but again, I don't mean to suggest that proper noun progress studies sees increased need. But I think the kinds of questions that progress studies tries to answer are now more pressing and urgent because I think the degrees of freedom are increasing and I think there's some Panglossian view that AI will just magically solve all the problems and predictions of the future are hard. But one, I don't think that's true, and two, in as much as we have evidence to date, I don't think that's been the track record. So I think that how we use these things, what kinds of decisions we make, what kind of considerations and margins of human welfare we seek to further, I think all those judgments are going to really matter. And maybe a critique you could have leveled at progress studies or progress Studies style thinking 5 years ago is these are all nice questions, but the world is on a kind of foreordained escalator path to some kind of teleological outcome. And I don't think the world feels that way today, or certainly feels much less that way today than it did

Michael Truel (38:05)

because of global affairs or something else.

Patrick Collison (38:07)

No, I mean, maybe somewhat global affairs, but the trifecta of global affairs writ large. Second, I think that aspirations and ideals are becoming contested more actively. And there's an ambiguity these days in the US as to what the left and the right even stand for. And I guess we currently have one party endorsing tariffs and another party opposing them, but with the valences kind of flipped from what one might have expected historically. And then third, yeah, obviously technology and first and foremost AI, but in our industry, stablecoins the rise of China as the preeminent manufacturing power in many technologies of the future, like drones and robots and batteries and solar, et cetera. So, yeah, in many different ways, I feel like the future is. Peter Schwartz has this concept of the Schwartz Window as the window of contemplatable futures in whatever number of years hence. And I feel like that Schwarz window, as of say, 2005, as we contemplate the world of 2015, was fairly narrow and was correctly fairly narrow. I think the world of 2015 did in fact unfold largely the way we would have expected in 2005. And I feel like today, in 2025, that window for 2035, it feels extremely broad. So, yeah, I think the progress studies style questions are more pressing.

Michael Truel (39:54)

So you were on the record in saying that people should focus more on the question of why we don't see improvements in productivity numbers as information technology increases and also as more people have started working on science and technology and more money has gone into it. And what do the numbers look like now? Do we see AI in the numbers?

Patrick Collison (40:15)

There was a new paper published in this very recently, like the past couple of days that I've not had a chance to. I just queued it today to read. So I have at this moment only read the abstract. Its claim is that one does not in fact observe productivity improvements stemming from, from use of language models. Now, I certainly can't.

Michael Truel (40:40)

Do you know what they're looking at?

Patrick Collison (40:41)

They appear to be undertaking some kind of natural experiment looking at the individual level based on intensity of LLM usage. But I certainly cannot endorse their methodological rigor. And upon understanding it better, I might be either really impressed and find it very credible or horrified, I don't know. But that was just the finding I happened to stumble upon today. I mean, look, overall GDP growth in the US looks well over the last two years. It's been somewhat better than we expected. Obviously we're speaking right now at a kind of volatile time. We certainly don't see any evidence for exponential takeoff. And if we, inasmuch as we thought that the encouraging GDP figures we have seen in the US for the last two years are attributable to some of these new technologies, I think you would also expect to see them in other countries. Right, because these technologies are quasi public good. Anybody can, you know, can, can use these LLMs. GPU growth outside of the US has, has not been that encouraging. We're not living in some, you know, massively accelerated period of economic growth for the world writ large. And so, you know, obviously it's, it's early days, but I think, you know, I think we're seeing that the diffusion of these technologies through the economy really takes time and involves substantial complexity. And maybe just last point of that is I believe Jack Clark said in an interview with Tyler Cohen, one of the co founders of Anthropic. And Anthropic to some extent has. Well, Anthropic has always taken the concept of AGI and even asii, I feel extremely seriously. And Dario speaks about this publicly, he's written about it, et cetera. And again, Jack Clark, one of the co founders and he said that he expects AI to increase GDP growth by half percent a year. And I thought that, I mean, I interpret Jack as really an optimist and half a point a year is in fact a lot of incremental GDP when compounded. So I'm not saying that that's small, but I think it's interesting that that was his figure.

Michael Truel (42:45)

Yes. Do you think that with the form factor that AI is taking in the economy right now, if we just kind of stretch the line forward, do you think we're going to need new measures in economic productivity than we have right now? So, like, assume real productivity goes up, assume that AI keeps getting better, it gets kind of deployed in the ways you would expect. Do you think we'll need new measures or it should show up in the numbers?

Patrick Collison (43:06)

No, no, I don't think so. I don't think that GDP is perfect. I think GDP can be improved. But in any world where what we generally think of as the economy is massively enhanced, it'll show up in gdp, I believe.

Michael Truel (43:25)

When will we be able to program human biology?

Patrick Collison (43:27)

I'm very excited about this. ARC, which is this biomedical research organization which I was involved in founding, we are working on training foundation models for biology using DNA and things like that. We're working on a virtual cell. And generally we're trying. I mean, a thing that I think is that I didn't appreciate until really spending more time in biology is we've never, like we humanity have never cured a complex disease. So one ontology or schema or something of diseases would be you have infectious diseases, the flu, the cold, Covid, whatever, and tuberculosis, and very diseases with high mortality rates. Then you have monogenic diseases where, you know, there's just sort of one genetic mutation that is responsible for the disease, like Huntington's. And then you have complex diseases. And the complex diseases are kind of the residual that are now left after we've cured most of the problematic infectious diseases, at least in the Western world, most cardiovascular disease, most cancers, most autoimmune disease, most neurodegenerative disease, et cetera. For certain of these conditions, we have maybe treatments that help, like statins with cardiovascular disease. But for none of them can we really say that we've cured it, that we, like, understand the causal pathways in meaningful detail and that we can vaccinate against it or something. And I think this is. Our hypothesis could be wrong, is that this is in part because we don't have experimental and kind of maybe epistemic is too grandiose a word, but kind of epistemic technology that's up to the task, like the pleiotropy of the genes in terms of all the different parts of the body and the systems and the mechanisms inside the cell that they affect is so, you know, there's so much combinatoric complexity there. And then the environment is such a vast and difficult to quantify thing that just, it's, it's really hard to understand for any of these conditions, the etiology and the dynamics and so forth. Okay, then over the last 10ish years, I mean, a bit longer, but a lot of the development has happened the last 10 years. We've gotten three new classes of technology in biology for reading. We've gotten much better sequencing technology, single cell sequencing, the ability to sequence, single cell sequencing of rna, and those improvements at the kind of think level. We've gotten neural networks and deep learning and transformers and everything there. I mean, they've existed for a long time, but we've gotten the recent improvements in them and the transformer in particular. And then on the right side we've seen obviously huge improvements in functional genomics and CRISPR and bridge editing, which is a technology that kind of arc, but the ability to kind of make very specific directed perturbations in cells. But if you put those together, you now have the ability to, again, at the kind of level of the individual cell, to read, think and to write. And this starts to really feel like a new kind of Turing loop and to have its own sort of completeness. And we will see how much this can do against these complex diseases and whether sort of this systematic approach is up to the task of shedding new light on their dynamics. But we are hopeful and excited if

Michael Truel (47:02)

we here at Kersher and also others in the industry are successful in automating lots of programming as we know it today and replacing it with a form of software building that's much higher level and more productive. And it's much more just focused on defining what you would like the software to look like. If we succeed in that. Who are you long? People talk about the designers and how this will be like a renaissance for them. But are you long the grad students? I mean, there are lots of really, really amazing grad students who are awesome and then maybe are less skilled at making things happen on computers. But who do you think is the most unexpected beneficiary of a world where both, many more people can make things on computers, and then also, especially if it's an evolution away from programming, the people who are already making things on computers are much, much, much more productive.

Patrick Collison (47:52)

I don't have a high confidence answer to that. There's all sorts of Trite stock answers like real assets, especially constrained real assets. Maybe we should be long SF real estate or something because it is one of the most beautiful cities in the world and will be enduringly so. Maybe we should be allowing the inputs and the ingredients to these systems because demand for them will go parabolic. And so maybe we should be long copper. Maybe we should be long positional goods and celebrities and Taylor Swift's music catalog. There's a lot of I think compelling theories here, but part of what I think is interesting at this economic moment is the unpredictability and the contingency and kind of sensitivity to the precise assumptions in the technology trajectory itself and the shape that it takes in five or ten years or whatever. I think is going to do a lot to determine the answer to that. And as I look backwards over the last couple of years, I'm struck by how many predictions have held up reasonably poorly even for people who are on the face of it, extremely well in fact formed. And so I've asked a lot of people this question and I have not heard any answers that are so compelling that I feel like I have conviction.

Michael Truel (49:11)

So we are very happy to be serving Stripe and your guys mission. What would you like us to build? How can we make Crusher better for you? Either you Patrick Collison or you Stripe.

Patrick Collison (49:21)

Well, you guys are already making Stripe better, so keep doing what you're doing would not be a bad outcome. From our vantage point, Cursor has today hundreds and soon thousands of extremely enthusiastic employees who are daily users of Cursor. And they report that it's a very significant productivity enhancement. And so we'll wait for the economic numbers. Well, the economy is pretty big and these diffusions take time, so it seems kind of greedy to want more if you're already making Stripe spends more on R and D and software creation than we spend on any single undertaking. And so if you're making that process more efficient and more productive, then maybe it seems greedy to want anything more. If I'm being selfish. Okay, three things.

Michael Truel (50:17)

Perfect.

Patrick Collison (50:18)

The runtime characteristics and integration stuff that we just discussed I think would be really valuable. I think the refactoring and the beautification stuff that again we also talked about I think would be extremely helpful and I think really change our degrees of freedom. As in if you could lower the cost of future changes to Stripe and improve the quality of the architecture. And then third, we really care about what we call at Stripe craft and beauty. And we want our, we want our software to be well designed. And pleasant to use. And pleasant to use not only in the superficial pixel sense, but also in the deep it works very well sense and is something you can set up and largely forget about and just trust or forget about it in as much as you want to. There's obviously a concern with AI that it leads to the creation of more slope and more kind of crappy things, but not more of the best things. I don't know what it would be that Cursor would do to ensure that the world is creating more of the best software and not just more software, but I think that's an interesting and important dimension. So those would be my Besides all the obvious things to do, those would be three suggestions Amazing.

Michael Truel (51:40)

Thank you, Patrick.

Patrick Collison (51:41)

All right, thank you for having me.

Michael Truel (51:42)

Yes,

Podcast Narrator (51:45)

thanks for listening to this episode of the A16Z podcast. If you like this episode, be sure to like, comment, subscribe, leave us a rating or review, and share it with your friends and family. For more episodes go to YouTube, Apple Podcasts, and Spotify. Follow us on X16Z and subscribe to our substack@ac16z.substack.com thanks again for listening and I'll see you in the next episode. This information is for educational purposes only and is not a recommendation to buy, hold, or sell any investment or financial product. This podcast has been produced by a third party and may include paid promotional advertisements, other company references, and individuals unaffiliated with A16Z. Such advertisements, companies and individuals are not endorsed by AH Capital Management, LLC, A16Z or any of its affiliates. Information is from sources deemed reliable on the date of publication, but A16Z does not guarantee its accuracy.