When Tokens Flow Like Electricity

Quinn: Just building software to do X is only valuable if you can get people to pay you, and I think that that's going to be a lot harder given that people can just make the software themselves. So developers need to think of themselves as doing X, not building software to do X. And I think that's going to be a rude shift because if anything, software developers, on average, have shifted to be more general, more horizontal in what they're building.

Thorsten: The richest companies on Earth are pouring all of their cash into this, and we're not even seeing the results of this yet. Like, this is still being built. If you now think, 'Oh, I have to be stingy with my monthly subscription and I cannot run out of tokens,' I think in a year or two, you will find that the tokens are everywhere. It's like electricity. You're not measuring the watts coming out of your wall, and I think it's the same thing with tokens. There will be so many tokens everywhere and so fast that people won't recognize computing anymore.

Thorsten: And we're back, another episode of Raising an Agent. This time we're back home. One of us in San Francisco, in Mill Valley, the other one in a really small town in Germany near Frankfurt Airport. And yeah, we're excited to talk again, right? Like, Munich sparked a lot of ideas. Munich got the stuff flowing in our heads, the jelly flowing.

Quinn: Yeah. We've been shipping a lot, and it's just been a few weeks since Munich, and we had said then that the way that we build had changed more in the prior, like, four or six weeks than it had changed all of last year. And I think we're still feeling that, and we're starting to think about looking even further ahead and what is the world going to be like and how can we take what we're building, what we're seeing, and get more people building in the Amp way. And also then thinking about what is that going to do to software and what that means for software, right?

Thorsten: Yeah. Yeah.

Quinn: So, Thorsten, predictions. What do you think is going to be different six, nine months from now?

Thorsten: I think all of the trajectories will continue. Like, I don't think there's going to be this rug pull that most people say there might be or there will be. So I think the price of intelligence will drop. And people are saying, 'Well, the models are more expensive.' Well, the newest ones, right? But like, the price of the old models has dropped considerably. And I think in, say, half a year, the price of GPT-5, GPT-6 levels of intelligence will be dirt cheap compared to right now. And, you know, Fable, incredibly expensive. I think intelligence at that level will be cheap. I also think if you look at the trajectory of tokens per second, right, OpenAI is rolling out their super fast mode. I don't have access. I wish I had access. What is it? 750 tokens per second, which is mind-blowing.

Quinn: If we had access, we would not be able to say, so.

Thorsten: If I had access, I wouldn't be here talking, to be honest. I would just send tokens.

Thorsten: That's mind-blowing. So I think—I'm not sure if this is correct, actually, but I think it's close to—like, the build-out we're seeing with AI, the data centers, the GPUs, it's one of the biggest infrastructure build-outs in the history of humanity, you know? The richest companies on Earth are pouring all of their cash into this. And we're only just—we're not even seeing the results of this yet. Like, this is still being built.

Thorsten: So if you now think, 'Oh, I have to be stingy with my monthly subscription, and I cannot run out of tokens, and I count the tokens, and you know, 50k tokens is something that I measure,' I think in a year or two or maybe three, you will find that the tokens are everywhere. It's like electricity. You're not measuring the watts coming out of your wall. You measure them in fucking megawatts and kilowatts, and you don't care about, like, 50 watts, right? And I think it's the same thing with tokens. There will be so many tokens everywhere and so fast that people won't recognize computing anymore.

Thorsten: I think based on these projections, a lot of things that we think about how software development is will change. Do you disagree with any of these predictions or do you want to add some?

Quinn: I agree. Intelligence is getting cheaper and cheaper. And anyone who thinks there's going to be a rug pull, the quote-unquote 'subsidies' will end—there's no evidence that subscriptions, which is what people usually mean, are actually unprofitable, and it's hard to actually tease it apart. In the same way that it's not like United Airlines is going to stop having economy seating because that's been a subsidy and they're going to pull the subsidy away. No, you know, once there's a big upfront expense, it makes sense to spread that in a price-discriminated way across the largest possible population of buyers.

Thorsten: Yeah.

Quinn: And also totally agree that if you are in a role where you're having to be really stingy with the intelligence that you can use, then that's a signal. In much the same way, if you're someone who's getting paid one twentieth of what a San Francisco engineer makes, then find a way to get to San Francisco or closer to San Francisco. It's a signal that what you're doing is not benefiting enough from tokens. You're not creating enough value. You're not in that good position. But if you're thinking that, then you're probably the kind of person who can create a ton of value if you get into a job or other setting where the tokens can flow.

Quinn: And at the same time, there's a lot of noise going on right now. First, it feels like everybody is trying to build the same thing. Now, you know, Thorsten, you and I have been building dev tools for a long time, and for the longest time everyone said, 'Oh, you can't make any money in it.'

Thorsten: Yeah.

Quinn: And now people have completely changed to the point where it feels like everybody is building dev tools, and that also is probably not correct.

Quinn: And ultimately, software, it has to solve the problem. You know, just building software to do X is only valuable if you can get people to pay you, and I think that that's going to be a lot harder given that people can just make the software themselves. So I think more and more—we've said this before, but developers need to think of themselves as doing X, not building software to do X.

Thorsten: Yeah.

Quinn: And I think that's going to be a rude shift because if anything, software developers, on average, have shifted to be more general, more horizontal in what they're building.

Thorsten: I do have a little pet theory that I want to offer here. And it's a pet theory. Say the inflection point was November '25, right? Which—this is my other pet theory—it wasn't for us. I don't think November '25 was that big. I don't think there was a bump in the curve. I think it was a smooth curve.

Quinn: Except for Gemini, remember?

Thorsten: That was—well, let's not talk about it. But I think it was a smooth curve, but there's a lot of engineers who've kind of woken up to agents now. And now we've seen, like, in the last few months—and I've said this before on this podcast, but it's even more than this—where people are now, like, they're hacking on their own agents, and they're plugging, and I thought this would go away, but it's still a thing that's going on where people build their own tooling around this stuff and blah blah blah. And my pet theory is, engineers have this thing now where they go, 'It can't be this easy, right?'

Thorsten: Like, you know how we always try to fix our tools and build, like, some elaborate workflows and automate stuff? I mean, not me. I'm the guy who copy-and-pastes, you know. I'm not doing this. But like, if you send a prompt to Fable—I did this yesterday. I used Fable. I'm kind of on a two-day Fable binge, I don't know. Maybe it's because I want to spend money after we can put ChatGPT subs into Amp, and now I'm like, 'Well, you know, got to use Fable.'

Thorsten: So I sent a prompt yesterday. Ian Landsman, shout-out to Ian. He sent a tweet. He's like, 'I want to be able to set the default branch in Amp for Orbs.' So I sent a prompt. I tweeted the prompt. It was like a text message I would send to somebody. And Fable went and did it, and it just added a feature. It didn't add complexity. It kind of wired that new field, the default branch, through, like, our different services. I had it watch deployment. I had it make sure it rolled out. I tested it, and it works.

Thorsten: I do think, here's the pet theory, that engineers then look at this and go, 'Oh, it can't be that easy, right? How about I add a bunch of stuff? I add, like, some tools, and like, some shortcuts, and like, a review thing, and this process, and that process, and blah, blah, blah.' Because it doesn't appeal to the engineers of the last, say, 20 years that you just say something in plain English and it goes and does it.

Thorsten: You know? Like, I think there's something like this going on where you want to kind of add some value, and that's how you build this whole elaborate stuff around it, but—

Quinn: Yeah. Well, it's like if you're a furniture builder, you would probably feel ashamed if someone comes over to your house and it's all IKEA furniture. And when you sit down on that IKEA couch, you're going to hear every little creak and it's going to annoy the hell out of you.

Thorsten: Yeah. Yeah, yeah, yeah.

Thorsten: I mean, we all know the story, right? That some guy posted, I don't know, 20 years ago on the internet. They were a 3D designer, and basically they figured out that every time they had something they made and they showed it to their boss and said, like, 'Does this look good?' The boss would always say—just to—the boss would feel they have to add value, so they would ask, like, change this, even though it was completely nonsensical. So the designer added a little duck to everything. And then the boss would always go, 'That looks great, but get rid of the duck.' And then they would feel happy about it, they added something. So I do think there might be something going on here where engineers feel like it can't be as easy as just saying something to the model and build software, right? And so they have to add something.

Quinn: Yeah. So, with an agent though, you wrote the 'How to Build an Agent' that turned on a lot of people to how simple the idea of an agent loop with tools could be. And that was pretty cool. That opened people's eyes. That's a new primitive. What about all these people who say, 'Oh, Orbs, how is that different from just EC2 and you set up a VPN and you have some orchestration?' You know, like, what are they going to run into that they can't build themselves?

Thorsten: There's multiple things going on. I think—well, first of all, we have to admit that building stuff is pretty easy now and getting started with stuff, right? And we had, like, the first version of what's now called Orbs in two weeks, a week or something. And then we ran into the long tail with that infrastructure provider we used, and a whole slog of issues. And then I think I rewrote it on the new platform over the course of a weekend. And this was not me sitting here for 12 hours. This was me starting prompts and whatnot. And so admittedly, it is easy to build a lot of stuff. But when somebody says, 'Oh, I built Orbs, and it's like EC2 and a VPN,' or, you know, 'I have, like, 15 tmux sessions running on my home lab and, like, 18 different Claude Codes in it,' and—

Thorsten: You can get far, but it's obviously not the same experience. Like, the value of Orbs is that you have all of the things in the same package, you know. Like, you don't have to manage tmux sessions. The beauty of Orbs is you don't have to think about the machine. You just send your prompt, you get the results back, you preview it in a portal, you can share it with your colleagues and whatnot. Like, you don't have to worry about how the sausage is made. And there's also people who are offended by this, where they're like, 'I want to see how the sausage is made,' you know. But I don't know. I don't know what to say. Like, it's the same thing, maybe. Like, are you really concerned about how we spawn up these sandboxes or VMs? Like, what do you want to see, you know? Like, you can specify hooks and scripts now, you can define your own bash script. We're exposing a bunch of stuff. But—

Thorsten: I think it's underselling the whole experience. Like, you can get, like, 80% of the way there, but what we found is the 20% makes a lot of difference. It's weird how hard it was to get this nailed down, because it's not, like, super hard programming. Also, what does that mean anymore? I'm not going on this sidetrack, but you know. Like, if you'd asked me five years ago, super hard programming would be like an optimizing pass for an optimizing compiler, you know. I'm pretty sure that has kind of flipped now. Like—

Quinn: Yeah. It's like the design, and—

Thorsten: Yeah, the design.

Quinn: How all these pieces fit together.

Thorsten: Yeah, into a whole. And like, the product, what are you building? In what sequence? When are you building it? What are the trade-offs? You know, all of this stuff. So, when we built this, this was really hard. Like, what are the primitives, for example, and what are the things that are the invariants of the product? One thing that I think we got right is you start an Orb, you get a single URL, you get a fresh Orb for new threads. That was controversial when I said this, right? Like, everybody was like, 'No, no, no, I want to spawn multiple agents in an Orb,' you know, in the same thing. And now look at us. Like, that would be a different product where you can spawn multiple agents and select the specific Orb and whatnot, and that would be a different thing.

Thorsten: So people can go far and wire their own stuff together, but wiring your own stuff together is not building the same product. And there's a lot of, like, decisions that are not code-level that go into making the full thing, and those seem to be valuable, right? If you look at the feedback we get, where people say it just works, or it's a great experience, or somebody tweeted this just an hour ago, like, your UI or, like, your front end is completely on a different level and whatnot, right? And obviously, like, we have great designers and engineers on the team who really sweat over the details here, and I don't know. I don't know how you can replicate this with your homemade VPN EC2 tmux thing. What do you think?

Quinn: Yeah. I think there's two ways to look at it. One is if you're just trying to have fun or just build something for yourself to use and you don't need to make it work at, like, team scale, you don't need to get other humans involved, you don't need to deal with the complexities that come with other people also wanting to make it work their way, then, you know, you can probably build something like an agent platform that's pretty fun.

Thorsten: Yeah.

Quinn: But once you start making it so that an entire team can work on it, that all the different ways they use it work, that you can read other people's threads, you can have the, you know, Puck-like orchestrator agent work across everything in it, that all the concepts fit together, that's hard. And the hard part for us has been no single person on our team—you know, our team is 20 people, all of Amp is 20 people—no single person on our team has every single piece of the system and the design in their head. And so much of it is figuring out how we can have all the different pieces that we all know and feel really strongly about work well together.

Thorsten: Yeah.

Quinn: And that is tough. We all use the product all the time. We have a small team that's highly trusted. So we've optimized Amp for being able to do that. But that's where, if it's—you know, you don't really have that need if you're one person building it for yourself. And if you're one person building it for your whole company, you're going to run into all the same problems that we have. And then people are going to be saying, 'Well, why can't I use Amp or, you know, all the other'—now there's 87 different things that are in this category. And that is probably going to give you a headache.

Thorsten: Yeah.

Quinn: But the more important thing is, like, it's fun, like, don't get me wrong, that's part of why we do it. But you're not actually creating value. It's not like any of these agents, like Amp, it's not like we're charging you a ton for the joy of using our product. We're making money, we're profitable, but you're not going to save a lot of money. You're probably going to—you will actually lose money on net, because there's a lot of efficiency stuff we do. So what is the business value of what you're doing? You can't be making software to do X. You most certainly cannot be making software to make software to do X. You got to be doing X these days.

Thorsten: Yeah. Yeah, but I mean, it points at a real tension, right? The whole build versus buy thing, right? Where should we buy something and not build it ourselves? And two years ago, you know, besides operational costs and, like, guarantees and support and whatnot, you had the big thing of, 'I don't want to build this myself,' or, 'I can't build it myself.' But now, in the age of I take a screenshot and I say, you know, 'Build this for me,' that equation has changed. Like, that scale has been tipped. And I think the interesting bit is that the models are now weight on the scale, on the build versus buy scale. And the weight of the models changes constantly. Like, you constantly have to re-evaluate.

Thorsten: And, I mean, admittedly, I built a bug tracker into Amp last week, right? And it was one-shotted, and it was deeply integrated into our system. So that might have been even easier than spending the time to set up Linear or something, because now the value is in deeply integrating stuff, which is why we're even talking here, right? Like, this whole thing is so incredibly fascinating to me that if you look at the history of software, and we've said this a thousand times, software was hard and expensive to write, slow. Basically, you want the investment you make when writing software to pay off or have a return, so you generalize the software that you write so you can sell it or reuse it multiple times in different use cases, right? You don't build one-off software. That doesn't pay, or it hasn't paid. But—

Quinn: Yeah. The beauty of a software business is you build it, and then for the next 10 years, your customers will stay on it, and you can sell it, and infinite copies can be made at zero marginal cost, and you can make money on each of those, so you recoup your fixed expense.

Thorsten: Yeah. Yeah, even if you're an agency and you build customer-specific things, most agencies have then developed some kind of framework, or like, some—I guess you can call it a stack or whatever, like, something that they reuse across projects, right? Which means they can save time, like a common admin interface or whatever. Or think of, like, WordPress, right? Which is, I mean, it's been 10 years since I checked, but back then it was the most configurable piece of software. Like, the admin interface had a lot of menus. And now, it's like, well, you could take a screenshot or four of different websites and have it one-shot a thing, like your hair salon website, or like, your whatever restaurant website, and then every time you want to make a change, you can ask the agent again to do it, right? So this has changed.

Thorsten: And like, what I find fascinating is that a lot of practices and methodologies of software, we still do them, or they're kind of crumbling, but a lot of stuff doesn't hold anymore, right? Where—

Quinn: Yeah. So before you even get onto that, I think you mentioned this, but I just want to put it to you again. Basically, what we are saying is, we see a lot of people say, 'Oh, Amp or other agents, I could just replace that with EC2 and some shell scripts and get the same thing.' And we understand that, but we don't think that that's the right thing for them to do. But at the same time, you're saying, 'I was able to code the parts of Linear, an issue tracker, that I need from scratch. I, you know, quote unquote replaced Linear with a few CRUD forms.' So which is correct? How could we say that in one case, you know, Amp is worth it, but in the other case, 'No, Linear is not worth it'? What makes it different?

Thorsten: That's a good question. I think what's really different about—let's start on this end. I would say the Linear or bug report case is so different because the workflow around how you do bugs is different in each company. And it's like—bug tracking or issue reporting or knowledge management, like, it's different in every company. That's why Jira has 15,000 options, right? And why every Jira is different. It's not because people don't like the button, but it's because they work in a different way. So I think, like—

Quinn: Couldn't you say the way that people use agents and do software development is different in every company and therefore every company should have their own?

Thorsten: I mean, I guess you could. I'm thinking about it. But I would argue that it's like the thing I said at the start, right? Like, you need to specify what you want and the model does the thing, and there's not a lot of this—it's handed over to the model is, I guess, what I'm saying. There's not a lot of touchpoints anymore with the humans. Maybe that's the difference, in that, you know, like, previously, like, your dev environment had a lot of touchpoints where the humans were changing things. But now, man, like, in Orbs, like, they just whip up software and tear it down, and I don't care. And I don't know. What do you think? Like, this is interesting. What do you think?

Quinn: I think this is the big question that everyone has about software, is what software is below the waterline where you don't want to go dive and mess with it, and what software is above the waterline where you want to, you know, go build. If you just look at people's behavior, I think you've seen a lot of people shift from wanting to spend their time in issue land and project land and typing that in, and now they want to spend their time in agent land. And you cannot argue with people's revealed preferences, their actual actions. And so there's something about, well, why do we think Amp, or generally the agent, is different from the issue tracker? It's because we have found it to be incredibly productive to work there, far more than issues ever would. And so there's more value to having that be really good and solid.

Thorsten: Oh, I see what you're saying. Okay, I see what you're saying. So the value, the business value of the software has changed, and you would say that building your own for low-value things is—that's, you know, like the—

Quinn: We don't spend that much time in it ourselves, so there's not that much complexity that we need to replicate. So in the past, maybe we would have used 60% of the features of Linear, and Linear is an awesome product. You know, we've used it, and it is the best of its category. But now we might only be using 10%. And I think there's a lot of people that are using some of Linear's agent features and they like that, but we would only be using 10% of it.

Quinn: So, I think there's also an element where Linear was built for a workflow that is undergoing a lot of change. I think there's also something fundamental about software businesses that were started before 2025 and have not completely reinvented themselves and burned the bridges. I think there's also a lot of valid skepticism that those workflows will not be there. I think there's also something about if, like, an agent is at the core, then that just makes the software so much more pliable and moldable. Like, in the way with Amp, if you want to do something, most of the time you can just ask Puck to do it. If you want an integration, you can just ask, you know, Puck or Amp in a thread to go set up a webhook. And yeah, I don't know. But you know, this is what we're thinking about right now.

Thorsten: Yeah. Another angle is the whole—I don't really like the term, but like, the whole system of record type of thing, meaning, like, some software is more important than others. I think that's kind of what people want to say when they use the term. Meaning, with Orbs, you're spending money on VMs, so as soon as you're spending money, like, a significant amount of money, that changes this whole equation, right? And you have the tokens flowing through the system, you want to keep track of this. I do think, like, the whole process that touches the code is important, so, you know, like, there's something system-of-record-ish about, like, the Orbs, whereas with the tickets thing that I built, it's not, right? Like, for us, that's not a cost. Like, it's a CRUD app in our admin CRUD app. It's basically free, and that changes it for me. And like, the whole Orbs stuff, that's our main application. That's the main thing that's load-bearing, to use the stolen term, the term the agent stole from us. But I don't know, maybe that's this.

Thorsten: But I do think, like, what you said is very interesting, with you have the agent at the core and you can change it, and there's obviously now this tension of Linear was built in a time where you had to, for different customers—they have different workflows, so you had to have the option to custom labels or, like, custom workflows or, like, custom boards and whatnot. And admittedly, Linear was, I think, three years ago they were pretty minimal, right? And they said, like, 'We only have this.' And then, I don't know, that's not true, but like, a couple years back they started adding more features and it became more complex.

Thorsten: And obviously, if you're SaaS software, you have to be this complex because you have multiple customers, and they give you different amounts of money, and they have different usage and different workflows, so your software has to be generic for different things, right? But with agents now, if you build your own, it doesn't have to be generic at all. And that kind of changes the whole cost thing of the software again. Like, it makes it less complex and whatnot. But obviously, like, what I'm talking about here is, like, this triangle of, well, you know, you can buy the SaaS thing and it's complex in the backend, a lot of work to build because you have to generalize it, or you build your own and then it's kind of maybe cheap to build, but it's customized to your workflow. But then on the other end of the triangle there's this thing that, you know, with Orbs and whatnot, where it's load-bearing, it costs money, you do want to modify it, but yeah, I don't know. Like, I think everybody's trying to figure out what goes where on this triangle.

Quinn: Yeah. And with Amp, we kill features that we no longer think are good, so there's not cruft in Amp that we're keeping around because some customer nine months ago paid us for a year and they'd be pissed if we take it out. No, I mean, everyone knows with Amp that there's no cruft in it. And by the way, Linear is, of basically any software company, best positioned here, and they've done way better than pretty much any other company I know in staying relevant. So in a sense we're picking on them because, you know, they're the strongest. They're an interesting case. They're a good test case here.

Quinn: And I think as we look to the future of what software will be, certainly for the stuff that we use at Amp, if there's something that our agent is the primary user of, or where we've ever been annoyed at the UI or their salespeople wanting us to get on the phone with them or anything about that, that's danger territory. And I think a lot of companies are seeing that. Like, if you're using a tiny fraction of the features of a software package, it is so tempting to just go and build it yourself. So think your dashboard application. And in that case, a lot of the complexity in that is, like, their own programming language on top, and you're not even interacting with that. You get zero value from that anymore. It also is kind of annoying to know that—maybe this is not the right way to think about it, but you're paying for a massive feature that suddenly you no longer use.

Quinn: And it's really tempting, and I do think that people will be doing that more and more. But there's this view, a lot of people talk about, like, 'Oh, you know, vibe coded Salesforce from scratch,' all of that, that people were talking about last year. I think that's dumb because it's not Salesforce that you would vibe code from scratch, it's the 2% feature set of Salesforce that you would need.

Thorsten: Yes. You're not going to vibe code Excel, but you're going to vibe code that one spreadsheet that gets sent around and that—I wanted to use the word load-bearing again—that's load-bearing for your one workflow. Like, that's what you're going to vibe code or build it yourself, yeah.

Quinn: Yeah. Or there could be a core where someone, maybe at your company, maybe someone externally, has built the really good primitives that would let you then vibe code. Because vibe coding, if that means starting from scratch every single time, even as models are getting better and better, you want consistency. And take, like, Granola, the recording app for Mac. I, in doing dictation on Amp, I've run into a lot of macOS APIs around audio, and there's a lot of footguns. There's just a lot of complexity that models still do not get right regularly. So you want someone who's figured out all of that, but then you could configure your jellyware Granola to route it here and to understand these dictation things, to not send all your data to the other company, all these things. So I think you want to do it on top of a core that's good. So it's not that there's no role for software packages that are made by someone else, it's that that role is completely changing.

Thorsten: Yes. I 100% agree. Like, even with agents, I do not want to think about authentication. I just don't want to do it. What I want is, I have an app idea and authentication should just be there. Like, somebody else should think about it, and that's not the agent. That's not the thing that the agent can do. You need management thinking. You need thinking of different options and weighing the trade-offs and whatnot. I don't want to think about payments. When I'm building an application, I don't want to think about the storage layer, you know? Like, the database or whatever. So—

Quinn: Yeah. And you're talking about when you're building on top of a core. You want someone to have thought about that so you don't have to think about it.

Thorsten: 100%. Yeah, yeah, yeah. Exactly. And, man, like, people say that vibe coding is fun. No, no, no. The most fun with programming—and we can say this is what we do with Amp—the most fun with agents and programming is when there is a foundation that's solid and that's working, and you can just let the agent go loose on it and change the UI or different things, or add new features or remove features and whatnot, without having to bump into those foundations.

Thorsten: Like, if you have an app where authentication is set up, and the secrets are set up, and like, your production deployment is set up, and you just have to tell the agent, 'Deploy the new version,' then it's fun. But like, it's always been the case that the worst part of programming is this whole wiring that shit together and putting the env vars in here, and the secrets over there, and do this, and ugh, the SDK is not configured correctly because it's the YAML and not the env var, and blah. Like, all of the glue code, right? It's the worst part of programming.

Thorsten: But now, with agents, when people talk about vibe coding, that's kind of the shit that's left for you to do, because the agent gets to have the fun and write the code, and now you have to do the fucking secrets management and the deployment and this stuff.

Quinn: Yeah. And a lot of the time the agent can't do that because Google's OAuth flow will block bots and—

Thorsten: Yeah. Yeah, it's like, 'Oh, well, the agent can paint on the canvas now. All you have to do is go and buy the fucking paint.' But what I want is somebody to bring the paint and the brushes and then I can tell the agent, 'Go and do this,' you know?

Quinn: Yeah. And that's what we have when we are building and using Amp. And a lot of the joy, just the sheer wonder and awe that we get to experience, is because we get to build on this foundation. And also we get so much feedback. We have tons of users who give us ideas. Why don't you share the realization we had?

Thorsten: Yeah, the realization is that there's two Amps. And one Amp is the one that our customers use, and by all accounts, it's a great product, they love it, they have fun with it. But then the Amp we use internally is the Amp where I can wake up on a Tuesday and think, 'I want my Orbs to be colored in the sidebar,' and send off an agent, and then I can say, 'Yeah, let's put this behind a feature flag and ship it,' and then I post in our Slack channel, 'What do you guys think about this?', then I tweet it out, and then I get 10 people saying, 'I want this,' and then I can enable it. From idea to deployed version, it's really short.

Thorsten: Like, the biggest blocker right now, I would say, is our deployment pipeline. That's still—because our scale is now large, so it takes a while to roll that stuff out safely to a bunch of these processes running.

Quinn: Usually, like, 10 minutes though.

Thorsten: Well, yeah, there's some stuff. For other stuff. Like, example yesterday, like, again, shout-out to Ian, he was like, 'Hey, can you build this for me?' I sent off the prompt, it did it. And then it was, like, my 8:30, I had to put the kids to bed and whatnot, and I was like, 'Ah, I really want to tell him it's done.' But then it was like, 'Okay, it's 8:30, got to put the kids to bed, I'm going to bed then after—' Like, I don't want to roll this, you know. Like, that was the biggest thing. But it was done done, you know? Like, it was not done done, but it was done.

Thorsten: So yeah, that's a realization that Amp for us is what we've previously called jellyware, right? It's high quality, it's high taste, and I'm quoting here, right? I'm not bragging. And yet we don't develop in the traditional sense of how other people develop software. Like, there's a lot of freedom and a lot of trust in this team on how and when people ship stuff. And it's not vibe coded. Like, it's not slop, and—

Quinn: But it's like, when we use Amp, we are like homeowners. And with homeowners, you can make your house your own. You can put whatever on the walls, you can paint it however you want. You got to do all the maintenance, and if you see something that's wrong, no one else is going to fix it. You got to go fix it yourself. And that's how we feel. And there's a certain joy in that responsibility.

Quinn: And then the other way of using software is where you're just an end user and you cannot go change it, when you're, you know, renting an apartment. And it's nice that you can call the landlord and they can go fix the washer and dryer and you don't have to deal with that. But hey, you know, there's a lot of stuff you'd like to change about it and you can't. And there's pros and cons to both, but all of a sudden, it's become so much easier to go and change the house and so much cheaper. And now, you know, a lot more people, understandably, want to be homeowners.

Quinn: And so we're thinking about, for us, how we can get that Amp way to more people, and how we can give that to you in Amp, and also how we can help you get that in more of the software that you're using. And it does require change in how companies work. Like, if we, instead of building Amp the way that we do, which is small team, a ton of ownership, the ability to fix things, to change things, not a lot of process—if instead we had a very slow issue, product management, roadmap process, and then we had a very slow code review and deployment and approval process, well then it wouldn't matter that we have the ability to change stuff about Amp because we just wouldn't be able to. We'd be bottlenecked on either side.

Quinn: So we want to, you know, as one thing, export the Amp way to more teams, share more about what that means, and why the joy of being able to push to main, and why that can lead to higher quality, and what you need to do differently on your team to make it so you can do that in a high-quality way.

Thorsten: Yeah. That's what lies beyond the Orbs, right? Like, what's the next steps. Like, Orbs are just the next stepping stone, right, to fully leaning into this. And it's funny because you—

Quinn: Yeah, and by the way, someone who has terrible process on either side, for them, if it takes you a week to ship something and three weeks to figure out what to ship, then an EC2 cloud with a bunch of shell scripts is going to be just as good as Amp. Neither of them are going to be that good. Amp really shines when you can move so fast. That's when the multiplayer stuff, the portals, the Orbs, the ability to do so much at once, the ability to have it monitor into production because it pushed and it is rolling it out, all of that stuff, we built Amp for that. So, you know, also us exporting the Amp way will help more people see why Orbs are different.

Thorsten: It's only because you just brought it up, I just realized, like, how seldom I now think about these companies with traditional processes. You know, where we get into contact with them when they say, like, 'Can you make Orbs work for us within this workflow, or in this environment?' And man, like, I guess, like, every software company should throw away, even as a thought experiment, how they've done things, and then restart from scratch and think, like, 'Okay, if we take the trajectories that we just talked about—prices of intelligence will go down, speed of tokens will go up, the intelligence itself will get smarter—if we take these trajectories and take them as a given, how would we develop software?'

Thorsten: And I think a lot of the outcomes would look completely different. That's a summary of this conversation, right? But the funny thing is, the interesting thing to me is, when we see companies—you know, we mentioned Linear, two others come to mind, like Raycast, Shopify, for example. They were founded pre-2025. Maybe 2020, I don't know, with Raycast. But like, pre-agentic companies, and they're leaning heavily into AI. And so you see them reshaping the company to this.

Thorsten: But the weird thing here is that, you know, it's selection bias because we don't ever hear about the companies that don't reinvent themselves. Like, they just die a quiet death. Like, I'm not calling out a name, but I found a company, I posted in our Slack, maybe I could say it's about email, but it was like the website looked like 2004, like 2008 maybe, and it's like, who are you selecting? You're selecting for people that use their computer like it's 2008. And it's not like they will go out with a big bang. They will go out with a whimper because the world has moved on and it's just not going to be interesting. So I don't know where I'm going with this. I'm just saying, like, you need to rethink how you do stuff.

Quinn: Well, it's easier said than done. 'Hey, everyone in the world, go rethink everything.'

Thorsten: Yeah, that's true.

Quinn: But that's why, as we are thinking about, given that we have Amp, how can we have the biggest impact? And to be clear, it's not about us suddenly making Amp bend over backwards to accommodate these old workflows. No, we want to evangelize this new way of working, and also take the fact that a lot of the software that these companies use, you can now replace it with something that has 10% of the features, no settings screen, is maybe 1% of the cost, and is infinitely more customizable.

Quinn: And you don't have to be a company that is ready to be agent-pilled. You don't have to be someone who is using the agents directly in all the ways that we might want you to in order to get a ton of value from that, because you can go and say, 'I used to have this CRM where, you know, one really smart person on my team had to manage it basically, you know, all the time. It was super clunky, it was super slow, and now I can just say, "Hey, I want you to connect to Meta and pull in the data from here for our ad campaign."' And that is something that anyone can appreciate.

Quinn: So, it's how can we get this impact out more? And that's why I don't think that, on the margin, the hundredth person building their own agent platform product, I don't think that's going to move the needle. I think it's time for us at Amp, and really software developers, to think about how you can actually go solve the problem, not build software to build software to solve the problem, or something like that.

Thorsten: Yeah. And you just reminded me of something or made it click, which is, in that triangle of build versus buy versus build and buy, there's a thing here where, what you just said, right? Like, it's easier said than done, rethinking your business constantly while the models are getting better every two months, right? And while the costs are changing and while how good they can do different things is constantly changing.

Thorsten: So, this is what we're doing at Amp. Like, if you're using Amp and paying us, you're literally paying us to constantly rethink how software is being done. Like, and this is what I do all day long, right? And that's in the product. Like, the way we think about how software can be built nowadays, that's the product. That's an expression. And it will look different in two months, right?

Quinn: Yeah.

Thorsten: So, that's another thing. So in times of these technological changes, it's not just like a static build versus buy, because the landscape is completely changing, right? It's like, you know, 'Do I make my own rain jacket, or do I buy a rain jacket?' No, no, no. It's like you're going into the jungle, and there's, like, a guide there, and he's going to give you the clothes for the day because he can read the weather there. It doesn't matter whether you buy or build your own rain jacket, the weather is going to change. And you want the guy in there who can read the clouds and whatnot, right? Not to oversell it, but I think that's—

Quinn: Yeah.

Thorsten: I don't know what that analogy is, but, you know, like, AI land is a jungle.

Quinn: Well, I think if you import that to software, in the past, software was boring. It had to be mediocre because of that principle of the software business: you build it in year one and then you milk it for the next 10 years because it's zero marginal cost copying, you know, you want it to appeal to the broadest market possible.

Thorsten: Yes.

Quinn: And now that's changing. Like, why do I use Ghostty? Because I trust Mitchell in what he thinks a terminal emulator should be. I want to see what is the issue tracker, not made by a company that has to water it down to appeal to a lot of people, but what is the issue tracker made by someone that I really respect that has crazy ideas, who's going to show me not just, 'Oh, it works,' but how I should be doing this in the future. Or how we do video calls, how we plan our team events, how we do travel, all these.

Quinn: And so, in the past, if you had a great idea here, you'd have to go and hire a bunch of people, spend all your time doing that, not on the product. You'd go raise VC money, and in the end, the incentives would not be to build the most opinionated, correct product, and there would only be, like, a few competitors. Now, there can be so many more competitors, and you could even have, 'I want to use so-and-so famous developer's or famous product person's product because their name is what gives me trust in it being different.' And they can make so much more money, and it could be cheaper because there's so much less overhead that they need to go and build that and distribute that and sell that. They do not need to make a settings screen. They do not need to make it multi-tenant. They do not need to do all of this other stuff that they used to have to do.

Quinn: And that is really exciting. So in the same way that we want Amp to be a representation of how we think you should be building, and if you trust us, then use Amp and we think you'll have a great time, I want that for all the software that I use.

Thorsten: Yes.

Quinn: You know?

Thorsten: You're paying somebody else to think about the problem constantly. Like, that's what you want. I want Mitchell out there thinking about terminals constantly. I want whoever the person is at Google Meet who thought of, when I switch tabs, they show me the little pop-up, you know, where the Google Meet meeting goes on. Great job. Like, I want you to think about this. I don't want to think about it. Which goes back to your point of, like, you want to do the thing and not build the thing to do the thing.

Thorsten: And yes, intelligence is cheap and tokens are cheap, and thus labor, like, intelligence labor, is cheap, but like, the thinking that a human does about a problem space is still different, right? Because it's continuous, and they have different options and they weigh different options and they're human. So that's kind of what's worth it, right? That's what you're paying for. I want, like, a Rasmus Andersson designed text editor or whatever, because I don't want to think through the edge cases, or Zed or whatever. Like, I can whip up my own, but for certain things, I want other people to think about it.

Quinn: Yeah.

Thorsten: Oh yeah, I think we should end it. I'll end it with a short anecdote because you brought up Ghostty and the terminal. So we all killed our local dev—I don't know, barely use it anymore, right? And I posted in our Slack, I said, like, 'In the last six weeks, I forgot all of the Jujutsu or jj shortcuts that I set up, the aliases. I was completely lost.' And then Tim Culverhouse replied, and Tim Culverhouse, for those who don't know, he built his own terminal emulator. He built his own, I think, Wayland compositor, window manager. He built his own email client. He built, like, everything he uses, he built himself. He has his own shell running in his own terminal. And he replied saying, 'I have the best terminal and the best shell in the world, and I don't use them.' And a sad smiley, because he's fully in Orbs now. So, what does that say about, you know, the value of software?

Quinn: Yeah. And everything is changing faster, so if you were someone who has thought X and then you found X to not be true—I mean, we have, and it's very humbling—then you just get your mind to a place where you permanently are more open to crazy changes out there.

Thorsten: Yeah. Wild times. All right. We'll see you next time.