Inside the Team That Killed Mandatory Code Review — Quinn Slack, AMP

Okay, we're in a remote studio with Quinn, who is in Munich. Quinn, I have no idea where in the world you are, and 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 U.S., 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. It's pretty fun.

I would say, you know, this is a tangent, mild tangent, but I think that, you know, 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 offsite anyway.

So, because then, like, 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 Germanyright 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, like, the recent transition, like, 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 theright 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 hundred 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.

I mean, 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 that's obsolete, and they're going to think less of you for it. So that's the principle. And we think that Orbs, there's, we're not the first ones to think of this idea. You know, Devin, massive props to Devin.

Devin was early when they were laughed at.

Three years later.

Hey, this doesn't work. Yeah. And they wereright 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 it end-to-end just work.

And you can see your dev server, that just works in a portal. You can, you know, 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.

So, you know, local dev, in our opinion, is dead. And that's been a huge change to, you know, how we all build.

You know, I think I wrote something in like 2021 about the end of localhost. At the time, that was how, it's just like a reflection of like 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 like, you know, have like a very light local clone or something that's much more powerful in the cloud.

I think even in Stripe. Yeah, once you have a good enough infrastructure, your laptop becomes a thin shell. Like you can just code on an iPad because it doesn't matter. Like it's just an input device into some cloud infrastructure.

But even then, you know, all the, 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's 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 devs, you know, VMs for dev."

It's, you kind of just realize, "Hey, I haven't run my local dev server in two weeks." I mean, 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, you know, it's not as daunting as people say and like, 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. Open code 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 tag. And then I guess Cursor has done it as well. It's just like, it's very interesting when everyone just decided that Claude was ready.

I would have said Claude was ready last year. Somehow it took this year to take off. But I don't know. Like, do you have any meta? This is a bit meta, but like, do you have any reflections on like, why now?

The agents have gotten better, for sure, on longer horizon tasks. And, you know, there's, I think something about when you see the agent so reliably getting itright 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, you know, more like 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, you know, 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, my company, if we have to review code, then what's the benefit of me stacking up 20 things that are waiting for review?"

You know, 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, you know, we are kind of getting to experience what other teams will be working like in six months.

Do we code reviews 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'sright. I mean, the most important system is having a team that is really trusted. And, you know, 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, you know, then you want to get to a place where you can ship a fix 15 minutes after you get, you know, something in the logs or something from a customer. And it's, you know, very much not the thing for all software.

It's, you know, the mean time before recovery versus the mean time before failure approach. But for end-user software that's moving so quickly, that's theright approach for us. And I think it is, you know, it's higher quality than if we had to wait, you know, 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. You know, obviously, one thing about the code review is that it is a sort of founding principle of trust, which I think I really love.

What else has changed or what were you referring to when you said, like, we've changed so much and you just want to share it? And I'm like, okay, well, I'll walk through it 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.

And, you know, 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, you know, ask it to, you know, make instant fixes to the software.

So let's pull this one up. And what it's doing here under the hood, it is actually, you know, probably number one complaint that people have about AMP is you 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, you know, if you go back two years, you would have somebody who's probably on the data team who would go and add a new SQL query to something like Looker.

And then like the intermediate is, oh, well, why don't we make it so that our dashboarding tool has some MCP so that it can, you know, 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. You, we were just talking about this before we started recording. Like, where's your head at with all this stuff?

With like internal, if I quoted internal tools

specifically.

Yeah. Yeah. And what it does to, you know, 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 AgentOS 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 since we're doing this.

For those who have, I actually wasn't even, 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, like essentially containers that are totally air-gapped and they have a few ways to reach to each other. So you can, on your own self-hosted kind of, you know, unit, bring in an office suite or, you know, 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, you know, completely containerized. So it was this idea of own your own software, own your own like 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 like, 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. Like it's just UI.

They don't care. So I'm seeing that, you know, 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 some 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 are a replit now or you are a whatever else is forkable.

Yeah.

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 you've compressed it into this tiny bubble that the only name that people have for it is like agents.

But, you know, 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.

Oh, Joy. Yeah, I think, you know, I think the important thing that you've done is that you've set up your company to burn some ships or burn some boats. I don't know what theright 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, you know, 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 10 years, do not move my cheese,right?

I'm trained and certified in this tool, do not touch it 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, you know, a former SourceGraph CEO pivot this to this entirely different side of the fence.

Yeah, totally. Well, I think, you know, we 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, you know, actually the ops part.

So there's this whole other category of work that is, you know, 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 B2.

Okay. So what is this? This is basically, you know, 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 like 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 what's, you know, you can see how big the 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, you know, 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.

And I was flying to Munich a week ago to get here and I was working on this migration and some others. And on, you know, 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. And 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 like a bunch of people and ops people just babysitting that the whole time. And a lot of people then say, well, how do you give your agent access to production logs,right?

I mean, that's like, you know, that kind of freaks people out. And this gets to this other interesting observation, which is that actually if you can give your Orb, you know, 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.

That you might think, oh, you know, 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 like hugging face to debacle and all of that. And we've heard from some of our customers using AMP that they, you know, had this other script that happened to be authenticated and it found a way to like 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, you know, its very nature can do pretty much anything, can break glass and get to prod.

Now that there's an alternative, I think, you know, 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, you know, some of our big customers too.

It is seeming more secure. So not only is it so much a better experience for developers because they can be doing a lot of things in parallel. They don't have to, you know, have the work tree 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, you know, I don't know, in two months we could be seeing CLI coding agents is 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 in full complete autonomy. 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 like when you put it in a box, like sometimes actually that's worse because like it just, you don't anticipate your needs ahead of time. You guys figuring out that limited auth thing is good, but also that, I mean, that's, 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 I mean, like 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.

Yeah. I mean, if it was just about doing stuff in Orbs more secure, then yeah, that's not what's going to win. But there's something about getting that friction to zero for the developer where they can spin up like 20 things at once and they don't conflict and they all have theright access and all, you know, that it's just a really magical feeling.

And yeah, that's one of the things we saw with Orbs. And some people say, well, how are Orbs different from all those other things? And I think it's just that we've gotten that friction down to as close to zero as possible so that you don't have to think your dev server is just going to work and all that.

So yeah, not just security, it's the dev push too.

What else comes to mind in terms of like the way you work?

Are on GitHub for our main repository still. I think you probably got stuff to say about this too, but I don't know. We basically never go to GitHub. The only time we go to GitHub is if there's like a problem with our GitHub actions, which happened a lot in the last 24 hours with like many hours of downtime.

What we've been finding is just, you know, using more ad hoc repositories that are hosted by AMP. And it's not like AMP is the GitHub killer. It's the next GitHub. These things don't die with a bang. They die with a whimper.

We just don't even think of GitHub anymore. We're not using issues. We're not using pull requests. We're barely on GitHub actions and we're looking to get off of that. We use them for pushing our reporight now, but someone could change that from under us and not even tell the team and a week later say, "Hey, guys, guess what?"

And that's just kind of a crazy feeling because I've been on GitHub for as long as I can remember. It feels like, you know, whatever one is on. And it's, yeah, it's kind of wild. So I've moved all of my personal stuff to AMP hosted repos that are just running on like Pierre's code.storage and the backend.

And I, you know, I don't even miss it at all.

While we're on the topic, a lot of people are thinking about this. What's your overall review as a third party on code storage?

It has done everything that we've wanted it to do. It's been reliable and we know the team really well. There's some ex-SourceGraphers there too. So, you know, really trusted folks. Whenever we have a request, they get it done.

I would love if they could get it done even faster, but they get it done.

I mean, they have a lot of attention at this point because they've been doing this for a little bit. I think the question for me, you know, for a side project, vibe coding and open source GitHub clone is I looked at Pierre and I was like, "Okay, they do storage, but they don't do actions.

They don't do CICD," which is actually the part I struggle with. Storing things is easy, no? Like what's hard about storing things?

Yeah. Yeah. It's easy in most cases. And that gets to the really interesting thing. It's so much easier for you to build something that's going to be self-hosted that just has to solve one person's problem and to make that really robust.

But if you're trying to build multi-tenancy, I mean, that doubles the complexity. If you're trying to build settings, and this is something where like AMP is a fairly minimal piece of software, but we have to do that stuff.

And therefore, something like code.storage that offers all kinds of guarantees that are really nice. But then for you, you don't need that. And you can find the thing that you're going to build by yourself better than what we or any other like third party could offer.

And that asymmetry is, I think, going to be the most interesting theme in like the software industry now. But you'reright.

I mean, what it comes down to is like coding SaaS will be the last SaaS in the world because all the other SaaSes will just be buildable via coding SaaS. So you might as well just only do coding SaaS.

Yeah. Yeah. We'll hope. I mean, wishful thinking for me,right? For us. But okay, with CI, I got a question for you. So why do you need CI? Let me take, you know, a thread here. Like, you know, what's something that I was working on here?

My agent knows to run tests. Obviously, it runs in a sandboxed environment that is the same for everyone on my team. So it's got that nice like reproducible environment characteristic that CI has. And I hate waiting. So if my agent has run the tests for its own verification, why do I need CI?

Why can't it just say the agent did it? Now let's push it to prod.

I mean, the simple, not very satisfying answer is you don't trust the agent to be exhaustive. Like it'll run what's in its context, but if you have a large project, you don't know that it's run everything that it should run.

And so CI is just like a deterministic stage of like, "Hey, just run all these tests." Any feedback, any failures you get, get passed back to the agent. Agent fixes it, goes back again. That kind of stuff. Like sometimes you just make a change.

And this happens to you. You make a change where you're not aware of like, "Oh, that touched this other thing that broke it." And so the CI will pick it up. Is that a satisfying answer? I don't know.

I am with you maybe for like three more weeks there. I'm like a wiggly tooth where like it's still holding on by a little bit. And like half the AMP team is like, "Guys, we don't need CI. Like we need something that will package the image and then push it for deployment, but we don't need CI because actually for anyone to have a non-incredibly painful CI, they already have something probably that looks and only runs tests for the changed files.

And that's a heuristic. I think, you know, usually you don't run your entire test suite all the time in CI or you kind of limit yourself. So, you know, if you want the agent to run everything, then it's going to be pretty darn reliable if you say run everything.

And then if you get rid of all the flakes that are a huge headache, then, you know, if it can automatically fix the flakes, I think you might be in a better place overall.

Yeah, I get you.

I think, yeah, every time someone has said, "Oh, I don't trust the model to do X or Y," that doesn't last for that long. So it just feels like the days of CI as we know it are numbered.

But at the same time, in this funny way, you know, what is CI but like a reproducible environment in which to run your project? Well, I mean, there's people that have a hundred Orbs per day and, you know, companies like E2P and Daytona and all these sandbox companies are absolutely blowing up.

So something that looks a lot like CI is absolutely blowing up. But CI as we know it, it feels like its days are numbered.

Have you talked about who you use for sandboxing? Did you roll your own? Anything interesting there? Just because you mentioned E2P and Daytona.

Yeah, we're using E2Bright now. They've been really great. And whenever we look at some other sandbox companies, there are some others that look really good. I don't think we feel a lot of painright now to switch. We love to get the costs down because we don't want anyone to have any hesitation to spin up more Orbs.

We have now the AMP subscriptions like AMP Megawatt and Gigawatt, and they give like super generous quotas for Orbs. So like 99.9% of people are not even going to hit it. But yeah, we'd love it cheaper. But then it's also just been kind of cool to see how E2B, which is a startup, I think they're doing very well, but it's a startup, how they've just totally nailed what are the primitives you need for sandboxes.

And I look at products from other companies like big cloud providers and they call it a sandbox. They think that they're competing with E2B, but they like lack the ability to resume or like their sandboxes have no network access or something like that.

And it's just, it's bizarre. So huge props to the E2B team, but it's a very competitive space now. And I probably get, you know, three or four emails a week from people saying, "Hey, I saw you're, you know, doing sandboxes.

You know, will you try my thing?"

Yeah, totallyright. And I think it's just a function of how seriously do you take it. Is it a side project for you or is your entire company's existence dependent on being the best sandbox company in the world? So yeah, I mean, it totally makes sense.

But also I think people's requirements for sandboxes differ a lot and we don't really know this space fully yet. So people are discovering the requirements as they build. It's very messy. You know, I'm over here.

Yeah, like RL sandbox is totally different. And that would explain why they would have those other kind of primitives exposed.

Yeah, totally. Okay. So again, I want to also like think about company running insights or stay at that level because I do think that not that many people are going to be in the dev tools business, but everyone's in some form of company running anyway.

So what do you have there as a founder?

My journey has been starting SourceGraph and that's code search. We have like nine of the 10 top public tech companies as customers and like four of the six top banks and like Uber and Stripe and so on. All these companies using SourceGraph for code search.

And I got to see what a great software business looks like. I got to learn from all of our customers. And for me, as, you know, founder and CEO of SourceGraph, I decided along with the board and my co-founder Bjørn, where we had these two products in SourceGraph.

We had SourceGraph, the code search product, and we had AMP. And we decided to spin off, which has not been done really in like startups and software since David Sachs spun off Yammer from Genie in like 2009 or something like that.

I didn't even know that history. Wow. Okay.

Yeah. And it's funny because he was on our board until he went to the White House. So, you know, we, I guess, kind of lucked out with that experience. And a spin-off is basically 20 people went forward with AMP and everyone else stayed on the SourceGraph team.

We did theright thing by the investors. So every investor, you know, all the employees, they own a share in both. So, you know, it's really interesting. I think that you've seen some other ways this could work out, like with Intercom and Fin and massive, you know, congratulations to them.

That's where Intercom was the first business and then Fin was the AI one. I think there's a lot of different ways this could work out, but for us, I think that, you know, SourceGraph code search, given that there's so much more code, it obviously has a bright future and it needed that focus and AMP needed that focus.

For me as CEO, I love being on a team of 20 people, you know, compared to for me, what I think I'm good at, I don't think I was, you know, that good or nearly as good at being CEO of a 200-person company.

And I get a lot more energy from that. And I think I've just, you know, found following my energy there. And now that we have this team of 20 people where everyone can be trusted with everything, I could, you know, feel totally at ease with any single person on the team, talking to any of our customers, fixing any bug, doing anything.

And that is incredible. And compared to a few years ago, you do not have the need to go and hire people that you do not trust, that you do not trust to have high agency or theright skills because you can use an agent to do those things.

And we have fully embraced that. We have a little bit of, you know, luck from that historical story of how we got here. We are profitable. We're in a space that's growing really quickly. And, you know, we've got that freedom, but it's, you know, just like that small team where everyone is doing everything is just so special.

And I see some other companies that are around our size starting to go hire a PM or a marketer, something like that. And that just feels like the old way of building a software business. And ultimately that's going to lead to something where 10% of the people are thinking about how to make a great product and the other 90% are thinking about the overhead, you know, how to sell it.

And I think in the past that was necessary, but I don't think that's necessary anymore.

Yeah, I would co-sign that, a lot of that. I think at least for this sort of startup, tech startup running mindset that works in AI. I do wonder, do you have internal agents that function effectively as your marketing people, as your product people?

Any internal agents that you've replaced, sorry, that you normally would fire a human for?

We do everything in AMP, which started out as a coding agent, but like you can't keep an agent in a box that has another label. It's just an agent now. But it is, you know, like what does a marketing agent mean?

Part of it is the ideas and implementing the things. Then part of it is like the marketing automation and all of that stuff. That's something we don't have, but that's one of the next, you know, like mini apps that we want to build.

And then, you know, to your point about it being open source, there's a lot of stuff we build that's very specific to AMP, but if we make something that's really good at like monitoring what everyone is saying about us on X and in Discord and our emails and making it easy for us to respond to that and identify theright people that are, you know, great community advocates, that's actually kind of generic and we should actually get that out there.

And in the past, that would have meant making an open source project and dealing with the headache of getting in the open source maintenance business. We don't want to do that. Or in the past, that would mean making settings and integration and like selling it.

But now if we can just put the code out there and make it so anyone else could like remix that and customize it with their own agent, that could be pretty valuable. So we will try that. We will be releasing a lot of these little, you know, jelly wear is what we're calling it.

It's like softer than software, but it's not totally vibe coded and you can customize it with your own agent. So we'll get some of that jelly wear that we've been building and using out there. What do you think of the term jelly wear?

I see you.

It's a memorable.

That's what you want.

Yeah.

It almost feels too tasty for what this is, but yeah, I mean, anything that's memorable is good in my book. For what it's worth, Codex has been my CMO for the last like two months, basically running our ads and giving me advice on AEO and SEO and what have you.

And I find it much more preferable to talking to a real human consultant, which I've also done, and it's roughly the same results.

That's awesome.

I don't know what that means about the sort of CMO or fractional CMO consulting industry because nobody knows anything anyway. So you might as well just do what everyone agrees to be true and you don't need a human to do that for you.

Have you ever run through like exactly what it looks like in your codex and what are all the things it does for you?

No, I haven't. It is still changing. The easiest way for people to find, I mean, I can talk to like my skills, which I publish a lot of and anyone who's like actually interested in how I work, you don't have to see my codex, you can see my skills.

This is updated quite frequently, I would say. This is like the bulk of like my GitHub usage is this now. I'm still pending to switch this over to Forge, my GitHub clone, but GitHub's good for now for this.

And we have to have a whole discussion about is Git still a thing? But this is everything I use for work, including marketing, including AI DevRel, which is like the newest thing. So Forge's engineering blog is not written by humans, but it is curated by me.

So I just give it some pointers and then it just writes the whole thing, including marketing design. So let me just give you an idea of what it looks like here. So here's an example of, you know, like even

the graphics are all generated and like I roughly read them in the transcript. I'm just like, this is a cool engineering story, write it up please. And then I give some guidance on what the angle is and that's it.

I mean, so I can talk about any part of that, but it's just all here because I think that is probably the new open source, which is you open source some Markdown files with some sample code. I do try to go a bit more than Markdown files, but it really does mean that this is portable to whatever project you want.

And that's probably more valuable than a library at this point.

Yeah. What about, okay, you probably know video editing and how to do that well. You probably, you know, hired a whole video, a whole, you know, village of video editors. How do you use AI for video editing and making clips?

Oh yeah, I actually don't do clips very much because we do long form. We try to go in depth. We try to be less clickbait or whatever. You know, for AIE, we do 20 minutes to three hour videos.

For Latent Space, it's 30 to 60 minutes like we are onright now and we don't really clip it. People have tried to use Claude Code to clip things and Hyperframes for stitching in generated visuals. I just haven't really experimented with it.

There's no hate amongst it. I just haven't sped the bandwidth. We tried Overclip, I think it's the A16Z-backed company that does clipping. It wasn't very good. We're about to try another one, StarZero for AIE in New York, which is focused on financial services.

And that one seems more promising, but I haven't tried to hand-roll it. And I think it's just a matter of like, do I prioritize it or not? There's no judgment on is it ready or anything. I just haven't decided to prioritize it.

I think editing, human editing is still cheap enough where it's not a problem. It's cheap and good enough. It's not a problem. And I'd much rather be able to say in the point of an edit, like, hey, Alejandro, like remember to do this.

And I know Alejandro will pick it up and we've had that working relationship for two years now and like I haven't needed to figure out how Claude does it. I'm sure you could do it. I'm sure you can hack it together.

I'm sure like, you know, you can spend some cycles doing it, but Alejandro's fine and he's, you know, generally intelligent.

Okay, cool. You're the only person who has told me that they think video editing is good and cheap enough by humans. Everyone else is looking for a good person to do that. So I think you are the apex predator of this.

I mean, it's like I run a media business where we produce high quality, high value videos. So I don't need to lower my cost of production that much. There's other people, it is a side thing for them and their budget is like in the hundreds of dollars.

But like, you know, my AIE budget, I spent like $6 million on AV this year. What's a few tens of thousands? That is a great catch up. You have lots of stuff to do, but I'm just really inspired by what you put out there.

And I also like you're in this sort of building public mode. It's really an energy that I love seeing. And I do think that, yeah, people, yes, I've also got a bit of psychosis and more energy now. I think what you ended on is really something to dwell on, which is should founders, should people basically leave behind their large company and go get a small team, that's a SWAT team, and go after what they perceive to be important and great.

And I think you're having results. I think it's also important that you mentioned you're profitable, which, you know, I think you and I had a really fun chat where I was like, you should host a meme of like a gathering of SaaS CEOs that are profitable and it's just you.

But I do think like this is a theme. Jeff Dean just left Google.

Yeah, big news.

Which not a thing I would ever thought I would say.

As far as we can tell, he intends to be five people working in a room and his mission statement when he left Google was like, what could a small handful of people do as opposed to like thousands of people?

And like him writing that is like definitely a dig at Gemini being like thousands of people. And I think it's very interesting that he wants to experiment with this. Obviously, he's like a 10X individual contributor, but like is there no room for domain expertise?

Is there no room for, I guess, skilling multiple people and what have you? I think this is a very open question on like how people run their companies now.

Yeah, it feels like nobody knows and we're all going to figure it out. That's why, you know, best place to be is just getting out there and building.

Yeah, people who do try will probably have a good shot at figuring it out. I was also mentioning, I was also thinking about Howie Liu from Airtable, effectively just did the same thing with Hyperagents, except that he didn't run it in parallel that much.

He basically had already sold the company and it was just kind of double-hatting for a bit. And so, yeah, it's a brave new world. Timelines are shortening. We're living in AGI and thank you for building in public.

Yeah, thank you. It's great to chat.