Enjoying this issue?
Get tomorrow's AI & engineering digest in your inbox — hand-picked, summarized, and always spam-free.
TLDR
AMP has killed mandatory code review for its 20-person team, relying instead on high-trust, high-ownership engineers and agents that can ship fixes 15 minutes after a customer report. The bigger shift is that AMP's orbs — remote, cloud-based agent environments — have made local development feel obsolete to the team, with orbs usage in the last month exceeding all workflow changes from the prior year. The real story is that AMP is betting the entire software development lifecycle — coding, testing, deployment, monitoring, even internal tools — can be collapsed into agent-driven, cloud-hosted workflows where traditional CI, GitHub, and settings screens become optional.
Key points
AMP has eliminated mandatory code review before merging to main.
Orbs usage in the last month exceeded all workflow changes from the prior year.
Quinn Slack argues local development is dead for agent-driven workflows.
AMP uses E2B for sandboxing and finds cloud agents more secure than local ones.
The team rarely uses GitHub, relying instead on AMP-hosted repos and ad hoc repositories.
Tools mentioned
Techniques
- orbs (remote cloud agent environments)
- jellyware (customizable agent-built software)
- agent-driven phased deployment with log monitoring and auto-rollback
- OIDC-based limited-scope tokens for agent access to production logs
Stop scrolling. Start reading smarter.
Receive the day's most important AI & engineering updates in one concise email. No spam.
Transcript (captions)
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 uh heading back now. >> Is the team usually remote? >> Yeah, we have one-third of the team in
Europe, one/3 in the US, and one/3 in Australia. and we're 20 people so we're all over. I don't even know what time it is for people working. >> Yeah,
>> 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 thing the money you would have spent on an office, you just have to spend on an off-site anyway. So, because then like everyone gets together. So, that that's really nice
that you do that. And I know you you did one in Singapore, too, which I 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 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 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 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 with AI moving so fast, the value of keeping users on doing the old thing is is actually negative. I mean, in the past, you would have a 5 or 10 year technology cycle and you could
acquire a user and then they'd be with you for 10 years. But now, if you're not nudging them, yanking them to be on the frontier with you, then 3 months later, they're going to say, "Hey, who are
these fools in 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 orbs there's we're not the first ones to think of
this idea. You know Devon ma massive props to Devon. >> Devon was early when they were laughed at. Hey this doesn't work. >> Yeah. And they 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 uh 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 uh you know what how we all build. You know, I think I wrote something in like 2021 about the end of
local host at 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 uh the Ubers of the world, they all had uh
setups where you would mostly SSH into a machine or like you know have like a very light local clone of something that's much more powerful in the cloud. I think even in stripe um yeah once you
have a good enough infrastructure your laptop becomes a thin shell like you can just like code on an iPad because it doesn't matter like you it's just an input device uh into uh 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 uh you know, VMs for dev." It's you 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 um 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, Codeex hasn't quite done it. I don't understand. Claude has done a lot. It used to be I guess like the the cloud
claude thing and now uh Claude tag and then I guess cursor has done it as well. It's it's just like it's very interesting when everyone just decided that cloud was ready. Um, I would have
said cloud was ready last year. Somehow it it took this year to take off. But I I don't know like do 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 um you know there's I 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 you know we had to over like uh 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 6 months. >> Wait uh code review is dead for you guys. >> Mandatory code review before it gets to Maine. Yeah, it's dead. It's been dead
ever since we started working on AMP. >> That's a very strong statement. Uh I guess you also have invested in 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 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 the meantime before recovery versus the meantime 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, >> you know, it's it's higher quality than if we had to wait, you know, days to ship something. >> Okay. I want to get to uh the genesis of
this conversation, which is that you said uh your the way that you guys have worked has changed a lot. You know, obviously um one thing about the code review is that it it is a sort of
founding principle of trust, which I I think I I really love. what else has changed or what were you referring to when you said like we we've changed so much and uh 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. And you know, I'll show off um 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, this is actually, you know, probably number one complaint that people have about AMP is you got to wait for the sandbox to uh 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 uh 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 someone 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 You have ultimate customizability. You don't need a setting 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 setting 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 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 uh like internal voded internal tools >> specifically? Yeah. Yeah. And what it
does to, you know, instead of software that ships with a setting screen and integrations, all that. >> I see. Personalizable end user software. Did you see what Cloudflare just
shipped? >> Uh, yeah. The agent OS thing. >> Cloudflare OS is what they call it. Kenton Va 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 viewing 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 airgapped and they have a few ways to reach to each other so that 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 uh why why bother having any configuration, any settings screen when you can just customize the app yourself. Uh I think it's important uh for people to uh 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 and respect security and privacy and all those things then do whatever you want
like it's just UI don't care. So, I'm seeing that, you know, this is called the mini app pattern, which is what I uh I'm seeing show up in a bunch of companies, not just not just you guys,
where you have a thing here where um you you can actually just build an app that that has some less semantics between the company data and yourself, but then also maybe between apps for reusability
and and what have you. and then people can fork it like you are a replet now or you are a whatever else is forkable. >> Um 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 reexpand again and we're all going to find the 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 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 like 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 uh are are you know the kind of customers that you want which I
think is important to 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 because that's how I like it and that's a that's a very different kind of customer. Uh yeah. Yeah. And it's also very funny to see, you know, a former
SourceCraft CEO pivot this to this entirely different side of the defense. >> Yeah, totally. Well, I think it, you know, we got to bring people along and that's why we're here. Another thing is
seeing just how these agents can be can help you with stuff that's not just uh 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 I okay so here I'm in AMP and the you can see phase 1 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 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 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 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 readonly access to just the G-Cloud logs or just your production database readon access. that you might think, oh, you know, that 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 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 it, 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 of
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 2
months, we could be seeing CLI coding agents is basically dead. I I definitely think that things are trending there. I I would say that people do like to have that unfettered access for general
intelligence and and full complete autonomy. And this is my reflection by the way on open claw as well that people just run open claw and and it's not the most secure thing in the world. It's
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 you guys figuring out that
limited off 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 you're 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 my concerns about security. But I mean like that's that's neither here nor there. I think I think that is just a 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 is 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 the right access and and all you know that it's it's just a really magical feeling and that yeah that's 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 it's the dev push, too. >> Uh, what else comes to mind in terms of like the way you work?
>> Um, are on GitHub for our main repository still, and I think you probably got stuff to say about this, too. But I don't know, we 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 the 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 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 repo right 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, what everyone is on. And it's Yeah, it's uh kind of wild. So, I've moved all of my personal stuff to AMPhosted repos that are just running on
like Pierre's code. and the back end and I, you know, I don't even miss it at all. >> While we're on the topic, um, a lot of people are thinking about this. What's
your overall review as a third party on 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
exource graphers 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 they have some uh a lot of attention at this point because of they've been in 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 Pier and I was like, okay, they do storage, but they don't do actions. They don't do CI/CD, which is actually the part I struggle with.
Storing things is easy, you know, like what's hard about storing things? >> [laughter] >> 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-tenency, 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're right. I mean what it comes down to is like coding SAS will be the last SAS in the world because all the other SAS will just be buildable via coding SAS. So you might as well just only do
coding SAS. >> Yeah. Yeah. Well hope. I mean wishful thinking for me right for us but okay with CI 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 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 it on all these tests. Any feedback, any 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 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 to see how we we'll pick it out. 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 heruristic 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 I 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 um you know, if it can automatically fix the flakes, I think you might be in a better place overall.
>> Yeah, I guess. >> 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 the days of
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 E2B 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 it feels like it's its days are are numbered. >> Have you talked about who you use for sandboxing? Did you roll your own?
Anything interesting there? just because you mentioned E2B and due to Twitter. >> Yeah, we're using E2B right now. They've been really great and whenever we um look at some other sandbox companies,
there are some others that look really good. I don't think we feel a lot of pain right now to switch. Uh 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 uh quotas for orbs. So like 99.9% of people are not even going to
hit it. But yeah, we 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. Uh, totally right. I think it's just a function of how seriously do you take it? Is it a side project for you or do you is your entire company's existence dependent on being the best
sandbox company in the world? So yeah, I 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. It's you know I'm over here >> like RL sandbox is totally different and and that would explain why they would
have those other kind of primitives exposed. >> Yeah, totally. Okay. So, so again u I I want to also like think about company running insights or stay at that level
because I I do think that not that many people are going to be in our the dev tools business but everyone's in some form of company running anyway. So what do you what do you have there as as a as
as a founder? >> My journey has been starting source graph 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 and all these companies using source graph 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 source graph I decided along with the board and my co-founder Bang where we had these two products in source graph we had source
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 Saxs spun off Yammer from Genie in like 2009 or
something like >> 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 SourceCraft team. We did
the right thing by the investors. So, every investor, you know, all the employees, they own a share in both. So, you know, it's it's really interesting. I think that you've seen some other ways
this could work out like with intercom and Finn and massive you know congratulations to them that's where intercom was the first business and then Finn 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 source graph 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 For me, what I think I'm good at, I don't think I was, you know, that good or nearly as
good at at um being CEO of 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 have high agency or the right 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 that freedom but it's 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 or 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 that you know how to how to sell it and I think
in the past that was necessary But I don't think that's necessary anymore. >> Yeah, I I would cosign that. A lot of that I think at least for this sort of startup tech startup running mindset
that works in AI. I do 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 have hired 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 with the ideas and implementing the things and part of it is like the marketing automation and and all of that stuff. That's something we
don't have but that's one of the next you know like many 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 the right 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 jellyware 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 jellyware that we've been building and using out there. What do you think of the term jellyware? I see you.
>> It's memorable. >> That's what you want. >> Yeah. [laughter] Um, it it it almost feels too tasty for for what this is. But yeah, I mean,
anything anything that's memorable is good in my book. I, for what it's worth, Codeex has been my CMO for the last like 2 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 codeex and what are all the things it does for you? >> Uh, no I haven't. It it is still
changing. the easiest way for people to to find I mean I can talk to like my skills um which I publish a lot of and anyone who's like actually interested in how I work you don't have to see my
codeex you can see my skills this is updated quite frequently I would say this is like the 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 we have to have a whole discussion about is Git still a thing But this is everything I use for uh for work including marketing including uh AI
devril which is like the newest thing. So um forg's engineering blog is not written by humans uh but it is curated by me. So I just give it some pointers and then it just writes the whole
thinging um a marketing design. So let me just give you an idea of what it looks like here. So here's an example of uh you know like
even even even the um uh the the the graphics are all generated and 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 end goal is and that's it. I mean, so I I can talk about any any part of that, but it's 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 I do 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 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 how do you use AI for video editing and making clips? >> Oh, yeah. Um, 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 to 20 minute to 3 hour videos. For latent space, it's 30
[music] to 60 minutes uh like like we are on right now. And we don't really clip it. People have tried to use quad code uh to clip things and hyperframes uh for stitching in um generated visual.
Uh I just haven't really experimented with it. There's no hate uh amongst it. I just haven't put spent the bandwidth. We tried Overclipip I think is the is the A16Zbacked company that does
clipping. It wasn't very good. We're about to try another one, star zero for AIE in New York, uh, which is focused on financial services. And that one seems more promising, but I haven't tried to
handle 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 or anything. I just haven't decided to prioritize it. Um, I think editing,
um, 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 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 because we've had that working relationship for two years now and like I haven't needed to figure out how Quad does it. I'm sure
I'm sure you could do it. I'm sure you can hack it together. I'm sure like, you know, he has spent some cycles doing it, but Alejandro is 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 I 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 my AIE budget, I spent like $6 million on AV this year. What's what's a few tens of
thousands? That is a great catch up. And you have lots of stuff to do, but I'm just really inspired by what you uh put out there. And I also like you're in a sort of build in public mode. It's
really an energy that I love seeing. And I do think that yeah, people Yes. I've al I've also got a bit of psychosis and more energy now. Um, I think I think what you what you ended on, which is 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 go after what they perceive to be
important and great and 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 uh SAS 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. [laughter] Um, and 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 um I guess scaling multiple people and and what have you. I think there's this 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. The people who do try will
probably have a good shot of figuring it out. I was also mentioned I was also thinking about how Louu from Air Table effectively just did the same thing with Hyper Agents except that he didn't run
it in parallel that much. He basically uh had already sold the company and was just kind of double heading for a bit and so yeah it's it's a it's a brave new world. Timelines are shortening. We're
living in AGI and uh thank you for building in public. >> Yeah, thank you. It's great to chat.