A Brief History of the Open Source AI Hacker - with Ben Firshman of Replicate

**Alessio** (0:05)
Hey, everyone, welcome to the Latent Space Podcast. This is Alessio, partner and CTO of Residents at Decibel Partners, and I'm joined by my co-host, Swix, founder of SmallAI.

**Swyx** (0:14)
Hey, and today we have Ben Firshman in the studio. Welcome, Ben.
Ben, you're a co-founder and CEO of Replicate. Before that, you were most notably founder of Fig, which became Docker Compose. You also did a couple other things before that, but that's what a lot of people know you for. What should people know about you outside of your LinkedIn profile?

**Ben Firshman** (0:36)
Yeah, good question. I think I'm a builder and tinkerer in a very broad sense, and I love using my hands to make things.
So I work on things maybe a bit closer to tech, like electronics. I also build things out of wood, and I fix cars, and I fix my bike, and build bicycles, and all this kind of stuff. And there's so much, I think I've learned from transferable skills, from just working in the real world to building things, building things in software. And so much about being a builder both in real life and in software that crosses over.

**Swyx** (1:11)
Is there a real world analogy that you use often when you're thinking about a code architecture problem?

**Ben Firshman** (1:17)
I like to build software tools as if they were something real.
So I wrote this thing called the command line interface guidelines, which was a bit like sort of the Mac human interface guidelines, but for command line interfaces. I did it with the guy I created Docker Compose with and a few other people. And I think something in there, I think I described that your command line interface should feel like a big iron machine where you pull a lever and it goes clunk. And like things should respond within like 50 milliseconds as if it was like a real life thing. And like another analogy here is like in the real life, you know when you press a button on an electronic device and it's like a soft switch and you press it and nothing happens and there's no physical feedback about anything happening. Then like half a second later, something happens.
Like that's how a lot of software feels. But instead, like software should feel more like something that's real where you touch, you pull a physical lever and the physical lever moves, you know, and I've taken that lesson of kind of human interface to software a ton. You know, it's all about kind of low latency, feeling things feeling really solid and robust, both the command lines and user interfaces as well.

**Swyx** (2:22)
And how did you operationalize that for FIG or Docker?

**Ben Firshman** (2:26)
A lot of it's just low latency. Actually, we didn't do it very well for FIG and Compose in the first place. We used Python, which was a big mistake, where Python's really hard to get booting up fast because you have to load up the whole Python runtime before it can run anything.
Go is much better at this where like Go just instantly starts.

**Swyx** (2:45)
You have to be under 500 milliseconds to start up?

**Ben Firshman** (2:48)
Yeah, effectively. I mean, I mean, you know, perception of human things being immediate is something like 100 milliseconds.
So anything like that is good enough.

**Swyx** (2:57)
Yeah. Also, I should mention, since we're talking about your side projects, well, one thing is I am maybe one of a few fellow people who have actually written something about CLI design principles because I was in charge of the Netlify CLI back in the day and had many thoughts. One of my fun thoughts, I'll just share it in case you have thoughts, is I think CLIs are effectively starting points for scripts that are then run. And the moment one of the scripts preconditions are not fulfilled, typically they end. So the CLI developer will just exit the program. And the way that I really wanted to create the Netlify Dev workflow was for it to be kind of a state machine that would resolve itself. If it detected a precondition wasn't fulfilled, it would actually delegate to a subprogram that would then fulfill that precondition, asking for more info or waiting until a precondition is fulfilled. Then it would go back to the original flow and continue that. I don't know if that was ever tried, or is there a more formal definition of it, because I just came up with it randomly.
But it felt like the beginnings of AI, in the sense that when you run a CLI command, you have an intent to do something, and you may not have given the CLI all the things that it needs to execute that intent.