Stripe’s Patrick Collison on AI agents, software customizability, and who should build tools

Patrick Collison and David Hsu covered all this and more in a wide-ranging 45-minute fireside chat at Retool Summit. Here’s what we learned from their conversation.

Patrick’s journey into programming started with a fascination with obscure programming languages. At 16, he created a programming language called Chroma, a Lisp dialect designed for web applications. Not long after, he built his first company—Auctomatic—entirely on Smalltalk. And while the architecture was elegant and the tool was powerful, there was one problem.

“Nobody ever benefited from it because Auctomatic had no users,” Patrick said. It was, he joked, “the world’s most elegantly designed userless company.”

That experience shaped one of Stripe’s founding philosophies: prioritize pragmatism over elegance.

“Every time there’s a super elegant way to do things and a practical, pragmatic way to do things, we’re just gonna cut the corner—at least until we validate that there’s actual user value here.”

Stripe was built in Ruby (not Lisp or Smalltalk) and initially used MongoDB despite its limitations. Why? Because validation trumps architectural purity.

This pragmatic philosophy extends beyond code to Patrick’s broader obsession: understanding what drives human progress—and why it’s slowing down.

It’s a topic Patrick spends a lot of time thinking (and writing) about. One of his key takeaways is that economic growth is the most important development in human history—yet there’s surprisingly little organized study of how to sustain it.

Almost every positive societal outcome—self-reported happiness, indices of freedom, female empowerment—correlates extremely highly with GDP (around 0.75 correlation between happiness and log GDP per capita). “You very rarely in sociology see correlations that are that high,” says Patrick.

The field of progress studies now includes conferences, think tanks, and policy organizations. But still, there’s so much more to understand, and, in Patrick’s view, not enough people seeking to understand it.

“I don’t understand why everyone isn’t obsessed with this. Are we on track for the flying cars or not? And if we’re not, what can we do to fix it?”

Related to progress, or in this case a lack thereof, one thread of conversation that came up was why companies still rely so heavily on spreadsheets for critical operations. It is, right up there with how to sustain progress, “one of life’s great questions.”

Patrick’s take: spreadsheets represent what programming should be. They offer simultaneous visibility of data and logic, easy collaboration, and immediate feedback. You can get started without ceremony.

That’s also, however, the problem. Spreadsheets scale poorly, break in obscure ways, and become unmaintainable as complexity grows. Yet they remain dominant because the alternatives have historically been too rigid or too complex.

Patrick noted this is part of why he was initially drawn to Retool—it felt like a missing piece between the power of dynamic languages and the ease of spreadsheets.

So why, then, do companies put up with inefficient tools and processes so often?

Patrick cited Marc Andreessen’s quote from the Cheeky Pint podcast hosted by Patrick’s brother and cofounder, that companies “...will endure any amount of chronic pain to avoid a short dose of acute pain.”

Ad-hoc processes and manual workflows proliferate because fixing them requires upfront effort. The pain is distributed and it’s chronic—but tolerable. However, the cost compounds.

At Stripe, recognizing this pattern led to significant tooling investments, with many of those solutions being built in Retool.

Stripe recently added a “fix it” button to their bug tracker that spins up automated development environments called “minions.” During a recent Atlas Fix-It Week, 30% of bugs were fixed by minions. Two weeks before the Summit, 5% of all pull requests at Stripe were generated by minions—completely automated end-to-end, though human-reviewed before merging.

“This is not just using LLMs in Cursor,” Patrick clarified. “This is a human never logged into the dev box. It’s completely automated.”

Stripe has also built their own documentation system in Retool to make these minions more effective. “The minions are gonna want to read the documentation, and the minions can’t ask the person next to them.”

Patrick revealed that if you work at Stripe, “you are a Retool user of necessity.” They’ve rebuilt many third-party tools that weren’t purpose-fit using Retool, gaining more control and the ability to integrate data across systems. The benefits are twofold: people are “happy rather than sad” when using them, and Stripe gains flexibility.

What’s particularly interesting is where some of these tools came from. Stripe’s agent builder framework came from their financial operations team, not an AI lab. People close to the work realized better tools would directly improve their domain, and it ended up “yielding dividends across Stripe more broadly.”

This isn’t unique to Stripe, either. Of the 1,128 respondents in our 2025 Builder Report, 65% were non-engineers who are building in Retool.

When asked about AI’s impact on Stripe’s workforce, Patrick pushed back on the doom and gloom framing that many take toward AI. The more interesting question, to him, is “What would we elect to do much more of?”

Currently, for example, Stripe’s largest customers have dedicated account teams. Patrick’s question: “How can we take the account team that Shopify or Amazon has at Stripe, and make that available to every single Stripe customer, including the person for whom it’s just a weekend side project?”

“As we look back in five years, the biggest changes are gonna be more of those type two changes—doing more—rather than type one of just straightforward substitution.”

Patrick believes most AI value will accrue to consumers and society rather than AI companies—similar to payments. Whatever the aggregate market cap of AI companies becomes, “it’ll be a hundred fold more in terms of consumer and societal surplus.”

Circling back to AI’s impact on software, the question came up of why software has become less customizable over time?

Desktop versions of Microsoft Office had Visual Basic, allowing users to script their applications. But modern SaaS largely abandoned this. “It’s strange because we’ve moved to these more dynamic programming languages, there are more programmers than ever before...but by and large, the median SaaS application is just not that customizable.”

Even Stripe is “an offender here,” Patrick admitted. He thinks this is a cultural wrong turn rather than technical necessity. “I think we’ve just gotten it culturally wrong…sometimes you just end up in an inefficient branch of the multiverse.”

The conversation wandered into whether Retool should have a “meta platform” for making applications customizable. As David notes, they see this happening organically: people fork applications and make their own modifications.

Patrick connected this to early computing pioneers like Ted Nelson and Alan Kay, who envisioned computers as “levers that would enable us to create in new ways and to fundamentally have more agency”—not just vessels for entertainment or efficiency.

With AI-powered development and platforms like Retool lowering barriers, we might be heading back toward that original vision.

The conversation wrapped up on the topic of software malleability. Patrick acknowledged the tension: infinite customizability can lead to unmaintainable systems. It’s easy to “paint yourself into a corner and end up with something that nobody else can understand.”

The challenge is “reconciling malleability and maintainability and the ability to collaborate.”

David shared our own internal philosophy at Retool: Freedom through constraints. Like Formula One drivers who wear seatbelts and therefore drive faster (an admittedly imperfect analogy), developers can “go crazy” when security guardrails are clearly defined.

That principle is core to Retool’s new AppGen capabilities. When people can get into the platform and build without fear of breaking anything, the bench of builders gets deeper, and the people closer to the problem can build solutions directly.

“I think people really do want to customize their software,” says Patrick. “I believe this partly from my own direct experience, partly from my interaction with others, and partly because it’s what I want to believe about the species.”

To learn more about what we announced at Retool Summit, you can read our event recap, or watch the keynote speech.