When Patrick Collison built his first startup, he chose Smalltalk — a programming language so obscure that none of his new hires had ever used it. None of them needed to know it beforehand. "Smart people learn languages really quickly," the Stripe co-founder explains with characteristic directness. That decision, rooted in a deep conviction about the superiority of interactive development environments over conventional text editors, tells you nearly everything you need to know about how Collison thinks about technology: from first principles, with an eye toward history, and with a willingness to be wrong.
In a wide-ranging conversation with Cursor CEO Michael Truell, Collison traced a line from his teenage experiments with Lisp-based chatbots on MSN Messenger to the multi-year effort to redesign Stripe's core API abstractions — and along the way, offered a bracingly honest assessment of where AI is actually showing up in the economy (and where it isn't).
From Smalltalk to Stripe: A Programmer's Journey Through Heterodox Technology Choices
Collison's path to founding one of the world's most important financial infrastructure companies began, improbably, with a frustration about web frameworks. After working on Lisp web frameworks and finding Ruby on Rails limiting by comparison, he went searching for continuation-based web frameworks — a programming paradigm he believed was "really the right way to implement web applications." That search led him to Smalltalk, and he never looked back.
"Rather than this kind of annoying feedback loop of having to add some log statements and, like, do this binary search to find the problem and eventually deploy a fixed version, a process that could take an hour, you could just literally inspect the stack frame, see which variable has the wrong value, fix it, jump back up, hit proceed, and have the whole thing work."
The Smalltalk environment offered something that most modern programming tools still lack: a genuine integration between writing code, running code, and debugging code — all happening in the same living system. You could encounter an error mid-request, edit the code to fix it, and resume execution from higher up in the call stack. The web request would simply complete as if nothing had gone wrong.
The startup built on Smalltalk didn't succeed — "I think just the idea wasn't that strong," Collison says — and when he and his brother John started Stripe, they chose Ruby instead. But the experience left an indelible mark on his thinking about what development environments should be.
The MSN Messenger Bot That Almost Passed the Turing Test
Before Smalltalk, before Stripe, there was an even earlier project: a chatbot written in Lisp that lived on MSN Messenger. It was a "really simple Bayesian next word predictor" that used conversations it had on MSN Messenger as training data rather than general text corpora.
"It never really passed the Turing test where people have actual suspicion that they're trying to exercise this discernment. But it certainly passed some weaker version of the Turing test where they were unsuspecting and people ended up having quite lengthy conversations with it."
The project introduced Collison to Peter Norvig's Paradigms of AI Programming, which he calls "a really formative book." But notably, he never seriously explored neural networks at the time. Instead, he went deep on genetic algorithms — even using one to determine the optimal keyboard layout (it turned out to be basically Dvorak, which he still uses). "That but probably 70 other reasons is why I did not create ChatGPT," he jokes.
The Development Environment We Lost
Collison's most impassioned argument in the conversation is that the software industry took a wrong turn decades ago by separating the runtime, the text editor, and the execution environment into distinct, poorly integrated tools.
"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, and the text editing, and the environment in which the code runs."
He still uses Mathematica regularly — not for symbolic mathematics, but because it's simply a more efficient development environment where writing, executing, and inspecting code all happen in one place. His wish list for a modern IDE reads like a manifesto for what programming could be: profiling information overlaid on lines of code, logging and error data visible inline, and the ability to hover over a variable and see the most common values it takes in production.
While Collison admires Bret Victor's "Inventing on Principle" vision and has even supported Dynamicland, he diverges on the emphasis on visual and graphical representations. "I reason much more symbolically and sort of lexically than I do visually and graphically," he says. For arbitrary complex systems like Stripe's infrastructure, he's not sure what a useful spatial representation would even look like.
What strikes Collison most, though, is the stagnation:
"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 things we're discussing here are from the '80s or the '70s."
Stripe's Big Bang: The Engineering Decisions That Echo for Decades
When asked about the foundational technical decisions at Stripe, Collison offers a vivid picture of how casually world-shaping choices get made. The decision to use MongoDB? "We were sitting on the couch just like, 'Shall we use Mongo?' 'Yeah, fine.'"
The reasoning, at least, was principled. Collison had a long-standing objection to SQL's "translational mismatch" between application domain concepts and the restricted set of primitives that relational databases offer. For his previous company, he'd written his own object-based data store. For Stripe, wanting to be more mainstream, MongoDB felt like a reasonable compromise — still flexible as an object data store, but less heterodox than a custom solution.
Both MongoDB and Ruby remain foundational technologies at Stripe 15 years later, for better and worse. The company had to build enormous infrastructure to make MongoDB sufficiently fault-tolerant and reliable for financial services. The result?
"Stripe's critical API availability last year was 99.99986%, which is 44 seconds of unavailability through the whole year. Others don't publish statistics that are as granular, but we believe that is the best in the industry."
Some services have been rewritten in Java for throughput reasons — "if you torture Ruby enough, you can get it to be pretty fast, but you're often fighting against the allocator" — but the core language choice persists.
Conway's Law and the Power of API Design
Collison's most forceful advice for technologists concerns the enduring importance of APIs and data models. If he could redo Stripe from scratch, he says, he would have spent even more time on these abstractions.
"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."
He illustrates this with the divergent fates of iOS and Android app ecosystems. Despite Android eventually having more devices, iOS attracted better apps and more developer attention for years — largely, Collison argues, because Apple's frameworks and abstractions were originally superior. The first versions of iOS used classes prefixed with "NS" — for NeXTSTEP — API designs that had survived for over two decades.
This conviction led to one of Stripe's most ambitious recent undertakings: the v2 APIs. Begun in 2022, this effort recognized that several core abstractions in Stripe were "not the right long-term abstractions." The company is unifying previously separate concepts — end customers, subaccounts, payment recipients — into a single entity representation. "On some level clearly the right answer," Collison says, but the execution has been enormously complex.
"I don't want to exaggerate it, but in certain respects at least, it feels a bit more like an instruction set migration for a chip architecture, where the instruction set by itself is easy, but it's all the coexistence questions that become hard."
The design process required a singular person who understood and owned the entire API surface, supported by working groups. The team validated designs by literally writing the integrations that would exist in the new world, safeguarding against over-engineering by ensuring the API code "feels right" when you look at it.
Collison's practical maxims for long-lived API design are characteristically concise: unify everything you can plausibly unify, and make anything that could conceivably be an N-by-M relationship support that from the start. "Even if it's non-obvious how it could possibly be N to M, just inevitably you'll end up needing that."
The AI Productivity Paradox, Revisited
Collison has long been vocal about the puzzle of stagnant productivity growth despite massive investments in information technology and scientific research. So where does AI stand in the numbers?
The answer, so far, is: not clearly visible.
"We certainly don't see any evidence for exponential takeoff. And if we thought that the encouraging GDP figures we have seen in the US over 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 use these LLMs. GDP growth outside of the US has not been that encouraging."
Collison notes that even Jack Clark, co-founder of Anthropic — a company that takes AGI and ASI "extremely seriously" — predicted AI would increase GDP growth by only half a percentage point per year. "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."
Asked whether new economic measures would be needed to capture AI's impact, Collison is unequivocal: no. "In any world where what we generally think of as the economy is massively enhanced, it'll show up in GDP, I believe."
The Future of Programming and the Schwartz Window
Truell and Collison explored what programming might look like in five years. Truell suggested that programming languages themselves could evolve — becoming less formal, higher level, more about what you want rather than how to do it — with AI functioning less as a helper and more as an advance in compiler or interpreter technology. Code, in other words, might not be the main thing programmers look at.
But Collison is cautious about predicting specific outcomes. He invokes Peter Schwartz's concept of the "Schwartz window" — the range of contemplatable futures — and argues that it has widened dramatically.
"I feel like today in 2025, that window for 2035 — it feels extremely broad."
The uncertainty extends to who benefits most from a world where programming is automated. Collison has asked many people this question and heard no answers compelling enough to give him conviction. "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."
Meanwhile, through his involvement with ARK, the biomedical research organization, Collison sees biology as perhaps the most profound frontier. The convergence of better sequencing technology (reading), neural networks and transformers (thinking), and CRISPR and bridge editing (writing) creates what he calls "a new kind of Turing loop" at the cellular level — one that might finally let humanity tackle complex diseases that have never been cured.
What Collison Wants From AI Tools
As a user of AI, Collison is enthusiastic but clear-eyed. He uses LLMs heavily for factual and empirical research — even activating Grok's voice mode to ask questions while reading books. But for writing, he remains disappointed.
"I wish they were useful for writing, but I usually end up dissatisfied with the writing that they produce."
He's tried prompting models to avoid generic output, even inserting the names of writers whose styles he admires. "It just doesn't work." The RLHF training, he suspects, creates an "attractor basin" that flattens out distinctive voice.
When asked what he'd like Cursor to build, Collison offered three requests beyond the obvious improvements: deep integration with runtime characteristics (profiling data, logging, production values overlaid in the editor); AI-powered refactoring that beautifies code nocturnally, cleaning up the "ungainly, not quite correctly factored detritus" that accumulates during rapid development; and — perhaps most ambitiously — tools that ensure AI helps create better software, not just more software.
"There's obviously a concern with AI that it leads to the creation of more slop, 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."
Conclusion: The Weight of Code and the Breadth of Possibility
Patrick Collison's career is a study in the tension between idealism and pragmatism in software engineering. The teenager who chose Smalltalk because it was objectively better became the CEO who chose Ruby because it was more practical. The programmer who dreamed of continuation-based web frameworks became the executive managing a 15-year-old MongoDB deployment with 44 seconds of annual downtime. The progress studies advocate who questioned whether technology was delivering on its economic promise now leads a company where hundreds of engineers use AI coding tools daily — while noting that the macroeconomic evidence for AI's transformative impact remains elusive.
What threads through all of it is a conviction that the foundational choices matter enormously and endure far longer than anyone expects — whether it's a programming language, a database, an API abstraction, or a framework for thinking about the future. The Schwartz window may be wider than ever, but Collison's message is clear: in a world of expanding possibility, the quality of our decisions, not just the power of our tools, will determine what we build.