Okay, we're in the remote studio with Quinn who is in Munich. Quinn, I have no idea where in the world you are at any given point in time. You guys seem to be having lots of fun doing offsites.
We got the whole AMP team together in Munich and it's been awesome, but heading back now.
Is the team usually remote?
Yeah, we have one-third of the team in Europe, one-third in the US, and one-third in Australia. And we're 20 people, so we're all over. I don't even know what time it is for people working.
I would say, you know, this is a tangent, mild tangent, but I think that when you run a remote company, the general principle I want to tell people is that the money you would have spent on an office, you just have to spend on an off-site anyway, because then everyone gets together. So that's really nice that you do that. And I know you did one in Singapore, too, which I really love to hear.
Yeah. Yeah, we love Singapore. The air conditioning is a little bit better in Singapore than here in Germany right now, but we love Germany, too.
Okay, so AMP people have been introduced on this pod and everything, and people mostly have just seen you online. I think the new hotness is orb and orbs. I guess if you want to explain the recent transition, catch people up, what's going on?
Yeah, with AMP, we want to explore the frontier. What is the craziest stuff we can do? How can we kill the older features so that we can make AMP the best way to use an agent? And if you're using AMP, then you're using it in the way that we bless. You're on the happy path. That is our promise to you. We will take out some features that don't make sense. We were early in killing an editor extension. We've killed a lot of features, and some people joked for the last few months we were more known for killing features than for adding features. And I think that was the right decision because now with orbs, which is a way to use AMP, it's running remotely. You can shut your laptop. You can do a 100 things in parallel. That way of working has changed the way that we all work on the team, and our customers are using orbs more in the last three or four weeks than all of the change to how we build software that happened last year. And last year was not some quiet year. So with AI moving so fast, the value of keeping users on doing the old thing is actually negative. In the past, you would have a five- or ten-year technology cycle, and you could acquire a user and then they'd be with you for ten years. But now, if you're not nudging them, yanking them to be on the frontier with you, then three months later, they're going to say, "Hey, who are these fools and their product? It's obsolete." And they're going to think less of you for it. So that's the principle, and we think that with orbs, we're not the first ones to think of this idea. Massive props to Devin.
Devin was early when they were laughed at: "Hey, this doesn't work."
Yeah, and they were right about this being important. With orbs, we wanted to bring it all together. So it's not just that the agent is running remotely on the cloud. It's that we make an end just work and you can see your dev server that just works in a portal. You can get to the desktop, you can run these in parallel, everything just works, and that is good enough for you to not want to use local dev. Local dev, in our opinion, is dead, and that's been a huge change to how we all build.
You know, I think I wrote something in like 2021 about the end of localhost. At the time, that was just a reflection of how even pre-AI, people at large companies like the Facebooks and the Googles and the Ubers of the world, they all had setups where you would mostly SSH into a machine or have a very light local clone of something that's much more powerful in the cloud. I think even at Stripe, once you have a good enough infrastructure, your laptop becomes a thin shell. You can just code on an iPad because it doesn't matter; it's just an input device into some cloud infrastructure.
But even then, I know a lot of people that worked at those companies and they would say, "Well, yeah, it's slower and you give up a lot. It actually feels really nice to work on your laptop, everything is faster." And with agents, when you can run them remotely, you don't feel like you're giving anything up. You don't want to use local dev. It's not like your corporate security department that says, "Hey, we need to use VMs for dev." You kind of just realize, "Hey, I haven't run my local dev server in two weeks." That's what I realized just a couple days ago. So it does feel different. You do need to invest in the cloud setup, but it's not as daunting as people say, and now you can throw agents at it.
Yeah. I will also mention or observe that you're making this transition similarly to a lot of other people in the coding industry. OpenCode is doing it. Conductor is doing it. Surprisingly, Codex hasn't quite done it. I don't understand. Claude has done a lot. It used to be I guess like the cloud Claude thing and now Claude Code, and then I guess Cursor has done it as well. It's just very interesting when everyone just decided that cloud was ready. I would have said cloud was ready last year. Somehow it took this year to take off. But this is a bit meta, but do you have any reflections on why now?
The agents have gotten better, for sure, on longer-horizon tasks. And I think something about when you see the agent so reliably getting it right enough times and you start to stop reviewing all of the code, then that frees up more of your time to run more things. And I think there's also just, over December and January, that's when really agents in the CLI took off, and that is just a prerequisite for this next step. So it's moving way faster than any other technology adoption that I've ever seen, but it's still moving at the pace of humans. And even with orbs, there's a lot of people that say, "Well, why would I want that? Because I have a local dev environment on my laptop and everything is set up." Or they might say, "Well, if my company has to review code, then what's the benefit of me stacking up 20 things that are waiting for review? I don't benefit from greater parallelism." So it's all these other changes that need to work through. And on the AMP team, we are 20 people, we are all co-founders, everyone is very like-minded about that, and we benefit from greater parallelism doing more stuff remotely because we do not have to wait on review. And I think that more and more teams are moving to that, but we are kind of getting to experience what other teams will be working like in six months.
Wait, code review is dead for you guys?
Mandatory code review before it gets to main, yeah, it's dead. It's been dead ever since we started working on AMP.
That's a very strong statement. I guess you also have invested in systems to compensate for less code review, right?
Yeah, that's right. I mean, the most important system is having a team that is really trusted. And some of what AI does is it means that you can have a team of people that are more trusted, that have more skin in the game, that have more ownership end-to-end. They're not automatons that are taking input from a product manager and some sprint and outputting things to a marketing team to go ship. People have a lot more skin in the game, they're accountable, and that's the most important thing you need to have to avoid code review. But then you want to get to a place where you can ship a fix 15 minutes after you get something in the logs or something from a customer. And it's very much not the thing for all software. It's the mean time before recovery versus the mean time before failure approach. But for end-user software that's moving so quickly, that's the right approach for us. And I think it is higher quality than if we had to wait days to ship something.
Okay. I want to get to the genesis of this conversation, which is that you said the way that you guys have worked has changed a lot. Obviously, one thing about the code review is that it is a sort of founding principle of trust, which I really love. What else has changed, or what were you referring to when you said we've changed so much and you just want to share it, and I'm like, "Okay, well, I'll walk away with you"?
I think we're seeing the agents change not just how we're building software, but also how we're running and using software. You'll see my very messy work-in-progress here. I'll show off this thing that we call apps, which is a way where you can just spin up ad hoc software and it's running in an orb. There's an agent there, and you can have the agent just go and ask it to make instant fixes to the software. So let's pull this one up. And what it's doing here under the hood—this is actually probably the number one complaint that people have about AMP is you've got to wait for the sandbox to spin up. What it's doing is under the hood, it's starting up the sandbox, and then there's some process running on that that speaks HTTP, and then I just get to see it. So this is something that someone on our team made like an ad hoc dashboard, and this is something that in the past, if you go back two years, you would have someone who's probably on the data team who would go and add a new SQL query to something like Looker. And then the intermediate is, "Oh, well, why don't we make it so that our dashboarding tool has some MCP so that it can interact with our agent and all?" But why even have that at a certain point? You have ultimate customizability. You don't need a settings screen. You don't need a complex integration and MCP and all of the overhead that's entailed by buying some off-the-shelf software package to do dashboards when really an agent is the ultimate settings screen for any software and code is the ultimate settings screen for any software. So this is a huge thing, and I think that it is just the very beginning of agents now changing how you actually use software, and how you run software, and how you distribute software. So we're trying to figure out where exactly that is going. We've got some stuff there. That's one big area. We were just talking about this before we started recording, like where's your head at with all this stuff?
With vibe-coded internal tools specifically?
Yeah. Yeah, and what it does to, instead of software that ships with a settings screen and integrations, all that.
I see. Personalizable end-user software. Did you see what Cloudflare just shipped?
Yeah, the Agent OS thing.
Cloudflare OS is what they call it. Kenton Varda is basically calling it Sandstorm V2, which is his former startup.
And I remember Sandstorm, and I've thought about that every day in the last few months as we're building this.
For those who haven't—I actually wasn't even aware of him, I mean, I was in tech, but I wasn't aware of him. Can you recap what Sandstorm was to you?
Yeah, Sandstorm. It's like a self-hosted web app where you can pull in applications that are packaged essentially like containers that are totally air-gapped, and they have a few ways to reach to each other so that you can on your own self-hosted kind of unit bring in an office suite or an email app and all these things, and there's limited APIs for them to do the things they need like an OS, and it was completely containerized. So it was this idea of own your own software, own your own internal personal cloud, and it was ahead of its time, really.
What I'm seeing here from you is a little bit like that and what you talked about with why bother having any configuration, any settings screen when you can just customize the app yourself. I think it's important for people to have forkable software effectively, even if it's not entirely open source, as long as the front- and back-end contracts are held stable and respect security and privacy and all those things, then do whatever you want. It's just UI, I don't care. So I'm seeing that this is called the mini app pattern, which is what I'm seeing show up in a bunch of companies, not just you guys, where you have a thing here where you can actually just build an app that has less semantics between the company data and yourself, but then also maybe between apps for reusability and what have you, and then people can fork it like you're a Replit now or whatever else is forkable.
For me as a business owner, it feels like everyone is building the same thing ultimately. So it's like we're all just trying to figure this out, and you've taken like the entire software industry and compressed it into this tiny bubble that the only name that people have for it is like agents. But you know that it's going to re-expand again and we're all going to find the lines that exist between the different categories now. But that's what's exciting. Nobody knows.
Yeah. I think the important thing that you've done is that you set up your company to burn some ships or burn some boats, I don't know what the right expression is, which is like, "Well, we will not be beholden to legacy. We are very, very committed to being cutting-edge and frontier." And so people who buy into that, both on the employee side and the customer side, are the kind of customers that you want, which I think is important to keep for this because there's the other kind of customer who says, "I have used this for ten years, do not move my cheese, right? I'm trained and certified in this tool, do not touch because that's how I like it." And that's a very different kind of customer. Yeah. And it's also very funny to see a former Sourcegraph CEO pivot to this entirely different side of the fence.
Well, I think we've got to bring people along and that's why we're here. Another thing is seeing just how these agents can help you with stuff that's not just coding, but actually the ops part. So there's this whole other category of work that is, after you ship something, how to make sure that it can be rolled out. So let me find a good example. Okay, so here I'm in AMP, and you can see phase one, v2. What is this? This is basically taking AMP from where a user could be in one workspace to being in multiple. And if anyone has built any software before, you know that that kind of change is a change at the core of the most important data models, and that's totally messy and you have to stage it out over so many different steps to make it so that everything is backwards-compatible. And you can see how big this thread is. What's been really powerful is having the agent work through the different phases. And after it deploys each phase—let me see where it first pushed something. After it deploys a phase, then it will go and monitor the logs. It'll go and monitor the database to make sure that the invariants that it thought of, to make sure that you're not seeing a bunch of errors that are unexpected. I was flying to Munich a week ago to get here, and I was working on this migration and some others. On a 12-hour flight with airplane Wi-Fi, you're never sure what to expect. I had it push out a few stages that were pretty safe and monitor the logs. And if everything was good, then it would go on to the next phase. And if not, then it would roll back. Ultimately, the airplane Wi-Fi did work pretty well, but I got a little bit of sleep on the plane. And this is the kind of thing that in the past would occupy maybe a dev or maybe a bunch of people and ops people just babysitting that the whole time. A lot of people then say, "Well, how do you give your agent access to production logs?" That kind of freaks people out. And this gets to this other interesting observation, which is that actually, if you can give your orb, your agent running in the cloud, intentionally limited access to your resources so that it can, through something like OIDC, get a token that allows it 30 minutes of read-only access to just the G-Cloud logs or just your production database read-only access, you might think, "Oh, that feels scary." But if you compare it to what everyone is doing today, which is giving an agent that is running on a developer laptop potentially unfettered access to anything else that the developer might have authorized on their machine—and we've seen that agents are very good at escaping containment with the whole Hugging Face debacle and all of that, and we've heard from some of our customers using AMP that they had this other script that happened to be authenticated and it found a way to a production console. I think this happens in all agents. And now that there's a better alternative than running everything on a developer laptop that, by its very nature, can do pretty much anything, can break glass and get to prod, now that there's an alternative, it feels like a CLI coding agent is a really insecure thing and you want to be moving to the cloud. So you might think that it's the security people that are most scared about moving to the cloud, but we've seen with some of our big customers, too, it is seeming more secure. So not only is it so much of a better experience for developers because they can be doing a lot of things in parallel, they don't have to have the worktree dance, but it's more secure. And that's the kind of thing that means that this transition, I think, is going to go a lot faster than people think. Because if security and devs both benefit from it, then in two months, we could be seeing CLI coding agents as basically dead.
I definitely think that things are trending there. I would say that people do like to have that unfettered access for general intelligence and full, complete autonomy. And this is my reflection, by the way, on OpenClaw as well, that people just run OpenClaw and it's not the most secure thing in the world. It's entirely local, and when you put it in a box, sometimes actually that's worse because you don't anticipate your needs ahead of time. You guys figuring out that limited auth thing is good, but also I think there's a fundamental tension in the UX between you just have everything and I treat you as a full human that's on my team versus you're still on a tight leash with me because of my concerns about security. But that's neither here nor there. I think that is just a preference that some people will have, and I think you guys offering this and figuring this out is still an important part of the landscape.
