Culture Stops Slop

Thorsten: Some people say, ‘Guys, you can only do this because you have unlimited tokens.’ The message I want to put out is: sorry, but tough luck. It's not a level playing field if you're the guy who can only spend 50 bucks in tokens a month going up against others. And saying, ‘Well, but you have tokens,’ is like saying know, 2003, ‘Yeah, but your company has better internet access. This is why you're, researching stuff on Stack Overflow.’ It's like, ‘Yeah, dude, get on the internet,’

Thorsten: You're not being graded on output and how many tokens did you use. You're just graded on output, and you've got to get the tokens.

Quinn: You say all of this stuff about how the agent is so good and how you should shape your company around it, but, come on, you work at a company that's selling an agent. Why would anyone believe you? You are so obviously financially motivated to say these things

Thorsten: The answer is: you got it backwards. I don't talk about agents and how good they are, and how good AI is, and how you should rethink software development because I work at Amp. I work at Amp because I think AI is changing software development and agents are good.

Thorsten: Welcome back to Raising an Agent, episode seven. And this time we're going to respond to all of the responses we got from the last episode, the one that blew up, where we talked about the company of the future, right? We got a lot of emails and a lot of questions. What's in your mind, Quinn? What's the most important question, or the one that stood out, the one that you got the most often?

Quinn: Well, my favorite thing is hearing people say, ‘I have wanted to make these changes at my company for a while, and listening to you guys actually gave me the courage and the ways to go and argue for this.’ So we heard from a lot of people that actually went in their private chat on Signal with all the cool people at their company and actually said, ‘We got to change something.’

Quinn: We heard from people that actually stopped doing pull requests, and, you know, the joke is, ‘Oh, you think that Amp is great for productivity, but actually the number of pull requests you do plummets when you get Amp.’ But, of course, that is intentional, and that's exactly what we want to hear.

Quinn: We'll get to questions. What did you hear, like what got you excited? I would say the mood here is quite ebullient.

Thorsten: Yeah. There's like this weird tension that I feel in the responses where some people all in. Like somebody yesterday, a customer, ‘Guys, we stopped doing PRs. I fully get it.’ Somebody else yesterday said like, ‘We're rolling Amp out to the whole company. It's going to be awesome.’ Others are like, ‘We're doing everything in Orbs.’ Like they fully get it. And then, there's like this other response of—well, I don't know. Sad responses. One of them was ‘Guys, I love what I'm hearing on the podcast. I want to work like this. Sadly, our security team says we have to do PRs. I can't have the agent monitor the rollout and whatnot.’ Like that's one thing. And then, not going to turn this into a rant, but there's like this response where somebody said, ‘It's stupid that you don't do PRs. You've got to meet people where they are.’ You know, like, ‘Everybody uses PRs, and why don't you have PR support in your product?’ And yes, on the surface, good—you know, whatever. If this wasn't 2026, good feedback. But it is 2026, and if I meet people where they are, I'm going to be left behind. Then I'm going to build something that's useless in half a year. You know? That's not what we do here.

Quinn: And if we do that, if we make something that is maybe helpful today for where you are, but in six months is totally behind, then not only do we lose, we also make you look like a bozo in your company, and we waste a lot of your time. So we don't want to do that, and our promise to you is come with us. We are going to walk with you on the frontier. It's going to be bumpy. We're going to learn a lot of things together. We're going to make some mistakes, but we're going to be way ahead of anyone who started walking and then stopped like six months ago.

Thorsten: Yeah. The other for which we have two good examples, is, okay, if the Amp team works by having a meeting on Monday, and then everybody goes off and does their own thing, which is also a simplified version, I'll get to this, but the question is, how do you do big architectural changes? How do you change a system and how it works?

Thorsten: I get where the question is coming from. I worked on teams where big architectural change was something where you would write up an RFC, or something, and you need to get buy-in because you need to get stakeholders aligned. And that all sounds dumb, but what it means is, I'm, say, on, whatever, backend team A, and then there's B and C, whatever, and you need to ask them, ‘Hey, we want to change the API because of this and this and this, so we got to get buy-in,’ and whatnot. How do you make changes like this? Obviously, we're not a three-team organization. We have a single team, so we don't have to do that whole thing. Our ownership is fluid in a sense, or people own a lot of stuff. To give you an example, last week, we launched self-hosted Orbs, which is an architectural addition, a big thing, we had to change it architecturally fundamentally. I sketched out an interface for how it could work. And I basically said, ‘Look, like a customer, if they want self-hosted Orbs, they've got to spin up a new service, and that service then listens for us telling them, "Hey, spawn up a new Orb." And then that service can implement it however they want.’ That's still how it works.

Thorsten: The customer has to fill in the blanks, and decide how to spin up things. So I sketched this out, I had it working, and then Hitesh picked it up. And Hitesh was like, ‘Yeah, I can own this, and I can make this work at a customer.’ And then with Karl and Jesse and Alex, I think, on site at the customer, they were trying to get—well, in some cases,

Quinn: Flying halfway across the world, by the way, in search of…

Thorsten: Not even halfway, like completely around the world. And then setting this up. This wasn't launched. This wasn't done. This was like a prototype thing just for this customer because we wanted to get it working for them. So, they try to set it up for them on site, and they notice the security team loses their mind. They're not going to allow inbound connections. We can't do this. So, there was a Slack channel with these discussions. They sketched it out. I'm like, ‘Hey guys, keep me updated.’ I wasn't there on site. I'm like, ‘Just what are you guys deciding? What's the new architecture?’ And they riffed around, and then basically we had just a Slack chat where we're like, ‘How about we do this?’ And then we sketched out back and forth in like one Slack thread, ‘How about we build this little piece, and it goes like this?’ And somebody dropped a screenshot of a diagram in, and then we built this. Turns out, yeah, we can do this. So, then, was me, Karl, and Hitesh basically focusing on this. ‘Yeah, let's roll this out.’ And then I said, ‘Let's write the news post, and have an example in there of how it works.’ And if you look at the self-hosted Orbs news post from last week, that's still in there.

Thorsten: The idea was, show me the API in that news post. And then we used that news post as like the foundational design document, basically, and went back and forth, and then Hitesh was like, ‘Oh, I can make the API even simpler. I can reduce even more.’ And then we just went back and forth, and then we changed the thing completely, how it works architecturally, by just, basically to summarize, go to a customer, get feedback, change the API, and then iterate on the design. And while we were doing this, we were already reaching out to other customers who had shown interest, and got them as a design partner on board, and said, ‘Here's the docs. Here's the news post. This is still work in progress. How about you try this out, and give us your feedback?’ And then we refined based on this. And then we launched last week with the final design, and now people can adopt it, and it's no problem.

Thorsten: So that was a big architectural design decision.

Quinn: Yeah, so let's break that down. What actually went into that? First, there was a high-level idea of the design, and I think everyone on our team is a good engineer.

Quinn: And then we actually went on-site to the customer and the people building it were directly on-site and they were not shielded by other people. They had the agency to do whatever they wanted to do. You happened to not be on-site that week. You cared a lot about the project, and you trusted them to go figure it out and to learn.

Thorsten: Yeah.

Quinn: And if they wanted to go make a big change, they didn't have to go through a lot of different layers. They could just literally make it work on-site that week. And part of it is we have a really awesome culture and a small team with high trust. Part of it is agents make that kind of stuff possible. And so because it's now possible technically, you get even more benefit from having your culture in a place where you can make those really fast changes.

Quinn: And

Thorsten: Yeah.

Thorsten: Yeah. Let's be honest, like it wasn't all everybody happy and roses and, you know, like that wasn't it. Like when they were on site and doing architectural design, I was over here thinking, ‘What are they deciding?’ You know, like, let me know. And I saw like a photo of like a whiteboard or something, and I'm like, ‘I don't think that's the right thing.’ And I pinged them like, ‘Guys, what's up?’ And then we went back and forth and whatnot. And that's how it is. Like there's no way around this. You got to talk to each other. Like whenever you're creating something or like sharing ideas, it's insane to think that five people at the same time can come up with the same image in their head without exchanging ideas and how the image in their head differs from each other, right? So you got to talk to each other. Like that was the other thing. There were so many responses to our podcast where my response was, ‘Well, we talk to each other,’ you know? ‘What if somebody ships something that you don't like?’ ‘I tell them.’ ‘What if you're not sure about something?’ ‘I ask somebody.’ And it sounds dumb, but, dude, like that's why we have a small team. You just talk to each other.

Quinn: There's another part, though, which is really important for making this work. The way that we chose the architecture is basically telling customers, ‘Hey, you write a program that follows this contract and takes whatever infra you have and just, you know, responds to certain messages and all of that.’ And it's very easy to do with an agent, but there's no way you could have done that even a year ago. I don't think agents would have been nearly good enough to do it.

Thorsten: Yeah.

Quinn: And it's also something where if you are selling software in a traditional way where it's like the white-glove support and people expect like a click interface and everything. I mean, no, this is not it. It's like customers will have some stuff, and we have a lot of stuff to help them get started, but we expect them to solve the last 20% for themselves. And it turns out they actually prefer that because that last 20% is either they go back and forth a million times with the vendor, like us, or they just have their agent go and do that.

Quinn: And we were willing to fully embrace that. And a lot of other companies, they are trying to do it the old way where you have to follow exactly their recipe. Oftentimes you have to get their people on to go and deploy it.

Thorsten: Yeah. I want to get into this. So the interface for self-hosted Orbs, by design, was based on the notion that it's really simple to now write adapters, or shims, or whatever you want to call it. When I basically say, ‘Here's my interface. Like I'm going to send you three requests: spawn, pause, and delete, right? Spawn an Orb, pause it, or delete it.’ And spawn acts as start or resume. And then you write a program that accepts these three requests, and then you decide in that program how to handle these. In the before times, before agents, people wouldn't have done this. Because then you would have to write Bash, or a different program, and what do you mean if I have this provider or that provider, you want me to write this up myself? Why don't you have a blessed provider or a blessed adapter, or something like this? But the idea from the start was that, ‘No, you got to adapt this to your own infra, and every infra is a little bit different, but now we have agents.’ As long as I have this interface, and you have your infra, and the agent can see both, it can rip out that code. So that was the bet behind this. I think in the before times people would have done YAML-based stuff, or like different configurations, or like a repo with like different YAML files, and you choose one or the other, and you put the config files in.

Thorsten: All of this to avoid writing code, right? Like you just change the parameters, and you don't write code. But now writing code is super easy. So, we shipped this, and then Andrew on the Amp Labs team, I think like half a day later, he's like, ‘Oh, I got this working with my own—’ No, my friend, he builds like a hypervisor or something, like a custom hypervisor. I don't know what it is. And I said, ‘Okay, I have a hunch, but how easy was it to get started? Like what did you do?’ And he's like, ‘Well, I just took the docs page and told my agent, "Please write an adapter for this." And it did it in one shot, and it worked perfectly on first try.’ So that's something that people have to lean into. You leverage when you build interfaces, when you build software, when you want to integrate with other stuff, leverage the fact that agents can now, fill in the gaps between like two pieces of software easily. Like it's so easy to say, ‘Here's this API, here's this API, make this work with this.’ If it can see both, and can exercise both, solved. So that was the little thing that we leaned into with self-hosted Orbs.

Quinn: And again, be a lot harder if we had different sales team, a different marketing team, a product management team, a different finance team, and all of that. That would make the product worse. It would make the customer experience worse.

Thorsten: Well, before we get into the next architectural thing, let's change it up. Let's get into the next response we got where people say, ‘Guys, it's nice that you work like this, but you're only 21 people,’ you know? ‘Of course, you work like this because you're only 21 people.’ So, what's your response to that?

Quinn: I think that this is the best way to work and I believe that this is how we make the best product for customers. I think it's how we make the best customer experience.

Quinn: And if you've been on the receiving end of—you have a feature request or bug report and then it gets shipped in 30 minutes, and we can do that, I don't think you care that we're 21 people. You just love that we can do that. If you love our product, you don't care that we're 21 people.

Quinn: So our product and the business that we are building, it almost doesn't matter how many people it is. It's: are we doing a good job of that?

Quinn: And if we are, then I think that having 21 people, that's an asset. And if you are in a company where because you have more people you are not able to perform at the level of a company that has less people, then I think you need to reconfigure how your company is built.

Quinn: You know, the only given is that you need to have a great product, you need to please customers in the market. There's competition, and everything else has to follow from that.

Thorsten: Yeah. The question or the response of ‘but you're only 21 people,’ it's kind of a self-own, as they say, because it's kind of like was it, 2003, Bezos published or said like ‘two-pizza teams’? I don't know if it was even Bezos, but it came from Amazon, right? Like the ideal team size is a two-pizza team, which is also, by the way, pretty US-coded. Like two pizzas in Europe is not enough for a team. Like that's just—but anyway—because the pizzas are smaller.

Quinn: Why not? Wait, how are…

Thorsten: You don't order like the huge pizzas, and only then it's like—you don't count your pizza in slices in here. You'll count your pizza in pizzas. You say, ‘I had a pizza.’ It's not like, ‘I had two slices.’ The slices are tiny. Anyway, we can turn this into a clip.

Quinn: You don't have pizza slices in—is that an EU or GDPR?

Thorsten: No, we do. We do have pizza slices, of course, but they're tiny. They're just much smaller. So anyway, two-pizza team.

Quinn: But the size of the slice doesn't affect the size of the pizza.

Thorsten: They said that—it did, it did. It's like you have huge pizzas, and then one slice is enough. So you're saying two pizzas is enough to feed the team, but if the pizza is this small, the team size changes depending on the pizza size. It doesn't make sense. Anyway, they're talking about like five or eight people, right? They said like ideal size is a two-pizza-sized team is five to eight people. I think when people now say, ‘But you're only 21 people,’ that's kind of like saying, ‘But you're only a two-pizza-sized team.’ Like, you have a small ideal team size. Yeah, that's not the reason. That's the cause. Like that's why we're doing this. It's like saying a huge company, ‘You can only move fast because you're a small company.’ Yeah. Like, you need to kind of justify that you're a big company by having other advantages. You can't say, ‘We're this big, and we move slower.’ Like, you know, like you have to have some reason why you're this big. And if you move slow, and you can't please your customers, and you can't ship products fast, and you can't build products you want to build, then you have to re-examine why you're this big. So

Quinn: And if you're not having fun—you should be having fun. Everyone should be having fun. It is golden age of technology right now. And if you're not having fun, that is more than anything, that's your body telling you—this sounds super woo-woo, but it's telling you that you got to change up what you're doing.

Thorsten: That was another response somebody was like, ‘Okay, real talk. What you said in the video about like do what gives you energy, is this like just marketing, or is this also the real thing, you know?’

Quinn: Have I ever told you, Thorsten, ‘Just do what gives you energy’?

Thorsten: Yeah, you've said this a bunch of times, like many times, and I said, ‘No, it's the real thing.’ They were saying like, ‘Would you tell me the same thing over beers?’ And I said, ‘I would exactly tell you this over beers.’ But I guess I would also say that, look, we're all grownups here, like it's not like an incident happens and people go like, ‘Oh, this doesn't give me energy, I'm off.’ You know, like everybody knows that yes, there's stuff you have to do, but everybody also is aware of, you've got to follow your curiosity to some sense, and it's not worth it to—you know, that we as a team say we're going to build a Jira integration for the next four weeks. And everybody hates it, you know, like maybe if like customer really wants it, then we kind of would get energy from helping that customer and enabling that customer, but just doing stuff where you don't get energy from it is not—I don't know, it's not valuable, it's not productive. And it's not always the same energy level, and you kind of need to figure out how you can make it more fun maybe, We talked about this yesterday, I'm not going to drop the name yet, but I'm working on something and it's kind of been dragging.

Thorsten: Then yesterday—I think it was yesterday—I sent you a message and I'm like, ‘Ah, now it doesn't give me energy. It feels like a drag.’ I went to the gym and then I walked back and then, you know, Tim Lucas was saying—he doesn't like the name of the thing and I was like, ‘Oh, now the name is not’—you know, like I was like, ‘This sucks. Like I want to do something else that's easier.’ And then I was like, ‘Okay, what if the name isn't good?’ Then I started riffing on the name and then I hit on a new name for the thing and suddenly everything clicked into place for me. And now it was this, ‘Okay, I can see it. I can see the news post, I can see how I announce it, I can see how I talk about it, I can see how I can sell this to somebody. I can see the whole thing.’ And suddenly the energy was back. Now, what does this mean? Do I do things that don't give me energy or do I like try and get more energy out of it? Do I push through? We're not toddlers. It's not like, ‘Oh, this is fun. I'll just drop the stuff and walk away.’ I think we're realistic and pragmatic about it, but we do see it as our goal to do stuff that gives us energy.

Quinn: Yeah. And you feel different kinds of energy at different times. We've had a lot of people for a long time asking for an Android app for Amp. We have not had one. We've just said, ‘Oh, use the progressive web app,’ and that's okay. But finally, I don't know why, but just last Friday, I decided I want to make an Android app. Let's just see how far Amp can get. And let's see how it can use all the things we've given it to, I don't know, see how it goes. And it was interesting for me because it's kind of a test and kind of a joke. It's a funny thing. I did not tell anybody on the team that I was doing this. No one had any clue. And I think if I had to go and justify to the team and say, ‘Why is this the most important use of my time right now?’ That would have sapped all of my energy. But instead, I just had the agent go and rip on it on a Friday night, and that was actually why when I was sitting with my wife watching a show or talking or whatever, all of a sudden my computer started saying like, ‘Android emulator test,’ and it scared the shit out of us.

Quinn: But it built it. And I did not even have an Android tablet at the time. And then another thing that would have sapped my energy is if then I had to wait, ‘Oh, I can't ship it because I need to go talk to people,’ or it's not at the quality bar that we need, so I have to go buy a tablet, go test it manually. I'll be honest, that did not give me any energy whatsoever. So what I did is I published an APK behind a hidden URL on our site, and I tweeted it out, and then people started to use it, and they sent in feedback. And I had the agent go and see, what was their feedback? Let's go fix it. By the way, throw in some free credits as a thank you for crawling through glass to find this. Then people said, ‘Actually, this is pretty good.’ And at this point, I still had no Android tablet. So then I went on—I think it was Instacart—and I got a Samsung tablet. Here we go. And I tried it, and thanks to all of those iterations, it was actually pretty good.

Thorsten: Nice.

Quinn: And that is a way that I took something that's, you know, kind of like that Jira thing. It didn't give me a lot of energy. But all this freedom that we have in this no process, this amazing customer base that is willing to give us feedback, and everything we've set up with the agent, it made it so it gave me energy. And now, we've got an Android app that a lot of people love.

Thorsten: Yeah. Okay. Good example.

Thorsten: Let's jump back to another architectural change. It just launched an hour ago, macOS Satellites. Hamish built this with Jesse over the last month maybe, a little bit more.

Quinn: People want to be able to build iOS apps and macOS apps using Amp, and previously the only way they could do that was with a runner. They could use their current Mac or some other Mac and they could run it. But people like Orbs, cuz then you don't have to think about it. It's just somewhere out there. And yeah, that's what we wanted to solve for.

Thorsten: Yeah, that was the problem. People said, ‘I love Orbs, I want to be on Orbs, but I'm building an iOS application. What do I do?’ And we told them, ‘Leave your Mac running, use this as runner, build stuff and whatnot on it.’ So then Hamish started working on this. And the first obvious solution is—and that's what everybody requested—let's just build Morbs, macOS Orbs, like instead of having a Linux machine in the cloud, as a VM, you just have a macOS machine in the cloud and you run your whole thread on this. Well, turns out in the year 2026, compute is hard to come by, including macOS machines. And I mean, I guess they've always been rare in the cloud, macOS machines. You've got to have those physical Mac minis and MacBooks and whatnot. And we have a great partner with Namespace they do a great job of like getting those machines into the cloud. And yet, still like they're rare, you know, and they're also expensive because they're rare, okay? That's the market at work.

Quinn: Some things are slower about them, just cuz Macs are different than Linux, or not as virtualizable, snapshot-able, and so on.

Thorsten: Yeah, Docker, for example, is slow on there. So that was a big issue. Like, they're rare, so they're more expensive. Okay, so they're slow for some things like Docker and whatnot. And then a twist on this is that most people's dev stack is kind of like better on Linux, or like, most of that stuff like your dev server and whatnot is on Linux or works best on Linux. And then now you have the whole thing in macOS. But when you look at it, you only need it for a portion of the time, right? You're building a macOS app with your local dev server, for example, where it talks to the server, you might just need, you know, the iOS simulator for 10% of the time, or 50% of the time, not the whole thing.

Quinn: Yeah, and the stats we found were very interesting. Even when you're doing heavy macOS or iOS development, which our early set of testers for Morbs were doing, you only needed the Mac 35 to 40% of the total agent time.

Thorsten: Yeah, that was what we found out. So then how did we make a change? We were in SF, it was Jesse, Hamish, you, and me the same table basically, and we were talking about this, and we were kind of riffing, and I think it was Jesse who said like, ‘What if instead of having, the macOS Morbs, we just have like a macOS machine the agent can use, like a sidecar?’ That was the first name for it. And then went back and forth, ‘Yeah, it could work, could not work. What do you think about this?’ And then, ‘Hey, Hamish, let's try it.’ And Hamish was like, ‘Yeah, I'll build a prototype.’ And I think it was like half a day later, he had it already working. So he gave the agent the tool to spin up a new Mac. And then what did he do? He gave us all the feature flag. ‘You guys try it out internally, let's get some feedback.’ At this point, too, we already had customers in like a beta, phase. They were like opting in, they were trying stuff out. Hamish was talking to them and kept them up to date, and was like, ‘Hey, we're going to change a bunch of stuff. They now work like this.’ And then we got feedback from them.

Thorsten: And then we realized, ‘Oh, this is much better.’ And then, again, Hamish wrote the news post of here's how it works, and then based on this, we iterated on, know, how do we talk about this, what are the explanations, what are the reasons. And basically, he owned this end to end. Him and Jesse were working on this. I I never looked at any of the code, I don't think you have. And then it was just based on customer feedback, based on trying it out, based on, having the feature flag on, and like just talking to each other, we kind of made an architectural decision. And didn't write an RFC, didn't write another thing. We used the newspost as kind of maybe like an RFC thing, or like it at least fulfills the function of, some function that RFCs have in other teams. But that was it. That was a big architectural change.

Quinn: It's the kind of architectural change that if you had pre-planned it and you had set off other teams to go and build around it, and it was documented, it would be painful to change at a later time. If marketing and sales had started talking to customers about, ‘Oh, we're going to do this way,’ you couldn't change it. And we can change. I mean, I remember we all kind of stood up like prairie dogs at our desks and we're just talking about it. And Hamish just like, ‘Yeah, we'll change it.’

Thorsten: Yeah. That's a good picture instead of like prairie dogs. That's really good. Okay, you might give me shit for this. I think at the heart of all of this is that we're truly, capital A, Agile. I know everybody hates the word agile. I know everybody hates it, but at the heart of agile is the idea that you cannot foresee the future, you cannot look that far ahead, you've got to build something in small increments, have it touch reality, meaning give it in a customer's hand, try it out yourself, get feedback, figure out whether the thing you built works, and then iterate based on this.

Thorsten: And that's what we do with most of the stuff that we build. Like I'm working on something, we all internally have access. Everybody's trying it out. I woke up to Kemper sending me six messages with feedback on it. So now, I'm incorporating this. Then, I'm building the next version. I'm going to tell everybody else, ‘Let's try this out.’ I plan on, it's Thursday today, I plan on getting a customer on this week. It's not finished, but it's not, don't know what it is, 70% done? I don't know. I'm not going to release it to public this week, but I'm getting a customer on. I know that some customers ask for this, I want to get their feedback. And then I'm iterating on this feedback.

Thorsten: That to me is like agile. And the funny thing is, previously, this stuff was hard because it's hard to get software in a user's hands. It's hard to build stuff that's only available for a bunch of users. Because feature flags are, nasty. Like I don't know, like I mix up the booleans all the time. Like shipping releases often is nasty, having like a separate, what you did, like an Android build APK that only some people can download, you know? Or opt into a bunch of other features. Like all of it's dumb stuff, but it's like chores, you know? It's work.

Thorsten: And making stuff only available for a few people, merging it in bits, hiding it everywhere. It's easy to mess it up, it's easy to half-leak stuff. So you end up with stuff piling up on the branch and whatnot. But now with agents, you can modify how you ship stuff. You know, not only what you ship, but how you ship it, how you get it out to people. And I think we fully lean into this. Where we're like, ‘Hey, I'm just going to enable this for a bunch of people, I'm going to get feedback, I'm going to iterate on the feedback, and then I'm going to ship more and more and more.’ Like how it works. Like that's what most of the stuff is.

Thorsten: And I've said this before, right? The first stage is, people treated the agent as a replacement for the text editor. It's the thing that runs on your machine, and then you do a git commit, and then you push it up. That was end of last year for us, I would say. Then, over the course of this year, we left our local dev env, we're now in Orbs. Okay, cool. And now, we have the full SDLC. So we have prototyping, features, ideas. We have all of this in one thread. And we should go into this in a second.

Thorsten: So now, the whole lifetime of a feature is now in an Orb, in a thread, it's controlled by the agent. The meta point that people have to realize is that how you approach software—not you don't just use it to speed up the things that you've done previously in 2019, you know? You don't just speed them up to now leave comments on PRs or whatever, you know? You need to rethink what are now ways to deliver software to my customer that are now within reach,

Thorsten: Founder reached out to me, and he said, ‘I want to work like you guys, but I can't because we have sensitive data. You know, we can't just ship stuff and revert it. We can't lean into this and whatnot.’ And I fully get it. Like we're not building heart rate monitors, right? We're not building rockets, which is what everybody else who replies to my tweets apparently does. But so we're not—you know, like we can roll back stuff. But his point was, ‘I'm working with data. You know, a bad deployment messes up everything, costs us a lot of money.’

Thorsten: And then I said, ‘Think about it like this: You can now snap your finger and make tooling disappear, So what tooling and what process would make you ship 50 times a day even when working with like sensitive data or lots of data? What tooling that previously only the big tech companies had do you wish you had? Because now you can snap your finger and actually build it. You can now have whatever duplication, you can have better reverts, you can have, I don't know, shadow copies, blah. Like all of that stuff that would make it easy to work with the problem you have, you can now build this. Like think about the tooling, the processes agents can touch and revolutionize those too.’

Thorsten: So,

Quinn: Right. Find the parts of what you do that an agent can be very helpful with and go really aggressive there.

Thorsten: Yeah.

Thorsten: What's your response to this? People say, how do you not ship slop if everybody can just push to main, and there's no meetings, and you don't have to have a PR review, how do you avoid people shipping slop to main?

Quinn: I think it comes down to the right people and culture, but not like, ‘Oh, we need to make sure we hire people who don't ship slop.’ I believe that there is someone who on our team would not ship slop, and you if you take people out of our team, us included—we are not, you know, special. ‘Oh, we're perfect. We never do slop.’ You put us in another environment with different incentives and a different culture, then that would cause us to ship slop. And what makes it so that someone doesn't ship slop? Well, they have to not want to ship slop, and they have to know what slop is.

Quinn: And how do you do that? Well, you give them skin in the game. You make it so that they're not just a cog in the machine doing this part of the process. You make it so they're actually the ones talking to the customer. They're the ones out there. They're the public face of the company. We have 21 co-founders at Amp, 21 people on our team, every single person is a public face. And you make it so that when they ship it, they need to go maintain it as well. And also, you keep that bar high because everyone else is doing this and then there's a sense of pride. And also, when you have 21 people and it is so clear that every single person is valued and trusted, and we get together all the time, and we have a lot of fun when we get together, you know that you can call someone out and say, ‘What the slop is that?’ You know, if someone does do something like that.

Quinn: And it's not perfect, but it's kind of like when people ask these questions, it's as though somebody is asking, ‘How do you turn on the faucet in the kitchen?’ And I say, ‘Well, you know, you kind of turn it on.’ And they're like, ‘But like, tell me more.’ And there's some things where it is just not a problem that we feel, and it is only because of our experience in other settings that we can understand where those questions are coming from.

Thorsten: Yeah.

Thorsten: Yeah. And I mean to be fair, what I realized after recording the podcast the last one was, yeah, a lot of it is culture, to paraphrase, what is a company's culture? It's the things you value, right? The things that if you were to do you promote and what you fire. Like that's your culture.

Thorsten: And in our case, we have a constant feedback going on in our channels, where if somebody ships something that looks sloppy, you will get like somebody saying in the channel, ‘This looks bad. Let's take this out.’ And if you ship something that's great, people will say, ‘This is great.’ And then you align on the taste, right? It's this, like I review all of the newsposts. If somebody puts like a sloppy-looking graph in there, and they haven't thought it through, I will tell them.

Thorsten: If you don't have this culture, yeah, you will have slop. But, the solution is not to have mandatory code reviews and then leave passive-aggressive comments, or point your finger at, ‘This other team ships bullshit.’ Like then you got to start earlier. Like why do you feel afraid to not tell this team that they're shipping bullshit? Is it because what? You will get reprimanded from their manager, Or your boss will hate you for it. Like that's the issue, you know? It's not that somebody ships slop or something. You've got to get aligned on what you value as a team, what you value as a company, what you think is good. And then, then the slop, I guess, disappears.

Thorsten: And

Quinn: Yeah.

Quinn: When you have that feedback mechanism, when there's someone who is actually going to come up with the idea, they're going to be responsible for getting other people excited about it and other people using it, then people can do incredible things. I think we have a brilliant team. I think we have amazing people, but it's not clear. I mean, there're people on our team that are doing things that they've never ever done before. And if they were at a much bigger company, they would be crowded out by senior engineers that know how to do all this stuff and that have done it before, and the marketing team would do this and all that. And people here figure out how to do it. And they can fail, but it's that feedback mechanism kind of like an agent where, if it can try things and fail and try things and fail and—yeah.

Thorsten: Yeah. Yeah.

Thorsten: I mean good example. Look at Hitesh. He's, I don't know, he's pretty young, I don't know, but basically his background is, he's

Quinn: I've been very surprised when I actually find out how old some of the people on our team are, and

Thorsten: Really…

Quinn: They are a lot younger than I thought. It's pretty awesome.

Thorsten: Yeah. And I realized this, realized at some point, they treat me like one of the older people, you know, how I look at people who are much older than I. I don't know.

Quinn: I think they called you a chopped unc.

Thorsten: And well, they didn't call me chopped unc.

Quinn: Is that right?

Thorsten: I think it came up, yeah. But yeah, it kind of took hold.

Quinn: And yeah, Thorsten and I are still trying to understand what that term means.

Thorsten: Well,

Quinn: So if you know, please write in and tell us.

Thorsten: Yeah, the cause was because I did the six-seven thing, and they were like, ‘This is, you know, this is over.’

Thorsten: But so Hitesh's background is machine learning. He's a really smart guy. It's fair to say his background is not product engineering. And yet here at Amp, what I just saw this morning before this recording is he shipped self-hosted Orbs last week. And then yesterday morning, he shipped personal self-hosted Orbs, which is kind of a twist on it, so more people can use self-hosted Orbs. Why did he do it? Because he was in the customer channels that we have, talking to customers that are using self-hosted Orbs. And there's one customer or two at large companies where they're like, ‘Hey, I want to start with this, but I'm not a workspace admin. I cannot do this. Is there any way I can try this on my own?’ And then Jesse had the same idea. And I think then Hitesh built it over the weekend, and then shipped it this week because he was talking to customers. And then this morning, he's in Slack going to other customers that have shown interest and letting them know, ‘Hey guys, this is now possible.’ Why does he do this? Because it's the culture, I guess. Because then somebody will write, ‘That's awesome that you're doing this, talking to customers like this.’ Because we don't have PMs in the middle, Like not to get all Karl Marx on anybody here, but you remove the middle thing where the fruits of your labor, you can see how they're used by the customer, and it's really energizing.

Thorsten: You're not removed from the outcome of your work. That's energizing. I guess in our Monday meeting, we say stuff like, ‘Hey, you should talk to customers. Get feedback from them. Talk to customers. Hey, can you reply to this person on Twitter?’ Everybody feels encouraged to talk to customers, and it feels weird maybe at the start, but it's energizing ultimately. So

Quinn: Right. And there's a lot of companies where the developers talk to customers, but it's a one-way thing and it's very delayed. It's like the engineer is on Mars and they're getting a signal from Earth, and then they may or may not respond, and it's going to be very delayed. But I think everyone knows that when you're talking to anyone at Amp, if you have any kind of feature request, if you have any kind of bug, if we don't turn it around very fast, then we have no excuse. Like, it's either a yes, we will do it and it'll be out very soon, or it's a no.

Quinn: And that's the other thing, cuz a lot of people did come and say, ‘Oh, we're doing this thing where now each engineer is adopting a customer.’ But that's not enough. You got to make it so that you don't just adopt them. I mean, I guess when you adopt a child, you also take care of them. So, you have to actually take care of them. You have to fix the things that they need. You have to make the overall experience that your whole company is giving them so much better. And you need to turn that around on an agent time scale. You need to ship them a fix within 15 or 30 minutes sometimes. That is taking care of them. It's not you are learning and then submitting that back in. So if you've taken that one step, take that other step, too, where you actually fix and improve the product, no matter who owns what you're fixing. You are their representative, you're the ambassador of your company to them. You own everything.

Thorsten: Yeah.

Thorsten: Yeah, but okay, Quinn, if we all build the stuff and fix the stuff that the customers ask for, we will end up with 1,000 features, right? We will end up with everybody just fixing stuff here and here, and adding stuff there and there. How do we avoid this situation? How do we avoid, Amp being the everything app with like all of the things and whatnot and too much stuff for everybody? How do we not fall into this trap?

Quinn: There's actually a really big tension there that we feel. Before I get to the kind of product side of it, it is really energizing for a lot of us to go and fix customer problems, to make Amp better in small ways, and neglect the really big things that we want to do. The big thing you're working on or something like self-hosted Orbs or macOS. There's a steady stream of things, the model landscape is changing all the time, we can always make Amp a little bit better.

Quinn: And you know, the example I gave about building the Android app, was that the best thing to do, or was that kind of procrastination? I don't know. I think a lot of users love it, but is that what's going to make the difference for Amp versus something else? I could not justify that. I could not prove that. So it has been hard for us to carve out the time to get deep focus and to work on the really big things that we think will bring us, you know, several months ahead, or that nobody else could do.

Quinn: We don't know the solution to that other than just talking to each other. And sometimes what we'll do, like what we did at the meeting on Monday, is we basically made it so one person on the team that really needed to do this thing could clear off their whole plate. And this was an interesting conversation because we are 21 people, and we have not hired anybody really, you know, since January.

Quinn: And sometimes it's tempting. It's actually been a lot less tempting than I think you and I would have expected, and it hasn't really come up on the team much. But this idea of let's go hire someone so they can work on this really important thing, it doesn't make any sense, cuz we have 21 people. And you view, you know, your work as a container ship, don't shove off the live animals and the GPUs from the container ship into the water if you need to, you know, clear out some space. You want to shove off the less important stuff. You don't want to go, you know, hire someone to go do the most important stuff, when instead it could be one of us who has all the context doing that most important thing. How can we, you know, solve for doing some of the less important stuff? And by definition, it's actually less important to solve for doing the less important stuff.

Thorsten: Yeah.

Quinn: So it's an ongoing thing. I don't know, you know, if you have any thoughts after a few days of this.

Thorsten: I think it's two things. One is, yeah, there's like this fallacy of thinking that if I don't make time for it, then we hire some other person and they will do it. You know, it's what we're talking about when it comes up with hiring, came up on Monday, it's not that we lack the skill for the thing we want to do. It's more that we haven't prioritized it. I think that was the realization. That's the heart of the matter. That's what this is. I worked in a company ten years ago, we had a Monday morning company meeting. And everybody showed up, except one team. They were always late, and they never made it to this meeting. And when I asked him, ‘Why aren't you in this company meeting?’ They said like, ‘Well, we have important stuff to do.’ And I talked with my back then team lead about it, and he says, ‘The issue is priorities. Everybody has the same amount of hours every day, and we all have important stuff to do. It's just you've got to figure out, is this important to me or not? And in your case, the decision is the meeting is not important to me, but you should switch your priorities.’ And it's kind of the same thing with hiring where, you don't get to it because you don't think it's important, and then you're hiring somebody, that should give you a signal, your focus.

Thorsten: Like is it truly that important if you never get to it? Maybe not, or maybe you need to refocus other stuff.

Quinn: Yeah. And it's a fallacy to say we…

Quinn: Can solve this really important thing that none of us are choosing to do by going and hiring the person. Why do you think that you're going to prioritize hiring the person, helping them get set up, why are they going to suddenly be successful if you're not able to carve out that time?

Quinn: And there was also some interesting discussion that we had about the psychological aspect where with an agent, it can be really fun to go and do a lot of things at once, to make the product better, to ship stuff, and when you try to balance that versus getting into that deep focus that we loved as developers when we would write code manually, it's hard.

Quinn: And human psychology is such that you might feel like you're being a lot more productive if you're juggling 10 things at once rather than that one deeper thing that you really need to do that you need to close Slack, you need to hide all your other threads.

Quinn: And it is interesting how we've heard from a lot of people that they are doomscrolling and wasting less time on Hacker News and X and things like that, for example, but they're spending a lot more time in their agent. I think that's probably an improvement.

Quinn: But still, we are thinking a lot about how can we keep you in a space where you can stay focused on the most important thing rather than being distracted.

Thorsten: Yeah.

Thorsten: Yeah. I do think that's the second bit. I don't want to use ‘culture’ in quotes as the reason or excuse for everything, but I would say, at least for me, and I think the same goes to you, but I guess you would put it in more optimistic terms, but for me, there's like this deep sense of urgency/anxiety of we need to keep moving. Like this is changing. You cannot stop. Like this field is changing every week. If you stop, somebody will overtake you. Adding more and more features can mean that you're moving ahead, but it can also mean that you're just dancing on the status quo and that you keep doing the same thing that you've been doing. So, in my mind, basically every day, there's like this—I know it sounds super dumb, I embarrassing to say, but the Elon Musk quote of like, ‘What did you get done this week?’ And when he asks somebody this, he doesn't mean, ‘I polished a bit of stuff, and did this, and did this.’ It's like, how did you move the team or the company along? Like, how did you take a next big step? Like how did you push the cart forward? It's not, polishing the cart and standing around and making it look a little bit better.

Thorsten: Like you got to push that forward. And I think we in the company have this deep sense of this, that we need to keep moving. And in every meeting, even if the numbers are good, it's like, okay, but how can we make them better? Like how can we be bolder and more aggressive, and just be faster, and take an even bigger bite off, even if we might not know how to chew it yet?

Thorsten: A long-winded answer to how do you avoid people just shipping more features, but I do think there's some sense of priority that the team shares, where just adding buttons here and there and moving on the same thing, that's not enough. In 2026, in AI, with coding agents. You got to keep moving along and not fall behind. So,

Quinn: Yeah.

Quinn: That's the psychological answer. There's a more practical answer, which is agents are good at zero to one, they're also really good at one to N, they're also really good at removing stuff, at keeping things consistent in the code, they're also good at doing that and keeping customers up-to-date, doing back-compat, doing migrations, they're good at all of those things. The one thing they are not good at doing is setting up cross-functional meetings in your company and convincing everyone that is the right thing to do.

Quinn: You know what? Humans are not good at that either. They hate it. It saps their energy.

Quinn: So, how do you make it so that you're setting the agent up to be the best? You eliminate all of that. And so at Amp, if someone doesn't like a feature, sometimes you'll ask the person who added it. Sometimes, if you think it should just die, you'll kill it. And if you are doing something that requires an update to what other people are doing, you just do it. That is the expectation.

Quinn: And if the person on the receiving end of that is asleep, or doesn't like that, I don't know, it seems rare. I guess sometimes that happens. But we just have this sense of we're not being judged on that one thing we shipped, we're being judged on the whole company's success. And sometimes it's actually really cool.

Thorsten: You removed my feature yesterday. The diff-based sidebar thing. I realized you removed it, I felt—what's the word? A weight fell off my shoulders. In that it was an experimental feature, and I didn't know how to move it over the finish line. Then you removed it. And now I feel better about it. And now we can take the new thing.

Thorsten: But then, obviously, somebody now will say, ‘But guys, I work on heart rate monitors. If I remove a feature, people die.’ You know, like, ‘If I can't do this.’ And I guess like that's always been the case, right? Where the hardest challenge in software is to build a product for customers, and you are not a customer, and you don't use the product. That's hard. If I build an admin dashboard for healthcare providers, I know nothing about healthcare.

Thorsten: What would it look like? You know, and that's the true thing where you need to talk to customers, and get their feedback, and whatnot. Like that's harder, right? My reply to like why this is harder is now you have all of the tooling, again, to maybe get more feedback, I think I said this in the last episode, but at this investment bank, one of the engineers came up to me, and he said, ‘We do have a two-week release cycle, and now I can build what I previously did in a week, in like an afternoon. And yet, I have to wait then, 13 days until I can release it and get feedback on it. What would you do?’ And I said, ‘I don't know, obviously, like I'm not in your team, or whatnot. But what I would try to do is, maybe build stuff in an Orb, share a Portal link to a mockup. And now you can build the fucking craziest, high-fidelity mockups of all time. Like your mind will be blown by how good of a mockup you can build.’ Back in say 15 years ago, when people That Sprint book from Google, or the ex-Google guy, like Sprint: new idea to whatever, day, build a paper mockup or whatever, and go to a customer.

Thorsten: And by all means, do this. But now you can build like a high-fidelity mockup in like 10 minutes, go and send the URL to your trader on the trading floor, ask him for feedback, and then iterate based on it. So, rethink how you approach software development, is my answer to this.

Quinn: You say all of this stuff about how the agent is so good and how you should shape your company around it, but, come on, you work at a company that's selling an agent. Why would anyone believe you? You are so obviously financially motivated to say these things and to say that these things are true.

Thorsten: Yeah, that's—I hear this a lot. People then reply to my tweets and say this. The answer is: you got it backwards. I don't talk about agents and how good they are, and how good AI is, and how you should rethink software development because I work at Amp. I work at Amp because I think AI is changing software development and agents are good. I started at Sourcegraph, you know, and the idea was to, use AI to build a code search tool. Amp came out of our realization that this is going to change everything. So, people have it backwards, and they think like I'm—I'm not an employee at some company who now, toes the corporate line and does the PR for them. Like, people got it backwards. I truly believe in that stuff. I truly believe that, AI changes software fundamentally. And the internet, so nobody will ever come up and say, ‘Dude, you were actually right.’ Like that never happened in the history of the internet.

Quinn: It's happening sometimes.

Thorsten: Sometimes.

Quinn: Not zero.

Thorsten: But you shouldn't expect it, is I guess what I'm saying. You know, that's one of the fallacies of the internet. You shouldn't expect the other person to say, ‘You're right.’ Usually doesn't happen. So, yeah, we've been proven right with a bunch of stuff. Know—what did I write? Like I said like they don't need unit tests anymore, or might not need unit tests in the future, and people go, ‘Whoa, whoa. That's crazy.’ And I'm like, ‘Well, let's wait a few months, right? I think you'll come around. You might see my point of view in a few months.’ And that has happened a bunch of times. So, I don't know.

Quinn: Yeah, people have it backwards. I

Quinn: I was walking down the streets of New York City, I bumped into a guy, seemed really smart, and he said, ‘Oh, do you have a wife?’ And I said, ‘Yeah, I do, and I love her very much. My wife is incredible.’ And this is true. And he goes, ‘Oh, well, of course you're going to say that because you're married to her, you know?’

Thorsten: Yeah, you got it backwards.

Quinn: It's like, no, I married her because I love her very much, and it is a choice that we made to be in this…

Thorsten: Yeah. Yeah.

Quinn: A lot of people are wondering, how do we do unit tests?

Thorsten: How do we do verification? How do we do unit tests? The short and flippant answer is they just happen, The truth of the matter is I'm not looking at unit tests anymore for the stuff that I write. I have trust in the model, and I've built up an instinct where I look at what they provide me as proof and I can kind of smell when they're off or not. And that's dumbest possible answer to give somebody who calls themselves an engineer, obviously, but I don't care about unit tests. Yes, if I were to say, work on a compiler and, I had unit tests for like different syntax of the language that I want to implement, the guest language—then maybe I would look at this, but the product we are building, I look at, the UI. The diagrams, I look at, you know, how stuff works, and unit tests to me are too much low-level. So, yes, the agent might write them. It might not write them. I haven't looked at a unit test in a while. When I change something, then sometimes it says, ‘Due to this change, there was now these tests failing, so I'm going to change them to this.’ And then I might look at it and go like, ‘Oh, what is this? Like what popped out there?’

Thorsten: But in general, I don't—do you look at unit tests?

Quinn: Oh, I think it's just been upleveled. Unit tests, they are trying to help you make it so that the stuff works as expected, and ultimately as users and customers expect. And so with the agent, I think we're doing this technique a lot where we ask it to run evals, or we ask it to look through the data and make sure that it covers it. I built this thing that we are calling the virtual executor. It's probably going to be an internal thing. Basically, I would have the agent run a lot of Threads and see the bash commands that it runs, and then I would build a program that would be able to virtualize running those bash commands so that we wouldn't need to wait on the Orb. And it wrote a lot of unit tests. I did not look at a single one of them. What I cared about is what percentage coverage of all of the data did it actually, support virtualizing? And then what percentage of Threads would it cover? How much would the speedup be? And that's like a higher-level way of me doing something that results in it writing a lot of unit tests.

Thorsten: Okay, I might be pulling on a thread here, we've got to talk another 20 minutes, but I think this—so I agree. What I did—Tim took this over from me. I started a GitLab integration, and that was basically Max, he's a customer of ours, he's like, ‘Guys, when do you have a GitLab integration?’ And just like your Android thing, on a Friday afternoon, I'm like, ‘Ah, what the heck,’ you know? So I thought I don't want to click through GitLab and, you know, like make sure that the account is set up and whatnot. I just gave the agent like an exe.dev machine, and I said, ‘Install GitLab on this, like install a GitLab instance. Here's the SSH key, set it up, and then implement it, you know, like—analyze the flow of what we have for GitHub, and then implement it for GitLab.’ And it just went, and it worked for, know, like 45 minutes or something. And then it produced videos and screenshots of the merge requests that it opened and how it clicked through them. Basically showed me an Amp thread in our local dev env that caused the merge request to be opened, and like the repos, and I could see the commit. And then I looked at the actual GitLab instance that it set up, I logged in with the login it gave me, and then I clicked around and saw, yeah, there's the issue, there's the merge request, there's the commit.

Thorsten: Like it worked. So I have the videos, I look at the code, I see that the code is basically, you know—when I say I look at the code, I look at the file names, right? And I see that basically everywhere we had a GitHub file, it added a GitLab file, so I know that it kind of didn't completely break the architecture or anything. It just added stuff next to the other stuff, and then in the files where there's like the branch of GitHub or GitLab, it changed something. I didn't look at the unit tests. Like why would I, obviously this stuff works, you know, and I have trust now that the videos are not fake, and I also checked that the merge requests are actually there. I have trust that the screenshots aren't fake, that it can exercise our dev environment to the full thing. So why would I look at the unit tests, you know? Like if the whole thing works and it can prove it to me. And that's the other response that we get, which is that's all fine and good, but what if the agent makes an architectural mistake and puts like a database table in or it adds something that you don't think is good and will put you in like a architectural dead end or something, it makes the wrong choice in this case, and then you're stuck the theory of you've got to keep a close eye, otherwise they take the wrong turn, and then you're stuck, and you've got to do this.

Thorsten: And my reply is, are you stuck, you know? Like even if it does this, like are you stuck? Or is it now easier than ever to kind of undo these changes? And then people say, ‘Yeah, but what if it's a database migration and the agent messes up the database, and now you're stuck with the wrong data model, and you have gigabytes of data to migrate?’ That is bad. Like I think you still need to look, ‘Hey, are you migrating the production data?’ It's like you need to still think like what the hell is going on, like how dangerous is this. But even so, even if—I've never seen this really happen—even so, then I would argue that even undoing a migration is now easier than before, which doesn't mean to YOLO and just have the agent push everything, but, again, people need to rethink the cost of everything. They need to rethink the cost of stuff that was tied to code. And migrations, undoing architectural changes, undoing data structures, like all of that they think that's hard because then you got to go through and undo this and blah. It's no longer that hard,

Quinn: And what's the alternative? I think some people think if an agent isn't good at something, then the alternative is we will not use the agent for that thing. And that is a valid alternative for some companies in some industries right now. I don't think that you can count on that being the case for very long. We never wanted to have that be an alternative for us because we get excited by figuring out, how can we push the agent to do more and more? And we're also in such a competitive industry where that's not an option for us to move at the speed of humans, we need to be moving at the speed of agents. And also, if we are not doing that, then our product is going to be bad. So we never consider that to be an option for us. So, we see this problem a lot less, and I think it's partly because the models have gotten a lot better, but it's partly because every single time we saw the agent do a migration in the database poorly, or create a bad schema, we consider that to be a really big issue, and we'd figure out, how can we avoid that?

Quinn: So, we came up with these techniques, and some of them probably are obsolete now. I think we've ripped some of them out, but for example, when you have a database migration file, if there's any create or alter table statement, then we had a linter that made sure that at some other point, the agent had gone through and looked in the production database to see, what query plan would that be? Would that hit too many rows? Would that write the entire table, and it needed that little annotation saying that either, no, it wouldn't, or that a human has done this. And we don't have that problem anymore. And that's because, models have gotten better, but we never considered it to be an alternative to not use the agent. And there's someone in your industry who probably is figuring out how to make the agent do well at these things, and maybe they are still banging their head against the wall, they are the tortoise in this race. Maybe you think you're moving faster because you're doing it with humans, but there's going to be a day when they cross the finish line and, you know, to slow down.

Thorsten: Yeah, two examples because people are interested in this. Niko, three hours ago by now, he messaged me and says like, ‘Look at this function. It blew up. We're now doing too many unnecessary requests.’

Thorsten: That's real. Like, you could say that's slop accumulated, or that's, like, yeah, somebody might have caught this in code review and said like, ‘We shouldn't do this.’ I think I would have caught it actually in code review.

Thorsten: But consider this. Niko is now fixing this in a thread and throwing the agent at it and trying to reduce those 15 requests down to the three or five or whatever it should be, it hasn't been a huge problem, and we moved faster than we could have had with code reviews,

Thorsten: Not everything is free, but if you compare the trade-offs, I would rather lean into being faster. Again, like sense of urgency, it's 2026, you've got to move fast, than to kind of throw the old processes at it that were never 100% perfect, So now we have this, and now Niko's fixing it. Another example, I actually took down prod last week with like a migration that I pushed that didn't take down prod, I basically caused 500 errors for the time of the rollout because I removed a column that was still being written to by old pods. And that's like a classic mistake, you know, remove the readers and the writers first and then you drop the column. But in this case, it was the column on like a secondary table, it was hard to see, it's hard to even spot for human that this is the thing. The agent usually doesn't make the mistake if it's obvious. This was truly like an edge case type of thing. So, yeah, okay, so we got 500s and we ran into this mistake.

Thorsten: I there's a 20% chance that you would have run into the same thing if you had human review. But you would have moved five days slower, because for me it was 20 minutes of my time shipping this. So what? Then you're going to throw like five days of waiting for PR review and two hours of a human review on this to reduce it by what? How many percent? It doesn't solve the problem. So people need to be really honest about did manual code review, mandatory code review actually fix this or help with the stuff that they think it helped with. So.

Quinn: That's right. It's the classic phenomenon of the seen and the unseen costs from the economist, you know, Bastiat, I think. I think he's French, long time ago. You do not see the costs that you pay when you have a very onerous code review process. What you see is the bugs that you prevent, and you don't see how it strangles the agency, the velocity, everything. And you got to see those. You got to shine a spotlight on them, and that's what we're trying to do.

Thorsten: Want to end on this. One last thing. We shouldn't shadowbox with people here that, you know, are not listening, I guess. But some people say, ‘Guys, you can only do this because you have unlimited tokens.’ And my response is, look, I also have my subscriptions in Amp and they're really generous. Like, if you look at my token consumption or yours, I guess yours is higher, but we're not in the Peter Steinberger, you know, Lauren realm of like trillions of tokens or whatever. Like, no, it's not that crazy the amount of tokens we use when we say, ‘Oh, yeah, an architectural change. I can just undo it with like throwing more agents at it.’ And people go, ‘Oh, it's because you have unlimited tokens.’ No, I don't, really. Like, we're paying for the tokens. But also, the message I want to put out is: sorry, but tough luck. Like, this is what it is, you know? Like, you've got to get to the tokens. It's not a level playing field if you're the guy who can only spend 50 bucks in tokens a month going up against others. And if you don't think this is a competition, then I guess you shouldn't listen to this podcast. Like, we're talking about, how do you ship and build software, and how do you do this in a competitive era and in a competitive area, you know, using AI.

Thorsten: And if you still think, this is not feasible because you're spending more tokens. No, that's the new thing. Like, this will be everything. Everybody will spend many tokens. The price of these tokens or the price per intelligence is going down. You will get more tokens per dollar in the next two years. Yes, the models will get smarter, so yes, the same amount of money will now buy more intelligence or whatever. But this is the new thing. It's not optional. And saying, ‘Well, but you have tokens,’ is like saying know, 2003, ‘Yeah, but your company has better internet access. This is why you're, researching stuff on Stack Overflow.’ It's like, ‘Yeah, dude, get on the internet,’ you know? Make sure you have access.

Quinn: There's no professor who's grading everything on a curve, who's seeing, well, how many tokens did you use and what did you end up producing? It's just what did you end up doing?

Thorsten: Yeah.

Thorsten: Yeah, that's a good way to formulate it. You're not being graded on output and how many tokens did you use. You're just graded on output, and you've got to get the tokens.

Thorsten: All right. Let's wrap it up. This was nice.

Quinn: It's Orbin' time.

Thorsten: It's Orbin' time. Bye-bye-bye.