Cloud Agents + Software Factories with Safia

[00:00:03][music] [music] [music] [music] All right. What's up everyone? Uh, welcome to a very special stream. It's special because it's not just me. Uh, so I'm the developer relations lead here at Warp. And joining me today is Safia.

[00:00:44]You're over there.

[00:00:45]>> Hello.

[00:00:47]>> Hello.

[00:00:47]>> Hi everyone. I am Safia. I'm a software engineer on the Warp team.

[00:00:52]>> Yeah. I mean, software engineer kind of underells it because we're at a small flat team. It's like everyone's just software engineer. Even if it's like, yeah, yeah, I built the entire open-source uh agentic pipeline, but you know, it's just it's just engineer.

[00:01:06]>> Um, alternative titles, agent, babysitter, factory engineer. Agent babysitter sometimes feels like the the [laughter] move.

[00:01:15]>> I I'm factory foreman.

[00:01:17]>> Factory foreman. I like that.

[00:01:20]>> I like that you leaned into that. It's super cool.

[00:01:23]>> Yeah, we all are. Uh, >> this is true >> as a company. Yeah. And welcome in everyone. Uh, >> we're going to be running through actually like a a presentation that you gave at AI Engineer, >> but doing a bit of a replay for people >> with maybe some more context uh because things change week over week. But the plan is for you to just like run through it a bit and anyone who's watching. Uh feel free to ask questions. We'll answer them you think as they come in, but also like a little Q&A space at the end.

[00:01:57]>> Yeah, there will be plenty of time for Q&A at the end. So if any of the topics that I cover or anything that I say kind of like um sparks a a light bulb or anything like that, I'd love to hear your questions and answer them.

[00:02:12]>> Yeah. Nice. And Shashi, also good to see you. we we ran to you at the the AI engineer uh conference. So, thanks thanks for stopping in.

[00:02:22]>> I know there were so many people. It was kind of intense but fun. Like my throat was sore by the end. There was so much conversation and chat. Yeah.

[00:02:30]>> Yep. I still remember day one when the workshops ended and nowhere at any everyone just went to the expo immediately and we were still like unloading shirts and all of a sudden I was like, "Oh, there's like 10 people who want to know about Warp." Okay, sure.

[00:02:45]>> [laughter] >> Yeah, >> we'll chat.

[00:02:48]>> Yeah, some of the activity at our booth was super fun. I was um very happy to see it.

[00:02:53]>> Yeah. Well, uh what do you say we jump in?

[00:02:57]>> Yeah, let's get into it.

[00:02:59]>> All right, let's do it.

[00:03:01]>> Cool. All right. Um hello everyone. As Ben mentioned, um this session is a little bit of a behindthescenes look at how the team at Warp built our cloud agent platform. Um, I'll be talking a little bit about the how of the cloud agent platform, but I really want to spend a lot of time talking about the why. Um, and for me, the why really begins um, in my own journey building developer tools. Um, I've spent eight years building dev tooling in open source and across the stack. Um, I've built desktop apps for data scientists.

[00:03:39]I've been at the API and SDK layer targeting web developers and now I'm at this like interesting junction where I'm working on cloud agent infrastructure and building tools to help developers leverage AI agents in their workflows.

[00:03:55]And one of the lessons that I've really taken from my years of experience working specifically in the dev tooling space is that really great dev tools meet devs where they are and grow with them. Um a tool that you're going to be using every day as a developer needs to accommodate your workflows um and preferences, but then it also needs to like grow um with the complexity of your work and the complexity of your team's workflows. And this actually turns out to be a really difficult balance to strike. I'll talk a little bit about how we do it at warp. Um, another angle that is important for dev tools is that they have a compounding effect on the world.

[00:04:37]Um, because good dev tools can be used to create more software. um developers can build better software when they love their tools and those dev tools kind of compound their ability to write um write good products, build good code, etc., etc. Um, and that compounding effect really gets harnessed when you recognize that individual engineers and teams have really strong preferences for their shell, um, their editor, their harness, their workflow, their review process.

[00:05:12]Um, all of these preferences are not just preferences, but they become a part of how people think um, and build and do work. So being flexible and accommodating to all of these preferences um is a key aspect I think of building good dev tooling. We'll talk a little bit about how that comes into play at Warp in a few moments.

[00:05:35]Um one of the things I think is kind of fun about the story at Warp is it's kind of followed this this natural progression of meeting the moment um and scaling with people as the landscape of dev tooling has changed. So, Worp started off um kind of meeting developers where they are um in their command line workflows with this really like refreshing take on what um a terminal should be. Um and then you had this moment where like AI entered the dev tooling space and we needed to kind of grow and accommodate to that. And so, Warp evolved to have a local agentic experience where you could interact with an AI agent um via the Warp app on your machine. Um and then more recently there's been trends of agent work um moving to the cloud. Um people want to execute longer running tasks that might outlive the duration of you know how long they have their laptop open. They might want to do work that um you know allows them to interact with different members of their teams kind of multiplayerbased agent workflows. Um all of these things um kind of come naturally when you introduce cloud agents into play. The challenge with cloud agents though is they make that same core philosophy of building great dev tooling that scales with developers that accommodates their preferences and that is a compounding effect on their ability to build good software. Much much harder because you have to deal with a very messy stack of infrastructure concerns. when you move things from just running on a person's local box to the cloud. Um, and this is where I think one of the like core philosophies of a good platform comes in. Um, which is that part of why you would kind of build a cloud agent platform or use one is the platform takes on the complexity of dealing with all of these like messy infrastructure concerns before it reaches you. Um, and one of the philosophies is that every primitive that we built in warp exists to support this philosophy that we want to take on complexity before it reaches you. So, let's break this down. Um, one of the first things or uh complexities that you might have to deal with is like a really basic question when you're interacting with local um or cloud agents, it's where do they run when um they're on your machine? Um there are agents executing commands on your local box, editing files that exist on your local box, but when it's in the cloud, like where does it actually do its work?

[00:08:11]Um and one of the key primitives that we need to think about here is sandboxes.

[00:08:17]Um so we start off with a pretty basic concept which is that um sandboxes could should come to you out of the box. So we give you warposted sandboxes um that give you this really easy on-ramp. um you want to run an agent workload, we give you the compute that your agent runs on and you really don't have to kind of be concerned with a lot of the setup or complexity that comes there. Um the the challenge though is that hosted sandboxes or managed sandboxes don't scale all that well to some of the requirements for kind of more heavy duty customers. Specifically, a lot of people want to run their agent workloads in infrastructure that they manage that they kind of understand the security properties of the costs of all of that fun stuff. And so in addition to these like warp managed sandboxes, we add in the layer of self-hosted sandboxes that you can still interact with the platform um through, but you kind of manage the compute layer of. And um this ties into something that I mentioned earlier about building tools that grow with developers. Um this is kind of what it looks like in practice. The story of growing from doing work on your local client to some sort of like remote dev box or remote environment is a natural progression. Um, and really good developer tools start off with these like simple manageable defaults like managing your compute for you, [snorts] but then they scale as you get into like these more heavy duty requirements around um things needing to run on your own infra be secure, be deployed by you, all of that fun stuff. So infrastructure um is one of the preferences that teams have that influences how they do work and collaborate with each other. Um the next kind of preference can be a little bit more personal for people. Um and it's a preference of which harness they use. Um people are really passionate about harnesses specifically. Um I think there's a lot of discourse in the past about whether people prefer claude or codeex. People have different relationships with their models and their harnesses too. They kind of perceive them in different ways and kind of sus out their personalities differently. So it's this like very strong affinity that individual developers and then even collectively teams, engineering teams might have when they interact with their work. Um and so it's important that people don't feel like they have to be boxed into a particular harness to do good work. They should be able to use the harness that kind of brings them the most joy but then is also like most fitted for the task that they are doing.

[00:10:58]>> [snorts] >> Um, and multi-h harness support I think is something that you can tack on to a platform um very quickly and give you the ability to like spin up cloud or codeex or all of these um other harnesses which warp does um but really we want to go a step beyond that um because it's important to provide some structure around all of these different harnesses that exist so that the flexibility doesn't exist at this super fragmented experience. Um, so you can use your codeex harness or your cloud harness or the warp harness itself in your cloud agents, but the experience of interacting with the agent run, inspecting what kind of outputs or artifacts it produced, how long it ran for, the timeline of the entire execution life cycle, [snorts] all of that is kind of uniform and provided by the platform. And so this this notion of giving people choice and flexibility without fragmentation is like a core platform philosophy.

[00:12:02]Um, cool. So we've got an agent that can run in the right place whether it's managed hosting or self-hosting um with the right harness either based on a personal preference or a team preference as far as like quality or cost that they're watching out for. Um what happens when one agent is not enough? Um this is like the reality of most engineering work. It like rarely fits into one neat prompt or one neat agent task. Um in a like realistic scenario, you might need one agent that's going to go and like investigate a bug and plan out a fix. You might need another agent that is going to go do the actual implementation and modify the code. And you might want to bring in a third to validate the fix. Um, and each of these agents might use different models or different harnesses, so you get a really nice adversarial effect going on. Um, and we want to support users being able to coordinate all of this work without kind of having to manually babysit every agent.

[00:13:07]And so, Warp has the concept of agent orchestration. You can spawn sub agents as part of your prompt, as you'll see here. Um, and it will allow you to delegate work to different sub agents across different specialized tasks. A parent agent will manage the actual process of interacting with all of those sub aents to get status updates and drive their work forward. Um, and we take off all of the effort of managing that orchestration off your plate. So the example I have up here is an example of kind of a promptdriven um orchestration experience where I am using natural language in my prompt to direct a variety of agents to like do different tasks. But there's something more interesting that you could do with the warp platform which is the ability to programmatically create the sub aents um and parent agents using our API. Um, I have an example of that right here.

[00:14:08]And I want to call it out because this is where things get really interesting as far as what Warp provides where we stop thinking of it as just like a feature surface area and start to think of it as a platform that you can build on top of. Um, and this unlocks a whole bunch of interesting opportunities when you ex expose a lot of these primitives, these key primitives like the ability to orchestrate um, via APIs that people can build on top of. Um, this means that people are not limited to what we provide in the Warp client app or the Warp web app or any of our specific UIs for how users end users interact with an agent. you can kind of programmatically spin up these sub agents. Um, manage them, manage their environments that they're working in, interact with the artifacts they produce, if they're producing markdown files that contain specs or plans, if they're producing PRs, all of that is kind of accessible at the API layer. And that lets you do something kind of interesting when it's accessible via the API layer because now you can use that API to build kind of your own agent experiences.

[00:15:20]Um and we've seen something really cool happen internally over the last I would say almost year um eight months to a year which is internally teams have been building so much interesting agent-driven workflows at warp based on these primitives. Um and specifically it's a lot of non-engineering teams that are taking advantage of of these things.

[00:15:47]Um, we have a bunch of stories internally of folks in our kind of recruiting and hiring teams building custom apps to help them manage resumeumés and people going through the hiring pipeline. We have people who are building like Slack agents to help them manage [snorts] product questions and competitive research, all of this fun stuff. Um, and all of that is kind of enabled by the fact that the platform itself and the primitives that underpin everything is API accessible by default.

[00:16:21]Um, this came into play um, in particular when we went open source. Um, if you haven't heard, I think we've talked about it before on the channel.

[00:16:29]Um, Warp went open source in late April.

[00:16:32]Um, feels like ages ago, but it's not actually not that long. Um, and it was a pretty huge success. We've had tons of people expressing their enthusiasm for the repo by starring us. We've had like thousands of PRs come through, many of which have been merged. We've had hundreds of contributors. Some of the PRs have kind of been of substantial impact. So, there's a lot of value being created. Um, [snorts] and when we went open source, one of the things that we wanted to do, um, is be intentional about how AI and how agents would support the work of maintaining the repo.

[00:17:10]>> [snorts] >> One of the things that we did when we went open source is um we introduced a flow um where agents participated in the process of building software um in a way where they had kind of context and guard rails and where there was opportunities for human judgment and human interaction to come in. So, an issue would come in to our open source repo. An agent would immediately jump on and help triage it.

[00:17:41]The agent might even do some back and forth Q&A with the person who reported the issue to acquire additional information and kind of get to clarity.

[00:17:50][snorts] When a human decided that an issue was ready to spec or ready to take to code implementation, the agent would assist with that by either drafting a spec or proposing an implementation. Um, agents review all PRs on the repo and for PRs that come from external contributors, an approval from the review agent is required before it takes on human review. [snorts] And so, um, some of the toil around creating clarity from initial issues, um, driving things and getting an initial spec to get people's creativity going is taken on by the agent. Um but humans are still deciding what ships and kind of still discerning what is important um as far as valuable in the product and managing the overall like quality of what we build which I think uh an important thing to account for.

[00:18:44]But this entire flow unlocked something um huge for us which is this workflow expanded who could build and contribute to the repo. um agents could really support anyone who had an idea, a good idea that was like everyone was aligned on in getting it into the warp app by providing this like context and structure on these issues. Um so you would have the ability to file kind of like an opaque ask for a feature and the agent could really like drive to clarity, drive to a spec and help you eventually drive to an implementation from that original intent.

[00:19:22]And this is like a super cool thing um because when agents help us do this, more people can build software because the agents are there to support um turning intent into implementation.

[00:19:38]And I think there's a couple of key words in this slide. Um one of them is that the definition for a person who can build is expanding. It used to be just people on the engineering team. But as I talked about earlier, the definition of a developer and the audience for a dev tool is expanding to like marketers and product people and support leads and finance people um who understand their problem domain really well and kind of equipped with the right tools and the right structure and infrastructure to help them produce software from their ideas can participate a lot more directly in building solutions that work for them. Um, and it's, you know, it's like serious software work. People are building, um, features that land in the Warp app internally. People are building tools that help us do our job as far as like recruiting and product development and HR and all of that fun stuff. And this is what gets me super excited about the next set of things that we're building at Warp and where we're taking our platform next. Um, and it relates to this concept that, um, is a bit of a buzzword in the industry right now. It's this um term known as the software factory. Um and I think it really reflects this intent that we have to provide a structured process that is repeatable for producing high quality code for our systems. Um when we talk about a software factory um we don't mean that we're like completely removing human judgment. Um, and we don't mean that it's completely lacking in like seriousness and robustness. In fact, those are like really key qualities of a good software factory. Um, it's about giving people these like really robust systems for turning their ideas into software. And we want to build on top of like our existing infrastructure and um, primitives that we already have. So all of these things are floating around. Um, and I think one of the things to consider about why software factories, um, reminds me of this story that I have, um, that happened last year at a farmers market. I had stopped by a booth at a stand where this potter was selling these mugs. Um, and I spent a bunch of time talking to him and he's one of those people who's just like really into their work, really into what they do, and I find that totally infectious. Um, and he was kind of talking about these mugs and how he spent all this time like refining the design, um, and the way that it was shaped. There's like a specific way the handle worked, the glazing on the top, um, that would let you like stop the dribbles from trickling down the mug if you spilled.

[00:22:24]Um, he thought about the mug itself a lot. Um, but then he spent a lot of time talking about his workshop where he produced all of these mugs with a bunch of apprentices and he talked about all of this time that he had spent designing the workshop itself. Um, how things were laid out and arranged. Um, the tools that were available at each station, what kind of quality controls man mattered at each step of the process and when they got um, involved.

[00:22:56]and his operation was like not small um for what it was. He would churn out hundreds of these mugs a day. Um and the cool thing here is that like the edge to his business wasn't the mugs themselves.

[00:23:07]like they were kind of interesting interesting technology and had interesting features. But it was the way that he had scaled his workshop and the amount of time that he had set up around the process and the way that humans interacted with the tools in the space to maximize the quality and output of his shop. And I think the epiphany moment is a lot of what we're trying to do with software and building the platform right now is do what my potter friend was doing with his workshop. um for software which is like building the process for building the things. Um I really love what he' done because he had kind of executed a lot of what I was talking about around serious and repeatable systems that accommodated anyone being able to take an idea um maybe it's the idea for a perfect mug and turn it into something real. Um, I think it shows that this philosophy of like starting to tinker with the process of building something and not the thing itself is kind of a natural evolution of starting to create things. Um, I think it emphasizes the fact that software is kind of unique. There's no two bugs or features that are alike. Um, and the process really needs to scale and accommodate just how varied the task is.

[00:24:28]Um, it highlights that these systems need to be like very malleable and react and tune themselves to the kind of work that was being done. It's not like my potter friend set up his workshop one day and then never changed anything. No, he like tweaked it as it was used more often as more apprentices were on boarded as like the scale and um the volume of product that he was producing changed.

[00:24:52]Um, and what's really exciting is that it gives us the opportunity to kind of build these systems and allow more people to turn their ideas in into code.

[00:25:03]Um, by being the people who build like a really excellent platform for scaling that. [snorts] And some of the like technical details I think on what an excellent platform are um is kind of expanding on the set of primitives that we've offered at warp. So, um, we've talked about being able to kind of fire off agents, um, to human intent based on a prompt, but we can start to think about automations that let agents react to real world events, whether it be APR being merged or your CI failing or like a sentry alert firing. Um, observability is important because we need to kind of understand what's happening in the workshop, what's happening in the factory and able in order to be able to tweak it. um and make decisions about how it should work. Um this also lets us know what our agents are doing, what decisions they're making, um how much they're costing us, so you know they're not running running astray. Um and these two things kind of combine into a focus on self-improvement. Um we want to be able to support agents learning from observing the work that we do. Again, these are not static systems that we're building. It's not a static factory. Um, agents should be able to modify the behavior of themselves and the way they orchestrate and interact with each other. Um, by understanding and reflecting on how individual instances of an agent being run or a task being completed might impact the way the system performs in the future. Um, and finally, we're going to be driving these agents harder and longer on more interesting problems. And so it starts to become really important to consider um costs um and be mindful about how much cost they are incurring. We want to do the most productive work for the least amount of cost possible. Um especially when so many things are being driven through kind of these autonomous um self-running infra. Um and once all of this is like in place, one thing that will happen is we really allow the human role to shine through in software work um which is you know setting direction um being able to inspect outputs and discern quality and intent and the correct implementation for an experience. um deciding what ships. Um I think to do that we have to stay true to the values that have made great dev tools in the past which is um tools that people love um primitives that give choice and flexibility without introducing um fragmentation um in systems that let you build serious software without a bunch of hurdle. And the net impact here is that if we as kind of cloud agent platform engineers, AI engineers um do our job well, we can build systems that remove a lot of the toil and drudgery from software. Um so that people can focus on being creative and build um where the definition of who can build and who can use code to produce software like expands super greatly. So, if these ideas are interesting to you, if you're excited about the concept of a flexible but not fragmented platform, something that allows you to expand but is mindful of the realities of building software that needs to be high quality and cost effective. Um, check out warp.dev. We're doing fun things there um with their cloud agent platform. And if you have any questions for me, I think we have like a minute, sorry, to answer them after this, but you're also welcome to reach out to me on socials and then I do have my email um up at the bottom there um in my website if you'd like to to send me an email.

[00:28:47]>> Oh, wow.

[00:28:47]>> I did it, Ben. [laughter] >> Yeah, that I mean that was great.

[00:28:54]>> Thank you, >> Sharon.

[00:28:57]Yeah.

[00:28:57]>> Yeah, I feel I feel bad. right on time for 30 seconds, but um folks are welcome to reach out over email or like Twitter or any of that stuff. TwitterX, sorry.

[00:29:08]>> Totally. And I'll I'll share that in the chat, too. Captain Sophia.com, right?

[00:29:13]>> Yes.

[00:29:15]>> Nice. And where did the name Captain come from? Just out of curiosity.

[00:29:19]>> I know. I am like a major truckie. I love Star Trek. Um, and so when I was like creating my hacker handle, my official hacker handle when I was like 16 or something, I was like, I would like to have um I would like to have Captain all of my my handles. So there you go.

[00:29:40]>> And [snorts] it sticks as soon as you make it.

[00:29:43]>> Yep. It's everywhere now. I'm just Captain Sophia. In fact, it's my first name now.

[00:29:48]>> Nice. Yeah, first name.

[00:29:51]>> Cool. Okay, we have we have one question maybe. Uh, who else is working on the beginnings of the software factory paradigm? I guess that's outside of warp, but >> it's outside of warp. Oh my gosh, it's like it's a lot of people. Um, >> yeah, >> you know, I think what's interesting, I've talked about kind of like the natural progression for things earlier on in the talk. Feel like we've seen that happen just in general, like the local to cloud agent one is a big one. I think that um every company working in the AI space has kind of like picked up on that more of this more of this AI enabled work is going to be happening in the background not on people's local machines kind of reacting ambiently to like things that happen in the system.

[00:30:34]Um [snorts] so I think there's we're definitely like not alone in in playing around with ideas in this space which is I think what makes it super interesting is everyone's kind of got their take on it. Um, I think we're unique in our focus on like programmability. I've talked a lot about um the way we focus on things being buildable as far as like our API and SDK. My own background has been in building APIs and SDKs. So, I get giddy about that kind of stuff a lot. Um, so yeah, I think it's going to be exciting over the next couple of months to see how this space all up unfolds and like um what things shape up to be like very important in how people interact with like software factories or these like autonomous software systems.

[00:31:18]>> Yeah. And I just shared a link in the chat to something our CEO put together, Zach Lloyd, which is like a a demo repo that lets you create a software factory [snorts] from like GitHub action triggers. So like the really simplified version. It's not the fancy talking to cloud runners with web hooks and stuff which is what you need at scale but it's a way to take >> but it's it's built on the primitives of the of the like cloud agent platform which I think goes to show like if you give really good primitives people can build their own factories that could probably do the job for most projects if they wanted to. Um but yeah, I think that's the the value prop of of a system with really good primitives.

[00:31:59]Yeah. I mean, I'm running my own right now just off of GitHub action triggers.

[00:32:02]>> Yeah.

[00:32:03]>> Uh, it's pretty easy.

[00:32:05]>> Yeah.

[00:32:07]>> Yeah. Well, I don't want to keep you. Is there any any like parting thoughts or things to share with the community before we go?

[00:32:13]>> Um, I'd encourage folks to follow us on Twitter if they're not. I'm sure most people here are. We're going to be like posting lots of interesting things about software factories in the future.

[00:32:24]Um, and we have been sharing things out as you saw with um, >> Zach's blog post on building a building a software factory. Um, and yeah, Warp is open source. So, if you kind of want to see some of like our autonomous triage agent stuff and our review agent stuff in action, some of the self-improvement loops that power that.

[00:32:42]Um, we have build.worp.dev where you can kind of see all that workup level. I think I really like to highlight that stuff because it just it showcases the primitives and the factory like live.

[00:32:54]Um, so yeah.

[00:32:58]>> Yep. And shared those links as well.

[00:33:00]Build.p is like a dashboard on top of everything that's going on because it's an SDK. You can build views on top of it. And we're also, you know, building our own views to help people out, uh, if you want opinions. But right now, it's just time to hack.

[00:33:14]>> Uh, so go check it out.

[00:33:16]Yeah. Thank you so much for having me, Ben.

[00:33:20]>> Yeah, totally. Uh, it's better of a guest if we ever do live streams like this.

[00:33:24]>> This is true. This is, I think, my second time. Uh, >> yeah.

[00:33:28]>> Yeah. Next time I'll pull out an Excala draw and I'll like do an architecture.

[00:33:32]>> I think those are a little more fun.

[00:33:35]>> Partially because I like being bald, but you know, it it's fun to do like a a whiteboard session and like pull people in.

[00:33:41]>> Yes. Maybe that'll be our next one. a whiteboard session on how the cloud agent um the like software factory stuff works. That might be fun.

[00:33:49]>> Yeah, exactly. Uh we're actually planning and I should also say we've been sharing so many links today, but we do have a Luma calendar and our next one will be uh with the guest, maybe the CEO. We're trying to plan out when that'll be, but >> wanting to like have a just walk through how to build one, how to build a software factory and >> All right, I'll be tuning in for sure.

[00:34:12]There you go.

[00:34:13]>> I'm sat.

[00:34:15]>> Nice. All right. Well, good chatting, y'all. Hope to see you around in the next class.