Markdown source

Transcript: Htm02Kmnznk

Source Video

Local Cache

Transcript

I need I need I need baby I need baby. I need I feel I feel I need Ladies and gentlemen, welcome to the AI Engineer Worlds Fair. We're excited to kick off an incredible few days of inspiring keynotes, technical insights, and conversations with leaders across the AI community. Please join me in welcoming co-founder of AI Engineer and editor at Leighton Space, Swix. >> Wow. How y'all doing? Welcome to World's Fair. Let's switch to slides and uh I'm going to kick off the the stage. I'm really honored to welcome all of you um to basically the biggest gathering of AI engineer we've ever had. Um I think it's interesting to talk and think about what we're all doing here today. So um I hope that we have the slides up. I can't actually see whether whether my slides are up. Uh we do need to make sure this thing is all right. Cool. Um in the beginning there was the token. Then there was the chat. Then we learned to use tools. Then we learned to set goals. I'm skipping a few steps. And these days we're all about automations. We're all about cron jobs and loops and the rest of today on this live stream. Uh the uh those of you watching at home, uh we're going to be talking about software factories as well. So there's a lot of loop stacking. Uh I wrote this essay called Loopcraft. Uh I think Joel in the audience did a workshop on it yesterday. Can you still hear me? Are we good? Sorry, I I um had a mic slip. Um and I think this is something that is basically a core skill of AI engineer. Uh is defining what loops you're working in and figuring out whether that's the right level of extraction and when you're ready going up a loop in order to figure out the next level in productivity and scaling your inference. and when you're finding issues going down a loop and going lower level in order to figure out reliability and fixing whatever bugs you you find. If you want to simplify it, uh I have a I have a better analogy that will be less complicated. Uh it's literally just a stack of wild loops, right? I think all of you in in the audience and programmers will understand this. Uh and effectively this is what we're here to do today. We're um I expect our engineers, our leaders, our researchers, our founders um to all be understanding and rehearsing as a as a as a sort of human general intelligence all these loops that you guys are capable of of um going up and down. And that is why there's so much content. Um I often tell people who who complain about the tracks, I'm not going to apologize for good content. uh it's up to you to decide and route yourself uh as to which level you currently working at and which level you're currently blocked on. Um so the thing that's occupying most of my time um recently and what I what I make the human analogy for is what is the human loop? Um and in the beginning there's a heartbeat when you when you're sort of in the womb you you sort of get that heartbeat that is the proof of life. Um then you learn to talk. Then we learn to use tools. Then we start to work. We eat, sleep, code, repeat or prompt. Um and then we start working in teams. We start working in small groups and families. We we've uh promoted the concept of tiny teams before and I think that is increasingly important with uh everybody. Um and I think the interesting thing to think about is like the broader human projects as a whole like where are we all going you know extend out from your personal context your family your country your company whatever um to the broader project of the human civilization and what we're building uh with collective intelligence uh I think it's very interesting to uh consider that so um I I think that's a little bit what I want to leave you with today like the things that you're doing with coding are definitely crossing over to human life. Um the message of my last keynote at AI engineer was that the you know it's very much like agents that you see are working in one domain are definitely generalizing this year. Um this is the year that we're adding vertical tracks like you know AI in healthcare, AI in finance, AI in GTM uh we have a four deployed engineering track this uh today which I'm very excited about. Um all of this is meant to see how AI is just diffusing finally beyond coding. Okay. Um last world fair I give you all an update on the stress curves uh of the of the the organizers. Uh just to give you an idea this is um the first world uh first AI engineer in 2023. Uh this is sort of the sales curves basically of like how people bought. Basically it was kind of linear. Then we had the first world fair 2024. uh about 2,000 people. 2025 uh was uh I think I maybe skipped uh skipped a few lines, but we're we're basically at 6,000. Um and if you sort of calculate uh sorry, we we we we aimed for 6,000. We actually crossed and going went to 7,000 today. Um and basically I asked you all to buy your tickets earlier. We did not. Um uh if you measure the Jenny coefficient, uh it has gone up and not down. That's the wrong direction. Um so if you all if you all can just gather uh you know your yourselves and um you know join us earlier I think that would be great. Anyway um why we want to work at a conference why we why I work on a conference why you all come to a conference is basically the concept of the highest loop. Um I I will submit to you that the highest loop of all is to uh if I can make this slide work. Oh my god I'm gonna refresh. Okay. um uh that the highest loop is where humans come together to figure out what the next loop is, right? The loop that makes loops. Um so we organize a engineer summits all around the world. Uh this year we have summits in New York, summits in Paris, summits in Singapore. Um and uh you know again Melbourne and I'm forgetting one already Miami. Um and uh we organize this as partners. We want you to organize it in your own home countries. We're we're hiring a partnerships team uh to do this and this is the highest loop of all which is the world's fair which is the summit of summits. So you're I'm very excited to welcome all of you today. Um I hope that you figure out your generative process for generating loops and propagate it down to your teams to your personal workflows to your lives. Thank you very much and enjoy the show. Hello and welcome. Wow, look at the size of this audience. This is incredible. A engineer has grown twice the size compared to last year and our expo is four times the size. Thank you to each and every one of you for being a part of this community. Today we have 18 different tracks of content ranging from breakout tracks, keynotes, and expo sessions across all of our time here and all of these different sessions. Today I'm super excited to introduce today's mainstage track called Software Factories. A year ago, Jeffrey Huntley released the Ralph Loop. It captured our attention and sparked our imagination as we saw the Ralph Loop work autonomously overnight on our behalf and create entire products on its own. However, in the early days, it wasn't perfect. The Ralph loop came recommended for green field work only, and it came with the expectation that it would get you about 90% of the way there. Over the last year, we've learned a lot and there's been considerable amount of advancements made across the industry, which makes now the single largest inflection point for software factories. Model vision has improved, allowing models to see and verify work they couldn't have previously. We also have access to far richer tool ecosystems, allowing agents to access real production data that they couldn't have previously. We've also watched context windows and memory improve, allowing agents in loops to track work that's been done before. Reasoning models and capabilities have improved, allowing models to take on more sophisticated tasks. Also, AI security best practices have emerged, allowing models and allowing agents to have the security, autonomy, and capability they need to do real meaningful work within the enterprise. All of this comes together now. Software factories are no longer a vision for the future. They become a practical reality. Today's speakers are on the forefront of this shift, and they're going to help us separate what's real from what's hype. what actually works in practice and how to build software factories that produce real results, not SLOB. So, I'm very excited to introduce our very first speaker. His talk is titled on AI and Knowledge. He's a CVP and distinguished engineer at Microsoft. Please welcome to the stage Pablo Castro. Now taking the stage is CVP and distinguished engineer at Microsoft, Pablo Castro. Hello everyone. Hello everyone. Good morning. It's great to be back here at the AI engineer world's fair. Now my job at Microsoft is to connect the dots between AI and knowledge. as an information retrieval nerd like that's great for me like I spend a lot of time on looking at knowledge representation extraction search and whatnot and thinking about agents and knowledge really invites to reflect on you know what it means to know something and uh you know the the the nature of how do we get things done based on what we know. Next slide. All right, there. So this morning, what I thought we would do is spend a little bit of time talking about the nature of knowledge and split it into these three categories of intrinsic, extrinsic, and learned. Intrinsic knowledge is just the knowledge that comes with the models. you know, it's what we uh train the models on the training data and what um uh stored in the models kind of parametric memory. And while it's kind of the obvious thing, I would argue this is the knowledge that actually threw us into the exponential we are in today. It's what started many of the scenarios that then grew on all the things we're doing with agents today. Let me give you an example with code. So I wrote these two pieces of code about 25 years apart and yet the process to put this thing together was surprisingly similar. Like I had to s sit down with what I knew or what I I had to go look up and um and then just write it up. And uh while you know I'm illustrating this with knowledge, you could say the same thing about you know writing an email or creating a summary of a document. Now you can see this exponential at play in tasks like these where you know I'm sure you can go further back but an interesting point in time to start looking at this would be when Microsoft introduced IntelliSense. That was in 96 and you know it was great. You didn't have to remember function signatures anymore and whatnot. It takes 22 years from there to go uh for the next step where machine learning helps us actually rank the options we give you in IntelliSense so it's quicker to pick the right choice. just three years after that GitHub copilot launches and that was one key inflection point. This was even before Chad GPT um was announced and you know I would argue that GitHub copilot chpt that sort of experiences were heavily grounded on this intrinsic memory what the models already knew from there of course things shifted you know a couple of years later cursor launches GitHub copilot X launches and how we do things kind of evolve really quick which takes us to kind of late last year Opus 4.5 ships and then in rapid succession you know GPT OPU and other models keep getting embedded and bettered at coding which takes us to early this year where incredibly successful uh software like like open claw uh comes out to existence with not a single line of code written by hand. So this is the shape of the exponential weing and a lot of this was powered by the by the uh intrinsic knowledge in models and of course the ability to reason. Now in the context of Microsoft, we want to make available all these models and make it easy for you to integrate them into the agents you're building. We do this from our agent platform that starts in GitHub where we all go and build has a contextualization system so you can ground your agents. And when it comes to agent hosting, observability and management, we all do all of these in Foundry. Microsoft Foundry is also where we uh offer uh thousands of models in our model catalog. So you can pick whatever is the right uh model for the right task and we keep adding more every day. In fact, just yesterday we announced uh that cloud in Microsoft Foundry is generally available. So you can use all the capabilities of cloud uh in the context of the kind of unified experience in Foundry. So you get best of both worlds. Now, intriguing model got us here, but it only gets you so far if you're building a system that or an agent that needs to participate in what's happening in an organization or a company. uh and you know as an industry we realized this early and we you know we saw the the rag pattern emerge that started as a pretty low tech uh technique but quickly evolved and what we do today with context engineering uh and you know it became a pretty sophisticated system for connecting agents and the knowledge they need to get their job done. Of the many dimensions of of which this got kind of complicated, I'm going to pick on two. One is kind of the evolution from simple and isolated data sets to whole companywide grounding and the other one is how we started with simple vector search and whatnot and we really saw this evolve into fairly complicated retrieval systems. So let's start with company grounding. Like at Microsoft, you know, spending time with customers, one of the things we saw early was that whenever you build an agent, you you always have the knowledge you care about for that agent and you'll manage that yourself. But you also need to ground the agent often on the kind of ambient data of your organization, you know, whenever the agent leaves. This includes maybe your documents, your emails, your chat, uh threads or uh the information in your data warehouse and whatnot. So we built Microsoft IQ as a way to give you a single entry point into all these kind of ambient data that agents need to get the job done in addition to the specific information that you build into the agent. Microsoft IQ is not one feature. is more like a set of capabilities that goes from work IQ that connects your agents to all the documents in say SharePoint, all the emails, calendar, your chats and the connections between people uh to fabric IQ that gives you access to all the all your analytics assets you know from data warehouses and data links to PowerBI reports and Foundry IQ which is what you use for your or agents where you can push your own data and then use it for grounding and of course sometimes you have uh your agents need to go out to the web to uh ground on data that maybe not yours is public information but uh but you need to uh use it to comp complete the picture of what the agent world's view is and for that we have uh web IQ. Now this first part allows agents to ground on the kind of this ambient data. Now the second dimension I mentioned before is the evolution of the actual retrieval systems. you know, when Reg first emerged, I think, you know, what we saw is like an initial adoption for uh vector databases that really unblocked us from uh getting a lot of these systems off the ground. And that was great. Um I think, you know, for a hot second as an industry, we thought that if we could get really really good at computing cosign similarity between vectors, we were all set for retrieval. It turns out, you know, things never are never that easy. Uh so you know what evaluations show over and over again is how you know if you combine methods you just get better results like in this case this is an evaluation from Ashrai search the search technology behind Foundry IQ and uh and you can see how individual methods don't do as well as combined methods particularly when you apply them to uh real world customer scenarios. Now the trick is how do you build a platform that allows you to combine all these building blocks without putting the complexity right in front of you like let you opt into it when you need control but when you have a scenario that is clear then you can have an easy system. So in Foundry IQ that was one of our core design goals and uh the way we do this is we actually layer the system. So you can start at the top. You can go to Foundry and say, "Hey, I have a bunch of I don't know PDFs or pictures over there. Just deal with them and then we'll do everything under the covers. Do like chunking, vectorization, deal with relevance and ranking, deal with agentic retrieval and whatnot." Now, if you're an expert and you want control, you can also do that. You can go to the bottom of the stack, you want to build vector indexes and tell us how to quantize the vectors or control lexical retrieval and whatnot, you can do all of that. And you can do it in the same stack which means you can go up and down as you as your needs change. Now on on top of the core retrieval system, we also introduced an agentic retrieval stack because we see that for easy cases like you know quick singleshot retrieval is great but for more sophisticated cases you do want a system that uh can reflect on on what's in the data set and decide whether or not we've satisfied the information need stated in the input before we come back with results. Of course, we see a lot of patterns like this emerge and the always the question is is this actually useful like are the results better? Our experience in our own evaluations is uh for for difficult cases agentic retrieval can make a difference across the many metrics that we we track you know things like um the actual evidence recall or answer completeness we see like the agentic retrieval approach continuously does better than than simple that's uh individual simple parts. Now, let me show you some of this in action. If we can go to the laptop. Can we switch to the laptop? There you go. So here I'm in I'm in foundry and uh foundry is where you you manage your agents, manage models but also the place where you can manage all the knowledge that you give your agents in order to uh do their jobs. Um when here you can you can create knowledge bases as the kind of the entry point of any agents into the knowledge you care about. In this case I'll create a knowledge base. I have a data set about movies. These are agentic retrieval systems. So I'll give it a model to power the retrieval workflow and I can say how much effort you want the model to uh to make or the system to make and this is effectively a trade-off between latency and and quality. I can configure a number of other things but critically I want to say where the data I want to ground is coming from and uh I can start from scratch or in this case I have a bunch of unstructured data like PDFs and whatnot in in blob storage. I have a structure you know parket tables with statistics and I also want to ground on the web. So if I take these three steps and then I save this knowledge base now I have this asset this knowledge base that I can connect to an Foundry agent right here and it'll take a second uh but also it's a standalone asset that if I have already a harness that I'm using in other in other places every knowledge base is an MCP server so you can just connect to it without having to write any glue code in the middle. Now a knowledge base like this has uh you know has a bunch of parts. Some of them like for example this uh storage uh content you usually build indexes uh and you you know vectorize these things and whatnot. Uh and if you want control over that like if I if you don't you can just use it here. But if you do, let me just switch to Ashure and show you the service behind that particular instance where if I go to knowledge bases. This is the knowledge base we just created a second ago. And I can go pick inside for example I can go fish out the indexes that back this particular uh piece of content. And in that index I can see what is the structure of the index. Uh if I'm opinionated about I don't know maybe the quantization uh approach I want to use or which indexing algorithm I want for my vectors. I can say all of that. And of course I can actually go and explore the data and you know see what's inside how chunks were organized and and whatnot. So the goal of this is to again give you high product a highly productive environment when you need uh when you don't need uh the sophistication and when you need it to make sure you have it to get your job done. Go back to slides. And of course the other aspect of this is you know top of mind these days for all of us is token uh is token efficiency and uh so uh we carefully evaluate this system to make sure that we give you the most information dense answer that has the fewest tokens uh so that you you know the the your consumption of tokens has a high value when it comes to all retrieval tasks. The last category of knowledge I wanted to talk about is learned knowledge. Now learn knowledge is the result of us doing the work we do as individuals and as organizations every day and the the idea that we can actually observe the processes and get better at them by reflecting and improving every step of it is something that is really uh changed now that we have agents doing the work and we can go tune the agents automatically. Satia wrote about this recently and reflected on the fact that people and agents can really compound in in how they do the work and how they can create this learning loop that uh effectively captures what's unique about the company or or the organization you're working on uh and and puts that to work to differentiate the work that you do. Now in Foundry we wanted to offer like a material a materialized version of this that you can use today. So we built a a component called the agent optimizer that effectively goes through this process and allows you to evaluate a baseline, generate candidates and then you know evaluate the new candidates and we have a strong result then deploy that to production. Let me give you kind of a quick flavor of what this looks like if we can switch back to the laptop. All right. So here I'm in VS Code. I have the foundry uh toolkit installed and uh I have a simple agent. It doesn't matter how you write your agent as long as you externalize configuration like you know your instructions, tool definitions, skills and whatnot. So once you have one of those it takes two key steps to do this. So first whoops um I can actually so usually you have an evaluation already but if you don't you can actually say eval generate and what we'll do is we'll look at what we know about the agent like traces and instructions and whatnot and we'll produce a task adherance focused evaluation for you. In this case I ran this a little bit earlier. So just to give you a flavor of what this looks like, you you have a bunch of tasks and then you know the questions and the criteria and whatnot. Once you have a data set you can evaluate then what the next step is you can say uh optimize and uh I could just run optimize on its own and that will run in this case this run for maybe 45 minutes or so and you get an optimized version by effectively hill climbing the metric that's established from the evaluation. Um so I ran this earlier and so let me show you the output for this particular one where you can see that you know we established the baseline first and then we kept iterating on candidates using different combinations using a JPA style kind of loop uh and uh looking for options that perform better given uh the rubric that we have. And uh the interesting thing is that once you found one that is that is better then you can simply just say optimize apply. And what this does is since you externalize the configuration, it allows you to swap one configuration for the other. Um if I if we look here, you can see that for example I have a baseline and the one we just applied and just to pick on instructions. These are just the trivial instructions for this example agent. But if I look at the optimized one, then you can see like a bunch of instructions that are not handwritten, but that they emerged out of the hill climbing process to get to make this particular um agent better given what we have in terms of instructions and skills and tools, but also based on reflecting on the actual uh traces from the agent as users are using it. So this is a real learning loop materialized in practice. Can go back to slides. So this was like a very quick overview about how do we think about knowledge in the context of AI and how do how we think we can enable this learning loops that will capture you know this differentiated capability that lives in each one of the companies and organizations we work on. If you want to try anything of what I talked about or showed today, you can head to ai.ashure.com and get going. And with that, thank you all for listening this morning. I hope you have a great rest of the event. Thanks. Please join me in welcoming the head of enterprise product and the head of developer experience at OpenAI, Alexander Emiricos and Roman Huitt. >> Wow. Good morning everyone. I'm Roman. Hey everyone, I'm Alexander. >> Wow, this room is incredible. There's over over 7,000 AI engineers here today with us. And you know, it's not just about who's talking about this technology. It's also about who's actually using it and pushing the frontier every day. So, we couldn't be more proud to be here with all of you today. And when we were thinking about this event with Alex, we kept coming back to the World's Fair. You know if we can advance one slide mine work all right we're great coming back to the world's fair and the world's fair actually in the future visible to everyone by building it in public you know ideas that previously sounded impossible were actually suddenly there people could see them they could walk into them and they could even start to believe in them and honestly this event has the exact same energy the future of engineering is not arriving from somewhere else. It's really being built here by the people in this room and much faster than most expected. And that's why it's a little surprising that people keep saying that engineers are going away. The argument is that coding is, you know, abstracted away and therefore eventually we won't need engineers. Well, in fact, we think it's quite the opposite. You know, software ate the world and then AI ate software. But now what we're here to say is that the AI engineers are eating the world. AI engineers are the people here pushing the frontier. Yes. And you all are figuring out how this new capability can reach everyone. And there has never been a better time to be an engineer. In fact, because engineering was never about writing code. Engineering has always been about solving problems for yourself and for other people as well. It's about taking the latest science and combining it with design, with taste, with judgment, and most of all, imagination to make something that people can actually use. And in that sense, it's not the end of engineering. We think it's a return to the roots of engineering. And the technology we're building on is accelerating, getting faster and faster. For example, we used to ship a new model every 15 months or so, and now it's about roughly every six weeks. And in case you missed it, last week we launched a preview of the 5.6 series, and we're super excited to get into all of your hands. Now, building on top of all these models, the rate of product progress is relentless. And as a result, I don't have to tell you, the engineering feels completely different. So, just to go over a couple years of what for me were successive like mind-blowing experiences. You know, obviously for a long time we've had, you know, completion and then we went to inline prediction and then finally we had then we had command K where you could ask a model to make a change but they wouldn't test the work. Then models started testing the work and now we have models taking on long hard goals until they're done. And for me each of these phases I remember the first time was just mind-blowing and then obviously afterwards you just get used to it and you're trying to get your work done. >> Yeah. In fact like I can't believe that build and test loop was not even part of the models just two years ago. This was a picture of me at dev day 2024 and I used 01 in preview at the time to build a mini drrome drone interface from scratch. And the slightly insane part is the model could not actually run the code or verify its own work. And I knew the demo would work most of the time, but surely not all of the time. So I had to cross my fingers. You can kind of see here that I was pretty nervous, but hey, that's me. I only do live demos, so I never know what's actually going to happen each time. Luckily, it did work. And by dev day of last year in 2025, I was confident enough now the models could test their own work to kind of control an entire camera system and lighting system live. But yeah, we've come a long way. >> Yeah. So we refer to as the demo god and you know before the demo like I'll ask him so how often does demo work? He be like you know three times out of four and all right good luck. Um obviously we've come miles since then and this year alone has been crazy. So what we're putting up here or here or somewhere u are all the things that we've shipped so far. No, actually not even all. A selection of the things that we've shipped so far this year. Actually, can we go back one slide? Um, anyways, it doesn't really matter. The point is, uh, my favorite things that we've shipped are like Codex app, goal mode, remote. These are things that really changes how it feels to do work. And so, you know, obviously we couldn't do these things if we didn't use codecs to build codecs. But I think to me, what is most interesting is that now codecs can do and agents can do any task that you can do on your own computer. And so that means they're not just helping you with the coding, but they're helping you with what happens before the coding and they're helping you with what happens after the coding. And this is really key, right? I think there's been a lot of talk, there will be a lot of talk today about loops. And if you can connect the agent to not only the work that you have to do, but why it has to be done, that's how you can get the agent to start to begin much more work. And then if you can connect it to what you do afterwards, review and deploy, that's how you help it land much more work. So with all of this, of course, we can move much faster. But to me as a product person, the most exciting thing is actually that we make better decisions around what to build. For instance, we try we prototype many more ideas and we spend much more time with users. So yes, that's all of you. So wanted to pause and just give you all a big thank you both for the love and the constructive feedback. I would say it's safe to say that we Codeex and actually the entire industry wouldn't be here without you. >> Yeah, thank you so much for all the feedback. We're constantly listening to all of you. Thank you. Okay, so what's next? The models are getting really good. I would say if you pick like a medium length computer task and you give me and the model the same amount of time to get that task done, probably at least in my case, the model will do a better job than me for the average task. And so, okay, we're we're getting these models, you know, in some ways they're smarter than us. They can do almost anything. How should we shape that? what should the product that we use feel like? And so to answer that, we look to our mission. The part of it here that I've got up is, you know, AGI that benefits all of humanity. And I think in order to do this, there are two main questions that I think about now. One is how do we set up the agents to actually do things in the world? So what can they do? You know, gradually agents are getting connected to more and more things. Then where do they run? More on that later. And then the other question is how do we use these agents for us? you know what what should the product feel like around them? And for us, the goal is squarely not to automate engineers. Instead, the the product shape that we want is one that maximally empowers engineers. So, you know, if we think about what that product shape is, we actually think it's pretty simple. I I read a lot of sci-fi and, you know, watching superhero movies and I actually think that the the simple ideas in there are approximately right. So, there are two modalities roughly. Chat, I actually think I know some people think chat is dead. I think chat is underrated. uh and some kind of hands-on experience. So, what you want is a single entity that you can ask for help with anything, anywhere. And then you want a sing a powerful collaborative UI that you can use when you want to inspect, steer, or shape things yourself. And so, I had Codeex image gen me an illustration of this to help understand when you might want to use these things. And so, my analogy for you, yeah, I hope you like the image gen. Uh my analogy for you would be it's just like working with a team. Most of the time you're just talking about stuff and your team is just doing stuff. You don't actually want to watch over the shoulder or like have to walk over to the workbench of your teammate for every single unit of work. Mostly you just want to talk and let them cook. And then every now and then you want to dig in and really dig in all the way to the weeds of things and dig into that problem together. And for us as we build product, we have this idea that we want to make it so that you can retain this feeling of mastery of the work that you're doing because that's really powerful. We don't want to make it feel like actually it's really hard to like get to the details and like you know disassemble the hardware in this case. So the way that we're bringing to this to life is just the beginning but this is why we built the Codex app. You get a very simple chat interface that you can use for coding and for anything else and you know you can have a conversation and then go as deep as you want. So, in the case here, we have Roma's predicted score of this upcoming World Cup match. >> I hope I'm right. I hope I'm right. We'll see. >> Okay. Um, and what you can do here is you could go in and you can point at a very specific thing and say, "Hey, I want you to make this change or you can make this change yourself." And a fun story here is that actually the Codex app was quite a controversial project to start. Um I remember pitching some of you who I know are in the audience uh this idea before we started and I was told squarely like we I will never use such a tool. I will never leave my terminal uh or Vim or Emacs. Um but actually those people are now using it and even internally like within our team there were a lot of questions like why should we build this? People love the CLI they love the IDE and it's a little subtle but our take is that you can't really build that collaborative interface for any kind of work in a CLI. It's mostly chat and then in an IDE the order is wrong. So you're starting with the code but now it's time to transition to like working with teammates where you chat first and you dig in when you need it. >> Totally. And we're moving really fast on this on the product surface and the model layer of course but we're also trying to keep pace with all of you. Right. Honestly half the time I open X I see someone in this room doing something that I had not realized Codex could actually do. And honestly this is what pioneers do. You guys experiment. You set up tools for yourself, for your team and in turn we get inspired. We learn from you and eventually everyone benefits and so we are helping uh uh you are helping us figure out like what to uh what to build next and also what the future of engineering should look like. But for that to work one thing that we we really care about is that codec cannot be a closed product that only openai can improve. So we've intentionally designed codecs as a set of layers that anyone can build on and we want to show you a little bit of that stack today and how it it manifests. First it starts with the model and Alexander showed how quickly we're progressing on models and you guys use these models through the responses API and guess what? This is how we build the Codex app, right? We use the same models through the same API and we actually are building on the same thing that we give to developers. And when Codex needs something new, we always try to bake it into the API first so you can benefit as well. One example recently was compaction. Codex needed a way to compact long contexts for longunning tasks and so we'll build that into the API. So that means your agents can use the same primitives that we built for ourselves. Moving on to the next layer, the Codex harness is also open source. So you can inspect it, you can fork it, you can adapt it. And we also took the same approach with agents MD. Instead of reinventing a new file format uh for codeex to follow instructions, we thought let's pick a name that other agents can actually use as well. The models are the default in the in the harness, the models from OpenAI, but they're not hardcoded in there. So if you want to use an open model and keep the same agent loop, you can. And we also bring this codeex harness into the post-training process of our model. So that means the models can learn to call tools and navigate an environment that's actually something that's open source. Now take the open code team for instance. They actually were able to inspect how we have this like reference implementation and they could reuse the parts that make sense to them or change entirely all the rest and make different choices. I know for instance they were trying to see how we did like sign in with chat GPT and so they could look at the code and and learn from it. And we think it's better than having developers reverse engineering how we build uh and and how we launch. But now let's say speaking of subscriptions that we want to go a level higher and how you bring this harness into an app and how do you let people sign in with their existing codec subscription for instance? Well, it turns out we had the same problem ourselves because we wanted to build a VS code extension and the codeex app and we wanted to have a unified way to like actually control this harness. So we built apps server and we also made that open source and the apps server is not kind of a a community adapter. It's really the path that we use for our own products and you can use it too. Uh Tuma for instance here aka Dimilian on X uh he built his own native app for Codex called Codex Monitor before we even launched the Codex app because he could build that uh using the app server and now he works on our team and he actually built uh Codex for iOS. And moving up the stack at the app layer, we also want to make sure that innovation is not blocked on our own ideas. And so we build extensible primitives here uh like the inapp browser that we showed on the screen and plugins. So if you take for instance browser use and computer use, these were built as plugins using the same extension points that we have available for for all of you. And lastly, we also recently built rosp specific plugins for codec say to make it easier to to customize for people who work in data science or design for instance. And these plugins are also open source. So you can see under the hood and get inspired from them if that's useful. Our goal is really to keep making this as open and flexible as we can. And the best part is people can use their existing subscription in more and more places from Open Code, Pi, Droid, OpenClaw to even Xcode and Jet Brains as IDEs. And you can see how they're becoming quite a meaningful part of how people use these tools. And that's really why we want to care about building this open ecosystem with all of you. Thank you. So really, if there's one thing I want you to take away from this section and this stack, it's this. We're not building one system for OpenAI and a second system that's simplified for developers. At every layer, we actually use the thing that we give to you. And we want to thank all of you because every time you fork the harness, every time you find the edge of capabilities of the models, it means we get to learn and improve. And honestly, with 7,000 of the finest AI engineers in this room today, I'm confident that all of you will define a lot of how we uh will experience AI and how the world will experience AI in the future. So, thank you. I want to give a shout out to whoever over there is injecting it. That's you. Okay. Thank you so much. Um so with all of your help we are making agents explosively useful. Um and so now the question is how do we get value out of them? And you know that's not token maxing. We have a term for this that maybe you use as well. I don't know is it on screen? Value maxing. So you know when we talk to engineering leaders most of the conversation is about some themes relating to the idea of value maxing. So we're going to walk you through a few common topics that come up. some things where we've already made a lot of progress and some things where actually there's a lot more progress to still be made. So the first one of these is cost efficiency. Everyone wants frontier intelligence. Pick your eight favorite eval. You want the best model. So with terminal bench here for instance, that's GPT 5.6 SUL. And like I said, we can't wait for you to have it. But okay, you also want as much intelligence as you can get. And that's where efficiency comes in. Cost efficiency has been a focus for us for quite some time and the results are continuing to pay off. So for example, GPD 5.6 Terra, I think it's in like dark blue in there, brings GPD 5.5 level intelligence, but at half the cost. And Luna there beats some pretty notable models in this eval, but at only $1 per million input tokens and $6 per million output tokens. I'll leave it up to you to compare those costs, but that is insane value. Yeah, we we really can't wait to uh to see all of you build uh with GPT 5.6 and this new family of models. Now, the next thing I want to touch on is speed, right? GPT 5.3 Codex Spark showed you what speed can unlock, but we also know that you all want frontier intelligence. You don't want to have a model that's like not as great as what you can operate at the very best. Well, this is GPT 5.6 cell running on Cerebras. The frontier intelligence at now 750 tokens a second. We can't wait to see what you can build with this next month. And honestly, to put that in perspective, this is kind of like having a pretty substantial PR written in like 10 seconds. And it's not just about getting one answer faster, right? It's about what can you do with that speed. You can think about an agent taking different approaches, maybe like five or six in parallel, maybe like, you know, coming back and picking the best one in the time it would have taken to not even generate just one. So, we really can't wait to see what that can unlock when you have frontier intelligence, the very best at that speed. It really starts to feel less like waiting for an AI to respond and much more like a co-orker that's like already showing you the results as it goes. Speaking of working with co-workers, um, can I get a show of hands? Who who is familiar with this kind of site in offices? Okay. Okay. Wow. A lot of you are very well behaved. I see some people up front. Um, so yeah, a lot of people are keeping their laptops open so that agents can keep working. And this is funny, but you know what we really want is to be able to shut our computers. Um, and we want to be able to run many tasks in parallel isolated on their own box. Now, we've been actually aiming at this from the start. Our first major launch was Codex Cloud, and it is due for some major upgrades coming soon. But better yet, as we think about this, the future shouldn't have this awkward distinction between like a local task and a cloud task and you have to decide where to run everything. Really, what you should have is kind of going back to what I was saying earlier. You should just have an agent. You talk to it wherever, whenever, about anything, and it should figure out, okay, what do I need to do? Which environment is right for my work? And use whatever is available. In fact, Theo made this prediction over the weekend on this very topic and it's a pretty acute tweet. Like, Alex, what do you think? Sooner or later than six months? I think the not maybe not exact details, but the vibe of this tweet, much sooner than six months. >> Yeah. I mean, at the pace at which everything is go is going, I would not be surprised if it's sooner indeed. Um well, so now you might be wondering where's the live demo today? Uh well, for this AI engineer, we wanted to do something a little different. this time around and we think it's a very unique moment for all of us to kind of reimagine how we work and how we build and so we wanted to bring a special guest who has bent what's possible with agents and really has pushed us to be more agilled at openai so with that please welcome to the stage the claw father Peter Steinberger Peter take it Okay, thank you all. >> Thanks all. >> Good morning everyone. You know, I love this picture because it reminds me just how much has changed in a few months. I was juggling 10 or more terminal windows, always waiting for one of them to finish so I could steer the agent and cue new work in in January. That felt like peak productivity. Today it feels a little bit silly. I thought I was orchestrating really I was Pauling. I was the scheduler, the router and the memory. You know, at first I paired with one agent with 10 terminals. I was no longer pairing. I was managing 10 direct reports. Now I mostly talk to a longunning manager which delegates work to a team. For tricky work, I can still drop down and pair directly with a worker, but my default changed. I manage the manager of a small company of agents. Three changes made that possible. Number one, serverside compaction made longunning tasks reliable enough that I stopped optimizing around fresh sessions. Coordination lets one thread create and steer the right projects. And third, automation can wake the same manager when something happens. So we have persistent context, delegation, and triggers. There's your loop. And once the loop starts working, you discover the next problem. The bottleneck keeps moving. You know, last year I was primarily constrained by tokens. Now I fixed that by joining OpenAI. I know I know the strategy does not scale. Then my constraint shifted to token uh compute. All these threads run at the same time and my MacBook starts sounding like a jet engine. That's mostly fixed by using test boxes. So agents can run tests on a separate machine. Now I'm primarily constrained by attention. And unlike tokens or compute, I can't simply add more of it. So the most important skill is today is deciding where to spend it. Are you still staring at the agent while the code flies by? >> I know. I know. It's it it feels cool, but with the earlier models, this was necessary. You know, you you you you see the agent go in a direction you don't like, you hit escape, you steer it, you steer it back. But the latest generation of models is so good at understanding intent that it's a little bit of a waste of time to watch the agent generate code. Imagine someone files an issue on one of my open source projects. The manager wakes up, reach it against the project's goals, notes, and vision and decides whether it might be a fit. If it does, it creates a worker. That worker investigates, implements the change, runs the tests, and another agent can review the result. I don't need to watch those agents work or consume every intermediary message. When the manager needs me, it returns a PR, the original issue, the proposed diff, maybe a video or even a running build I can VNC into. I review once, I re leave a note, I maybe approve, the loop continues and can land after the checks pass. The agent runs the inner execution loop. I set the direction and I make decisions in the outer loop. You know, Paul Paul Salt is already running a version of this. He pinned his chief of staff. It wakes up every 10 minutes and it coordinates his GitHub work. The agent creates threads in the sidebar so Paul can jump in whenever the work needs additional steering. And you know once the manager is long lived tying it to a laptop just feels wrong. Codex can already move work between hosts. Open claw has a gateway and notes, but neither feels like the final form. I don't even want to sync where I work. My agent should be able to connect to any of my machines. They should know which work can be done in the cloud or which work requires my local machine. The manager shouldn't be a session trapped inside your app. It should be an agent that I can text, steer from Slack, or hear from wherever I am. Really, why can't I talk to my agent and have it design the whole loop for me? We haven't solved that yet. Models are advancing faster than the harnesses and organizations around them. Designing those things is the next engineering problem and that's where all of you come in. The future is not 20 terminals, it's better loops. Let's build them. Thank you. Please join me in welcoming co-founder of AI engineer an editor at Leighton Space, Swix. >> Hi. So, we actually were supposed to have Tashan from Z uh joining us today. Um he unfortunately couldn't make it in. uh to the United States. Uh but we have him dialed in. So Shan, are you live? Uh I hope I hope he's we're the team backstage is is dialing him live. Um one thing I also wanted to uh thank people for doing is this is a very very big community effort. Uh I love that. Thank you so much to the open open team uh for and to Microsoft for bringing the energy in the opening things. Um but even uh all you guys have been organizing all these side events uh and one of them I just wanted to shout out in particular the um AI engineer kids day. Um you know we are very sort of adult professional serious uh but we you know we also care about the next generation of AI engineers. So I wanted to play the video. We're here in San Francisco at AI Engineer Worlds Fair which is the biggest collection of AI engineers and entrepreneurs in the world and we're holding the first ever AI engineer kids day. >> And I really love this workshop series because we're inspiring the next generation of AI technologists. These kids are the people who will be doing AI in the future. They're very AI native. They'll be the AI experts. Something that makes this workshop stand apart is traditionally when you work with 3D games, if you don't use AI, it takes a really long time and you won't get as far. But in this workshop, because we use codeex, we were able to get a lot further than you normally would in a workshop and be able to explore a lot more advanced comp concepts than normal as well. >> Come here. It's really fun. Blah blah blah blah. And you can train AIS and create AIS and ask AIS to create games. Really fun. Give it up for the kids uh events. Thank you to Stephen Chin for running that um and basically generating the funnel for us for 10 15 years from now uh for our next attendees. We have to grow on TAM somehow. Uh so uh without further ado, we're going to bring on Sashen uh for for his keynote. Uh if we're all set. Hey, how are you? >> Great. I'm here. >> Uh yes, uh to the magic of the internet. Uh it's really good to see you again. Tashen has you've been speaking with AI Singapore. Uh and obviously GLM is uh the talk of the town right now. Uh there's been an amazing booth downstairs in the expo and uh I'm I think a lot of people are just very excited to hear from you on uh what all is going on at Zai. So if you want to take it away. >> Yes. Sorry again for not showing up in person, but I have a team, whole team coming to the town and we have a booth. So you have any questions, feel free to reach out to me on a LinkedIn and also you can look for my team on our booth. And since I cannot see my slides though, I will needs to help me flip through all the slides for me. Yeah, >> you're good. Can you share like what which slides we are in right now? >> Yeah. Uh so we're we're on the opening slide. Uh we're talking about intelligence and ZI. >> Okay. So yeah, so you can you can see that it's the first time for us to introduce G 4.2 uh 5.2 to the world. And also we're are going to share something about Z.AI and GM because maybe people will think Z.AI and GM they're irrelevant, right? you or your company is not G.AI or your model is called Z1 or Z2 and you can find my X and our company's X account here. So you can just search for my name Zishan Lee and Zai or you can follow them for the follow-ups. So yeah, we can go to the second slide. Yeah, actually I cannot see the slide. So I I'll try to >> so we >> yeah try to make sure that it is correct. So the company actually is called maybe some people have heard of it and the model the models it's it's called GLM actually it's not a a brand name it's a generic term so GLM actually represent general language model for training with auto reggressive blank fill and that paper was published back in 2021. So actually we were the one of the first labs to do explorations on large models. So at the same time with open AI and anthropic and deep mind and even today we we no longer use GLM as the architecture we still use the name GLM as our brand name. So we use JGM 5.1 5.2 and it become like one of our like most broad uh broadest product and model. And the second thing that we look for is intelligence upper bound. So in terms of intelligence we we may feel that it's represent IQ something something like that and when deepseek launched when 01 launched people are talking about the models capability to solve math problems physics problems but what actually intelligence mean is not just like IQ or A&E or other other physics problem. So from GM 4.5 to GM 4.7 we are exploring like several things like reasoning coding agentic capabilities. So as you can see from the slides so we add like uh yeah the last slide. Yeah we haven't I haven't like finished that slide. Yeah. So, okay. Yeah, I need to go back to the to to slides back. I don't have a back button. >> Thank you. I I don't understand clickers that don't have back buttons. Like, why? Okay. You know, anyway, go ahead. >> Yeah, never mind. Yeah, because people want to see the GI 5.2. they don't want to see like GI 4.1 or five but like G4.2 actually specialize in coding energetic task as you can see from the graph because there are a lot of rumors whether your model is close to mythos fable but actually I want to share this slides to all of you so you can see it's somewhere between Opus 4.7 and 4.8 eight and we use the hardest problems like deep tunnel bench 2.1 which was mentioned by the open eye team uh several minutes ago and all the like long horizon task and benchmark shows that the capability is on par with at least open 4.7 and it it it shows a significant improvements over 1.1 also for G 4.2 to we add a thinking uh level called high. So because we also notice as we move to the harder task it may consume more tokens and also we we care a lot about the token efficiency. So it's the first time we add the high level for thinking budget but even without thinking the non-thinking model is better than the 5.1 thinking model. So I think it's a huge improvement for the open weight model that's really impressed the world and why people are talking about GLM 5.2 lately. Okay, the next slide and one one thing that I want to mention is that GLM is more more than coding model because people use it inside clock codeex open code but actually we have trained a lot of things outside coding for example we improve a lot in GDP val and also math problems we also care about math problems frankly speaking and also we train a lot of thing uh related to role play general chat. We want to improve every aspects of the model. So you can see from the artificial analysis intelligence index actually leads the other open way model a lot and close to the frontier model. So I want you if you you haven't experienced GLM yet, you can use GLM to do general chat, use it to process your daily workflow, not just for coding, but you can explore the model like beyond the coding scope. Next slide. And GM 4.2 is a openw weightight model. So people always ask me why do you open weight? So do you care about your business or like do you care about losing market to some inference providers but actually we open the weights for several things because there are users needs and there are ours needs if we can meet their needs I think it's okay it's definitely okay for us to to open the model for example if our users wants security and control and we want to build trust we can open the For for some cases if an enterprise or government especially in the western world want to use the model we open way we upload to the hugging phase so that they can use the model on premise I think it's very beneficial for the whole e ecosystem to explore the model especially when the capabilities is close to the frontier model and second if people want diversity so in terms of diversity Firstly, I mean the capabilities in legal, finance, security, they can fine-tune the model. So, we need to open the model to let them fine-tune. For example, Harvey is fine-tuning G 4.1 and maybe they're thinking about fine-tuning G 5.2 too afterwards and I I have like talked to a lot of other companies they are also thinking about fine-tuning GLM as their like next step or next strategy to differentiate themselves from other application problem and third if our customer or an individual want to co-design and predict the future sometimes they need to see the architecture of the model they need to see the recipe of how you train the model. So we want to make the norm. We want to make right bets. So we want to co-shape the future with our customers with the open source uh community. So I think our needs and our ecosystem pretty like fits into each other and GI 5.2 to couldn't succeed without you all the open source community players like on flaws and media and and some like individual super developers they are part of it and thanks a lot to application builders like Peter right because open source doesn't just include open source model but also open source softwares and open source other sorts of support so all your support and what you you're are doing right now push us to to make better models. I think uh you you are the true hero. And the last I want to share a a great resource for you to go through GIF 5.2 is our tech blog. So actually in that tech blog we share several things like our hugging phase uh repo how how you can try the glm 5.2 to you can try it inside the chatbot agent and also you can call the API and also we have a coding plan like the codeex or clark code subscription for you to use your tokens as individuals and also we share something about our training pipeline training recipe which you can understand why it's a good model. So there are a lot of things behind the behind the model not just um a a a model that had great data. We also have fantastic technologies behind the model. So you can explore the model yourself. You can see what difficulties we have gone through. And the last slides actually it's kind of a one more thing. So it's the first time we share Zcode to the whole community. So that one more thing is we actually have our own harness. The Zcode actually it's built for GI 4.2 but also support all frontier models. You can bring your own key. You can connect to Zcode. Actually the I think the operations is similar to codeex. Actually, you you can try some techniques like goal or other like compact technique techniques like what you've been in in codeex and call code and this harness I think it's the perfect one for G.2. If you haven't experienced it, you can just search Zcode or you can go to our booth. We have our team members showing this harness to you. and welcome to to our booth and welcome to like talk to me in the future and next time I'll definitely be in SF talking to everyone. Yeah, thanks. >> Thank you very much. Um, so uh trust me the very first World's Fair I wasn't allowed to come back in the country for for my own conference. So I know exactly this feeling. Uh but it's all good. uh the ZI team really appreciate them uh making the effort. They really want to meet you. They're here to meet you and this is the whole point of the world's fair to bring all the top world's AI uh companies and labs uh all in one place so you can do business together. Uh meet the people behind the models that you use ask the questions that he cannot answer in public but you can ask in private. Um I'm also very proud uh he showed uh Zen showed that that list of uh hugging face uh you know top uh contributors. I think we're are four for eight uh in that list uh present at Willsfair. Uh we're working with Nvidia and Unsllo and O Lama and and uh all those sort of finetuners as well to uh to make sort of the inference and the local tracks that you're going to see over the next few days. Um with that, thank you so much to Shen. Uh I'm going to invite on uh the next uh couple folks. I think I think I might be doing Alli's job here. So uh we'll we'll talk to Hugging Face uh next and and Minia. Thank you. Joining us on stage is the co-founder and chief science officer at Hugging Face, Thomas Wolf. >> Hello everyone. Hello Olive. Nice to have you on stage. >> Hi. Nice to Thanks for having Yeah. So I think you're on for a treat today because you just saw uh GLM which is current number two on the artificial analysis table. I take fab fable out because nobody can use it and now we have number four. So basically you will have all the top models at least the top open source model in a row and we're very lucky to have a leave who has a pretty amazing path in life. Uh so she came to the US Pennsylvania she was studying doing PhD at NYU uh in the lab of Yand working on JPA but we decided we won't talk about JPA today right something for another day um and then instead of joining hugging face which was in New York also that time she decided to go join Mini Max so uh for those who who maybe don't know all the all the nail labs around the world and you're you're forgiven because I think there's like 64 nails right now. Minimax is one of the top of what we call the AI dragons in China. So these are the new there's uh there's deepseek which is very well known now. Moonshot who does Kimmy Z and GLM that you just saw and now we have Miniax. They're all extremely good, extremely talented team fighting for the first spot. uh so the the the latest release of minimax was M3 uh just earlier earlier in June which was the top model at the time top open source model uh very impressive there's a lot of very interesting things about this model so we'll quickly dive in them and then talk a little bit about uh what's what's what's specific about minimax what's what's great there so uh maybe Olive to to start a little bit can you can you give us you know a little bit of your your view of of M3, what you like about this model, how is the release? >> Yeah, M3 we released M3 earlier this month and it is a smaller model with 400 around 400 billion total parameters and 20 billion activated. Um but it is very capable in terms of both coding performances and also it understands vision. So um that's uh what open source models don't usually have is that they can the model can only deal with coding but it can also understands videos um images and it has a super uh long context of 1 million um with our new architecture called MSA minimax sparse attention. So we you we really put these three things together uh because we know that they are they will be very important in future AI applications coding capabilities agentic capabilities longer context and multimodel understanding. Um yeah I think that would be very interesting about the model. >> Yeah. So, so there's a lot to unpack unpack in this model and it's um it's it's still I think the only top five model open source model that is actually multimodel. So, we need to talk about that. But maybe first about the long context because that was also the first one that really had this real one million token long context that's actually functional and you guys had also the the minimax pass attention which is this one technique to to make that efficient that you also published and and share extensively. So can can you talk a little bit about this maybe how the project went from from the attention how to make this long context? Yeah, I would say the story about long context went back to even Miniax M1 and Miniax01 where the model was actually was able to perform tax of 10 million um token context. >> 10 million >> 10 million. Yes. Um but then it was not an agentic model, right? It was just um 10 for example dumping a book, it would be able to give reviews on it and stuff like that. So uh what we realized was that you know longer context actually unlocks a lot of capabilities especially when interacting with users and now when you know the agents is interacting with the whole environment and getting all the tool responses um getting multi- rounds the like shorter context wouldn't be enough to perform the complex tasks. So for this version we said oh we have to have our longer context backs and so what we pursued was with our miniax sparse attention um which you know was the architecture that was scalable and had a simple design. So I would say from a higher level right it has an index branch um that you know selects on a higher level what is what matters more in the context and then we have a sparse attention branch that calculates performs the calculation on the selected blocks uh to actually performs the tasks. Um and so yeah like that we really designed um an elegant architecture so that we can scale the length and then scale the model size in the future with that. >> That's beautiful. I like how for for those who've been in the field for quite some time we we had a lot of work on attention right this N square and there was a lot of linear attention. Yeah. And then some that somehow all of this disappeared at some point when flash attention came around. We discovered we just needed more efficient camera. Now I like how we come back to thinking you know first principle what is attention how can we make that more efficient. So 1 million token is crazy right GPT2 was24 and and everyone was like oh that's really big we we we never need more. Where do you see this coming like going in the future? Like Jeff was pitching me the other day a trillion token attention. You think we should go token attention? That's definitely something we can explore towards, right? Ultra length of the context. Definitely that's something that's very exciting to explore with and something that architecture design along with hardware um would require a lot of research on to that. >> Yeah, you think there's still a lot of lowhanging fruits. So typically today we saw open really reducing I mean we don't know how as a phone but like reducing their their inference bill by half by probably having some more efficient processing around tensions. Do you think there is still a lot of lowhanging fruit that can be get in how we can process that? So so one one thing still very interesting about M3 is how cheap it is in particular because of this part attention or in part because of it's small one but it's also very efficient. >> Right. you think we can go even way further maybe how did you guys invented uh minmax passenture was it an agent coming up with the idea was it a human still coming up with the idea tell us a little bit about >> yeah um so we do think there's still a lot of work that can get into architecture and inference optimization so that the model can be more efficient especially if there are tasks that are very task sensitive but require very strong capabilities right and for that those kind of task we really want the model to be efficient. Um and who came up with partic I think an intern from our team worked on that that yeah an intern uh that doesn't usually happen in a lot of labs. Um because I think in some labs interns don't have access to the data the work and stuff uh but yeah we are open to anyone who would like to contribute to our models. So um the architecture was actually designed by an intern. >> That's really good. still some work for interns here. Good, good news. Um, that's also a good segue to also how minmax is working internally. So, so we were discussing before coming on stage, you were saying everyone can propose a project. Can you tell us a little bit about how you are organized, how you do research? Mhm. Mhm. I think that is very different from uh even in school or even in earlier you know the earlier tech companies is pretty pretty different is that um what we what we make sure is that we have good foundation and good um infrastructure so that anyone can play with the model and can think of what they can improve with the model and then after model releases when they are free Right? They can play with the model. They can think of their own evaluations. They can find their own weaknesses and propose a thing that they want to improve on the model. And then other people who are interested in that would you know propose to join the project and they will work on for a couple of weeks or even a couple of months and when they work out the final thing is shipped to our model. It it is you know we use that in our final training and it's shipped out to the audience. >> Interesting. So you can have people working for a really long time on project. When you say a couple of months, it can be like really deep exploration of possible. >> Yes, I would say for example architecture might require longer time of investigation, research, experiments, even redoing the evaluations for pre pre-training. Yes. So it might require longer time. >> Really nice. Yeah. And I know you're also very big on evaluation. I agree. We could talk about that. I think one one thing probably related to that is this unique specificity that M3 and your team has um around multimodality. So not just text but this model can also understand image and video and as I understand but but please expl explain better when we read the model card on hugging face it say the model was trained from the first step as a multimodel not just at a like user one as after salt right can you tell us a little bit more about that and why you think it's important and and and why starting from the first step on multimodel training and not just training >> um so we call it native mortal modality um And so it is somehow typical for model labs to train the multimodel let's say vision understanding capabilities after the text pre-training is done. Um they put adapters and then train that part. But what we found out was that that would actually harm the text performance and the vision vision understanding performance wouldn't converge that well because the model is kind of converges towards the model uh the text understanding um and it's just not the most optimal and also not the most scalable if you think about it. we want to scale the data right and also we can also some labs um train this capability from halfway through the pre-training for example continued pre-training but what we found that this would be very you know uh recipe sensitive it is different for the recipe would be different for different architectures different uh you know data mixtures different learning rates um it's hard to control hard to you know scale to you uh you can't really scale your experiment results and conclusions to a larger model and so for you know what we thought was why not just training from the very first step that comes the most natural. We know that a lot of labs run into problems doing that. uh the model would collapse after a couple of steps of training you know both text and vision understanding but we managed to solve that problem we did a lot of work on um vit and we did a lot of work on the data that we actually training um for example we do interle data what we call interled data um it's actually natural data but we keep the um images and videos in instead of mass masking it out and we do some pretty good cleaning and masking on the data and we do very good reward modeling so that we train it from the first step and scales up a lot. Yeah, it does does not collapse. >> That's really impressive impressive. Should do should we expect much larger model in the future? So, this one is still fairly small, right? It's it's 428 billion parameters, 23 active billion. Um well do do you think you will go past the trillion? >> Definitely. Yeah definitely in the future uh there are many tasks that wouldn't be able to the more model wouldn't be able to perform or good at with smaller parameters. We are definitely going more ambitious than this. >> It's great looking forward. Um, another interesting thing I always find fascinating about Miniax is how how you also have this whole range of of apps and product, right? So I remember already so so Miniax started to open source things on the on the HuggingFace platform in January last year. So 18 months ago and and we were chatting a little bit about the team to understand what you were doing and I remember so you were already having a huge usage on some of these uh of some of these apps. Um can you tell us a little bit how how this started right so was it basically you had a lot of apps and then you thought we have we have all these data why not training a model and then they build up research team how is how is the story there >> um our our story is model from the first day so um I believe that multimodality model a model that can understands all visions and outputs all modalities was the first thing that our um CEO planned on the first day even before the company even started. So that was the dream of AGI. I think that was very very early even before Chad GBT came out. >> Wow. Um yeah and then apps were something that comes along because you have some model capabilities you want people to experience it well not many people can use it with API right we can't expect everyone to experience with API so we need good um user interaction you know interfaces good apps good scenarios that people can can you know experience experience the model with I think actually those apps covered more than 300 million people around 200 countries globally and I think over a million companies as well. Yeah, this was uh mind-blowing when I heard about the size and we we don't often realize the size of of of this type of usage already and and that that kind of brings me to the question around um opensource business model and and all of that which is the always existing question which is right now it's nice to open source model but you you also need to have some revenue stream right so I guess M3 is something you you decided for instance to give for free and I think It's it's great for the world. Um, how do you see this? Do you also have some specific models you use for the app? Do you think about do you think in the future you'll keep it's probably hard to say for sure, but do you think you'll keep open sourcing models? How is the culture around open sourcing right now? >> Personally and also for the model research team, we always hope to open source the models. Um that is our plan because we really see how the open source community together can help the model build better. For example, we receive a lot of um feedbacks on the model performance from the great community and we receive PRs on um whatever we open source right and those are very very valuable and come comes to our later versions. So definitely open sourcing is great. >> That's great. And actually do you have some ask for the audience people who are using M3 or minimax is there something you would love them to send back to you as feedback? Do you do you for instance do you read when people try to modify the models or play around you know tweaks or what is the best thing you you think you can take from the community uh for the future models for instance? I would say whatever um issues that people are running into especially with multimodality right this is the first time that we're combining it together we are definitely going more ambitious on that in the future it might have some flush right now but we are improving on that so whatever that's uh feedback that model is not good doing that great we will definitely improve that in future versions and also whatever features that um people want say you know for example um thinking effort right some people ask for that um like everyone can ask and we will try to accomplish that in the future models >> yeah do you see a lot of usage right now already in multimodality in terms of coding agents I feel like it's it's a little bit underexplored >> it is it is but um it can actually unlocks a lot of capabilities and a lot of uh agent applications say that for example you want the model to read the PP PowerPoints, right? Or to read some reports that is not very structured um and you wanted to understand a very long video say that you dump in a long playing video and then you want the model to act uh using some tools uh after understanding it and it unlocks a wide variety of um agent use cases. >> So like the agent could finally watch my YouTube tutorial and understand how to use my coding tools how I described it. Is it something like that? >> Huh? >> Could the agent finally watch YouTube tutorials and understand things from them? >> Yeah. Yeah, I think so. >> Do you use a lot of uh agent coding tools internally? Is it like I mean coding for sure, but like is it also already in terms of research? Is it automated part or not? How does this >> Yes. >> Um we have our own research harnesses. Um we build our own research harnesses that automate our workflows. I would say a lot of our workflows are automated. You can see how um the latest frontier models all pursues capability like kernel optimization, right? Like let the model pulse train other models. Um let the model build data, auto data, stuff like that. Um you can see how more and more models are capable of doing those including M3. Actually, we were very good at those cases longer horizons and kernel optimizations. Um, and so we can use that model capability, harness it together and help with our um, daily routine and make our iterations even faster. >> Is M3 building M4 already? >> Um, building M3.1. >> M3.1. Okay, >> the gem >> already. >> Um, I would love to finish on what what you find exciting in the coming month. What do you think? It can be Asia in terms of feature or or things you want to see happening in in AI or or more generally in terms of whatever whatever really is top of your mind. I would say it's going to >> happen. >> A lot of things are very exciting. Um but what I recently find the most exciting would be a multi- aents that I think a lot of AI applications are using model routing multi- aents um that unlocks even more capabilities even comp more complex tasks and also it tells us what the models are capable and not capable of and you can you know do a lot of things with that is pretty exciting. >> Thanks a lot. Pleasure to have you. Thanks for having me. >> Thanks. Ladies and gentlemen, please put your hands together and welcome back our MC, member of technical staff at Keycard, Ally How. Wow, what amazing content so far. Super excited to tell you more about our next speaker who's introducing the security track. Software factories are only made possible if security is in the loop. Today, engineers have to navigate an ever evolving agent supply chain between skills and software packages that seem to be compromised almost daily. Organizations have to manage identity sprawl as agents increasingly do work on behalf of users and other agents. Security teams have to find ways to govern agents and make sure their access is scoped to only what's necessary for the task at hand. Today, there's an enormous shift that's happening across the industry from traditional application security to agentic security. Randall Daggs, VP of marketing engineering and AI orchestration at Sneak, is helping large enterprise customers navigate that shift. Randall's here to tell us more about AI engineer security track, which was made possible by Sneak. Please welcome to the stage Randall Diggs. Hello. How's it going everyone? Uh, I'm Randall. Thanks for the nice intro, Ally. And I'm only up here for a couple minutes. This is going to be very brief. But what I wanted to talk about in the time that I have is kind of the state of AI security and the things that I've been thinking about quite a lot lately and maybe things that you've all been thinking about, too. So, I've been a developer and security professional pretty much my entire life. And even though I've been in the security space, the thing that makes me excited in these recent years with the rise of generative AI is being able to build better quality software more quickly. There's nothing more fun than shipping the things that you're working on to actual users and sparking that sense of joy, right? It almost feels like a cheat code. And I think that there's really a few obstacles to allowing all of us in the room today to do these things at scale in today's world. So the first thing is something that all of us probably learned the hard way a few years ago, which is when you're building software using AI, uh there's always the risk that the code that AI generates might have a security issue. Everybody knows that. It's nothing new, right? And I think the reason that that's not a big deal is because first of all, everyone kind of intuitively knows that when humans write code, we generate security issues. When AI models write code, turns out they also generate security issues. And so having security as part of your development life cycle is just like a core part of like modern engineering work. No questions at all. I think the second thing though is a little more interesting. It's when you're trying to deploy actual autonomous agents into production. How do you do that in a way that allows you to go to sleep easily and not worry that the agents you deployed are going to go off the rails, do something they're not supposed to do, harm your business or your users or something else, right? And that's a much more difficult problem to solve. And then the final thing that I think is a barrier to us, you know, really innovating and moving quickly is almost geopolitics at this point. Like I don't know about all of you, but how many people were kind of annoyed when access to Fable got pulled? Show of hands. Yeah, a whole lot of people, right? How many people are a little annoyed they can't use the brand new OpenAI GPT 5.6 model right now? Yes, a lot of people. And I think it's interesting because this is all related to security, right? Like fundamentally the biggest problem that I feel we have to still solve in our space is being able to use AI fearlessly and have it be secure by default. And so that's why I'm really excited to announce that right after this keynote downstairs on the second floor in room 2005, we're going to be running the first security track at the World's Fair for the entire day with some of the best companies and presenters in the world talking all about these problems and how we can fix them going forward. So if security is a concern to you like it is to me, please come downstairs, join us again. Room 2005, second floor. Uh we have presenters from Nvidia, Anthropic, Keycard, where Ali works, uh Sneak, of course. We have a ton of amazing content and it's hopefully going to allow you to level up the stuff that you're building and do it without any worry at all. So that's really the goal. So with that being said, thank you so much for the time and hopefully I'll see you down there. Um I'm Randall and I'll be ming the event all day. All right, take care everyone. Suddenly your team is on on call rotation to figure what actually went wrong. Pretty common, right? Now, as per the standard engine response, your gut will tell you to pull the raw prompt from the telemetry logs, pass it to the same model using the same prompt and run it locally to isolate the bug, which we'll all do. And surprisingly, it will work as well. Run it again, it will work again. You run it 10 more times, it will be just perfect every time. But now let's talk about that one run which costed you and that will be gone. You can reproduce it and if you can reproduce it, you can debug it. But if you can't debug it, you can't promise it won't happen to your next customer or user. Right now I am Tisha. I have Sushin with me as my co-presenter. We both run agents against real production backends. You know the kind of place where a bad right isn't. Oh well, run it again. It's you on a call with a customer explaining where the data actually went. This whole talk is going to be about that one thing you lose the second an agent goes hey buy in production which is being able to reproduce it. That will be a not for the next 10 minutes to follow. Now let's look at how this actually blows up. We've got an agent hooked to a broker API which is the scenario I'm taking. The user says, "Hey, sell $1,000 of stock." Now comes the interesting part. Instead of doing the math, the agent sells the raw number 1,000 and dumps it straight into the quantity field. Guess what? It sells $1,000 shares instead. Now, at 190 bucks a share, $1,000 in 10 will become how much? $190,000. Disaster, right? And the terrifying part is that the API or my infrared returned a clean 200. Okay. In 30 milliseconds, we got zero exceptions, zero alerts. If you see the trade is completely wrong, but your dashboards are sitting there perfectly green, perfectly flawless. When such a scenario as we last discussed comes up, what's the first thing which you will do to try and fix this? The reflex here is to, you know, just turn the model temperature down to absolute zero. Assuming greedy decoding will make everything deterministic, right? But that's a complete misconception. Setting the temperature to zero doesn't fix a broken reasoning path. It just means the model is going to make the exact same logical error the exact same way at the exact same time. And honestly, even worse than that, to back up the scenario we just discussed, look at the engineering threads on Reddit and hacker news. The hard data shows that temperature zero isn't even truly deterministic on a hardware level. Running the same proced a thousand types can still return dozens of completely different responses just due to the underlying GPU non-determinism and the NOA architectures which are there. So to understand why this actually happens, we'll have to look at it from first principles. It comes down to four simple things. One, sampling determinism is in system determinism. Temperature zero just means always take the AG max, but it doesn't guarantee that the underlying scores stay identical run to run. Two, floating point math isn't associative. The order you add your decimal matters, right? But a tiny shift in matrix operation alters the final logic and which in turn will flip the winning token. See, it's not a concurrency issue. Run the same matrix multiplication alone on the GPU a thousand times and I'll guarantee you'll get this exact same bits. So the real culprit is batch invariance here because a request gets grouped with whatever else hits the server that millisecond. Four mixture of experts routing has the exact same bottom line. Experts have strict capacity limits. If a patch overflows a specific sub network tokens get rerouted. Whether a token makes the cut depends entirely on the traffic you got batched with. So the ultimate takeaway here is that chasing text output is a losing battle completely. We don't need the model to return the exact same token back every time. We just need our system to execute the exact same state transition. Which means we've been asking the wrong question all along. Right? The wrong question is how do I make the model deterministic? And I've seen teams burning weeks on that and walk away deciding the system's just unknowable. The right question is how do I debug and retest a run I can't reproduce? Because determinism was never the northstar. debugging was two words we keep mixing up which I'll talk about now is bitwise determinism and replayability. Bitwise determinism is same input, same output. That's controllability. You're not getting it from a hosted API and you don't actually want it because the randomness is what makes the model good. Once the model explores more, you'll get more creative answers. The other one is replayability which is rebuilt a run that already happened well enough to debug it. That's observability. You don't need the model deterministic. You need the run recorded and you don't freeze the model. You capture what it did. Now the question which we are all thinking about is where do you record? For sure not at the network layer because half your agent will never touch the network. the local retrieval, the inprocess tools, the memory and the parts that do not shred under streaming and async record at the boundary instead because you need to capture what enters each node and what leaves it. Imagine imagine something your agent didn't pro was wrong. Co the wrong tool. It wrote the wrong thing and now suddenly your team is on on call rotation to figure out what actually went wrong. Pretty common right now. As per the standard engineering response, your gut will tell you to pull the raw prompt from the telemetry logs, pass it to the same model using the same prompt and run it locally to isolate the bug, which we'll all do and surprisingly it will work as well. Run it again, it will work again. You run it 10 more times, it will be just perfect every time. But now let's talk about that one run which costed you and that will be gone. You can reproduce it and if you can reproduce it, you can debug it. But if you can't debug it, you can't promise it won't happen to your next customer or user. Right now I am Tisha. I have Sushin with me as my co-presenter. We both run agents against real production backends. You know the kind of place where a bad right isn't. Oh well. >> Hey everyone, I am Kushan. Uh I worked at Som as a founding engineer for two years. Let's talk about what I'm interested in right now and that is browser agents. Browser agents as an idea are so cool, right? Browser agents should go crazy, right? I personally have not seen that adoption and me myself, I don't use browser agents that much. I've been exploring that for some time. Been trying to understand why that is. So on my screen right now, we have the browser challenge. But uh this is a very interesting benchmark for browser agents because there are so many things that you have to do long rising sequencing of your tasks. And this actually reveals, you know, why browser agents suck. If you saw at the beginning of the video, uh the browser, this agent took like maybe 10 20 seconds just to click the start button. And now we're on step one. There are 30 steps and it has taken so long just to click one button. Um so enough of this. I want to show you what I've been building. So same website. Um I've tried to sort of replicate the feeling of seeing what's happening. You know, you can see what the browser agent is thinking. But as you can see, it is so much faster and so much quicker and I'm using a much cheaper model. Right? The hypothesis here is models are pretty smart, but it's the infra around them that sucks. If you noticed in the video earlier, maybe I'll put a screenshot, the agent is trying to debug what's going on. It's trying to click something, but it doesn't understand what's going on. So, my core thesis here has been give a nice environment for the agent to use, right? So, where it can plan long sequences, it can figure out where it failed, what is going on, and it can plan the click correctly. I have figured out is scattered across not just a codebase or a single repo but across things like Slack and email meetings and documents a bunch of other stuff right and then half of it is actually just stuck in someone else's head and so I'd have to have my AI reach out have them answer questions and move forward and you know when I was a individual contributor maybe it's very easy to just write code but as you sort of scale yourself you find that a lot of the knowledge work that is happening today is just figuring out like what has happened who is waiting on what and which loose threads needs attention. And so if you want to take anyway from this talk, you can just leave right after this if you want, is these six things. One, compaction works. Now you can really feel comfortable pinning a very long thread and knowing that it's it's generally going to remember uh what you've told it. You should also start getting really comfortable with talking to your computer. Voice is really good and voice is only going to get better through time and you're going to be able to do even more with uh dictation rather than a keyboard. uh computer use and appshots are very great. It's a great way of bringing in context and I'll talk a little bit more about what that looks like. And then most importantly, really start investing in what your personal memory looks like, right? What are the skills that you want to use and what are the skills you want to automate? But also, what are the plugins you want to share with the rest of the team? And once you have that set up, you can start thinking about these pin threads and automations like teammates. And more interestingly, I don't know if many people know this, but every thread in codeex can talk to each other. So maybe today you can work on having a pin thread feel like a teammate, but very quickly you might have threads that run automations that communicate to other threads. Now you can have this idea of a manager. And these are some of the really big concepts I want to bring to you today. And so if you've used something like chat tobt uh in the past, maybe you were taught, okay, you know what, you have to really have these very short threads. you know, um, they only happen every once in a while. After a couple messages, the context is going to run out and you really need to create a new thread to capture context. Now, all of my work happens in a pinned thread. You pin it, you give it a name, it runs over time, and with automations and triggers, you can start waking these things up. And so, codeex really happens in three acts, right? You bring the context into the system. You do work on this pinned thread, and then you figure out how the computer can then act and write back to the rest of the world. And we can talk about these things pretty quickly. How many people here actually use dictation? Just show show hands. I'm curious like how many people Yeah. You know, maybe like 30% 40%. I I I can almost assure you that by the end of the year more and more people will do. So, right. Tony Stark is not like typing into a keyboard talking to Jarvis. And I really want you to sort of recognize that by the end of the year, you're going to feel like Tony Stark. You're going to be automating a lot of your life through voice. Voice is like three times faster than most people type. And I have like a hand injury. I can't even type anymore. I just use a foot pedal to control dictation. And it's pretty awesome. And I'm also really lazy. So if I had to type, I would just send a message like fix this, right? And and I hope that the AI can figure out what's going on. And then when it doesn't, I complain on Twitter that, you know, the AI sucks. But in reality, when I use dictation, I will just blabber, right? Take a look at this issue, check the browser, there's some white space I'm not happy with. Maybe it's a screenshot from the website, maybe it's on Figma. then like make a pull request, edit only the CSS, and then also like when you're done, message the guy on Slack and then wait for the preview link and then send him the preview link too. I would never type this, but this basically is very easy to say and the the model can figure out how to actually take these actions. Once you have all this input in place, you just have to connect it with the rest of the world. And this is where you want to install plugins, right? Most of my work is just Slack, Gmail, Calendar, Notion, Linear, Obsidian. By having these plugins, you can really just give your AI the ability to reach out into the world and read more information. Once you do this, I just want you to try out a very simple prompt, right? Triage what's changed around my projects. Bring me the important things. And you're really going to be surprised at how much these newer models can just figure out what you do for work and how you can become more productive and what's important. Once you trust a plug-in's work, you can start also thinking about your own plugins. So, I work on the developer experience team. A lot of the time I'm also just dealing with all of the messiness of the feedback on Slack and on Twitter. And so, I built out some skills that just do delegation and triage. It knows given some feature, who's worked on it, and what Slack shall I need to share this in, right? And I can invest in this for myself and then share this with the team. And you can kind of become the plug-in hero, right? You you build these automations and you can scale not only yourself but the entire organization. But sometimes, you know, the context doesn't really come in by asking codeex to read Slack and figure out what I just saw or read Twitter. There's this really cool feature called appshots it. It's one of my favorite features of all time. All you have to do is press both command keys beside the space bar, right? It's just like and it'll take a screenshot of the application plus all the context and the accessibility tree. And then half my conversation with codeex is just I take a snapshot of something I'm have a conversation on Slack and I just go like answer this question reply back also make a poll request if it's important and turn this into a skill. I've actually invested so much in my triaging skills that usually I just feel like a manager now. I take an appshot I send the question mark and the AI has to figure out oh someone asked for like credits from Twitter based on some outage and let me go handle this. Right? So if you just do anything today, you try try an appshot workflow, right? Maybe you're reading some feedback on Twitter and Slack. You take an appshot. Codeex will then trigger some kind of triaging skills or some comm skills to communicate between the internal Slack versus the external Twitter. And then you can just pin that thread. Okay, this is some outage or this is some rate limit issue that people are facing on Twitter. Let's figure out how we can manage this. And you can pin this and work with it over time. And that's brings us to part two, working on the work. So now basically my sidebar is just every single project I manage. There's a chief of staff thread that just wakes up every once in a while. I have a single thread that runs all the documentation for OpenAI, one for this these slides. I do I maintain the open source community and also I just have a thread to monitor X feedback. And if you wanted to do something like keep an eye on it every 30 minutes, you just ask it to. And just by doing that, it will just wake up every 30 minutes, check for any updates, and update the context that's around you. You can do this to babysit a poll request, right? You can just say, make sure the tests are green, check every hour, address all the feedback. If CI is broken, fix it, and make sure it's always mergeable into main. And they'll do that, right? I also do things like coordinating support. Uh check that someone on Slack has answered a question. If you can answer the question, then report back on Twitter. And then also my chief of staff threat that just wakes up every 30 minutes. Uh I don't pay for my tokens. I do 30 minutes. If you are using your pro plans like doing it like twice a day is very very productive. But not only can you run these automations on your computer, you don't have to be glued to your computer, right? These are where this is where features like remote control really come in. So remote control is the ability to view every local and remote thread on your computer in the cloud from your phone. And so a lot of the work now can be done like at a park or riding a bike. It's actually pretty convenient. Last week I was working on a launch video, right? This is not like a codebase. This is a launch video. Someone giving me some feedback. And so I pulled out my phone and I told my computer to go find the video, make some changes in iMovie, share the video on Slack, and just monitor that Slack thread and say, "Okay, every 30 minutes if someone says the wording is off or the timing is weird, try to fix it and send a revision." And when I got back home to work on this video, there was no more feedback to execute on. But threads really just work across a single workstream. One of the big things I really also recommend is just setting up like a memory base, right? Like I just use an Obsidian vault. It generally looks like this. I have a people's directory. I have a projects directory and some agent notes. And if you scan this QR code, you're going to get a template of how I set up my my system. And so you can just pull this repo. Tel code as I set it up for you and it'll install all the skills that I use and introduce the same structures that I really recommend. And then lastly, you can sort of choose the forms that you want to interact over. For example, the same plugins that can read context, right? Uh you can read an email, it can also draft things. I I don't know if people here really trust AI to send emails and Slack messages on your behalf. But generally, most of my automations now also will prepare drafts. So every email that I ever has when I review it, there's already a draft. Every Slack message where someone's asking me a question, I already have a draft set up there. You can also do a lot of progress, make a lot of progress with artifacts. You can make PDFs and slides and Excels and documents and they all open within the Codex app and that way you can just annotate and give feedback directly in the application. And then recently we've launched a sites feature. So now you can just like byput your little applications. You have login with chatbt and you can connect your databases and you can effectively have applications that you share across the org. And so more and more instead of sharing a Google doc, I might actually just share a website with a database to communicate with the rest of my team and track the progress of some kind of work, right? Maybe it's launch readiness or maybe it's some kind of migration. And if there's no integration, if there's no plugin to do something, this is where things like computer use comes in, right? Codeex has a very powerful browser built off the same technology we built Atlas with. And so you can do a lot with things on the Chrome extension side, right? You can have uh authentication. You can have multiple tabs running in the background. And if it's a native app, then you can use just general computer use, right? With computer use, it doesn't take over your screen. it still uses the accessibility tree and allows you to control your computer in the background. And so oftent times I'll just be doing work and I'll switch it to a tab or I'll switch to some other application and I realize that Codex is just doing what it needs to do to get the job done. And these things are also incredibly powerful. Uh in the past week I've had Codex do a bunch of really fun things. It's gotten me refunds on a plane ticket, right? It just checks the customer support channel every five minutes and it's it just wants me to get my money back. Uh, every time I see a really long form, I just hit an appshot and I say, "Fill out this form for me." You know, recently I had, and I don't recommend this at all, but recently I had Codex use docuign and sign a document and then send a fax message to my doctor. And I was like, "Oh, I need to send a fax message. This is like, you know, faxpdf.com. I just need your attention to put in the credit card information and then we can go forward from that." So, a lot of these things are automated now. Really fun. You can also use this to test native applications, right? Most of the time when I'm working on the Codex app, I just spin up another version of the Codex app and the main codeex is just testing the future it's building and I can watch it do this automation or I can just go and do something else and you know ride a bike. And recently, I didn't know this until maybe like you know two days ago, it somehow can also control the iPhone through screen mirroring. I don't know what you can do with that just yet, but I think it's a very cool experience to not only be able to control your computer, but effectively control your iPhone just through technology like through screen mirroring. But then you might ask, okay, well, can can computer use control codecs? And the answer is that you don't really have to because like I said before, these codeex threads can already talk to each other, right? Which means you already have managers. So in the earlier example where I say maybe someone is giving me model feedback or or on Twitter or on Slack, I might take a screenshot, take a appshot, I might have the agent gather some context, triage of the right engineer, figure out how to communicate this outage and then I might pin the thread, right? But this still requires me taking the appshot or taking having the agency to take some kind of action. But because threads can now talk to each other, you can really change the way you do your work. Now I have a single monitor thread and that thread wakes up every hour and it just using computer use or using the CLI reads all of Slack and all of Twitter and then it will try to figure out what are the big issues uh that we have. Then instead of doing the triage in the coms itself, it'll make a new thread. It'll rename it. It'll pin it. And then that thread's job is to figure out how to triage. that jobs that thread's job is how to do communications and then that thread is the one that does this automation and maybe in a in a day from now maybe someone else also has some feedback about this issue. the main agent can say, "Okay, this is still an ongoing issue. It doesn't seem like anyone's addressed this. Let me send a message to this thread about the like rate limit outage, right?" And that thread might decide to post a message on Slack or ask a question or maybe read the docs or just see if any pull requests are pending review. And these are the kind of really cool things that you can do once you understand these basic concepts around pinning these threads, enabling heartbeats and computer use, and then just allowing these agents to talk to each other. Right. So I really hope that in this quick session I've really convinced you that the the nature of work has changed. Compaction works. Right. Generally speaking, I feel like we're pretty close to things like continual learning by just having a memory base and a pinned thread. And by taking actions using plugins and computer use and making sure you write things down in your memory vault, you can get a lot of results in terms of how you can improve your productivity. And by just having something like a heartbeat, just by telling codecs, keep an eye on this, you can now run these automations that carry your workstream across uh different sessions. And so I think if you're a busy developer or a manager, an executive, this is a really great way of using codeex not just for coding. you know, if you want to keep track of everything in your little uh Obsidian vault, if you want to use a chief of staff thread to manage your daily briefs or your meetings research, or if you just want to use loops to basically automate this work, uh check out the Codex app. Try some of these ideas out. And then today at 2:50 p.m. at track 4, we're going to do a longer like hour-long workshop where we can actually have a longer conversation and deeper conversation about what we actually do. and I can give you guys some feedback on the specifics of how I've been using these kind of automations. And uh lastly, come say hello at the OpenAI booth. We're right in the middle. You can't miss it. It's a lot of fun. And uh that's it. Thank you. And now suddenly your team is on on call rotation to figure out what actually went wrong. Pretty common right now. As per standard engineering response, your gut will tell you to pull the raw prompt from the telemetry logs, pass it to the same model using the same prompt and run it locally to isolate the bug, which we'll all do. And surprisingly, it will work as well. Run it again, it will work again. You'll run it 10 more times, it will be just perfect every time. But now let's talk about that one run which costed you and that will be gone. You can reproduce it and if you can reproduce it, you can debug it. But if you can't debug it, you can't promise it won't happen to your next customer or user. Right now I am Tisha. I have Sushin with me as my co-presenter. We both run agents against real production backends. You know the kind of place where a bad right isn't. Oh well, done it again. It's you on a call with a customer explaining where the data actually went. This whole talk is going to be about that one thing you lose the second an agent goes hey buy in production which is being able to reproduce it. That will be a northstar for the next 10 minutes to follow. Now let's look at how this actually blows up. We've got an agent hooked to a broker API which is the scenario I'm taking. The user says, "Hey, sell $1,000 of stock." Now comes the interesting part. Instead of doing the math, the agent sells the raw number 1,000 and dumps it straight into the quantity field. Guess what? It sells 1,000 shares instead. Now, at 190 bucks a share, $1,000 in 10 will become how much? $190,000. Disaster, right? And the terrifying part is that the API or my infrared returned a clean 200. Okay. In 30 milliseconds, we got zero exceptions, zero alerts. If you see the trade is completely wrong, but your dashboards are sitting there perfectly green, perfectly flawless. When such a scenario as we last discussed comes up, what's the first thing which you will do to try and fix this? The reflex here is to, you know, just turn the model temperature down to absolute zero. Assuming greedy decoding will make everything deterministic, right? But that's a complete misconception. Setting the temperature to zero doesn't fix a broken reasoning path. It just means the model is going to make the exact same logical error the exact same way at the exact same time. And honestly, even worse than that, to back up the scenario we just discussed, look at the engineering threads on Reddit and Hacker News. The hard data shows that temperature zero isn't even truly deterministic on a hardware level. Running the same procedes can still return dozens of completely different responses just due to the underlying GPU non-determinism and the MO architectures which are there. So to understand why this actually happens, we'll have to look at it from first principles. It comes down to four simple things. One, sampling determinism isn't system determinism. Temperature zero just means always take the AG max, but it doesn't guarantee that the underlying scores stay identical run to run. Two, floating point math isn't associative. The order you add your decimal matters, right? But a tiny shift in matrix operation alters the final logic and which in turn will flip the winning token. Three, it's not a concurrency issue. Run the same matrix multiplication alone on the GPU a thousand times and I'll guarantee you'll get this exact same bits. So the real cult is batch invariance here because a request gets grouped with whatever else hits the server that millisecond. Four mixture of experts routing has the exact same bottleneck. Experts have strict capacity limits. If a patch overflows a specific sub network tokens get rerouted. Whether the token makes the cut depends entirely on the traffic you got batched with. So the ultimate takeaway here is that chasing text output is a losing battle completely. We don't need the model to return the exact same token back every time. We just need our system to execute the exact same state transition. Which means we've been asking the wrong question all along, right? The wrong question is how do I make the model deterministic? And I've seen teams burning leaks on that and walk away deciding the system's just unknowable. The right question is how do I debug and retest a run I can't reproduce? Because determinism was never the northstar. Debugging was two words we keep mixing up which I'll talk about now is bitwise determinism and replayability. Bitwise determinism is same input, same output. That's controllability. you're not getting it from a hosted API and you don't actually want it because the randomness is what makes the model good. Once the model explores more, you'll get more creative answers. The other one is replayability, which is rebuilt a run that already happened well enough to debug it. That's observability. You don't need the model deterministic. You need the run recorded and you don't freeze the model. You capture what it did. Now the question which we are all thinking about is where do you record? For sure not at the network layer because half your agent will never touch the network. The local retrieval, the inprocess tools, the memory and the parts that do not shred under streaming and async. record at the boundary instead because you need to capture what enters each node and what leaves it the meaning of each step and not the packets. What replay adds here is a deterministic CI where you stop the model you'll rerun the exact failure offline with zero model calls. Let's talk about the loop end to end. Now it starts with annotation, recording, visualization, understanding, fixing, then the part we working on which is replaying and finally verifying. All right, let's now see how to bring the workflow we just discussed into action. >> So we've established that replayability is a core tenant of productionizing any AI agent. But how do we build this in code? As a proof of concept for this, what we have done is we have built something called Chronicle. At the heart of Chronicle lies the concept of a boundary. Think of a boundary as a bounding box around any node in your agentic workflow. A node can be a tool call. It can be a call to an LLM or a retrieval from a rack. It doesn't matter as long as it's a method. It can be annotated with the boundary annotation. Now what does this annotation do? It ensures that anything that goes into the method and comes out of the method gets recorded. So any input and output pair will get recorded. On top of that, you can define parameters like your model version or the version of the code that is running so that the entire state during which the agent run happened gets frozen and saved as a trace. Now let's see this in action. We've been talking about this stock selling agent which went haywire in production. This is a representation of the same. You have your initial planning step which takes into account the user input. It can use the place order tool to do the actual selling and buying of the stocks and then finally it delegates to the final Uh hi everyone. Hey what's up? I'm Theresa. Uh and today I will be talking about software factory. Uh everyone is talking about software factory but only few people are actually building one and even fewer people know what it actually takes to build one and how to define it. So I will be talking about what is a software refactory? Should I build your own or outsource it? What works in production already? What are the main challenges and how much is this all going to cost? Uh my name is Theresa. I work at a company called factory.com. And we've been building uh this concept of the software factory for quite a long time. But finally uh the technology is catching up and it's possible to build this in production for enterprises like EY or Adobe. uh I would define the software factory as the whole loop the whole life cycle of developing software with autonomy which doesn't mean just coding and generating code by that I mean collecting all the signals reacting to user feedback to logs prioritizing what's important then orchestrating it all executing validating doing really good uh testing in production and then iterating on all this uh while also continuously improving in the process and gaining new knowledge and new skills. So this is just our dashboard how our software factory looks if you if you look at it and it's catching the whole cycle there. Uh this is just some history and by history I mean 2023 in AI. So the software factory wasn't really possible before even though we always had this idea from the beginning of CH GPT lounge and others we had this idea of the continuous loop there was autog baby agi already with the concepts of iterating on the software but it didn't work before because the LMS were hallucinating there was problem with context length uh problem with the reasoning quality uh different problems like this or we were missing good environments where the agents can actually work in the isolation. So all this kind of led to why the software factory is the paradigm that's starting to be popular now and actually useful. I like to define things by what they are not. So I want to say software factory is not just coding agent and it's not even a swarm of coding agents even thousands of agents because generating code writing code that's the easy part compared to all the others. Uh engineers don't even spend most of the time uh just writing code the challenges are the rest of it. uh so this is what I want to enhance and it's also not just some consultancy or just some abstract strategy that someone will try to sell you and to your organization uh I think the approaches are of course different but we believe you should really rebuild your organization from ground up to be ready to become a software factory like you can't invite a consultancy and just throw something in the middle of your organization you should really be mindful and rebuild build it from scratch. Uh this is the approach I like uh showing to building the software factory and I think it's similar to building the real team of humans because there is a lot of agents as I said they will be testing validating iterating and it all can end up as a big chaos. Uh so you need to be mindful and I would say the three important things is being agnostic in the software factory. So being independent of LLM choices uh of how you already work as the organization then you need to be autonomous. So you need to give the agents the right trusts and all this permissions and governance and you need to trust it to run really for a long time because the predictions are that agents will run even a year or more years without the human in the loop. Of course that sounds ambitious but for example our missions already our long runninging sessions already build uh things and run for weeks. So it's not that crazy. And third thing, always improving. So same as human organization, you need to onboard any new people in your team by giving them good uh code base, understanding, good structure, documentation and also let them improve in the process and gain new knowledge and share it share it within the team. So these are the three points and now let's talk about the agnostic one. Uh I think the important thing to point out if you are a builder and building different primitives of the software factory you need to be ready for how everyone is already working you need to work across environments like slack, github and connected to everything and you need to also allow people to already bring subscriptions they are using because there is every every time there is like new technology new frontier models uh new benchmarks and it's so difficult to catch up but also to predict what we'll be winning. So it's best to be agnostic for everyone. Uh then there's the topic of being agnostic to models. Uh this is a topic of a lot of discussions recently and this chart is from this chart is from CEO of Coinbase uh who tweeted about how they started uh started saving money in their organ or organization on AI but without reducing the token spend. So the black line is how much they spent on tokens. They continue growing and token maxing but they stopped spending so much money. Uh how they did it uh different tricks like different default default models for people. So stop pushing people to use only the frontier as a default. Then caching of course uh to stop prefilling the stuff every time. And then no limits on spending but just needing to see the results if you spend a lot. And the last thing that's really important topic is routing. So smart routing between LLMs and just a token optimizing between uh the LMS instead of just spending so much tokens. Uh we built uh a thing in factory called uh automatic model routing and there's been a lot of questions around it but what it does is it automatically routes between different models in your process. The important thing is it decides first what model is most optimal and then uh it can switch to different model if it's failing the task or in case of any troubles but it usually doesn't happen and important thing is it doesn't just help uh save money. It also helps with reliability or with speed because open source models are often faster and uh if one LM provider fails you can just switch to another one automatically. So it really does more things than just saving the money. This uh is our benchmark which is very conservative. I prefer conservative benchmarks but I think the direction is clear. You can save for example 25% but even more probably uh how the routing works. Uh there are four parts. First you just assign the task and you don't really need to do anything but as an organization you can for example give different permissions and different default models to different people which is very useful like marketing or sales or engineers can both uh have different default models and then you have the classification which is the important part. This is the magic of the routing. You need to really uh look at the structure of the prompt of the uh code base of how difficult the task is, what tools are being used, all these factors and make a classification of difficulty of the task. Uh after that you basically do a threshold of what is enough to accomplish the task and you choose the cheapest model above the threshold. So cheapest model that is predicted to accomplish your task and then you go. Okay. So when we launched this we got a lot of questions like does it actually work? What if uh the model miss out? Uh is it slower? Is it more expensive actually? What if the model can't accomplish the task or what if it needs to upgrade? And how do we handle caching? So I think these are all valid questions and that's why it's so difficult to build a good router like you need to basically classify it very well and the challenge is to not not to need to switch too often but even if you're switching in the middle of the task to difficult to more difficult model you still overall are faster probably because it's still worth uh this is just some overview of caching uh lot of questions we got on this was also So how do we handle caching? Do we do discounts for users? Uh because LLM LLM labs of course save a lot of money by caching and skipping all the context prefill all the time. Uh open models can do this as well. I think people sometimes forget this and you can just host open models as well uh on dedicated compute and you can take the same advantage of the caching. Uh so I want to enhance uh the final price for users is just a pricing decision. It's not a technical challenge because everyone can do caching. It's just what price you pass on the users and what deals you make with the API providers. So this is uh being agnostic and now the autonomy which is the core of the software factory. Uh everyone is talking about loops. uh loops I think have been here the whole time already in different context. They are just now leveling up and moving to the context of agents. You probably heard about dal loop and specifying the tasks and splitting to subtasks for agents. Uh this is a known concept and uh the question is not the loop itself but the question is how how you define what it means to be done in the loop. This is one example from my colleague. Uh he he made a loop uh of agents building a 3D printing of our logo. Uh I think here you can see what is the challenge of the loops because before in programming loops had clear criteria of what it means to be done while now the criteria become open-ended because a lot of the tasks are very nondeterministic. It's basically open world. can do even real stuff like printing something and it's really difficult to define how do you verify that the loop was done that the task was accomplished so that's the difficult part uh yeah they just need to be verifiable this I call the scary chart it basically shows that the tasks and how long they run autonomously with agents have been increasing but still it's not that reliable even if you can run for a very long time it doesn't mean that it will be reliable in production and you still probably need to need to iterate on it and uh provide feedback. So it's still not solved and there are problems like cheating. For example, if you write the what it means to be done in the wrong way, the agent can try to pass your test but not really like not really verify what you need to do and accomplish but instead try to solve just passing your test. So cheating by that. uh we have something called factory missions and this is like long longunning sessions of the agents. We just call it missions because we send the agent to the mission and uh the missions work in the loop and iterating on task until it's done and they can do it even for weeks and uh the main agent is orchestrator and then it's uh assigns work to workers agents and then to validators who review the task. So this is one example uh real mission from our customers that run 16 hours and just just to see how important is the validation as well. It takes even 40% of the whole process. Uh to summarize the orchestrator just decides and writes the conditions what it needs to be done. Then it gives it to the agents called workers. The agents work on it. And what is interesting or worth noting is that they work in a sequence. So they don't work in a swarm or parallel. The agents work in sequence and everyone accomplishes something and passes it to the next one. Uh we actually found that if you do this, you end up with more fresh context and kind of fresh head. Same with when with humans have like other colleagues verifying their code. So similar thing we just let the agents pass to the next one. But still every worker of the sequence can have parallel agents doing smaller tasks. So I don't know researching on the web or building files during that. So they are in sequence and everyone has sub agents as well and validators they review the output and provide feedback and send it back to the beginning. Uh important thing is uh the validators judge code that they didn't write. Uh there is something from the orchestrator agent called validation contract. Uh that's written before any code is done. And first type is scrutiny validator. Second is user testing validator. The scrutiny is the one who really verifies how the codebase looks, the interest, types, tests. It's really rigorous check of the code. But the second I think is really interesting is user testing validator and that's the one who is really in the arena trying the things. So it doesn't care how it was made. It just goes, it works in its virtual computer and it clicks on the stuff and really checks if everything works. I've seen one engineer migrating uh code bases with droid with our agent and uh it really needed the agent in the end to click through the stuff because with other products it just created created the product but it didn't work and was wasn't interactive. It was just a dummy result. So our agent that really clicked on the stuff uh allowed to check that it's actually working and not just looking good in the code. I think this is one cool thing that was also allowed by the progress in computer use and the persistent environments virtual machines for agents which also wasn't here before or wasn't that great but now it's really great. So it's allowing to go in the arena as an agent. Uh this is just one example of real mission from our users. I I like to just learn what users are building and get feedback. And this is just uh how it can look in your dashboard. And this is how I visualize the missions. What is interesting is that it's just a loop with smaller loops because every of the agents are running in loops as well. But overall, it's like one big loop. Okay, maybe this is a bit weird, but I just like that it's all loops with smaller loops. Uh okay. And the third part always improving, always learning. Uh there is this elephant in the room context with agents. A lot of questions which are valid are like how do you navigate the context blo because you work on these long missions in the software factory and how do you actually keep the context clean and that's very valid because enterprises especially they use hundreds tools. They use Figma, notion, Gmail, drive, Slack like hundreds tools on average. So all these have specification in the code. All these have schema and parameters and log descriptions. So uh it can cause agent to really bloat with that and pick wrong tools if there are two tools that sound similar or to actually lose context because they fill up the the context window and need to compress. So this is really dangerous. Uh for this we have something within the software factory called uh deferred context engine and we build it such that we just progressively disclose what's in the context and what tools to use. So we basically have a surprise tools uh that help later only if they are actually needed. So it first just has short list of the tools and uh only a short descriptions and when it's needed actually in the code uh they can call the tool and fully load it. So important thing is nothing is actually removed it's just hidden and not reachable until needed. So it's just for later and important thing is it actually saves a lot of tokens uh at scale once you use more and more tools. uh the more actually you save it really scales and you can save 50% of tokens or more. Okay. Uh another thing which is tricky and was surprising for me for the first time is that when adopting AI you either succeed big or you can fail big the same way. It's a bit of power law. So if your codebase is not ready, if you don't have structured codebase and all important things, then adopting or turning into software factory can actually make you end up worse and make your code degrading and uh there is a big and growing gap in productivity between those who just adopted AI versus those who actually thought about it a bit more. And there is another data from Stanford about yeah without structured uh code base and being ready and documenting well the AI can make your code worse. And I think if you are engineers you probably can agree that sometimes AI really makes a mess and this can really compound more and more and it's difficult to go back. Uh we have something as a part of the software factory uh we have something called agent readiness and it's a framework. I don't like the word framework, but take it as a hygiene check of your codebase and things you should do because there is actually a nice correlation between how your codebase is looking and all the details there and how good you're going to adopt the AI and end up productive instead of uh with a messy code base. So there are things like how how reproducible is your developer environment or if you have written good tests if you have all things well documented. what's the style of your code? All the te tests and llinters uh everything that you would do also to keep code base clean. So these factors actually show to be very useful and we have our bigger customers actually go through this agent readiness framework and do all checks and then they can follow up with recommended actions uh how to fix that. Uh I think one more thing about the context and the continuous learning in the software factory is the most of the time when working with AI or at least from my experience is that you keep repeating to agents how how do you want the things done and you feel like the agent doesn't really get you and I think this is again nice parallel with human organizations and teams because when you join a new company there are a lot of rules that are not really codified anywhere like you just learn and observe how things are done and there are a lot of things between the lines that you can't really learn anywhere else than just observing. I think this is big challenge for agents as well and one thing we launched for that is plugins which are like packaged reusable skills and context and the things behind the scenes that you can really codify or autok which is automatically updating our documentations and uh yeah and um reviewing and documenting what you have. So the question is what will happen to us humans if we build software factory like this? uh will humans just lose jobs and go to permanent underclass? I think they will not. And uh I want to be positive. So I'm thinking of this parallel of humans just moving up uh levels up to the uh to the cooler tasks than before. I think we actually had before the same same experience of us as humans abstracting some levels up and we actually started ourselves as human computers. We actually were the computers doing all the most detailed stuff at the beginning. Then we had programming languages, codifying some of it, abstracting and then coding agents. So outsourcing some of it but uh still being in the loop very closely uh and very monitoring everything. And now we are moving kind of up to software factories where we manage these agents as I said orchestrator agents and workers and validators and all these teams structured teams of agents that work really continuously in the loop and we just monitor and decide what to build. Uh so I want to really end this positively. We should be as humans deciding what to build in the software not how to build it. uh because that's up for the agents and by this uh continuous cycle of autonomous software I think we can actually achieve that. Uh this is one warning chart or if someone thinks AI will take the cool cool stuff from us. I believe actually it will take the annoying stuff and in enterprises and organizations you already spend a lot on alignments on the meetings as I mentioned basically the thing behind between the lines that you really need you need to get context from everyone share your status sing on the things on meetings so all these things could be actually outsourced to your software factory and you could be just talking about the cool stuff okay so this is it thank you so much go touch some grass and let your agents uh built for you. Thank you. Okay. Hey everyone, I am Kushan. Uh I worked at as a founding engineer for 2 years. Let's talk about what I'm interested in right now and that is browser agents. Browser agents as an idea are so cool, right? But browser agents should go crazy, right? I personally have not seen that at auction and me myself, I don't use browser agents that much. I've been exploring that for some time. Been trying to understand why that is. So on my screen right now, we have the browser challenge. But uh this is a very interesting benchmark for browser agents because there are so many things that you have to do long ring sequencing of your tasks and this actually reveals you know why browser agents suck. If you saw at the beginning of the video, uh the browser, this agent took like maybe 10 20 seconds just to click the start button. And now we're on step one. There are 30 steps and it has taken so long just to click one button. Um so enough of this. I want to show you what I've been building. So same website. Um I've tried to sort of replicate the feeling of seeing what's happening. You know, you can see what the browser agent is thinking. But as you can see, it is so much faster and so much quicker and I'm using a much cheaper model. Right? The hypothesis here is models are pretty smart, but it's the infra around them that sucks. If you noticed in the video earlier, maybe I'll put a screenshot. The agent is trying to debug what's going on. It's trying to click something, but it doesn't understand what's going on. So my core thesis here has been give a nice environment for the agent to use, right? So where it can plan long sequences, it can figure out where it failed, what is going on, and it can plan the click correctly. I figured out is a cool representation which compresses the website and lets the agent see the entire page in very few few tokens. Now I wanted to show some actual uh examples. Let's say I want to download my Aadhaar. Um, so this is claw trying to do it. So I'd assume that this is very simple for our browser agent. I take a screenshot. You see the button right there? Click it. Uh, but then what's interesting is that it got stuck after this point. So from 46 seconds until the end of this video, it took a screenshot. It scrolled for some reason. It took a screenshot. Basically this entire process took 2 minutes. Whereas in my case, in our video, so it just boots and boom, done. And that's the beauty of a browser agent. Just how quick was that? And I'm using such a cheap model for this. Another interesting example is so my friends and I are going trekking on uh on Sunday. I was wondering, you know what? Because this this site is in Canada and I am not very fluent in Canada, like it took me some time to figure out this website. So I asked Claude like, "Hey, can you book this for me?" And by the end of it, it's unable to pick a date and it's just stuck. This is the video of my agent. So you can see it selects it and puts in the date and boom, done. Right? It's so simple and convenient to use in theory. So what's next? Right? What am I planning on doing? Thinking of open sourcing this project because again my this code is not super defensible. The product that I want to give is again maybe an an API that as you can see we were running these commands. Maybe I just want to expose this command as an API. Give me a URL. Give me your intent and I will execute it for you and give it back to you and or maybe open this as a website or expose this as a plug-in. But yeah, so bottom line is I want to make browser agents faster, cheaper, and more reliable. And just make sure everybody in the world is using them because they can just do so much for you. So yeah, that's the broad idea here. Thank you for watching. This entire markdown presents the website that particular page. And let's actually do this interesting comparison, right? Let's go to AIS2. The full DOM for this would be around 20,000 tokens. But so let's say we have this screenshot, right? This screenshot is about 1,100 tokens. My Macd about 1,800 tokens. And instead in one screen where you can see only one particular snippet, you can see the entire website, right? A couple of other things that it's important to give feedback, right? So we say that okay, hey, these are the new things that have popped up on the page. This is now gone, right? And similarly, we can say that you know this thing that was blocking a thing that you wanted to click has now been removed. you know we give it feedback that you tried to click this but that didn't happen because you know we're keeping track of the entire end to end browser page right so all of this together what I've built is a very clean representation that that basically compresses the website and you can give this along with the screenshots pretty cheap token wise um so the model can reason well and then it can construct this long sequence of tasks to execute >> hi everybody welcome to our talk the agentic AI engineer I'm CEO and co-founder of Mutagent and I'm here with my colleague. >> Hi, I'm Burak. I'm the CTO of Mutagent and today we're basically going to talk about loops and how the agentic AI engineer works. So as you all are aware of now loops is the hot topic how you build software in an agentic loop and uh we apply the same loop to the building of AI agents and as you're all aware there's uh two concepts here one is the offline loop where while you build you iterate um on your agent you test it you evaluate it you improve it and you go on and then you have a second loop which is we call the online loop where once your agent is deployed to production, you monitor its traces, you diagnosis and then you feed it back into your optimization loop. Uh yeah, to iterate and have multiple versions of your agents. Yeah, up to until now um what we did was uh this doing this loop manually it's quite slow. Um the life cycle is basically um you have an issue. Um you want to change something to your agent. Um yeah, you implement the change. Um you maybe VIP implement the change if you use coding agents for it. Um yeah, you generate some samples for this new feature or issue to test it. Um yeah, then you look at the result. You look through the traces. How does the outcome look like? Then you maybe ship it. You do AB testing. And all your feedback is kind of manually. it takes very long. Um yeah and uh the the bottleneck basically becomes the human uh review and the human yeah building time and uh yeah that you can't scale especially if in your organization you're now planning to roll out hundreds of agents uh etc. Yeah. And uh yeah, this is why we think the agentic AI engineer is the natural next step to build agents. And I'll have Burak deep dive into how we improve timing and the the road to production reliability with the agentic engineer. Uh so yeah the key thing here is basically once you reach a certain number of agents or AI based features the human performing this loop again cannot really scale in enough time. So this is why doing this agentically is the key to increasing the throughput because then you can fit many more cycles into the same time window. And now how that loop works is basically we have a few stages. So this is when you are starting from scratch like the current software development practices. You first create a spec for your agent or your skill in this case. And here you need to define all the responsibilities and the functions that agents needs to handle the decisions that it has to make on certain conditions. And here again this is only the definition stage once you defined your agents requirements. Hello I was at a wedding this weekend and it was in New York and there were a bunch of trendy people there and uh I I told I was talking to someone who I'd never met before and uh I told him I was prepping for this presentation and he was like, "Oh, that's cool. Like what's the conference about?" And I said it was about AI engineering. And I could just see his eyes glaze over and he started like looking behind me to find the next person to talk to. And I'm it's like so cool to actually be in a room full of people who actually want to hear about this stuff. So I I'm very excited to be here. Um I am the co-founder of Conductor. Um has anyone here used Conductor? Okay. Nice. Nice. Okay. Cool. So uh uh for those who don't know, Conductor is a desktop app for managing a team of coding agents all at the same time. So instead of having a bunch of terminal windows for your cloud codes or your codeexes or your uh whatever uh coding agent, you have one interface to manage them all. And one of the really cool things about building conductor has been that I've seen a lot of the best builders up close. I've like watched their workflow. I've seen how they work. I've seen the things they do do and the things that they avoid doing. And so I thought I would compile a bunch of the principles um that I've seen the best engineers use um and give them to you all. Um so here's what conductor looks like. Uh can you can you guys see this? Okay, nice. Okay, so here's what conductor looks like. Um and here are my principles for being the fastest builder in your organization. So let's start with number one. Stay near the frontier. Staying near the frontier means you are always trying the latest things basically the day they come out. Uh it means that when uh Ultra Code comes out you're trying it. It means that when uh uh slashgo comes out you're giving it a go. Um it's really important to stay near the frontier um for a few reasons. Um if you are doing your own startup then staying near the frontier means that you will um come up with lots of new ideas for what you should actually be building. And this literally happened to us. We were building a totally different app called Chorus. Um, but we started using we were such power users of cloud code back in February of last year that we uh started building our whole workflow around cloud code and we started cloning our repo five times and then we discovered work trees and then bit by bit we had built conductor as an internal tool and we couldn't have figured that out if we uh weren't staying near the frontier. And if you're not doing a startup, you should be the person at your company who always knows what the latest uh the latest workflows are. Um it used to be that you could just kind of like use your social graph and the information that was important about the best workflows to use would trickle down to you, but things just like move way too fast now. You're you're always going to be three to six months behind if you do that. Um so it's a very important to stay near the frontier. And there's an important word here near. Um there is a danger if you are at the frontier. Um you can you can do what uh I call midwip memeing where you're spending all of your time working on your workflow and not doing actual work. And so internally we've come up with a heristic for this. Um we call it don't beat the market. Don't try and beat the market. Um uh the concept here like the heruristic you should use when you're trying to decide if you're near the frontier or at the frontier and uh too deep in into uh uh the latest trends is you should ask yourself why isn't this workflow the default. So, for example, um when uh Ralph loops were becoming a big thing, uh uh you should ask yourself like should I spend a ton of time optimizing my workflow to work with Ralph loops? Um because if Ralph loops work for everyone, like if they are the default, um then you probably should just wait for Anthropic or OpenAI or whatever to build the uh workflow into the into the default harness. Um, you could think of this as sort of like an efficient market hypothesis where um, unless you have like real alpha, uh, you shouldn't be optimizing your workflow too much. Um, and what I mean by real alpha is like some kind of information about either your users or your codebase that the models might not know about. So an example for us is we it's we we're a chat app. we have to render really long chats really quickly and performance is is important to us and so we need to spend a lot of time optimizing our React queries uh to uh render the chats quickly and we're willing to make sacrifices um in other parts of our codebase to make that happen. Um so if you have some kind of alpha like some kind of information about the app you're building that the models might not know about then you should put time into the workflow. Otherwise don't don't midweet meme. Don't don't be the person who has an amazing Emac setup but like doesn't actually get stuff done. Okay. Three, create slot free zones. So at Conductor, we have this term we call a slot-free zone. And a slot-free zone is a part of the codebase or a part of the app that requires really strict human review. Um, and we're actually I think a little bit unusual in this way. I think a lot of people assume that we are pure token maxers and we are like ripping through like 30,000 line PRs, but we're actually not. We're actually quite careful with certain parts of our codebase and then very loose with other parts of our codebase. Um, the reason this is important is because if you are not careful about your slot free zones, your your code your codebase can get in a really tricky spot. Um, and this actually happened to us. We we've had to rewrite our whole app like a couple of times because we weren't careful about slot freezones. Um specifically we have a uh migrations file and uh in our CI uh any change to the migrations file requires the a uh a human to review it. Um we also assume that anything written in Slack is slop free. It's it's not written by the AI, it's written by a human. all of our docs, um, all our cloud MDs, like all our skills, we put a ton of time into making them good. Um, and this is also something I've seen with all the the the best builders up close, like they put an unusual amount of time into the cloud MD or their skill files. Um, and I I think like another way that I've thought about this is like if you had a a new intern that was joining your company and you had the opportunity to like whisper something in their ear every time they started working, like every day, anytime they sat down, you could like whisper something in their ear, you would probably put a lot of thought into like what it is that you're whispering in their ear. And this is what the cloud MD or agents uh MD is. It's like information that gets loaded into the agents context every time they start working. Um, and so you probably want to put a lot of thought into uh into those. Um, okay. Four, feed the beast. Uh, at Conductor, we have a uh internal tool we call the conductor internal agent. Um, and it is uh we also also known as the CIA. And the CIA is basically like the the uh centralized database of everything that's happening in the organization. So anytime a new Slack message gets sent, the CIA picks it up. The CIA agent will see that a new message sent in Slack. It will pick it up and it will save it to a Postgress uh uh table. Anytime a user has a bug request in Discord, the same thing happens. Anytime we have a meeting, we are recording it uh and it goes into the CIA. Um, we call this feed the beast because you you want to for your agents to be effective uh in your company, you want them to have as much information and as much context as they can have about the way you guys specifically work. And the best way to do that is by having a centralized place for all the information to go. Uh, I think this this tweet sums it up pretty well. uh uh it's really effective to just put everything in a database and then give your agent a SQL tool and let it handle uh uh handle the rest. Okay, next is free range agents. Give your agents a lot of space to play. Give them give them a sandbox where they that won't get killed, where they can explore your codebase, where they can work on really hard tasks, where they can they know that they're not going to get shut down when you close your laptop lid. Uh give them give them opportunities to create more of themselves. Um give them ways uh to collaborate with other agents and other humans. Um, I think what's really interesting about freerange agents and like this this concept and why this is important is the models are getting better and they are able to run for much longer and they're going to be many more of them. And so if they are confined to your laptop, then the they're not going to be nearly as effective as uh as if they are free roaming. Um, the other thing that's important here is that once you give them a a sandbox to play in that isn't confined to your laptop, there's a bunch of really cool stuff that you can build on top. Um, and we have built some of those things into Conductor. And I uh I'll give you a quick glimpse into into some of those cool things. So, this is Conductor. I'm going to make it a bit bigger. Um, and this is actually a new version of Conductor that is uh coming out this week and it is centered around collaboration in the cloud. And so the the import the thing I said was you need a spa a sandbox for agents to play. You need a free-range agent. And so you'll notice that each workspace has a little cloud icon at the top and I can click it and get information about the sandbox that the agent is running in. Um, and what's what's awesome about this is I can close my laptop and the agents are going to keep running. Up up up until basically this week, every uh every task in conductor was built on a git work tree, but now they're in a cloud sandbox. They are free range agents. But what's also really cool um that you can that we have built on top of uh cloud is collaboration. So you'll see here I'll make this even bigger. That's me and here are lists of the things that I am working on. And you can see that I'm in the conductor or But if I scroll down, I can see what Kaden's working on. I can see what Lewis is working on. I can see what Tywin is working on. And I can I can I can see that I can see Jackson's face pop up there. I can click in and see what he's working on in real time. Um, and I think collaboration is the the one one of the most important new concepts uh in these tools that no one is really talking about right now. Um, collaboration is important because not only as not only is it true that all great things are built with teams of people, like they're not built by individuals. They're built by teams. Um, but also as the models get better, um, as we've seen this with the two days of Fable, you can get a lot more ambitious with the kinds of things you're building. And if you're getting more ambitious, you're going to need more people and more agents to work on those things. So, I'm going to go into an a workspace that Kaden is working on. uh this one. And I'm gonna say um I can review the changes that he's made. Um I'll make this a little smaller. And this looks fine, but I'm just going to say uh can we actually use tabs spaces? And Cadence should be able to see that message happen in real time. And he can actually chat in the workspace as well. So, we can see here that he's typing. So, I see Ken is typing. Let's see what he says. Seems like he's typing a lot. Okay, maybe he stopped typing. I'll give him a second to take a look at it. So the point is we can now have collaborative workspaces that are shared in real time with people on our team. Um, okay, he's typing again. Okay, come back. The agents have escaped. All right, so uh I'm really excited about this and we're rolling this out to uh all Conductor users this week. Um I think I think collaboration is going to be one of the most important uh one of the most important new interface changes uh this year. Um the other really cool thing about cloud is that um and giving the agents the free range sandbox is that we can give the agents APIs to spawn themselves. So I have here a uh I'll bring up my open claw. Uh this is my open claw called Lord Crandon. And you can see that it has I don't know h how well you can see this text but it has access to a conductor API. And so from my phone or from my telegram or from really or from Slack or wherever I am I can say hi can you create a new workspace for me that makes uh yeah makes all the buttons blue. And so I'll I'll text that to Lord Crandon and Lord Crandon has access to the conductor API and so it can kick off work itself. Um so let's see what it does here. Okay. So it just created the workspace. The agent is on it and then I can go into my conductor whe I'm out and about but it's still setting up the workspace and uh it will do work for me while I am gone. So, I'm pretty excited about all the uh all the cool things you can build on top of of uh freerange agents. Okay, the final principle that I want to talk about today um and the title of this talk is orchestras not factories. The whole like talk track today is about software factories and I honestly kind of hate the term. I think it's the wrong way of thinking about these new tools that are emerging. I think like when I think of a factory, I think of automation and I think of uh like there's a lot of amazing things about automation and like it makes our lives more efficient and we can like create more of everything. But the I don't want the future to be built around factories. I want the future to I want to feel like a human. I want to like be in the flow. I want to be like in front of an orchestra like waving my baton and and like I wave it this way and this this team of agents starts working and then this intermingling of humans and agents starts working as I go here and I when I want to I can zoom in on the details but most of the time I can zoom out and I don't think the future should be we are like managing swarms of agents and we are like factory line managers like pushing buttons getting the agents to like pump out the next feature like we we we tried this like 10 years ago with the term feature uh feature factories and it just doesn't work. Like I want my software to feel human and crafted. Um I want to feel like a human at the center of it all. And I think because we're all building these tools, we actually have a responsibility to make the tools um great for humans. I think it's really important to like use the words that make us feel excited and like feel uh feel capable and feel uh like we're in the flow and having fun. And so I don't think the future is uh is is something like this. I don't want to be I don't want to be in in my dark factory. Um I don't want to be a line manager. I want to feel like this. I want to be in the flow. I want to be having fun. I want to be crafting things. I want to feel like I'm Steve Jobs designing the Mac with a team of amazing humans and AI agents all in the same place. Like I want to feel like I'm in an orchestra. So, here are my principles for uh for being the best builder in your organization. Uh stay near the frontier. Don't try and beat the market. Create slot-free zones. Feed the beast. Free range agents. And think about orchestras, not factories. Came up with this handy acronym for for remembering it. Stickfo. All right. So, thanks thanks a ton for uh for having me. I'll be around. feel free to ask questions and uh I'll see you on the internet. Okay, I want to tell you a story about a factory that taught itself how to remember. Hi, I'm Rushab. I run machine a 100 people factory in India. No data science team, no ML budget, none of that. And somehow we ended up building a 36 AI agent that runs our entire go to market. I think that's still a little ridiculous. Let me show you how it happened and why you can do the same thing. So here's the thing about our company. From the outside, it looks like machines and metal. But the actual company, the part that matters isn't the machines, is the knowledge. who the customer is, what we quoted them in 2019, why that one machine needed that weird custom tweak. And for three generations, all of that lived in exactly three brains. Initially, my grandfather's, then my father's, and now mine, which is a genuinely terrifying way to run a company when you sit with it. A lot of people have joined us. People have left us. The revolving door never stopped. And every single time someone walked out, a chunk of our brain walked out with them. We weren't scared of the competitors. We were scared of forgetting or waking up one day and realizing the whole company only existed inside two increasingly tired heads. So, I had an idea. I'll be honest. Sounded insane first. But what if instead of writing the knowledge down in some document nobody ever reads, what if we grew a brain that just held it? Not a chatbot you poke at, a twin of the company. I didn't hire a sales team. I tried to build one. A quick detour because you need to know how messy this is. We make thermopforming machines. They heat up a plastic sheet and shape it. same core machine, but it ends up making hydroponic farm trays, spa bathtubs, EV car panels, medical casings, and even packaging. Seven totally different worlds, seven totally different buyers. So, this brain couldn't just memorize a brochure. It had to know which universe a given customer lives in. Step one was almost boringly simple. Feed it everything. And I mean everything. Years of courts, drawings, payment schedules, timelines, email threads, hundreds of gigabytes of our own private history. Not the public internet, our internet. And here's the plot twist, the part that surprises every engineer I tell this to. We never trained a model. No GPUs humming in the basement, no fine-tuning. We just looked at all the history, chopped it into bite-sized chunks, and let offshelf models, read it, and pull out the facts. We stored the meaning of each chunk as vectors and relationships. Who's connected to what as a graph? The brain is in a smarter model. It's actually a really, really well organized memory. Now, this is where it gets a little weird in a good way. We stopped thinking of era as a software and started thinking of it as something we were raising. So we gave it a body modeled on biology senses to figure out who it's talking to, a gut to digest the documents into facts, a memory, a dream cycle, an immune system to fight off bad information. Why biology? Well, because evolution already spent a billion years solving, how do you stay coherent over time? We just copied the homework. Okay, so the big question, why 36 agents instead of one genius mega prompt? Because, and you already know this if you've ever tried it, one prompt that's supposed to do everything ends up doing everything badly. So isn't one mind. It's a pantheon. A whole cast of specialists. Each one has exactly one job. Athena runs the room. Prometheus owns the sale. Plutus does pricing. Hippastas knows every machine spec gold. Vera fact checks everything. And Memon, my favorite, guards corrections. So the second a human fixes something, it stays fixed forever. One agent, one job. It's a team, not a hero. And here's the cool part. They hold meetings. Athena pulls in specialists. They actually argue and a single answer comes out the other side. It's like having a boardroom that never sleeps, never gets tired, and somehow has no ego. So, what does all this actually run? Honestly, the whole front business, everything between a stranger exists somewhere and now they're a customer. Nine concrete jobs every single day. Outbound emails that actually reference my real world. Account briefs build from cross-cheed truths before a call. Quotations. A swipe left, swipe right mode for outreach. Reviving dead leads, which I call blast from the blast. Inbound replies and figuring out before we waste an hour whether a company is even a fit. Nine jobs, one operator who never sleeps. Where does all this live? One cursor tab. That's genuinely it. You type and a reaches out with a dozen hands, searches the knowledge base, reads the inbox, drafts the email, builds the code, and then shows you before anything actually goes out. Under the hood is genuinely a real stack, not a demo held together with the tape. databases for vectors for relationship graph for the CRM. Three different model providers each picked for the job it's actually best for tools for Google for swallowing documents for every communication channel plus monitoring so we can see what it's thinking. All of it, every capability exposed as 213 tools over one protocol. And the golden rule, the one we never break, era drafts, human settings. Now, memory, and this is the part where most AI quietly lies to you because a raw language model is basically a goldfish. Brilliant for about 30 seconds and then you close the tab and forgets you ever existed. So we engineered memory on purpose in layers, working memory for the last few minutes, pinned facts about someone who is episodes, whole conversations as little stories, relationships with warmth that grows from stranger to trusted and a bouncer at the door. A salience gate that decides what's even worth remembering so the brain doesn't fill up. achieve without making things up. >> Hey, my name is D. I am one of the co-founders of a company called Grapile. And at Grapile, we are working on AI agents that review and test poll requests with full context of the codebase. The way we do this is when you open a pull request, Gravile reads all the files. It uses a knowledge base of the codebase to understand what could potentially be affected. It also runs your code in a sandbox to find various issues. But I don't want to talk about reptile today. What I want to talk about is something very interesting. So when I first moved to San Francisco 3 years ago was when AI coding had really just started to work. And what we had at the time was copilot with tab complete and later cursor with more advanced tab complete. In 2024 AI agents got a little bit better and we started to see multifile edits. This was with cursor and early versions of cloud code. In 2025 something interesting started to happen which is the agents got increasingly autonomous. And December of 2025 was the turning point for anyone that's working in AI coding or using AI to code. They understand that those models were fundamentally different from the ones that came before and that they were completely autonomous. They could go from ticket to pull request. And from there, Twitter seemed to be full of stories of people experimenting with polyphasic sleep to keep their agents alive and building large amounts of code all at once. And to me, it seemed like this was something that was possible inside the realm of maybe indie hacker projects or startups, but not in the enterprise, which was all of the companies that we were working with. And this notion that I had that truly agentic coding could not take off the enterprise was starting to get challenged because I heard many reports of people doing this stuff in the enterprise and that it was really working. And so I got really curious. Are these fully vibr? Can you do this in a large scale company with real customers? And in what ways did they fail when they did fail? So as an amateur data scientist, I decided to dive into the data and see what came of it. And the first thing I discovered was it's actually very hard to figure out which PRs are fully vibe coded. At Grapal, we work with tens of thousands of teams. And we have this interesting place where we're not the coders, but only the reviewers of the code. But all this code goes through our system at any of these companies. Companies like Nvidia and Coinbase and Scale, real companies with real customers and critical workflows. Identifying which PRs were vibe coded was difficult, but I decided to give it a shot. And the first thing that I tried was I looked for the GitHub author field. Every commit in GitHub has to have a field for the author. And I figured that if the author was attributed to codeex or cloud code, that was pretty strong evidence that that was a fully vi PR. But I found of all the PRs and again more than a million poll requests go through GPU every month. Only about one out of every hundred were attributed to an agent in the author field. Intuitively, this didn't make sense to me. couldn't be that only 1% of all PRs were fully vioded. And so I started looking for PR description fitters. Turns out these agents are as narcissistic as humans are. And they like to leave traces that they were the ones that worked on the code. And so Claude would leave a co-authored by Claude and Codex would leave a co-authored by Codex. And that seemed to help a little bit. The third thing I looked at was branch prefixes. Codex actually names the branches for you. And it seemed to me intuitively that if someone was using codeex to produce the branch names, there was pretty good evidence that most of that PR was vioded. I found that in the month of April, more than a quarter of all PRs that Gretal reviewed had evidence of being, if not fully, at least largely vibecoded. Then I tracked this number back to the previous 12 months and it turns out that the rate of change is incredibly fast. About a year ago, less than a percent of all poll requests had evidence of being fully vibe coded. And in April, that number was more than a quarter and trending upwards. And then became the real question. Are these PRs any good? Are real companies doing this? Are they any good? Can you merge this stuff? Is this just slop or is it real good software? And of course, then the question becomes, what does it mean for a poll request to be good? What does it mean for a vibe coded or a human written poll request to be good? So then I started to do some statistical analysis around PR quality. And the first thing that I looked at was revert rates. GitHub lets you revert pull requests. And it seemed reasonable that if a pull request was reverted, it must have not been very good. And so I started tracking reverts across our entire customer base. Conveniently, GitHub labels reverted branches with revert dash and then the name of the PR. And so I started looking at the rates at which poll requests were being reverted. This is the data that I found with Codeex. about one out of every thousand poll requests seem to be reverted. For Devon, that number was three and a half. And for humans, interestingly, for PRs where there was reasonable evidence that it was written largely by a person or at least owned by a person, that number was around two and a half. These numbers are fairly within range. They're all small, less than a percent. And all kind of within range of each other. So, I started looking at some other pieces of evidence because I was very convinced that these vibe coder PRs aren't good. So, I was really looking for evidence that that was true. So the next thing I looked at was are the river rates different by size because it seemed that it was possible that people were making agents do simpler work. It was the straightforward well- definfined tickets that agents were working on and humans were taking on the more complex tasks and that's why the revert rates were similar. And it seemed like PR size was a good proxy for complexity of a change. But it turns out that revert rates actually stayed relatively stable across different sizes. There wasn't even a real pattern that said that agents were working on smaller or simpler tasks. It turns out revert rates were pretty even across the board for agents and for humans. The next thing I looked at was Graptile comments. If Gretile's the reviewing and testing and validating agent for all of this code, it seemed reasonable that it would find more issues in code that was worse. And Gretile conveniently labels all the issues with P 0, P1's or P2s. And so I started tracking the rates at which Graptile finds P 0, P1's, and P2s across poll requests that are written by people versus ones written entirely by AI. Once again, there just was not that much of a difference between the human written and AI written pull requests. In fact, humans were actually more likely to make P 0 errors than Devon and CEX or claw. Similarly the case with P1's where both Devon and Codex created fewer P1s and P2s were even closer. Once again, there just wasn't that much evidence that the agent written PRs were meaningfully worse or more critically damaged than their human written counterparts. The next thing I looked at with review rounds. A very common pattern for using Reptile is that you have it review a pull request, give it some comments, and then you let the agent fix those comments, make another commit on the pull request, and usually two rounds is enough for all of the issues from the pull request to be addressed and for the pull request to be ready to to be merged. It seemed reasonable that a smarter, more capable author for a poll request would be able to get to a mergeable PR with fewer review rounds. That seemed intuitively true to me. And so I started tracking average number of review rounds. With Devon, a little over two. For people, 2.2. For Codex, two and a half. Once again, entirely within a range. The mean number of iterations it took for an agent or a person to get a pull request to a mergeable state was fairly consistent throughout. Once again, no evidence of agentic PRs being worse. So now that there wasn't any strong evidence that these were quantitatively worse or better, I was interested in seeing if there were patterns of failure that were different in agent written PRs and human written PRs. Were they bad in different ways? And so I started tracking some interesting data around that. Here's how I did it. So Guptile leaves comments on all of these pull requests. It tends to identify all kinds of logic performance and security errors. And so I decided to run a very simple text search and said, "Okay, are types of errors in different agents different for different sites." Now the data set here is quite large. It's in the millions of poll requests. And so this data is reasonably high confidence. And of course, you can't use old data. So I only used about two months of data since prior to that the agents are essentially obsolete. And I saw some very interesting data points. Claude, for instance, is one and a half times more likely than people to produce a SQL injection error. off bypasses are half as likely coming from Devon than from any other agent and for people. And another interesting data point, but N plus1 query errors were much more common in cursor than any other agent. Far more common. And so it was interesting to me that there were this much variation in the qualitative aspects of what these agents were getting wrong when there was so much consistency in how good or bad they were measured in many different ways. So it might turn out that autonomous agents are actually quite good. And this is very exciting to me because to an extent I'd kind of become a programmer before AI had taken off and I was used to like many of us the craft of programming and it seemed like a lot of the vibecoded agents that we were seeing in 2024 and 2025 were a lot more promised and substance especially when applied to professional commercial settings. But the trajectory seems quite clear. These agents are getting really, really good. And they're getting really good at coding not only in general environments. Reptile's customer base is made up much more of larger companies than it is of individual coders. Of course, individual coders don't really review their code or don't need to. And so this sample set is essentially created from companies with real customers. And it turns out that they actually can do a lot of true vibe coding in a commercial setting. So we started thinking about what that means for code review and code validation. If most of the code is going to be written entirely by agents and it seems like the agents are writing pretty good code then what should code review look like? I think a couple things are very clear. Interesting data point that emerged from my statistical analysis is that there was quite a bit of a difference between the 99th percentile of coders and the 50th percentile of coders in terms of how much code they're writing. In fact, the median coder that uses Graptile is writing fewer than 50 commits a month. The 99th percentile is writing close to a thousand commits a month. At that scale, it is completely infeasible, especially if this is going to be the standard for how people code to do anything resembling manual code review. It also seems not very intuitive that we would be maintaining large test suites. As Grubile, we got really excited about this idea that we could build truly autonomous code validation. We started thinking about what that means. And of course, code validation in the prior era was made up of these three general facets. You'd have testing, you'd have review, and you have quality assurance. But to us, these seem like implementation details. The goal of code validation was actually just to answer three very simple questions. Does this change violate the user contract? Two, does this change increase the future propensity of a user contract violation? And third, does it fulfill what the author intended? And so we've designed Reptile from the ground up to do exactly that, to answer those three questions. We do this by reviewing the code of course in a more traditional sense where we use agents to look at the code, look at the blast radius of the change files outside of the diff that could be affected or related and then we run the code in a sandbox, click around with web browser agents to try to break things, simulate users in a sense. And that has turned out to be a much more effective path towards truly autonomous code validation because it's hard for me to imagine that this idea that humans would be reviewing large amounts of agent code and that will become the new job of software engineer is quite dystopian. I I don't think I want to wake up every morning and review SLO all day. I would much rather spend the time coming up with the genius ideas and letting machines figure out how to turn that into commercial grade code. That's my talk. My name is D and you can try Reptile today. You should also come visit us at our booth. We have an arcade machine. Thank you so much. Hi, I'm Amole, CEO of Nori Agentic. We deploy an AI employee that understands your company, your code, docs, Slack, and other kinds of data. We spend a lot of time thinking about how coding agents really work. Most people think coding agents only write code, but if you ask me, that's just bad marketing. Forget the name for a second. Coding agents can do almost anything. There's just one trick. You have to be able to think like an agent to get it to do what you want it to do. Today we're going to talk about how we use coding agents to do something most people think agents are terrible at. Make visual artifacts like slides, docs, and yeah, even video. Every day, the world pours something like 34,000 human years into making slide decks. Most of that time isn't the thinking, it's the fiddling. A deck that takes 10 hours should really take about 25 minutes once you remove all the formatting and the branding and the moving things around. Say you need to make a slide. What do you do? You open a tool, PowerPoint, Slides, Figma, Canva, and then you start manipulating a canvas. Every one of these tools is built for human hands and human eyes. Click, drag, drop, resize, snap to grid. All motions and patterns that make sense for our geospatial view of the world. There is a data structure underneath, but it's in a format that only the application can read. What happens when you hand these tools to an agent? Well, the output comes out all wrong. Things overlap in weird ways. You can't see the text. There's no alignment. It's just garbage. AI skeptics say that it's not just the tools. agents fundamentally can't reason about space. And there are whole benchmarks like Arc AGI that are built exactly around that premise. There's a famous little test for this from developer Simon Willis. He asks every new model the same thing. Can you draw a pelican riding a bicycle? But there's a trick. The agent is only allowed to use SVG. It's a quick gut check for whether a model can reason about space at all. Here's some examples of what the models actually give you on this test. And yeah, these are pretty bad. Like genuinely, deeply really bad. So, does that mean it's hopeless? Agents are just doomed to be bad at graphics? No, I don't think so. If you ask me, it's not the model, it's the medium. If I asked you, someone who is presumably human, to handw write an SVG of a pelican, you wouldn't be able to do that either. SVGs are just a wall of numbers. You can't go from a wall of numbers to a pelican. You just can't see that way. That's just not how people think. We think graphically. So, we build tools that let us draw on a canvas. Figma, MCP's, PowerPoint, CLIs, screenshot and replace loops. What do all of these agent tools have in common? They all approach the problem like a human. But an AI is not a human. Asking an AI to use a canvas is like asking a human to write SVG by hand. It doesn't really make sense. You need to give the AI tools based on how it thinks, not in pixels, in language. Words, tokens, structure. That is its native medium. Imagine a language that's incredible at describing layout, that models have seen and trained on billions of examples of that they understand intuitively, that renders to pixels and can run everywhere. Oh, right. HTML lets a model think in structure. HTML tags have meanings built into the language, a heading, a chart, a grid, and the browser turns it all into pixels. So the model never actually places a coordinate and you can get all sorts of visual effects, charts and layouts, fonts and motion, all of it for free. Remember that pelican from earlier? Now ask it to do the same exact task, but in HTML. Same bird, but now it's in a structure that the model can reason about. And you can read and theme and edit every single line of it. I spent my whole life building slide decks with PowerPoint. So, I always thought that those two things, slide decks and PowerPoint, were synonyms. But that's just not really true, is it? PowerPoint is a tool that you use to make slide decks. The deck itself, that's just the presentation mode. And as it turns out, no one in your audience is going to care how you got to the presentation mode. The editing format is totally arbitrary. So you can just pick the editing format that the agents are already good at HTML and if you need to render to a different format like PDF later on. We use this HTML trick to build all of our slide decks, our board decks and our sales decks. These are real things that we actually present and send out constantly. We use it for our docs, too. It gives our docs color and vibrancy all while following our brand. And of course, we also use it to make videos like this one. What you're watching is just HTML and CSS. It's literally just divs all the way down. Almost everything is better with a little structure and a little bit of color. Plain text is a choice, generally a choice of convenience, but it's usually the wrong one if you're actually trying to create something of use. Now, I do want to take a quick beat here and point out that a beautiful deck on its own is generally not worth anything. You still have to go and get all of that content, all of the things that actually populate that deck, right? Well, again, we can think like the model. If you just give the model access to your data, say your call transcripts or your emails, you can have the model build the deck end to end. Let your agents do all the grunt work while you focus on vision and story. That's what Nory Sessions lets you do. I've built entire board decks for my phone on the subway during my commute. Why? Because our Norybot lives in the fabric of our company. Of course, Nory ships with everything you need to make this all work. So, don't bother reinventing the wheel. That's my little Thanks for listening. If you have just one takeaway, it's this. Stop thinking like a user. Think like the model. Give it the right language. And for graphics, all you need is HTML. Hi everyone, 10X. You feel it yet? Hi, my name is Zion and I'm a mobile software engineer for the last 14 years and I'm here to talk to you today about 10X, reimagining the mobile dev workflow. So, you know, back in the old times when cursor was that thing you make with your mouse and AI agents were that dystopian character from sci-fi books or movies, whatever fits your style, you know, just a few months back then when we thought that we will still be using our IDE just maybe slightly better. And now we know that we already switch to like chat style um engineering when we discuss with cloud code codex cursor whatever um and we just tell them what to do and we don't use our IDs unless it's for debugging or something that the agent couldn't figure out and that in theory should have made us 10 times more productive right that's what everybody says right with are we 10 times more productive do you feel it I don't know because I can't feel that we are 10 times more productive not as single engineer and not as a whole group and not as the whole company. So why is that? Why don't we don't see the promise of 10 times more productive came to an actual life. So you know they tell the story about how when factories switched from steam engines to electric engines at first they didn't see that big of a gain. So yeah, the electric engines were better. They were more efficient, but they didn't see that 10x, 20x, 30x uh more productiveness that they have been promised. And the reason for that was that they only changed the steam engine with the electric engine. But the real gain came some years afterwards when they understand that it's not only about changing the engine, it's about changing the whole workflow. Because you see, they used to have like one giant big steam engine in the factory and all of the machines were rearranged based on their power consumption and their proximity to that steam engine. So it wasn't organized by the workflow that it should have been like from the start to the end of the workflow. No, it was designed by proximity to that central engine. When they realized that and they also realized that they could take the electric engine, make it smaller and put it inside each machine and then they rearranged the factory to make it work as the workflow should because now it it was made possible. Then the real gain came. Now they were 10 times, 20 times, 30 times more productive than they were before. Not because of only changing the engine but of changing the whole workflow. And that is what I want to talk to you about today. Let's think how AI make things that weren't possible before possible now. And we can change our workflow and then becoming 10 times 20 times more productive. To do that, let's look at the current workflows. The PMs have an idea. They iterate with the designers. They iterate with the user. They iterate with the dev. They iterate then back with the designer. Then they iterate with the QA. And they iterate back with the dev. And maybe after all those iterations maybe you have something in production. So what was that word that was repeating so many times? Yeah, iteration. And this is the problem because iteration creates friction. Each iteration creates context switch create time waste creates communication that needed to be done syn synchronization that needed to be done and AI didn't eliminate all of that AI sped up code but didn't eliminate the friction didn't eliminate the iteration why is that so let us reimagine what we could do bear with me for a moment what if what if What if instead of using one tool for designing, another one for testing, another one for coding, and then another one for releasing, what if we could use one tool, one codebase? What if instead of designing on Figma, then sending a design doc to the developer in order for them to figure out how to um make those uh designs alive? What if designers could actually design own code and then send the developer a PR? What if QA could iterate with the agent itself, just getting a link with the simulator and they can tell the agent exactly what to test, what to be cautious of, and if they find something, exactly what to fix? What if we could make the dev workflow works on the code itself? What if God was one of us? No, sorry, I got carried away there. And you're probably asking, how can we do all of it? So one way would be to tell everyone to just download their Xcode and and their Android Studio and teach designers and PMs and QA how to build and how to uh test on simulators, emulators and blow to their laptops with a 200 GB on storage and uh whatever they do to the to our memory. That's one way. But let me guess that most of them would reject that idea and for good purposes. So we can make another way. Maybe we just put it in our CI, right? So we let the agent iterate with the CI so they don't have to download Android Studio and Xcode and everything. But you actually know that CI builds take between 20 to 40 minutes. And we can't actually let our agent wait for 40 minutes just to understand that the iOS code that it pushed actually failed to build. So what else? What can we use? Introducing cloud sandboxes. So cloud sandboxes are actually concept that has been around already for many years just not for mobile development yet. Using cloud sandboxes, you can tell the agent here's an here's a CLI. Talk to the CLI. Create a VM, a small VM that runs only for this iteration. The VM boots up in 30 seconds or less. Make the build. show them a simulator on their inapp browser in the cloud code, codex, cursor, whatever. And then they can iterate over it, tell it to change that button, uh to go back and test something and change the code and they push and open a PR and then the designer can work on code, send a PR to the developer after they done. Developers make an iterations make one, two, three, four different VMs uh to run in parallel. They send the PR for review. QA can take it from there and tell the agent exactly what to test and tell it what to fix and from there it goes straight to the stores for review. So let's see it. Let's see how it should work. So imagine you see this screen. Imagine you're inside Codex for example. You have the chat interface to your left. You have the actual app to your right. The designer is iterating with the agent. tell it exactly what they want them to do, what they want to change and see the changes immediately on their screen. Build time is faster. It's done on the cloud and preview time is faster. Then they either some more not with the developer but with the agent on their laptop without the need to install Xcode or Android Studio. And once they done, they can tell the agent to take that code, open a PR and send it to the developer. This workflow is what makes us 10 times more productive. Not only because of using AI, but because of using AI to change the workflow, reimagine it and remove all that friction that we took from for granted in the old times. That is how we become 10 times more productive. Thank you. >> Okay, I want to tell you a story about a factory that taught itself how to remember. Hi, I'm Rushab. I run machine craft, a 100 people factory in India. No data science team, no ML budget, none of that. And somehow we ended up building a 36 AI agent that runs our entire go to market. I think that's still a little ridiculous. Let me show you how it happened and why you can do the same thing. So here's the thing about our company. From the outside, it looks like machines and metal. But the actual company, the part that matters isn't the machines, is the knowledge. Who the customer is, what we quoted them in 2019, why that one machine needed that weird custom tweak. And for three generations, all of that lived in exactly three brains. initially my grandfather's then my father's and now mine which is a genuinely terrifying way to run a company when you sit with it a lot of people have joined us people have left us the revolving door never stopped and every single time someone walked out a chunk of our brain walked out with them we weren't scared of the competitors we were scared of forgetting or waking up one day and realizing the whole company. All right. It's great to be here and today with me here I'm I'm Gerge, author of the pragmatic engineer and I'm excited to have a chat with Simon Ericson uh founder CEO of Turbopuffer a very technical CEO and we're going to have a pretty technical discussion but before we jump into it Simon I wanted to ask where did you fall in love with computers? um through PowerPoint. >> PowerPoint you I don't know if any of you know this but in power well you probably know this but in PowerPoint right you can make the the diagrams and stuff when you click them go to another slide that becomes turning complete real quick right you can sort of you know create very complicated convoluted games and then at some point you know you make it through the Microsoft Office suite and you discover Front Page. Do you remember Front Page? >> Yeah, I remember Front Page. It it it was supposed to eliminate the need for all any front-end developers. >> Exactly. And it it only worked in Internet Explorer. I remember a heartbreak I had one day when someone opened a website I created in Firefox and it just it was it was all over the place. And then one day I accidentally clicked the HTML thing in front page and it just showed all of this stuff that I couldn't make sense of and I just started looking at it and then going online and finding little snippets that you could add in to make the cursor change and all of these different uh different things and then it just sort of escalated from there. Then you upgrade to Dreamweaver and now you're coding and then you're like well how do you make the pages dynamically? you learn PHP and then for me I exhausted the internet on Danish language programming advice. >> Mhm. >> Um and I was I was around 11 or 12 and so I just you know went and got addicted to World of Warcraft for four years but that gets you really really good at English. So you kind of start hacking get into deeper. Now the logical step would have been to just you know go to university and learn properly about this stuff. But that's not what you did did you? I mean I just um I I started just I I mean you know then I learned video games then I learned English and then you know this like massive arsenal of the web. I now it'd be very interesting because the LLMs would just speak Danish to me and you could just you wouldn't have hit the wall like I did. Um, so that would have been very interesting. Maybe I would have been better at programming. That would have been nice. And then I Yeah. Then I just started picking up jobs and things like that throughout high school. And when I was in high school as well, I got exposed to this thing called the International Olympiad in Informatics. You heard of this thing? >> Yeah. >> Um, and I had a I had an internet friend and she lived in Australia and she was on the Australian team >> and she told there's probably something for the Danish team as well, but I had never I'd never heard about it before. And so I found it on some like little mysterious website and then applied and then solved these programming problems that look very different from the HTML and PHP things that I'd solved until >> were like the algorithmicalish programs. >> Exactly. It's sort of like this is not actually the kind of problem you would see there but I think it illustrates well the kind of problem that you might get right is you could imagine something like okay here's like n trucks here's m packages the m packages have these dimensions give me which trucks which packages should be in right and then do something optimal like that's an npmplete problem you can't solve that but you could compete with everyone else in the competition of doing the best thing so it's these kinds of problems right >> um and so I started doing that. In high school, I was working um I was working as well um for a startup. Um and then I just Shopify found me while I was still in high school. >> And and the whole like Shopify found me, was it through your open source contributions? Was it was it something else? It was because I had written an article where I had I had I dropped my iPhone and it was you know the iPhones are a lot like there used to be a time right where you drop your iPhone and you just knew it was over for the screen. >> It doesn't really happen as much anymore like the screens have gotten a lot better but back then it was like yeah one drop and it was dead and it just couldn't use it anymore. And so I went back to one of these old Nokia brick phones and this is back in 2013 and people hadn't really realized all the pernicious effects of smartphones at the time. And so I wrote this article about how oh my god I'm like calling people and I have my sense of direction back. Um and I wrote an article about it and this article it went on hacker news briefly and it um New York Times decided to feature it. >> No way. >> Yeah. And so a lot of traffic was driven to it and then some astute Shopify recruiter put it all together and um and I had a call with them and then I don't think they realized that I was still in high school but um but I had a great call with them. They invited me on site to Ottawa, Canada. Um I had no idea what Ottawa Canada is. I think the email says something like what's an Ottawa? I had no idea. Um, and so I went there and it was just like walked into the building and it was just a just felt right. Um, and so I I I interviewed with them and then said, "Well, I got to finish high school first and then uh and then I moved to Canada uh to to to work at Shopify." Yeah. In 2013. >> Yeah. I think that's that's a like legit excuse for like not even worrying about college and and university. >> But I did it crossed your mind. >> It did. I thought I was going I thought I was doing a gap year. I thought I was like, "Okay, I'm going to go work at Shopify for a year and then I'll probably go back and do but I would just I was very insecure at the time about the fact that I hadn't studied computer science and my only exposure had been all the II competitions. It's a pretty good crash course in a lot of computer science. And if nothing else, it had really taught me that you can just sit down and read a paper and just figure it out if you spend enough time on it. So I did I did that repeatedly and in my first year at Shopify I just every time I heard something that I didn't know what was I noted it down on a piece of paper and then I went home and then that evening I would just read about it because I felt insecure that like well if someone mentions mentions like TCP surely they know exactly what's in the three-way handshake and how TLS is like layered on top and they've looked at Wireshark and all of that. I don't think that's true but that's what I thought. >> So I went and did that for everything that I encountered. Um, so that was a really good crash course and then very quickly it became clear that well I just want to continue doing this. I don't want to go go somewhere else and then come back to this because I felt like I'd already found what I wanted to do. So it sounds sounds like it was a pretty good combination of like you just having this like very natural insecurity like you know you're young, you know, you don't have the education that everyone else has and inside a company that's just doing pretty like cutting edge stuff even at the time and even even to today, right? Like they're they're leading. So you just kept self-seing yourself like just catching up and go then do I understand that you just went deep in every concept that you understood you didn't like just like try to understand a surface level but like go as deep as you can search on the internet buy books whatever that is I think it was just that I just wanted to know keep learning how computers work and I think that this is something that I now look for when we interview engineers is that you just you can't help yourself but trying to peel back the layers and for me that ended up with the infrastructure layer. That was, you know, the people closest to the metal at at Shopify. And I would just always sit next to them at lunch because I was working on the on the product side. But I just I couldn't help myself. I was so I just wanted to learn what it was when they were talking about a reverse proxy. I'm like, why is it reverse? I I still can't answer that. I I I mean okay you know well what's in reverse because it's proxy right I don't I don't know I don't know it's like an inverted index like what's inverted it's like it's a terrible name anyway yeah I I mean it's still better when when you get the not tables the lookups some of those things like some of that but yeah I hear you there there's some like weird names with But at at Shopify, what were some of the kind of like hard engineering challenges that you engineering challenges, outages like like learnings that kind of defined you that were really also fun at the time or interesting to learn, but it would have been hard to get it elsewhere. Yeah. So I think it was, you know, in the 2010s there's like a bunch of SAS companies that that scale really quickly and I felt so fortunate to have a front row seat to that and so I ended up on the infrastructure team and this was back in you know 134 and uh Docker was coming out and so we were containerizing everything and we were just every single year we had to you know the growth rates of of of SAS sometimes seems quaint in comparison to the growth rates of companies today but it was a company that was growing at you know 120 40% year-over-year. Um, and so every year we were just preparing for a Black Friday that was going to be a lot worse than the last. And this is back in the day of we're buying physical hardware, right? We have to like place an order at a particular point in time and do some interpolation based on that. Um, and the software also had to scale. And when you're scaling most software, a lot of the application layer problems end up back at the database layer. >> And so I just naturally found myself at this layer between Rails and the databases. Shopify didn't at the time at least contribute many patches to the databases themselves but mostly just spent time orchestrating. So we were doing sharding because as um my my dear boss Camilo used to say you can't cash rights. So there's a fundamental point where you you just you have to move beyond a single shard. Um so I wasn't I joined around the time and they did the sharding and they did it I think they did the cut over a week before Black Friday which is mindblowing. uh and very but it worked and then the the subsequent years we worked on things like going into multiple data centers. We also had this big mysterious reddish server that was like you know 128 GB of RAM which was a lot at the time. Today it's not that much and no one really knew what was in it and then it went down one day and people were like well that's super terrifying. Um because people had just been treating it as this KV store. Um and so we started splitting it out. We did all this stuff around making sure that if you if you if you go visit a Shopify store and the thing that stores your sessions is down, the right behavior is not just for the entire the of everything to be down. But that's kind of the default failure mode, right? You're not going to rescue all of that. Um unless you're in a programming language that really forces that decision. So we did things like um build this matrix out of okay well this service when this component is down should act this way. Um and I found myself writing the test suite for a bunch of that. And then I was like okay well we can't just mock all of this. And so um I came up with this idea at the time of like oh what we're going to do is we're just going to um shell out to GDB and then into the process and then close the file descriptor to the database to simulate through the entire layer that the database fails. That was a little crazy and we never shipped that on CI but it did uncover a massive amount of issues in Rails that' be upstream and things like that of around just like handling failures at the connection layer. So then I moved on to create this proxy called Toxyroxy and >> have you heard of this before? >> No. No. >> Yeah. Toxyroxy is it's just like a layer 7 proxy that sits in between um you and well layer four but in between you and the databases. So you basically have just like this proxy and then my SQL whatever doesn't speak the protocol but then you can do an API call say take take uh take the database down make it slow um and over time it also added layer 7 things of like do a bunch of failures this way you're not mocking the low-level drivers but you're testing the drivers and their failure handling as well. So then this entire matrix could be implemented in CI. So the basically the proxy was just like a really thin layer which like was passed through but you built the functionality to like simulate problems with database or things like data corruption or whatever you wanted to do. So you could just do it in there and then you can anything that built on top of it but but then Oh yeah and then everyone had to like call this proxy or it needed to be on in a layer. >> Exactly. So you could do like do like my SQ you know toxyroxy.mmysql downdown and then pass it a lambda of what you wanted to do like get this page do a checkout whatever with the sessions table down and this just uncovered tens of issues right in the myql driver in the rails like it's just like no one in the ecosystem had been testing for this and it was very difficult to see this in prod right because in myql down you're focused on just getting back up and not like what could the application actually have done. Yeah, it's interesting. Of course, we're going to talk a bit more about databases obviously, but just thinking about how a lot of the problems or some of the most gnarly problems in large systems are always to do with state and I never connected until now that I mean state is usually there's a database. If there's no database, if you have stateless services, you know, I mean you still have problems, you have nodes going down, you have I don't know corruption, whatever, but it's usually like more isolated. But basically like if we have state, we typically have databases. is if we have databases and if you can simulate these problems suddenly you can I mean you you can like predict a lot of things the problem with state often time is it's really hard to simulate problems happening ahead of time unless when they happen so did you it sounds like you had pretty good success with >> yeah I think to my knowledge it's still um running in like the CI system of Shopify today I don't know if anyone in the crowd is from Shopify but I'm pretty sure that it still does um and so we wrote all these tests against it to implement and all of these different uh different failure conditions and it just yeah it was it was it worked out great. So you spent eight years in total at at Shopify. So like starting from like all right just a gap year it just went on a year a year another year. Um at what point did you think about leaving and why and what was your kind of decision framework? It sounds like you or you were like on Epic right now even today Shopify it's doing wonderful. It's probably doing even way better than like you know that growth kind of kept on. So I'm sure there would have been an argument to stay and you know stay on the rocket ship. >> Yeah. So I I spent I spent eight years there from 13 to to 21. Um and I I think there just came a point where I wanted to see something different again. I've been inside of Shopify since I was 18 years old, right? I'd been seen one other startup in high school. I was like if I want to learn more about computers and learn faster, it might be time to inject some novelty into this function. Um, and so I I left in in in 21 and I'd worked on so many different parts of the infrastructure like caching. Um, me and Justine, who's now my co-founder, we wrote the entire storefront um, storefront for Shopify um, which powered almost 100% of traffic 18 months after we embarked on it. Um, we've worked on running Shopify in multiple data centers. We've worked on so many database scaling projects like caching, all of these different things, right? Um, a lot of the a lot of the scalability came from the Kardashians launching lots of products on on Shopify, which would force a lot of traffic. Um, but that's that's eventually how I left. And so when I left, I didn't really know what I wanted to do. And so I one of the projects I had while I was at Shopify was this napkin math project. Have you seen this >> napkin math? No. >> No. Um, so napkin math was essentially just this table that I maintain on GitHub of how much bandwidth can you drive to DRAMM, what is a roundtrip to S3 cost, and how long does it take, how much bandwidth can you drive to an NVME SSD, how much bandwidth can you drive to an EBS volume? Just a collection of probably there's probably like 50 of these numbers and then a RS script that generates them all. um what all these things cost? What do you like? What does a gigabyte of memory cost? $2. What does a gigabyte of S3 cost? Two cents. What does a gigabyte of um this cost 10 cents, right? What does it cost on spot? What does it cost on a three-year commit? Like I had just have a massive table and then create flash cards for almost every single cell. So I know all these numbers. And this was a project I started taking on at Shopify because I found myself in um this role a lot where I would go in and review a project, right? So some product team would be like okay we got to do we got to build this thing so we got to build this infrastructure to support the feature and a lot of the times they would say okay well we've gone and benchmarked it on database A but the benchmarks are not very good so we're going to go with database B and I hate benchmarks so much because that's not a satisfying answer to me to me it's like this does not jive maybe my intuition ition database A that you're saying takes 10 seconds to do this should take 10 milliseconds if you do the napkin math right if it's a search query right it's like okay you're searching for three terms there each term has this many documents that match it that's this many megabytes we inter intersect these many this many lists you have DRAM bandwidth on multiple cores of 100 gigabytes per second this should take 10 millisecond you tell me the benchmark takes 10 one of us is wrong. Either there's a gap in my understanding, which is very likely, or you would benchmark the wrong thing. And in some ways, some reasons, right, it's like, okay, you've done a benchmark, you don't didn't realize that your benchmark is doing a distributed query across a 100 different nodes. And so, of course, the P99 is going to be really, really high, right? Unless you've cut that off or or made some different set of trade-offs. So I just found myself in these discussions repeatedly where people were making infrastructure decisions based on poor benchmarks. And so I needed some I I needed some ammo to go in and just be like okay we can just do the calculation right here and then. Um because I was always doing these like little demos or like writing little prototype scripts to to demonstrate this. But it was just I just the argument of here's how a beach tree works. This is how many pages we have to visit. This is what a random SSD read takes. It takes one millisecond. you have to visit a thousand blah blah blah blah blah and then percent it back and see this is the difference to your query well like is the query plan correct like is there a bug in my SQL do we have bad discs like what's the discrepancy here and I just got caught with that bug and so after I left Shab I was just writing a lot of articles about this I was just like well how long does should this query take and then I one hypothesis I had at some point like okay well how many writes per second can my SQL do well shouldn't the amount of writes per second that my SQL do equal the amount of f-syncs that you can do per second. That sort of makes sense, right? Every time you do a ride, you f-sync to persist to disk. So, how many f-syncs can you do per second? Well, an f-sync takes one millisecond. So, you do a thousand rights per second. That well, that doesn't really match up. Like, feel like a database can do more than,000 rightes per second. Why can it do that? So, that was one of those things where I tested and it's like, okay, well, my SQL on a little dinky box could do 10,000 writes per second. Well, how is that possible? >> And now you would just ask, how is it possible? >> Because you batch. So an f-sync happens on usually a 4K. >> Yeah. >> Right. But it's like that's not intuitive. Like it's actually I I I got caught. It was like just like you know probably some like 24-hour period where I just got obsessed with this question whereas like you're writing like the BPF traces and all of that to do all of this. This is like preLLM so it took forever and you and then I found out that oh every f-sync was like much larger than I would have inferred like oh it's batching. you go into the code and you read it and then you found some obscure article by it's always somewhere in like a central German town that's like written some article about like how some intricacy of my SQL works and a patch that they did to it's like the entire internet runs on small towns in Bavaria. I'm convinced. Yeah. And then you decided to start Turbopuffer. Yeah. Did h how did you decide? Did you know what you wanted to build or was it more like I want to build something something databases because you were clearly very into databases. You you've done an awesome job benchmarking like what is the theoretical like limits you were very familiar with this probably became you know like world expert in in this niche and then how >> did you want to go into databases again? >> I think it was there's three things that sort of came to a head. Um the last project that I worked on at Shopify was search and I didn't have a good time. >> What what what did you use back there? Um I don't we don't need to name names of other database companies, but it was uh it was one of the one of the like traditional search companies that a lot of different um companies run and it was just very difficult to get it to do what I did and I was just like the projects that touched that database just I couldn't get them to perform at the napkin math and like there's there's no query planner and like I couldn't figure out why it wasn't there and sometimes it tracked and then sometimes it really didn't track at all and so I tried to learn as much as I could to figure out and like start reading the source code of it and I was just I couldn't get it to track very often. It was very difficult to operate and so I just that was sort of like in the back of my head. I never thought I would touch that again. Then the second ingredient was the napkin math project because it sort of just gave me a lot of facility with all of these napkin math numbers of what might be achievable with the machine if you utilized it perfectly properly. Yeah. And then the third one was that doing this you know leaving Shopify in 21 having spent eight years there and during that time I did this I called it angel engineering so I like joined my friends companies and then I just vested equity instead of um instead of just investing or something like that and because I wanted to have my fingers in it I wanted to like see what else was out there that's why I left and this problem kept coming up again again and again and again right like ChachiBT came out in 2022 and I was working with with a company then and They wanted to connect a bunch of documents to AI and that's when the context windows were really small. So you had to reach for search very quickly. >> So it's like a few kilobytes. >> It was eight kilobytes or four kilobytes depending on the model. It was very very small. So you had to reach for search very quickly, right? And >> so I I I worked with them and I was I was I created a little recommendation engine and the recommendation engine was actually quite good. Um, like I s I found out that one of the co-founders wife was pregnant through the recommendations that I was getting when I was running it on his feed. Um, like it was it was it it >> weird but >> it was recommending. Yeah. I mean it was just like you know he was reading about like and I did get permission. I just like I don't think anyone expected to be good enough and just like okay it's this this thing is working and then I ran the back of the envelope math on what it would cost to do this for everyone like all the users. This is a company called Readwise. So it's like articles that you save and then and insert later. And it was going to cost 30 grand a month. And this was a company, it's a bootstrap Canadian company, they spend about five they at the time they're spending about 5K a month on all the other infrastructure combined. So it just it didn't the you know fundamentally in a company if you're doing an investment you have have to earn some gross margin on top of whatever you're paying, right? And it just didn't line up. Um, and so we just didn't ship it and I worked on I you know tuned to autovacuum on Postgress or something like that which is a good pastime and then you I just couldn't stop thinking about why it was so expensive to store all of these vectors that we were using for the recommendations and I just sat and did the napkin math one day of like can we just use it all in S3 and do some clustering and then organize the files and just the way and it's like maybe you could build that and then one day I just kind of said did and did it and like sat down and started to like to write it out. Um, and I spent the summer of of 23 just hammering my head against the wall trying to find an approach where I could get the latency that I wanted. Um, >> because the problem with S3 is it has really good durability, but latency we're talking hundreds of milliseconds, right? >> Yes. The P99 on a uh 256 or 512 kilobyte object on S3 um is around 200 milliseconds. Um, and and you're saying P99 because like when you're talking large scale, you want to care about the P99, right? >> Yeah. I think when you're >> That's why we're not talking about P50. >> When you're designing a system, you want to optimize for the P99. And especially because when you're designing a system on on S3, generally in every roundtrip, you're not doing one request. You're often doing lots of requests, right? >> You're going to hit the P99 real quick. >> Exactly. So, it's like if you're navigating a tree on S3, right? It's like, okay, you get the upper layer of the tree 200 milliseconds. You get like another layer of the tree 200 milliseconds. You get a bunch of leaves of the tree in 200 millonds. So in aggregate you have like you want to look at the P99 probably even the P999 to design the system properly because you will need to minimize the number of round trips that you had to make. So, I just sat and sketched that out um and tried a bunch of different approaches and then and then finally in in in July of 23, I I I got something end to end that seemed to work and then rewrote it probably twice and then released it in in October of of 23 based on um based on just that that summer of of of working through it. And then you kind of you built it on on top of S3 because I guess durability and and all of and just really good. How did you make it fast? We didn't in the beginning or I didn't in the beginning. Um it was just me at the time and it was really like it was it was it was a project. It was not a company. It was not >> it was it was it was to satisfy a curiosity. It was not I did not set out to do this like I'm going to go like raise $10 million and do like I was like I barely knew what a VC was. Like I was like I just had to do this thing and I was so focused on doing it. became so clear to me that if I wasn't going to do it, someone else was going to do it and I just became fully obsessed that summer with it. And so the first version was the simplest possible thing. I think I'm a very pragmatic person like I I didn't get buried. I barely read any like of the literature on LSM. I sort of like you know read a bunch of it just like got the basic idea barely implemented that because that would have taken too much time. It was the simplest possible version of what it could be. Like really what you have to imagine is that the simplest way you could do this is you run some clustering algorithm on the vectors. >> You get the clusters and then you put the clusters in files. The cl the files are called cluster one, cluster two, cluster three and then you have another file called centroidids of the clusters and then you do the search by downloading centroidids looking at the centrids and then downloading the n closest clusters. There's a few optimizations around merging some clusters that were JSON in files and so on just to like control some cost and some performance but that was basically it and then getting that to scale. That was the first version. And then how do we make it fast? Well, I didn't even implement a caching layer. I just put the reverse proxy in front of S3 with Engine X and then had it cached. >> You know what a reverse proxy is? >> I like I do know what it is. I just still don't know what what the reverse is about. But anyway, um the reverse the reverse proxy reverse things um the the performance in this case um maybe that's what it's about by caching right all of the all of the S3 objects it again it was the simplest like it's like I'm just going to put that in front I knew how to configure engine X like I've written more engineext Lua than u than a lot of engineext Lua very good software um just had that cache in front and then the way that I would do things like deleting in the cache was just like shell out to XRX and just removed like things in the in the cache and reverse engineer the directory structure on engine X and that's what we shipped and it was just running on a single server and a T-Ox instance. I was like okay let's see if anyone gives a Yeah. So so far I mean this is kind of like cool engineering and like a cool side project and like a bunch of novel ideas and I you know like I think just some hardcore engineering. How did cursor come into play? Because like when I learned about Turbopuffer, I was talking with Cursor about like how they built their their backend, their database, how they scaled, and they're telling me all these migrations and they were telling me like, oh yeah, so we we were on Postgress, but it didn't No, they did something else in Postgress. It didn't really work that well. They went to AWS Aurora, which is managed service of Postgress, and it didn't work well, which is very surprising. And they're like, "Oh, yeah." And then we went to this thing called Turbopuffer, and they worked well. And I was like, "What's Turbopuffer?" And they're like, "Oh, yeah, Turboer." I think I think they said like we were one of their first customers. And this never computed to me. Curser was already massive at that point. Yeah. How did you meet the folks? And how did they become would were they the first customer? One of the first. >> They were the first customer. >> The first >> the first. >> No. >> Um they they they reached out um after I just launched on on Twitter. I was like, "Hey, I built this thing." And frankly it was like in I exact you it was like hey launch this thing and to me I was like I am so sick of working on this like I was like I've been working on this all summer I don't know if anyone cares I only want to work on this if anyone cares. Let's put it on Twitter again single Tox instance on a 8 core node somewhere in GCP. I was like if someone goes to prod I'll I'll set it up properly on multiple and like I'll just block on that but let let's see if anyone cares. It was like the MVP of MVP. anyone who's actually worked in the internal on databases would never have had like would have had too much pride to ship anything like that. Um, and I've just, you know, I've worked on I was just releasing it like a SAS project. Why can't you work on a database like it's SAS? I don't, you know, it's like if anyone uses it, we'll do it properly. I know how to run software with a lot of nines. Um, but it was not a proper LSN like it was very very it was the simplest version of what it could be. And then I released on Twitter. I was like, "Yeah, you could do a million vectors for a dollar." And before that, I think the the cheapest was maybe $100 per million for something that actually worked. >> Yeah. >> Um, and I knew it was reliable, right? I knew like I had these invariants like if you shut down all the VMs, like no data is lost, like all the rights are committed directly to object like it has all the same invariants it had today. Um and cursor reached out and knowing them now I'm sure at the time the cursor was maybe eight people and knowing the founders now I am sure that they had sat at the dinner table one day and we're like the unit economics of what we have right now where all the vectors are in DRAM are not working why hasn't anyone built it where we can put it in S3 and the actual code bases that are actively being used we can put in memory >> and everything else just sit in opic stores and then we just hotload it in and out of the cache >> makes so much sense right you open the codebase few seconds and it's in RAM and then the queries are as fast as anything else. It made so much sense. So I mean at the time they were if you look at some of Aman one of the co-founders early tweets he talks about uh using S3 for KV caching and things like that which barely anyone is still doing even though >> um the economics >> yeah price wise yeah it's and it's very it's very uncommon and I think it will happen right but they were ahead of their time >> and they I think they were I don't know if they were thinking of building it themselves I think that's quite likely um and they found turbuffer and it just perfectly pattern matched into that again I don't know if this dinner conversation happened or if this was just inside Harvey's head. Um, but it pattern matched something and so we exchanged a bunch of emails and then something compelled. I didn't know anything about B2B sales. Now I love B2B sales. Um, I didn't know anything. I was just like I just want to help them because they they were they had some unit economics that didn't line up. So I just went to San Francisco, right? I live in Canada. I went to San Francisco and I showed up at the office and when I showed up at the office they um they were having some Postgress problem that they were discussing. Yeah, the AD as Aurora problems. Yes. >> Yeah. Early on. And I was like, "Oh, do you guys have PG analyze?" And they said, "Oh, no, we don't." I was, "Okay, let's let's let's get that going, right? Let's look at it." And it was the same thing as it always is with Postgress, which is auto vacuum hadn't run enough. And so, they had all of these like going to heat when they should be doing index scans and blah blah blah. So, we were talking about all of that. And so, it's just helping them, right? It was like my, you know, my database genes just like kicked in. And I think this built enough trust with them that okay, well maybe if he knows how to help us with the database, maybe he also would know how to build one. And um at this time I'd also approached who I thought was the best engineer who ever worked at Shopify, my co-founder Justine. um and she'd come on and the first thing that she did was um remove the reverse proxy enginex cache with a file-based cache just a direct cache which again great like the S3 thing worked um and so she was online she was starting to work on it and um and cursor cursor cursor then that night was like okay well we're going to migrate and so they migrated everything over the course of like a week or two after that um but cursor was a small company back then right yeah and they were they just in the beginning of their massive rapid growth. >> Exactly. And I I told them that I was going to reduce their bill by 95%. And I did like we did. Justine and I did. We like they came on and their last bill with their previous vendor and the first bill with us, it was 95% lower. Yeah. And you're you're nice for not saying vendors, but I I can say talks to them and and it's in the deep dive about cursor. It was it was it was Aurora specifically. Uh so >> this was this was not this was not Postgress. No, this was a >> it was a different one, but it's probably still in the write up. We don't we don't need to name names, but uh yeah, but they were the reason they went there is reliability was their main main pain point. I'm sure the unit of comics would have been there, but yeah, this was and then what Swallow told me is he said like look like there's a few things that we did that you should never ever do and he said one of them you should never ever bet your business on a tiny startup where you are their only or biggest customer except for Turbopuffer and he said I love love those guys. So I guess it just comes to show that even in your case like to me what this story is shows is is you can do things when you build highquality things and you're pushing for things good things can happen and on the other side of cursor when you're a startup it's okay to take sometimes irrational risks when you have conviction and it sounds to me that you gave them conviction by showing up in person by helping them by showing that you know you know your stuff like you suddenly brought in your your 10ish or eight years of Shopify experience and your curiosity and They probably took a risk because of that, not because you were some, you know, random vendor. They probably would have never done that. So, fast forward today, uh, Turbopuffer is now a lot bigger. You're you're working on some some some cool things. But you have this very interesting business where for you CPUs are important, right? You run on mostly CPUs. And you told me a story over dinner yesterday that uh you met Jensen uh and Jensen he really wanted to sell you on GPS. Can you tell me how that meeting went? >> Um yeah, Jensen Hong, right? >> Yeah. I just I never met uh I'd never met uh Jensen before. We were we were at an event at uh at at Nvidia and we were just doing um presentations in a big HQ. Super impressive. >> Yeah, exactly. They've invited a couple of companies to go and and um and and and talk about um uh talk about our businesses and how we can partner with Nvidia and so on. And I I don't I I don't know. I was like I think I was in a goofy mood that day. And so I went up on on stage and I said, "Um, hey, I'm Simon from from from Turbopuffer." And uh and yeah, if you're wondering about the name, it's like if everything goes south, we can always pivot into vapes. I was kind of nervous. I This is what I This is what I said. And then and then he said back to me, >> wait, who was in the room? Was it Jensen? Was it a direct report? >> It was It was Jensen and then I don't He has like I don't know if it's just 50 direct reports or it was like, you know, it was there was it was Jensen and then a bunch of the um like Nvidia Nvidia leadership, right? Um cuz you go there and then you talk about that you find opportunities to partner and work together, right? And so I said, "Yeah, you know, so plan B could be that we could pivot into vapes." And then he said, I was already nervous. He said, "Judging by your slide, maybe you should." No, he did not. And and I didn't know what to say back to that. So I said, "Well, Jensen, do you vape?" He didn't he didn't answer the question. And then someone um someone on the um someone on the on the team um wrote to the whole company, Turppuffer Company, Simon just asked Jensen if he vapes. Um and then you know this is this is a great start right and um and then the team had team team had sort of talked to me beforehand was like son we got to make sure we don't say the c word we can't say CPUs and so I just couldn't stop talking about CPUs. I was like AVX 512 is so sick like we love SIMD and um like we we we like there's so many CPUs. They're so easy to get. like um it's just a riot in CPU land. Like you know I I don't I think I stopped short of saying I'm so glad I don't need GPUs but but it was just it I just couldn't stop talking about CPUs. Yeah. And so you know Jensen took an interest in that. Yeah. So who who knows like I'm sure you made you made a memorable impression. Maybe he made it his mission now to like at some point get you guys onto GPUs. But speaking of CPUs, can you tell me a bit what you're seeing inside of the hypers scale the cloud providers? You're now in AWS, you're you're in GCP, you're on Azure. What I would think naively is there's a GPU shortage and when I talk with inference companies, they are and and and AI labs, they're just getting whatever they can do. I would think getting CPUs is should be easy. Is it? >> No, >> it's not anymore. Why? What's happening? Can you tell us about dynamics on on on the why and what you've learned? Yeah. So, I think that GPUs will probably continue to be scarce. Like, I don't know, maybe there's going to be some surplus. I I refuse to speculate too much about the macro, but I think as as RL is becoming a very very large amount of the workloads that needs a lot of CPUs. So, the labs are sucking up a lot of CPUs because you need CPUs to be like, okay, we need to like teach this model how to how to search. We need to teach it how to use GP. We need to teach it how to boot up bash. We need it needs to run real things and learn from that takes a lot of CPU. >> Mhm. >> Um and so I think as we RL is consuming a lot of CPU and then also just all of the agents are running on CPUs, right? They need to do all kinds of very general purpose things on a CPU and so as as as the demand curve is sort of shifting to the right and it's becoming more and more applied and that feeds back into RL by the way, right? because as things become more applied like oh the models are not that good at CAD or ship building I don't know and then you know you have to spin up even more RL environments to do that so I think that's what we're seeing and so we're on the other end of that needing these CPUs we need a lot of NVME SSDs as well um and a lot of this right now is tied up in DRAM right of of where like >> you need a lot of that also for the GPU servers um but I would assume that it gets a lot worse before it gets a lot better on the on the CPU side um and I think even the big companies are fighting amongst each other, right, to get the allocations and even we, you know, we're selling to companies that we also fight for CPU with and against, right? It's uh it's it's it's really difficult and so you write things to try to make sure you get these CPUs as f fast as possible. >> Yeah. And yesterday I was at a dinner that you hosted with your team where you actually have a bunch of Turboper customers. A bunch of them are AI AI labs or or AI startups but a lot of them one of them uh reflection had have hu massive amount of footprint and they were telling me that they're in a situation where they cannot buy more like they when it comes to GPUs or CPUs they max out they have the longest contracts that possible and I didn't realize how competitive it is in the cloud when you're you go beyond a small fish to like a medium size or even a a large fish that now like It's it's interesting. So So now you have this and even you're having this this uh kind of fight behind the scenes that is maybe not as visible. >> Exactly. And I mean you you work with the clouds right you work with them to talk about which regions have um have CPU which regions are getting it comes down to power right of like okay well where is the power which is generally where they're going to ship the new CPUs. Um and so we have to work with some of our biggest customers on that. So these are real constraints right that are that are making our way to us. We're just very fortunate that it's very easy for us to run lots of turbo power clusters because all we need are like a few CPUs and NVME SSDs and then S3 and then we're in a good place. But there's lots of changes that we can make even to the architecture um to try to protect from from a lot of this. Now I'd rather spend that engineering effort on other things but we are very very good at using a lot of very different SKs, right? So we don't need everything to be a particular CPU or instance type. We can run with many many different types of machine types. Um Q meaning that's the it's a fancy name for like the different machine types. >> Yes. Exactly right. Like you know C4D or I AG or whatever they're called. >> What's your favorite one? >> Um we really like right now the um C4s on uh GCP. >> GCP. Yeah. >> Um the Z4Ds are also performing really well um now that we've done done a bunch of of um of optimizations to them. Um those are really really great machine types. Uh we really like those. Um and then the ARM C4As as well um on on GCP. Um we like those. But I think that in general like when you're yeah when you're small it's very easy to suck up a bunch of but at Shopify I was also part of you know deciding ahead of BFCM right a few months out you have to tell the cloud providers how much you're intending to use. do commits on all of that, right? The the clouds are not infinite as they seem when you're small. >> And one way, of course, to like get like infrastructure and and also just like credibility is venture capital. If you raise $und00 million, a billion dollars, some of your customers just raised $2 billion. Actually, I talked with them yesterday. You know, it gives you credibility, it gives you cash, you can pay for this thing. Your specific Turbopuffers relationship to venture capital seems very interesting. I never heard you announce a raise until m maybe just very recently. Can you tell me how you and and you told me that when you started this thing you didn't think too much outside of just building some cool stuff. How did you think about venture capital and how do you think about raising because again I feel you have a very fresh and different perspective than what which is typical inside of Silicon Valley. Yeah. So I think to to understand my how I think about capital, you have to go back to the the beginning of Turbopuffer, right? Where I promised Curser that Justine and I could get their bill to 4K a month. And this was based on some very rough napkin math on, okay, if if Turbopuffer was a better implementation than it currently is, then it should cost this much. And that's the pricing we ship with. And that's what we guaranteed um guaranteed cursor. Um but the software was not that good. Like it was very reliable but it was very simple, right? And that's like a core engineering principle of me is simplicity above everything. Um you and I have talked before about how software that ages well and some of the advantages of seeing be having long tenures inside of companies. You had a long tenure at Uber. I had a long tenure at Shopify. So you see simplicity just almost always wins. Um, and at the time I was not convinced whether this was a venture scale opportunity because I understood that if you take venture capital, no matter how many smiles there are in the room, everyone's sort of expecting that you have to earn a big return on that on some timeline that makes sense to everyone involved. And everyone involved are, you know, pension funds in Canada like that. It's like it there's like a whole stack, right, of of of people that that need to. So at the time I was like I don't you know I don't know if this could be a billion dollar company. I didn't know that in the very very beginning. Um it wasn't completely clear to me. It felt like a very niche kind of product right to build this particular search engine. Um and that was completely fine with me. So I you know it's it's it was fine. And so then I just I just looked at the cursor bill and I looked at my GCP bill which is what we started on. and you know as like a you know dumb Danish person who's just like okay like this number should just be lower than the other number. >> Yeah, >> that's sort of like you know and it's just I don't think I'd spend enough time in San Francisco cuz I think the money over here it works a little bit differently. Um that's just that's all I knew. You you were doing business 101 as as long as you're making a profit you're good, right? >> Yeah. It was like I'm I'm not kidding in this exaggeration that it was just like that just made sense to me that Justine and I were just going to go optimize this until these numbers were roughly equal. And maybe if if if we could get some other workloads, we could start paying ourselves. But that was like very much the philosophy at the time. Um because I didn't know if I could go raise a bunch of of of money. I didn't know anyone who had the money. I I didn't have any relationships. Um you were an absolute outsider to the >> I was I was an outsider. I was like an outsider squared, right? I grew up in Aus, Denmark and I um I then moved to Ottawa, Canada. So it's like I'm an outsider to Canada and in Canada I'm an outsider to San Francisco. So I was just thinking about this from first principles like oh you're a venture capital you need this return you need it on this timeline. I don't know if I can deliver that yet. I would need more data to decide that because I want to like I kind of want to keep working on this and now I have to get to this point for it to not be a failure. Um in in in January then I uh there was a person that I was at II with in in uh in 2012 and 2013 and his name is Buen and he was on the North and Macedonian team um at II um and he was he's he was really good. He was so good that the North Macedonian team called him God. Um I don't know why but that was what he went by. And he was yeah he was very good. Grew up and and I really wanted to work with Boyan but I couldn't afford to work with Boy. Um and he was very much like this is what I can live off like you know I just like I want to build this D like that would be like this is what it can be. But at this point, Justine and I hadn't taken a salary for like 6 months. And we'd already we'd already spent like tens of thousands of dollars on like on GCP bills and all of that. And I was like, I don't think we can I don't think we can we we can do it. And so I had met one one individual in in Silicon Valley. Uh his name is Locky. And it just I ended up just calling him and saying, hey, I kind of want to learn a little bit faster here. Can I can we raise like 700k? That's like what I wanted to raise. So, it's just like I want to have like two engineers for the rest of the year. Just and I still don't need to be paid and then a little bit of buffer room. It's like this is what I need and if this doesn't have PMF and is a big opportunity by the end of the year, I don't think we're going to bother and we'll just shut the whole thing down and we won't have it taking a dime. We'll return everything to you. Um I think there was the first time you heard anyone say it like that. Um, and um, I told some other VCs that at the time and that was terrifying to them. I think to someone on the West Coast, this sounds like you have low ambition or something like that. >> Um, and to me it was just like I I don't know, it just came from a when I don't know how to play a game, I just play with open cards. Like this is how I see it. >> And so I we were it was very clear to us that we wanted to do this and but also it became clear to us that we didn't want to just like keep working on this unless it could become big. And we were starting to develop conviction conviction that this actually become really really big. And so we we we did that and hired Buen and then became profitable later that year. Um and then just continue to hire. And then it's like to raise more money you need sort of there's six reasons to raise capital. The first reason to raise capital is to fund R&D. >> Mhm. That was the reason that we raised capital in January because we funded R&D with a lot of our own, you know, opportunity cost and not taking a salary and then paying the bills ourselves. Um, but we wanted to learn a little bit faster and so we hired Buen and Morgan as the first engineers. And then the second reason to raise capital is to fund growth. You've you you've built something and you want to tell the world about it and you want to spend more capital to do that. Um the third reason to to to raise capital is for the founders's ego. Um it's a very popular appreciate the honesty. >> It's very popular. Very very popular. Right. Big numbers, lots of press like um and I think this is a very very dangerous reason to raise money. And I wish that it was more talked about because you're diluting all of your employees when you do it. You are um setting a certain price for future employees and their upside. It's it's it for some people it can become a status game and that's not what it's about. We're here to build a big business together and this is not a reason to raise money. Um but I I do think that it happens. Um the fourth reason to to to raise capital is to reward your employees, right? It's a you're on a very long journey and you want to work with the best people in the world and by definition there's not that many best people in the world. So you want to reward them. Um that was the reason that we took more capital in December um was to allow the employees to liquidate as some of their equity um instead of waiting for some like event like an IPO or something like further out. Um the fifth reason to raise is for a strategic partnership. There are strategic partnerships that have been made in this in this city that have made companies. Um and um the sixth reason to raise would be do doing M&A or or something like that. But it's like you have to be very honest about what reason you were raising in those six. First reason we raised was one and second reason we raised was four. Um so which which ones? First reason to raise was R&D. >> R&D and the second reason was >> um to provide liquidity to the employees >> employees. Yep. I I think it's a it's a nice and healthy way and I think yeah the the e ego part we don't talk about and the identity and especially the closer you are to to tech e ecosystems where a lot of people are raising it it will be part of it as closing I I wanted to ask you about the way you have a remote culture these days I'm seeing it especially for companies that do anything with AI may that be building AI infra or or or just AI products a lot of them prefer in person having a HQ often times in SF or wherever your headquarters may that be London or somewhere else because you often these companies often find that they have faster iteration uh it's just fewer layers cut in between and of course speed is is very very important you have started full remote and you're still full remote how is it working uh and what kind of quirks or like or turbo ways have you found to to make this work better >> yeah I think so the the company started in in 23. So sort of like on the on the on the cusp of COVID where a lot of companies were just remote. Um the Shopify infra team was remote since the very um very beginning because it's very difficult to get them all to move to Ottawa. >> Um and so it was natural to me it's like okay I think there is kind of maybe two cities where you can build a database company fast and that's San Francisco and and maybe New York. There are maybe other cities, right? But that's like kind of where it's been done. >> Yeah. >> And so if you don't want to do that, I think you have to go all in on on on some distributed model. >> And so we've tried to figure out what does that distributed model mean for Turppuffer? It doesn't mean the absence of in person. We get everyone together twice a year in in some in in some location. Uh earlier this year we were in in B, right? And then we were in Mexico City and so on. So it's like that's that's not that uncommon. Um but one of the things that we we we've been trying to do is we have this concept called campfires. And the concept of the campfire is that when a couple of people just sort of randomly congregate in a place, you call it a campfire and you encourage as many people as you want to come and join. So for example, this week is a Turbo Puffer campfire in San Francisco because I'm here for this conference and a bunch of other things. And so everyone is invited to come. Like we're going to go meet customers, right? We're going to put on dinners for our customers and things like that. And we just make a thing out of it and and spend time together. And uh we encourage everyone to come. We've also gone to the extent now of um we want to encourage that but not everyone not everyone needs to go to the campfire all the time. Some people just want to you know lock in and hacks into tent and that's great. We have people that just make it to the off sites twice a year and otherwise they're home they're with their families and they don't they don't spend time on an airplane. Um fantastic like that is completely compatible with this model. And there are other people at the company who are on a plane probably every two weeks. Um, we had someone the other day where they saw a campfire happening in New York and everyone was dialing in from a meeting room in New York and she had so much FOMO that she took an Uber straight to the airport in Ottawa and flew to flew to New York to hang out with the team, right? And I think that's fantastic. Um, and we've also introduced these things where um, if you if you uh, if you do a conference talk or a blog post or something like that, a turbop or something a bit extracurricular, we give you a turbo credit and a turbo credit allows you to upgrade your next flight to business class which again encourages spending time together with the team. Um, and now I mean turbo credits are probably going to take on a life of their own. Someone was talking about doing a central bank and doing interest rates on the turbo credits. um and doing a betting market on the turbo credits. And so like this might take on its life on its own. Um and uh you you know if you um if you're at a conference like this, there's some of the our engineers here who are just want to interact with customers and be on like and standing on a like expo floor all day is quite taxing. And so if you do that for two days because you want to do it, oh, you get a turbo credit, right? And so it's just like these fun little things that we try to do to to to encourage people to meet if they want to meet Thank you. Well, in this session, uh, what I found very interesting is Turbopuffer is a so many AI companies are using you as an infrastructure layer, but in this conversation, we managed to talk very little about AI and a lot more about engineering principles, pushing, being curious, and the human connection, how important it is for people to work together, to trust each other. So, just thank you very much for that. So, let's give a big round of applause for Simon. >> Thank you so much. This is great. Thank you. infrastructure for the meta super tangentes lab and their infrastructure organization. Today we're going to be talking about production val for authentic systems. When most people hear the word valuation, they think about benchmarks. A model scores 90% on a benchmark. A new version scores 92%, the team celebrates. But agent systems have fundamentally changed what the evaluation means. Today the systems don't simply generate answers. They plan, they call tools, they retrieve information, they execute workflows, they interact with the production infrastructure. The question is no longer did the model generate the right answer. The question is did the system behave correctly. Today I would like to discuss how evaluation is evolving from model benchmarking into production infrastructure. This is the problem almost every AI organization is encountering today. Offline benchmarks continue improving. Yet production reliability often remains unpredictable. Why is that? Because benchmarks measure model capability. Production measures system behavior. A benchmark doesn't capture tool failure, API outage, context changes, user variability, longunning workflows. And as systems become more autonomous, the gap between the benchmark performance and production performance grows. The result is what many teams All right. Hello everyone. Um, my name is Kevin. I'm going to be talking about anti-gravity. So, are there any World Cup fans out there? Woo! Imagine you are coaching Argentina and you're in the 89th minute and you have Messi on your team. What play are you running? It's called give Messi the ball and get the heck out of the way. LLMs aren't just role players anymore. They can be your star player if you build the right product around them. And to let your star player cook, you have to get out of the model's way. We might want to get the slide. Are the slides up? Oh, they are. Great. Um, so anti-gravity is Google's agentic coding product for technical and non-technical users. Uh, we launched back in November of 2025 and have been accelerating devs both within Google and externally ever since. My name is Kevin How and I lead the engineering team on anti-gravity. So let's talk a little bit more about what anti-gravity is. We have and always will be unapologetically agent first. So, we debuted the anti-gravity IDE last year with a brand new agent manager concept and it was a platform to manage and orchestrate many agents. Since then, we've actually extracted our agent and launched our own anti-gravity CLI. And last month at Google IO, we had the pleasure of launching anti-gravity 2.0. In the theme of getting the model out of the way, we actually decoupled the IDE from the agent manager. So, now you have two separate applications. Um, and now you can use the agent manager in a standalone app. And since pictures are worth a thousand words, here's a screenshot of anti-gravity 2.0 in action. As you can see, not only is it your own dedicated mission control for your agents and projects, you have sub agents, you have all the new models, you have work trees, scheduled tasks, voice mode. There are so many things to unpack with the product. But I don't want to spend today telling you about the product. I want to tell you a little bit more about the behind the scenes, some of the principles that went into it, and notably some of the things that led to its roadmap. So, as some of you, for the longtime AIGE fans, uh this is actually my fifth time speaking at AIG. Um, and I've been building developers tools since 2022. And the one thing that has stood above all other lessons that I've tal talked about is the idea of scaling with intelligence. This means that as the model gets better, so should your product and the frontier edge of whatever model you are serving should be apparent inside of your users's product experience. So let's get into more concrete examples of what this means. So for those of you that follow me on X or hear me just yap generally for the last four years, you'll know that I've been working on a number of these sort of transformations year over year over year. In 2022, I was working on autocomplete and chat sidebars. This was based on embeddings, rules, files, as syntax tree parsing. Basically, everything inside of that app is deterministic because that's all that the model could really handle. And in 2024, when agents came onto the scene, it completely changed how developers were going to do work. With it came new primitives like MCPs, custom tools, and permission systems. And with 2025, we introduced anti-gravity's agent manager with many other products following suit in that similar form factor with users managing many agents at once in parallel. And this led to things like skills, hooks, artifacts, and a couple other primitives. Um, and that sort of defined the 2025 era. So, let's talk a little bit about 2026 and what those primitives might be. Before we answer this question, I want to take you back to some of these battle scars that are a little bit closer to home. Scaling with intelligence really is not easy. It's really hard to take away something that users love and are familiar with to lead them down potentially, and that's a big keyword, a better path. We aren't right 100% of the time, but there are two that jump to mind when I was putting together the slides for this talk. The first one is giving AI a terminal. We all remember fears about son of Anton deleting your entire codebase and doing catastrophic things to both you know your startup your company etc etc. But as models got better and people invested in primitives such as permission systems users ended up building faster they ended up shipping more and they did so safely. So we were able to overcome this and as models got smarter they were able to make better decisions about what they should and should not run in your terminal. The second instance is um this tweet which is very representative of sort of the yelling that I got uh when we removed chat from windsurf. So a lot of users were yelling at our team because we took away something that was very dear to them the chat sidebar and replaced it with only an agent. Now at the time this is something that was familiar and rather difficult to swallow. But when we look back models have advanced multi-step research agentic research and execution became the new paradigm. And here we are today using and loving all these agentic products. And so now I bring you to today's battle. What is going on today? So we decoupled the agent manager from the IDE. And with anti-gravity 2.0, we split them into separate applications. We believe that the IDE is to the agent manager what the debugger was to the IDE. You don't always need a debugger, but it definitely is helpful to have it if you need to go a layer beneath and go one step deeper into that abstraction stack. And our prediction is that this idea of agent orchestration, you can call it agent teams, you can call it swarms, you could call it software factories, is the future. And we're willing to bet on that future. So here are the primitives for what we're calling the agent teams 2026 era. These are things like sub aents, generative UI, and sidecars. And we'll talk more concretely about what those things are and some examples of how they manifest inside of the product. But it's really important to first understand the why. What brought about these changes? And what model changes? What model properties actually led to the development of these new things? And as a product team, do you force the new era of primitives or is it something that comes to you by using the model and experiencing the model? The answer is kind of both, right? And the privilege of being inside of Google DeepMind is that we do have that relationship between the product and the model. So you remember the crux of anti-gravity 1.0 is to manage agents in parallel to put the human in the driver's seat. And if you remember my last talk, I talked a lot more about this research product flywheel. And now as promised, because of the anti-gravity product, Gemini has now learned a thing or two about how to manage a team of agents. There's still a lot of headroom to make multi- aent systems better, more collaborative, better at deconstructing tasks into smaller tasks, but we've got a really good head start with Gemini. And all the basics have been imbued to the model so that we can build a product like anti-gravity 2.0. Gemini 3.5 Fl Yeah, Gemini 3.5 Flash was launched back in April. And this brought to market a lot of those capabilities that we had been working on in the background with anti-gravity. And Flash now isn't just good at executing tasks. It's actually really good at leading teams. It's faster and cheaper, pushing the paro curve of what is intelligent versus the speed and the cost at which you run those things. And putting this all together, we were really excited to announce agent teams in public preview inside of anti-gravity. All you have to do is simply type the slash command/teamwork and you'll see a new mode where you can enter and unleash a swarm of agents onto the task at hand. So we'll talk a little bit about how this works. You as a user will specify your task. The more specific you are, the better. Though the nature of these agentic communication styles is that if it needs something more, it can actually ask you for more until everything is basically clear. You'll work with that lead agent and it will manage a team of arbitrary size to get that work done. And what I like to say, it's kind of like the Avengers, right? It'll take a bunch of specialized roles. It may front-end engineers, backend engineers, infrastructure specialists, QA, design, the list goes on and on and on. And there are infinite possibilities for what each of those sub aents could take on. Each sub aent is dynamically generated and can operate independently. Um, and it can even actually select a different model from what the main agent is using. And this is done so by that main agent. Again, we are scaling with intelligence. And one of the coolest aspects of this is that it can use generative UI. With a model that is as fast as Flash, things can happen nearly instantaneously. If you ask, hey, what is the status of my task? show me a cananban of what's going on or maybe you know you prefer something a little bit more like uh the the Chrome debugger tool. It can show you a timeline that all these things are generated on the fly because it's able to generate UI on demand. So some of the projects that the system has implemented um we've built a photo editor can actually edit raw photos directly inside of your browser. Um we've also built a messaging app that might look a little bit familiar to those in the room. Um, and each of these took hundreds of sub aents uh and took almost half a day to run. But to really put it through its paces, one of the hero runs that we did was actually building an entire OS kernel. This is something that uh we got to show off at Google IO, but we built a complete OS kernel from scratch and actually played Doom on it. And my colleague Verun was able to demo this at Google IO. We were super proud of this particular milestone because it really demonstrated that if you throw more intelligence, you throw more sub aents um at this sort of problem, a model like Gemini 3.5 Flash could do this in a way that was not only very very powerful but also scalable and you know mildly affordable. Obviously, we're not going to spend thousands and thousands of dollars to build an OS kernel every day, though it is possible. And some of the stats out of this, it took 93 sub aents over the course of 12 hours, made 15,000 requests, two billion tokens, and it was under $1,000, which was one of the really cool aspects of this project. And so, as you can see with this particular example, sub agent primitives are one of the defining parts about building a 2026 era of agent teams. So, agent teams are just that first example. And I want to show you another example that our team uses internally that sort of demonstrates some of these new primitives. Um the second one is about automating research tasks. So we work inside of Gemini. We help sort of make Gemini better at coding related tasks, agentic related tasks. And this is where the real magic starts happening with the product. We have an internal version of anti-gravity that researchers, engineers, nontechnical folks can use. And when they understand the primitives that anti-gravity offers, it becomes a very very powerful way to automate your own workflows. So we'll take the example of sidebyside eval analysis. So this is a very common workflow not only at DeepMind but just generally in the industry. You essentially will take multiple rollouts 1 2 3 4 etc. Um and you want to compare them. So you'll take a set of tasks, you'll do some rollouts, you'll get some results and they'll essentially be in two different tables. Now you'll look at the control, you'll look at the experiment and then you'll have to figure out not only what the difference was but perhaps what are the reasons for those differences and how can we actually iterate from there and make a better version of for the next experiment. Now traditionally this was a lot of Jupyter notebook elbow grease essentially but when you start working with the new primitives in 2026 you end up with a lot cleaner of a workflow. So researchers were able to automate 90% of this workflow by simply asking the agent about the eval in question using natural language. Then the agent that is now primed with skills and an understanding of Google's massive monor repo codebase is able to crunch the numbers and get back to you with a delta. Now what's really cool here is instead of just taking that delta then handing it back to the user, it went the extra step. It spun up for a research agent specialist that proposes a hundred different hypotheses over why those deltas might occur. And then it uses sub aents to then spit up one sub aent for each hypothesis and basically drills into that particular case in parallel mapping back to a single response and then telling the researcher, hey here are some areas that I found. Now uh here's a report that you can review. And what's really cool is that it doesn't stop at just the report. It actually puts together a generative UI for you to look through, interact, select dropdowns, filter, segment, slice, and actually interact richly with that data. And internally, we care a lot about this sort of workflow, improving the model, improving the product, and understanding the ways that users find success and failure internally at Google. So, what used to be a very manual process now takes minutes. So, what used to be handineering, you'd have to build your own async pool of agents, you'd have to set up your judges, uh you'd have to tape together data pipelines, all of this now starts becoming grounded in these new primitives that we've established earlier in the slideshow. You have a sub aent graph that is completely dynamic. The generative UI comes in at the end to richly convey the findings in a way that the user best understands or maybe caters to their learning style. And all of these things can be regenerated and redone on the fly. All the user had to do was load up a skills file and ask away. So with teamwork and this eval example, we start arriving at these 2026 primitives that I keep talking about. And these model characteristics really change the way that we have to think about the product and how we have to develop the product. So the three examples that we've talked about, first we have the dynamic sub aent. And to provide a little bit more color here, basically no two sub aents are the same. The main agent is the one that is orchestrating this entirely on its own. It's configuring and prompting and seeding these sub aents on the fly. They can operate in parallel. They can operate in different types of secure environments be it a sandbox be it a remote execution system and they can all take on infinitely an infinite number of specialized roles. So the scaling story here is quite obvious and from the last two examples you can probably tell as the model gets smarter your team will become more specialized it will become more collaborative and ultimately that means it'll be capable of getting more complex work done for you. And now the second is this new concept. We've alluded to it slightly in the past, but it's called sidecars. This is a new plug-in protocol that we're bringing to anti-gravity. A sidecar process is essentially it is a sidecar process. The naming sort of reflects what's going on under the hood, but it's a longived utility and it's responsible for listening. It allows the model to listen to the outside world and set up its own triggers for things that might happen. For example, this could be SMS messages. This could be web hooks, cron jobs, hooking it up to GitHub PRs, the the list goes on and on. But this is a generic plug-in primitive. Anti-gravity already uses sidecars for things that are timebased. This is where the the scheduled task cron concept comes from. Um, but under the hood, this is all this new sidecar primitive. So, we'll be releasing the spec for this so that you all can build on top of this new primitive um later this summer. But there are some really, really cool ways that people internally have been using this sort of concept. And the third and final primitive is generative UI. So we hypothesize that human written specialized UIs are kind of dead. Gemini Flash on anti-gravity clocks in at almost 900 tokens a second. This is 10x faster than a lot of the other frontier model experiences. And in a matter of seconds, you're able to go from whatever you were thinking inside of your head into a prompt into a use case that is designed and embedded inside of your conversation view perfectly. And rather than rely on templates or even HTML files, anti-gravity can render your generated UI in line. So you can do things like this and play Doom, but this also extends to things like bar charts, graphs, um, tables, anything that you would want to interact with and maybe inspect a little bit further than just a markdown file or just a conversation. And generative UI in many ways reminds me of the quote that the late Steve Jobs said when unveiling the iPhone. He justifies the removal of the keyboard and says they all have these keyboards. They are there whether you need them or not. And they all have these control buttons that are fixed in plastic and are the same for every application. In an analogous way, we built our product to dynamically scale with the needs of the agent. We skipped the heavy infrastructure and mechanical UIs in favor of sidecars and generative UI. And that creates a product experience that is not fixed in plastic. So sub aents, sidecar triggers, and generative UI are the latest primitives that are powering anti-gravity. We've tried our best to stay out of the way and let the model cook. And if you're building a product around an agent, you should consider what are the primitives that are in my product and how might they scale with the model's intelligence. We all are familiar with shipping features is now quite easy with all of these new tools. And it's about deciding what features to actually add um so that the model so that your product can scale with the next release of the next model which will inevitably be faster, better, and cheaper. And so with the right primitives, you as a builder or you as a product owner, you might be surprised at what the models can do. And in classic fashion, I'm going to keep using the slide until we've actually conquered the TPU crunch. So you can find me on Twitter. Uh you can DM me for feedback. We're always looking for new ideas on how to build the latest and greatest. Thank you for watching. Thank you Swix and Ben for having me. It's always a joy to be here. And I'll be at the anti-gravity booth if you want to talk further, if you want to get to know the product a bit more. Some team members will be there. So, thank you so much for your time. Excited to meet you all. Not for human. In 2026, coding agents will quietly retire their first software platform. Not because it's bad, simply because the platform is unnecessary. I am Dominic Turno. I am founder and CEO of Resonate. Resonate is a durable execution platform built with minimalism and simplicity as its core technical values. And these properties will play a central role in this talk. At Resonate, we have a working theory where software engineering is headed. Generalpurpose implementations will increasingly be replaced by bespoke implementations generated on demand, not as a new library, a new framework, or a new platform, but as a minimal extension of the infrastructure that is already in place. If this theory holds true, reuse will move upstream. Instead of reusing a general purpose implementation, we will reuse a specification and we will derive a bespoke implementation from it. In fact, we can build many bespoke implementations tailor made for the infrastructure that is already in place. We just have to ask the agent. At this point, the prompt is a platform. Resonate is a dual execution platform. We have an implementation of the Resonate server. We have implementations of the Resonate SDK for TypeScript, Python, Rust, Go, and Java. So, we have to ask what does this new reality mean for us? If implementations become generatable, where does our value live? And our answer, our value moves from implementation to specification. Now this changes how we think about Resonate. The product is no longer the implementation. The product is the specification, the protocol. And from that protocol, we want to derive multiple server implementations. One is a general purpose resonate server, our reference implementation. Others are implementations built with infrastructure partners. For customers and partners, this means durable execution right on top of their existing infrastructure with minimal additional dependencies. So the question is no longer can we build a server. The question is can we repeatedly synthesize trusted servers from the same specification and if so how? When we talk about agentic engineering we focus all of our attention on verification. How do we know the result is correct? But today I want to focus on the specification instead and more importantly how can agents participate in specifying the system not just building or verifying it. Now Resonate is partnering with multiple infrastructure providers to bring durable executions natively to their technology stack. One of them is Senadia the company behind Nats.io an open-source messaging system designed for building modern distributed systems. for the rest of this presentation. Okay. Hello everyone. I'm excited to be here. Uh my name is Zach Lloyd. Um today I'm going to be talking about self-improving software factories, the new open- source model, and basically what I think is happening to development. A little bit about me just to begin. So I am a former uh principal engineer from Google, lead engineering on the Google Doc Suite. I've been an engineer now for over 20 years. Long time. I am still uh shipping frequently, but I haven't written a line of code in the last six months. Uh and I'm the founder of a company called Warp. Uh Warp, if you're not familiar, is a open-source agentic development environment. Uh you may know us as a terminal. That is how the company started. We're basically a terminal that has agents built in. Uh we open sourced it a couple months ago and I'm going to talk a little bit about that experience and the motivation for it. It's popular open source project over 60,000 GitHub stars. We've had a couple hundred people contributing. We have over 800,000 active developers who are using warp. And increasingly we are focused not just on the terminal aspect and the interactive aspect of development but more so on how do you automate development. I'm going to talk mostly about that. So the thesis that I have uh is that the discipline of software engineering is going to become something more like factory engineering and I'll explain what I mean by this in a minute but just keep that in mind. That's that's what I think is going to happen. Um if you look at development over the past couple years it's I mean it's crazy how it's changed. We've gone from a world of chat and AI autocomplete, so cursor co-pilot, to the phase that we're in now, which I consider to be mostly interactive agents. So you're sort of sitting at your computer and you are telling cloud code to do something, you're telling warp to do something. And I believe what's going to happen over the next six months, a year, hard to predict the pace, is that we're going to move much more towards a world of automation. But before I get into that, just quick show of hands. How many folks in here are building with agents? Every 100% makes sense. Uh how many how many folks are building typically with multiple agents at one time? So again, almost everyone. How many people are running an agent right now? I'm not offended. I would Okay, that's totally cool. I would be doing it too. Uh how many folks are running agents in the cloud out of curiosity? So that looks like less than half but still significant. Uh and how many folks have have set up a system internally to automate the whole software development life cycle. So everything from like triaging, specking, implementing, reviewing. So I see some hand. So some people are doing this. So this is what's going to happen. Uh, every project of significant size, I believe, is going to have something like this. Um, and it's going to look kind of like this big loop. And everyone is talking about loops. There's nothing that complicated about loops. This loop says a cloud software factory. This loop could literally just say like the software development life cycle. It's the same thing. Um, but just to go through this loop, it's like ideas are going to come in at the top. Agents are going to do triage. If something is complicated, they will write a spec. Uh these little blue boxes are where humans step in. Humans will review the spec. Uh agents will do the implementation. A human and agent will review the code. Agents will verify. Human will review the product. You ship and then you monitor and round and round you go. Uh and this is what software development for better or worse I think is going to end up looking like. So I repeat the thesis which is that if this is what software engineering is going to look like um software engineers are going to be the ones who end up building and managing these factories. Now I promised at the beginning and I put in the title of the talk that I was going to talk about open source and so I want to do that for a few minutes. I'm going to take a quick digression. Um, I bring up open source because one of the main reasons that Warp opens sourced was to build uh build a public factory. Um, and so this is a picture of this website we've built called build.warp.dev which shows all of the issues that are flowing through our system and what state they're in, what agents are working on them, what contributors are working on them. And it's kind of like a protoactory done at scale. It's not working perfectly, but it is working. And one of the reasons we open sourced was to try to build this. Um, just in general, I think it's interesting to talk about open source in the time of agentic development. This is a really stupid graph, but it's like it just it you get it. It's like it's becoming much cheaper to build software. Um, a correlary of that is that it's becoming trivial to clone software. And so if you are in the software business, and I don't know how many folks in this room are in the software business per se, but it's very hard to build a software business if it's free to build software. It's hard to capture the value, especially if a competitor can clone. And so my big takeaway or big tip for everyone in here is that the first thing you should do is patent your code. I'm kidding. Don't This is a complete joke. Don't don't don't do this. Uh my my first tip is obviously you need to have a great product. Uh this has always been the case. Um but I would say a great product probably was never enough. But even now more than ever, if you think that you're going to build a great software business just by building and shipping a great product, you're probably not going to succeed. Uh you need advantages beyond the product. And so those advantages could look like distribution ecosystem. It could be that you have a great brand or a data moat. You might have capital. Um, but if you're a startup, again, I'm coming from the startup world here, you just don't have these advantages. And so, you you still want to break through. Uh, and one of the ways that I suggest doing this is by building in the open. And so, to be clear, it took Warp five years of building closed to sort of make the leap into building in the open. And I'll explain why. But if you build in the open, um it helps build your ecosystem. It it can take you from being like hated on hacker news to like tolerated. Uh it can burnish your brand. It creates community. And so there's all these advantages to it. Uh and some of the things that I think have traditionally been a pain um can now be managed. And so like the traditional, you know, pain of open source might be something like you get a lot of noisy issues. You get sloppy PRs, you can end up in code review hell, you can end up having to spend a lot of time verifying changes. And so the solution, it's a kind of a long-winded way of getting to this for open source or at least for Warp in the case of open source. The thing that made us finally decide to do this was that we built a whole set of automations, really a software factory around managing the open-source project. And so, like I said, this is what I think the future is going to look like. I'm going to drill into it a bit just to get a little bit more technical for folks who want to try to build something like this for their own projects. So, what are the components of an effective software factory? Uh it's really not that complicated to start or at a high level. You need a set of automations. You need a way of providing context and skills. You need a way of bringing humans in at the correct time to sort of like when things get stuck on the factory. And then a really important thing is you need some set of self-improvement capabilities. So think of this as loops. And if you do this right, uh, in the open source world, you can get a, you know, world where agents are helping contributors contribute. They're helping maintainers maintain. And I want to emphasize there's nothing special about open source here. I think every sizable project can benefit from this approach. And I I predict that every every company, every open source project will have at its core a software factory. kind of like the way that CI/CD became just like, oh, of course you have that. Uh maybe I don't know when that happened 10 years ago. Let's tour the t uh the factory floor for a second here. So, you're not going to look at this. This is too much. Uh the the point of this slide is not to have you read the workflow. It's that the factory floor is basically a graph um of steps where you are defining like okay, how does software get built for my product? And it looks pretty similar for every product. Things come in, they flow through, um, they get stuck at certain points. Um, and you know, broadly speaking, just to back out a second. So there's the inputs. The inputs are really ideas. Um, the inputs could be coming from your team, they could be coming from your users. Um, the inputs themselves tend to come in through certain channels that you should think about as like your task tracker is an obvious one or Slack, your teams, like your communication channels. They could come directly from like your terminal or IDE. They could come from your monitoring systems, but there's some set of inputs that bring work into the factory. There's triage. This is a really important step. So again, I boil it down to something very simple, but like you want an agent that is looking at issues as they come in and just saying, you know, if this is easy and this is unambiguous, just implement it and this is how you can actually get going with a factory. If an issue is hard, uh I recommend having uh an agent that produces specs. Folks in here using spec driven development, show hands, people follow this. Okay, you can do this many different ways, but I think it's very effective. The way that uh we do it at Warp that I recommend is having an agent write what we call a product spec and a tech spec. Product spec describes the product invariance that you're building towards. Techsp spec describes the architecture and the shape of the code. Then you have an implementation agent. This is basically a coding agent that runs somewhere in the cloud. It makes a diff. You can use all sorts of coding agents for this. You have review. This is in many ways the most painful part. Like I expect that people are a little bit tired of reviewing a gentic slop. Uh I would have an agent do code review first and then it becomes over time like a riskmanagement exercise of like when do you bring in humans to do code review. But you want to have a step in here where humans can do it. This is a very important step uh for certain types of apps. The verification step. So this would be things like computer use. Uh if you're building a a sort of UI, having the computer actually use the code that the agent produced and producing videos and screenshots. CI/CD still use it obviously. Uh and then monitoring. So agents don't stop in your factory when code is shipped. They should observe what's been shipped. Is it crashing? is it being used? And round and round you go because you take the output of this monitoring step and you feed it back into the top of the factory. Now you could try and build this and um I went to a talk earlier that my friend Adam gave where Uber has built an internal version of this um and it's pretty cool. I would say for most, you know, most organizations, it really depends where you are. You'll be able to build a simple version of this easily, but to build a thing that actually scales is probably like you should probably be focusing on your own product, not building this infrastructure because there's a lot of stuff that you end up wanting. You're not again not supposed to read this. Uh it's just a lot of stuff. If you do build it um or if you buy it, you'll end up with something that looks kind of like this, which is um you're going to have a bunch of ways of getting work into your factory. That's what's at the top here. You're going to have a sort of control plane for figuring out how work gets distributed across your factory floor. You're going to have the actual place where the work happens. And so that's going to be cloud sandboxes. It's going to be figuring out what agent to run. So, what's the harness? What's the model? And then finally, I think this is a really important thing. You're going to want to set up some kind of data plane that sits below your factory. And so, that's something that lets agents remember what they've done, learn, um, improve over time. The factory is not just like a product, it's also a mindset. And this brings me back to the thesis I had at the beginning. You need to measure and improve. So factory, this is where the I don't know, you can stretch this metaphor as far as you want, but like you should be thinking of efficiency. And so that means like how much software did you ship? How much did it cost in terms of human time and token time and you're going to want to measure this and try to improve it over time. A key part of this is creating loops. So, uh, loops are again, they sound complicated. They're not that complicated. Loops are basically ways of, uh, having agents improve, um, by like observing what they're doing, where they're failing. Um, and so a common kind of loop that you're going to want to put in your factory is like a skill loop. That means you're going to have your factory agents that are running skills, and then you'll have observer agents that are seeing how those skills are being applied, looking for issues, and trying to improve the skills. So for instance, if you had a code review agent uh and it was leaving comments and a senior engine engineering or team was going and correcting those comments, you'd want an observer agent that would look at that and basically uh improve the code review agent for the next run. This is one thought just to leave folks with like what is where does this leave engineers? Um, I think you're going to have to get into this mindset, and I'm trying very hard to get our team into this mindset. It's not always easy that you're not just building the product, but you're building the thing that builds the product. And that's like it's just different. It's more like process engineering or manufacturing or something like that. Um, and you could think like, okay, maybe that's a bummer. Like, is that a bummer? is that uh you know and it depends like it depends what joy you get out of software engineering. If your joy is in writing the code, I think you're everyone in here who is a software engineer is going to be writing less code. But if your joy is in shipping product, like it's never been a better time. And this is actually where I find my joy. It's like I like building and shipping the thing. So everyone in here is going to code less, but they're going to ship more. And that's going to be a trade-off. But if you approach it like you're a a factory engineer, I think you can see like that there's still a really cool set of engineering challenges. Um you could almost think of it as like meta-engineering like how do you engineer your system of agents to be the best possible engineering that I think is a very compelling and interesting set of challenges to solve. So that's it. Um uh for folks who were interested uh this if you follow the link on this QR code I've set up um a open source GitHub repo where anyone who wants to try building their own factory agents can do it. This uses Warps uh agent platform as part of it. But you honestly you don't have to use it. I'm not trying to like push into our product. But this should give you a good sense of like, okay, if you want to set up uh an agent that does uh triage or an agent that does uh specw writing, how do you actually do that? How do you get from like the theory of uh working with a factory to actually putting it into practice? Um I don't know if we have the capability to do questions in here. I saved a few minutes for questions if anyone has questions. Otherwise, I will I will wrap up. Yes. Yes, >> it's a great question. So, I said something that's almost contradictory. I think um you should the way you should think of it is like everyone's going to deploy some sort of factory, but then the tuning of the factory, the like are these the right skills for my domain? Is this factory building my product in the right way? I still think there's a bunch of interesting engineering challenges and for some places you can build this but again I I think I think that the you should probably be focusing on building the core product for your company for the most part but there's a bunch of like tuning and like uh figuring out how to make the factory work for your product that matters. That's a great question. Yes. >> Yes. Yeah. So the the question in case people couldn't hear was like if I was a college student graduating and entering the workforce right now. So I think that the most important skills in this new world are adaptability. I think that that's critical thinking. It's like this the speed at which you can learn. I do think I don't know if you're a computer science student, but I still think there's a ton of value in understanding like the underlying systems and architecture and being able to reason and understand the code, understand the specs that agents are written, sorry, our writing. So, I I would focus on on those skills. Um, and like I don't know, we're hiring more people than we've ever hired. There's a lot of kind of like misdirection around like you know people not being hired because of AI. That's not the experience we've had so far. And what I'm looking for are like really adaptable product focused thinkers who can like basically be great problem solving problem solvers uh even as the underlying technology changes. Yeah, I think I have time for one more question. Yes. What about the like so the question was what about the the product taste and like the how do you actually build something useful I think is probably the right like maybe the framing and like uh where do the ideas come from and so I think that um the problem with the factory metaphor even though I'm like leaning into it because I think that's like there's something to it is that it can kind of sound like uh mechanizing or dehumanizing um and I still think underlying ing all of this, the only thing that matters is like are you building something useful? And if you have like a a factory that is like churning out that no one cares about, it's like what's the point? And I think that human taste, human input, human product sense, um humans like guiding at those touch points where you can't automate stuff is absolutely like essential. And like that's like what I do like I'm trying to figure out what what do customers want, what do people want, what's going to be valuable to them. So I think that's an absolutely key point to it. I think I'm at time so I I have to go. I hope folks uh enjoyed this chat. Uh really grateful for being invited to speak. So thank you all very much. Yeah, agents in production. Specifically how open gov built and scaled ogassist. Uh so um this presentation is going to be jam-packed with just so much good stuff. Uh we're going to talk about uh AI agents. We're going to talk about our harness. We're going to talk about um eval observability traces. We're going to talk about um tools and skills. Um it's there's going to be a lot of good stuff in here. We're going to talk to you guys about uh what we do at OpenGV and how we operate at the scale that uh we operate at um in production. So you'll be able to see a real use case and workload uh with AI agents. Um so without further ado, let's get started. Okay, agenda. So just really quickly going to go through uh high level what we're going to talk about today. Uh I'm going to tell you guys a little bit about OG Assist and what uh OpenGV is. I'm gonna tell you guys the origin story of how this all kind of came to be. Uh we're going to talk about OGs uh big bet on effect uh a little bit into our core agent loop. Uh we're going to talk about the A2A protocol, eval. We're going to talk about how we manage long context. We're going to talk about um monitoring observability, how we collect feedback uh and how we iterate on that feedback. We're going to lastly uh also talk about tools and skills and how at open gov uh we use um AI not only externally uh that we uh serve to customers but also internally to improve our development workflows. Just a little bit about me before we go any further. My name is Gabe. I'm a software engineer here at OpenGV. I work on the AI agents team and uh I'm one of the folks that helped build uh OG Assist and some of the systems that you guys will be seeing today. So, a little bit about OpenGV. OpenGV is a software company uh on a mission to power more effective and accountable government. Um so, OpenGV sells ERP software. That's things like budgeting, procurement, asset management, and permitting. And um we were founded about 14 years ago. And what's cool is um we have this thing called OG Assist. And OG Assist is this little button on the top of all of our products in the in the navigation bar. And what's cool is um all of our product suites and product teams um have built tools and skills in order to power this button. So, for example, if I open up uh this this um if I click this button and I open up OG Assist, it says, "Hey, um I'm going to ask about rate codes, which is very specific to utility billing, the current product that I'm in." And you can see that inside of this kind of chat interface, I'm able to speak to an agent, and the agent is able to make tool calls in order to um look up information against data inside of that suite. So, it's really cool um to be able to kind of first party create these experiences uh through the capability that we've built called OG Assist. Okay, so just a quick story about how this all came to be. So, um, a little while back, we we we saw that AI was really starting to take off and a principal, uh, spun up this new team called the AI agents team and asked me to join and, um, instantly I said yes and OG Assist started to to grow and we started to integrate, uh, OG Assist into all our products and, uh, not only our back-end capabilities, but also our front-end capabilities as well. So, you'll see that one of the capabilities that we give the agent is it's able to um see what's on the screen and and see and and and take action on what's on the page. So, you could see that um I'm asking the agent here, hey, hey, what's on the screen? Can you maybe highlight uh some of the next steps that I could take? So, you can see that the agent here is thinking. It's saying, okay, what tools do I have available to use? And hey, let me go and highlight something that you could actually click on and and tell you more about it. So just another capability of OG assist and just a little short story about how this all came to be. So the big bet on effect. Um, so I really wanted to include this slide because um, here on the agents team, we made a huge bet to um to to bet on effect and suffice to say it's paid off in dividends. Um, we write effect. So effect is this library for Typescript. It's open source and it helps you write better um, TypeScript code. uh you know it's got a lot of uh stuff baked in it like a sk a schema similar to like zod if you've ever used that. It's also got um things for error handling uh for logging for traces for uh it's just got so much in there. It really helps write better code and structure your code better and uh helps with architecture, spinning up new services for uh and and for us on the agents team really helping uh design and build the the core agent loop. So you'll see throughout this presentation sprinkled in um how effect on our team uh has paid off in dividends. So we we really love effect here at open gov and we encourage other folks to try it out and um yeah let's keep going the effect native loop. So originally we were on lang graph and that was fine until the team really started to scale uh and our use cases started to evolve. So we decided to move over to our own kind of effect native agent loop to have full regency over this uh agent loop such that if we have complex use cases or features that we need to build we could kind of get in we we had full control of the of the agent loop. And not only that but now we're fully on effect. So all the cool things you get with effect is now propagated throughout the entire agent loop like the tracing structure currency, the logging, everything is more fine grading control and it it really allows us to really unlock the full potential uh having our own agent loop from the ground up. Um so another thing I wanted to mention is on the left side you'll see a code example. This is really the basics of the effect loop that we're using. Uh we're using this thing called the effect AI package. And in that package, there's this thing called um there's a chat and a language model. So with the chat, you can instantiate like an a chat for example. And then you could stream text using um that that kind of stream text function. You could pass in a prompt. And what's cool is uh with a language model under the hood of since we're kind of doing dependency injection, we could pass in a different language model if we were to uh hot swap to another one for example. So really just having full control of our own agent loop just kind of gives us all the levers and it really just unlocks the full capabilities of the model and uh for the team as well to have full agency over this this loop. Another thing I wanted to mention is the agentto agent protocol. So here on the agents team, we've had a lot of success with this protocol. So this protocol being the protocol that Google created um kind of an open protocol for agents to intercommunicate. But um we found this very useful for uh defining our agent routes for example in the back end and our model and our schema to follow this kind of uh agent protocol. So we modeled so for example there's this thing called an agent card which you see here and it's got the name of the agent a description etc right and having this kind of rigorous protocol this rigorous spec really helped drive our development and drive alignment because you know all we had to do was um align with this spec and follow this spec and we knew that this was kind of the contract that our front end and backend and would both consume and and produce. So, um this uh I would say also has been uh very helpful for us and and what's really cool is A2A has a lot of extensions, right? So, you could extend the protocol uh add in like metadata. Uh there's also A2UI. Um so, lots of fun stuff uh with A2A protocol, but uh this is kind of what's worked for us. So just sharing that with with you folks feedback and eval. So here the quote is shipping is the start not the finish. So what we do here uh on the agency team is we have kind of multiple ways we do evals and collect feedback. Um obviously you know we'll have folks uh call in or or email us or or just let us know and tell us. But the main way is we have this thumbs up and thumbs down mechanism. And here uh someone is able to tell us, hey, this this worked really well. This was a great response or that wasn't a great response. And that signal we take and we're able to iterate on uh and we could take it back and help improve uh you know the response in the future. Um we also have automated evals. So in in the in RCI we we have evals that run against real completion. So we could test the prompt against hey did it hit some tools? Did it do what it's supposed to do? And that also helps with our accuracy. So, uh those automated evals in conjunction with collecting feedback really help us um improve our our our tools, our skills, um our harness and and that's really how we're able to iterate so fast and so quickly. Humans in the loop. So this is a really cool feature we built where we deterministically interrupt the agent loop if there is a tool call approval required. So if an agent tries Okay. Hi everyone. Uh I'm Solomon. I am the creator of Amcraft and I also created MCPUI which became MCP apps and MCP steering committee. I've done a bunch of other stuff. Uh but we're here to talk about why we're the bottleneck and why we don't have to be. So uh as you all know and use every day, agents are amazing. There's so much they can do. Uh from generating cat memes to B2B SAS apps. So if they are so amazing, we have to ask why aren't we all unstoppable? Why doesn't everyone have an army of agents that just does whatever they want? So it should be relatively easy. I mean, you just have a bunch of monitors and you spin up 25 cloud code engines and you're done. So the reality is that it's just not that simple. To do something like that, you need to a really want to use agents and secondly, once you actually spin them up, each one of these agents requires you to steer them, direct them, review them, and when it's at scale especially, it's just exhausting. We need to find the skills to allow us to do it without burning out. So in reality, we are the bottleneck. And the the cool thing here is that while we are the bottleneck, the skills that we need to do these things to uh find ourselves not burning out every time we use an agent are with us all along. uh if you try and compare it to other stuff that you've been doing outside of programming, for example, playing video games, it's not really that different. Like if if you're playing Warcraft, for example, or Sims, and you have a bunch of different uh units running around, you need to understand what they're doing and supervise all of it. How different is that from from actually inspecting agents? So I took this concept uh too far and I created Agentcraft uh which is a game inspired orchestrator uh that tries to bring all that good stuff together into work. So let's take uh a quick look of what that actually looks like and try and understand the journey that we can go through to really raise the ceiling of how humans and agents can collaborate. So uh this is a craft. Uh there's really a lot to unpack here. Uh so we'll just go through the basics really quick. Um what you see here is an agent. Uh it's an actual representation of a cloud code or open claw whatever agent that you can imagine. Uh it can be detected in your device or you can actually spawn new ones directly from Asiancraft. Uh so like I said you have like codecs and uh open code etc. at your command. >> Uh, and these agents can do everything. They're just normal agents. Uh, so I can just prompt them in this nice side panel that also has voice. So there's multimodality here. Uh, and just do something for me. >> Prompt prompt. >> And now these agents can do whatever. Uh, and if you look around you would see that the map has a bunch of different elements. So you have buildings. These buildings represent functionalities. So for example uh if you can manage your plugins or skills uh you have like integrated terminal integrated git uh you can do in your all of your work from within this space. So now that we have this and we understand the basics let's look at what we can do uh to raise the ceiling. So the first step is obviously visibility. I need to understand what's going on. What are my agents doing? So, I have this nice side panel and it shows me the different agents and what their task is and what the last thing they did is and what they're currently doing. Everything I need to quickly understand who needs my attention and who doesn't. The second part of it is we're not just limited to this. You have a map. So, I can take let's say my file system, project it onto the map and now I can see exactly what my agents are doing. Not just by looking at a list of stuff. I can actually see, okay, this agent is now working on this directory or this file. And these files are represented as runes on the map. So I can really look at each one and see exactly what each agent did and when. And now I can take this nice information because we are the orchestrator uh and use that to create linkages. And now I can create cool stuff like heat maps. So I can really easily see what's going on. And the the the other aspect is that now that we have this visibility, that's not really enough. We need to be able to react to what's going on. If someone needs my attention, I need to be able to quickly jump to it. So much like video games or RTS games or Civilization, whatever, you would click uh spacebar and it would just take you to the nearest thing that actually needed your attention. So you can really easily understand what's going on and jump from one thing to the other and answer questions or approve plans etc. That was nice. I mean it's a nice step just to have that visibility but it's not really enough. It's pretty exhausting to keep looking at what the agents are doing in the granularity of what files are they using and what tools are they using at the moment. So we need something else. Uh and the reason is that we have like two two main problems here. Uh one is that there's just too much to hold in our heads. Even if I can understand what's going on and I can see everything, I can't really do like 20 things at the same time. I can't even think of the next thing I want to do if I have this huge coding project or whatever. So I need to find some way to fix that. Uh so we can I mean we can tell the agents uh you know go through my codebase, find out what the next things I need to do are, create these tasks for me and I just click a button, I accept the quest and there's some agent that does it for me which is fun. Uh it's cool. Uh but the next problem here is that okay now I have 20 stuff going at the same time and I have to babysit each and every one and that is completely exhausting. So you could ask okay we have agents agents are amazing as we've established so I can just go ahead and tell the agent to do it for me now it's called software factories but at the time it was just doing stuff autonomously uh so you can give it like a general sense of what you want it would spawn an orchestrator and break it down for you and run it all in well in this case it's a local uh container so everything is just done in isolation and I don't need to do any babysitting the agent does it for me. On top of that, you have loops, which everyone really likes right now. So, you can do cool things like just tell it to, I don't know, scan Twitter for cool stuff you want to build or scan your GitHub and it will just create these nice uh features for you in the background without you needing to do too much up front. The bad thing is that I mean this is nice uh but what do I do when I have again I don't know I would say 20 but even five things to review at the same time it's very very hard to get that out of the way. So what I did is create uh this like review kit. So I get the entire changes I need and I get uh what files changed if you want to go like file by file or you can get just get visual evidence so you can actually see videos of what changed or photos of what changed so you can really quickly understand what you want or even run a few uh instances in parallel and just pick the best implementation out of these. So now that we have this, we have uh visibility and we have autonomy. Uh it's pretty cool. Like we reached a pretty good place in raising the ceiling of what we can do with agents, but it's still pretty exhausting. I mean, it's it was fun. Uh but now I have to ask myself, do I really need to be the only one doing this? It's pretty lonely to just talk to agents all day and trying to and you know if you look at uh what a team does for example if it's just me that's fine but if I have a team I might not even be the right person to review what's going on. So I need something else. Uh and that something is collaboration. We can just have other people join us. So the way that looks in agent craft is that I can create these uh you can call it you know war halls war room whatever uh host them it's like completely local but you can do like uh tunnels and people can join you so I can create a room and let's say I have a product designer in my team in this case uh it's my wife and I can approve uh her otherwise she'll be mad uh so I can approve her and she does her thing she designs whatever and I as an engineer here can not only see that that's that's her. Um I can not only see that on my map uh I can actually take that and follow off off of it. >> Prompt prompt. >> Yeah, that's just like her. Um so I can take that design, follow up on it, implement it while she keeps working. Uh, and the cool thing here is that not only can I hand off or fork and kind of have this shared workspace. So I'm not really bound anymore to get. I can use Git, but I'm not really bound to something. Everyone is working together. Uh, you can see that there's also some kind of chat between not only between uh the people within the room, but also between agents. So we can have this really nice notice board of exactly what each person is doing, what each agent doing. they're all aware of each other and they can collaborate much more closely uh than you normally would be able to do. Uh so for example here I can say okay I took off this design task. Uh so now we have oh by the way this is also from devices you can have like mobile and and if you like telegram you can use telegram whatever floats your boat. So we have visibility and we have autonomy and we have collaboration. So we managed to raise the ceiling. uh it's now possible especially if you're power users to do really cool stuff and use more agents and do more things. But the interesting thing here was you know if I looked at the feedback I got it's not just that power users were able to do more. The cooler thing for me was that people that had even nothing to do with agents or nothing to do with productivity, uh, come and say, uh, okay, my kids really loved it and they use it all the time to to orchestrate agents, which they didn't do until now. Uh, or you know, someone that flunked out of college because they play Starcraft and now they can suddenly do really productive stuff with it. uh and a bunch of other examples of kind of bringing communities that so far were kind of behind into this new world of productivity. So we need to raise the ceiling but we also need to uh lower the floor. We need to have some kind of way to take no probably around 90% of the people in the world and bring them into this hygienic future without having them burn out. So again I took it too far. Um and there's this uh currently named TBD um potentially loopers. Uh the idea here is okay why don't why do we need something like you know Warcraft which is potentially very complicated uh especially or might be even daunting if you're not into the granularity of what files are there are or how uh complex the UI is and kind of try to find a lower denominator of what makes stuff accessible especially now that agents are much more capable. So instead of granularity or having like exactly what files they're working on, maybe I can have it more of a mobile game level, uh have projects that I keep returning to and use loops and other stuff that rely on agents being more autonomous to have like a very basic level of I prompt, I get the result. I don't really care perhaps about the way I can see it if I want to and I have this really nice interactive and cool experience that makes me want to come back to this. And obviously I mean this is one visualization uh it can really resonate with some people but might not might not resonate with others because we're not all the same and what may appear like amazing and easy to one person can appear very difficult to another. Uh but here uh I'm trying to look at a way to make this more customizable. Try and understand what it is that you as a person need in order to understand and want to use these tools. So this is a very very early draft. Um but if you want to use it, please let me know. So we're the bottleneck. I think we've established that uh pretty well until now. But the skills that we need to stop being the bottleneck and enable this new future are already with us. So we are the bottleneck but we don't have to be. And I hope that you all can take what's relevant to you in your life and apply it forward. So I would ask you for two things. One, agent is already out there. Like you can just npx install agent as a website uh and do your thing. Uh this new thing that I just showed you uh potentially loopers uh is still experimental. I'm still trying to understand the interest and what people are actually looking for to uh get the floor that they want or the ceiling that they want. So please uh go here and express your interest and tell me what you're looking for so I can know what to do with this. And thank you. and co-ounder of styling search and today my top user signals die at retrieval boundary. So we'll look into uh what are agents essentially why agent fails what is uh the cause of fails in retrieval particularly and how to make actually signal cross the retrieval boundary and how to make your agent basically outcome fair. So uh let's get started. What is an agent? An agent is an LLM that has agency to reason, invoke tools, uh interact with the real world, retrieve uh the memory to complete the task. One major loop here is missing is uh learning. It should also learn from what worked and what it didn't work. Suppose uh if I have to uh explain what is agent, I can explain with react agent. So if I have to explain uh what agent is, I'll explain it with react agent. So basically user prompt the agent uh and execute it in a loop uh kind to a retriever search and then pause when the task is complete. This is very basic react architecture. One thing that is missing is how to make agent learn from the outcome. So Asian keeps failing at the same task got reported 85% of AI just fail. So it's in McKenzie's 2025 report. The problem came out to be most of the time is that retrieval is static. 73% of uh our app pipeline fails because of retrieval not generation and context stuffing. So a recent uh uh post from Ram Shria the execto of Pine cone said uh we have been optimizing for the wrong thing. You are paying a lot for your agent's memory. It is probably broken and we have been optimizing for the wrong things. We made wrong answers appear faster and cheaper but we forgot to make retrieval learn. So why this is does does it matter? Again uh the third column is agents are not outcoming for. So there's a missing layer between evals and action. Your obsibility has all the traces or all the stack that capture. Observility is the stack that capture every tool call every LM completion every exceptions. Your EVA suite judges whether the final output was correct or wrong. Basically pass or fail. But these evils are not reflected in agent uh context, skills, MD files or agent action in any ways. Right? So the agent doesn't has any access to why yesterday's runs uh runs past or fail. EVA signal dies in the dashboard. This is a missing layer. a system that consume traces, absorb eval and convert both into retrieval guidance for future runs. So there's a manual improvement tax and engineer actually has to sit and see if the email and obserility perform well, rewrite the prompt, redeploy it, upgrade either upgrade to expensive model, restructure to or harness or fine tune the custom models. Why are current memories failing? why memories was designed to actually address this but uh uh it's not. So let's see uh what we have in as a current system uh and current memory is that they basically store user preferences, profile, conversational history or long lived personal personalization. So chart experience is not self-improving learning systems for production. If you see uh the already existing approach in the uh market there's a uh lang chain uh there's me zero which does extracted f references it uses retrieval signal is embedding similarity does it learn from our code? No. Uh so we have come up with something called utility score which is a similarity weighted by how useful it is for the agent to execute the task. It has actually the history of past precess and past outcomes. So we came up with agent RX and that is agents with runtime experience. It's a runtime layer that let production agent improve from experiences without pre-training, fine-tuning or manual prompt training. Uh it's a bit different from compile time like DSPI because uh you bake in all the lessons in the prompt. Here it's actually improving uh while it is executing. So this uh again introduces uh utility score. So you do not retrieve by keyword. You retrieve by semantic similarity the current task weighted by whether those memories have historically helped or hurt the execution or the outcome. The EI outcome becomes a first class signal in the retrieval reanking and not just one of the key things is it treat memory as reasoning not as facts static fact with no context and no history but reasoning like suppose uh if uh if there's a if there is a customer support B looking for refund it will not say hey user prefers uh uh dark theme or user prefers uh to be called by a shorter name. It's actually a reason about the query like uh if some someone asks for refund you should check the settlement before refunding it so that the the the customer doesn't get paid uh refund twice. So rank based on usefulness context is updated based on task. So this is a very big thing uh because most of the agents fail with context stuffing and this has been brought up in the past and learned from history and reasoning right talking about benchmarks. So uh we have benchmarked uh our memory system reflect with on tow bench which essentially measure if agents have followed the policy well or not. So we have seen uh the uh uh the performance improve from 66 to 76% without baking in uh skills and with skills uh reflect performance at 80. So um once there are uh enough memory like 10 uh memories uh what we do is we bake in the uh reasoning and the understanding into skills so that your agent always remains updated. What happens most of the time we have seen suppose you have a product SQL agent and there's a system there's a column in system prompt even though that column is not useful anymore it remains in the system prompt so there's no system right now that can update that hey there's no column uh right now called this so maybe probably you shouldn't entertain it in the future and this is possible with skills that uh because agents always uses uh calls that skill uh updated skill all the time and the similar behavior has been seen in GPT 5.4. Uh we have also benchmarked it on agentic task which essentially test a model's ability to reason, plan and use tools over extended multi-step workflows rather than measuring a static Q&A. So you can see here uh with the suppose the human last exam uh with rag you get 47.5 if it is starting from the baseline 35.7 uh with the memory system it gets to 58.2 but with the ref memory system uh it gets to 61.3%. So this uh this kind of trend is shown in another uh agentic benchmarks uh as well like big code bench like long TV etc. Okay. Hello. Okay. Before I get started you guys this is a huge keynote room. Can everyone like come forward because I'm talking to like four empty rows and disperse people. Do me a favor. I'm spending 30 minutes telling you all of our secrets. I can see you still. Thank you. Thank you. Thank you. Thank you. We're just going to chat. It's a giant room and there's 500 of us. This room is way larger than that. Thank you. Honestly, I knew you guys had it in you. It's really not so hard. Thank you. I also sit in the back. I also work during talks. I get it. I totally get it. I did all day, but not for me. Okay, I'm gonna start, but I'm gonna still point at you if you're in the back like you. Okay, I'm Sarah. I'm uh lead our engineering teams for AI at Notion. Um, welcome to my talk. Um, it's about token town. How do you go from not go from AI pled to AI poor? Okay. Um, I know that today is all about software factories. We're going to talk about that, but we're going to talk about how to do it sustainably. This is me. This is on my first day at Notion in a very sweaty subway. Um, like I said, I lead our AI teams at Notion. Um, and I negotiate AI contracts for a living. My team jokes I act like Anna Winter. So, this is a nice a nice image of me with AI Anna Winter hair after a press article referred to me that externally. Um, and that's kind of the idea, right? Uh, how do you think about negotiating between different vendors? um making sure that you maintain taste for your company. I don't do it alone. Um this is launch day of one of our recent launches. This is just a subset. Any good engineering manager points out that we have a whole company of people building this. I'm just the one that gets to come talk to you about it. So, we've been building a lot. Um this is um an example of our AI usage um just in 2026. Um, and we've been really proud of how we've been able to grow that usage. And I'm going to talk to you about how you can build an AI native product and an AI native company. Um, but this is just to give me some credit that that we're doing it kind of well. Okay. So, for those of you that don't know, notion's always been that durable system of record. It's always been the place where you can collaborate with your peers. Um, but today that point of collaboration is a little bit different. It's not just humans. Notion's always been the place for collaboration. And today that collaboration happens between humans and agents, humans and humans, agents and agents. And we like to think about AI transformations going through this journey. And I'm sure some of you are looking at the slide and wondering where you are. AI as a thought partner is when we all started tinkering. We all started just going to the very first version of Chat PT on Thanksgiving when it came out three years ago, four years ago and we started saying like how can I send this email to my landlord to say that I shouldn't pay for repainting, right? Then we'd copy paste it, enter it into our email. Eventually we started getting to a place where we could use AI like an assistant. AI was able to maybe execute individual tasks. That's how notion AI really took off in the beginning. um and it was able to save employee time but functionally was limited in its capabilities based on what humans asked it to do. AI as teammates is what we were really excited to launch almost a year ago now. Um but this is true in many products. We can do repetitive work and think about a process and have AI do that process. What I think is really interesting is when AI actually becomes that critical workflow where processes are interfacing with each other and you have entire systems running. How many of you guys feel like you have AI as a system down? Aren't you sad you came up now? Great. None of you. Exactly. We have found that no one has figured out how to do this. Well, 88% of people can't even get past AI as an assistant. And why is that? We have a thesis that notion. It's because there's too much silo data and not a sturable system of record for that point of collaboration. And we believe that for your software factory to work, for your company to work, and for your systems to work, you need that durable system of record. And that is notion's mission. So doing that is expensive. Um, you see a lot of companies that try and commit themselves to this vision, and these are just a series of headlines all within a week of how that's painful. So you can put all of your money into a process to try and make a system, and you end up feeling like this. Right? You end up using a blowtorrch to light what is actually a large cigar. But you kind of get the idea. Cost is a structural barrier to entry. It makes it hard for you to serve products. It makes it hard for you to build factories. And it is ultimately, I would posit, one of the largest reasons why things do not happen at scale successfully today. And I would argue for anyone working in an applied AI company, it's something for them to be really familiar with to understand the trade-offs that they're making to build durable and exciting and enlightening product for their customers. But that's not really how the market is today, right? I'm not going to name names here, but you guys have search engines. You can figure it out. Exhibit A. A reasoning model gets upgraded. Amazing. The per token pricing is the same. What's not to love? You try it out. It uses three times as many output tokens. Right? Exhibit B, a model gets upgraded, but it has an entire new digit, right? Whatever marcation system that model family likes, it's brand new. It's 40% more than its predecessor, which is being deprecated in the next four months. These are real scenarios that we faced at notion. All of you are nodding because these are common pretty much monthly now. But here's the problem. Are you growing 40% in that time period? Are you making 30 3x more revenue? No. So, how do you navigate the system? If you just auto upgrade your model and everything that you're doing, you're you're giving someone a bad deal. Either your customers or your investors depending on how you charge and where you get your money. Neither are good. Fortune 5 million companies have the capability to navigate this. They can hire large consulting teams, have durable teams on their own, and build expertise on how to navigate these trade-offs. Um, most people don't. Everyone else has no ability to negotiate with leverage, and they're stuck in these scenarios. Right? Part of my job, as that Anna Winter joke, is to think about advocating for the Fortune 5 million, the non-fortune 500 companies that don't have the mass to have leverage and negotiate, but need to think about how. and I'm going to share some of the lessons that I've learned when I have kind of large amounts of traffic behind me that I think scale to those who don't. Um, this is probably less of a secret now than it was when I started giving talks like this maybe four months ago. Um, your supplier is your competitor. I know very few people who have convinced me that that's not true. um you will always be getting a bad deal on tokens with someone who builds them natively, right? Sometimes the cost of goods served is extremely different. You're basically they're serving a first-party product and then you're buying those tokens at a huge search charge and then selling them again at another search charge. Um that's not really value you can defend. You're getting a really bad deal. And if you tie yourself to one provider, you have no exit. If you build an AI product that you're selling with this structure, you are crossing your fingers and hoping that you are a viable business. I do not encourage that. This is really interesting. Dylan in semi analysis posted this. I think it's it says eight hours ago. It wasn't at this point. It was probably a month ago. um they purchased a subscription plan and they just highlighted right how different what Frontier Labs charge customers for first-party products are versus what they sell. It's a bad deal. Don't play this game or try and let me know how you win. I don't recommend. Think about everyone else. Think about what that structure means and where you have expertise. I don't think that that's winning on the token economics. I think it's about product. It's about building data flywheels and understanding your customers better than anyone else. Understanding when you need capability, when you need low price, when you need latency improvements. I promise you, you don't always need what is usually the slowest but the most capable model out there. And then build compelling UI and orchestration. And I'll show you some examples of that to justify the cost on the bad deal tokens that you do resell. The job is not to train. I mean, some of you might be training the best model and I'd love to serve it and come talk to me afterwards, but most of you are not doing that. Stop trying to win that game and think about the best product that uses many models. Help your customers, help your team. Bet on the frontier, not on the lab. And we'll talk about what it looks like to do that. This cost per capability per second trade-off is actually really intense. Um, Citadel came out with this memo um, a while ago, maybe two weeks ago. I loved it. The idea is that for the economy at large, simpler models might be the most cost-effective productivity augmenting pathway. They talk about this bifurcation on frontier versus everyday usage. I really believe that. And for every product, the definition of frontier versus everyday, the definition of saturated capabilities or model capability overhangs depends on your expertise on your product. No one can replace that. And not all traffic is equal. It is a huge miss to send all of these to the latest opus model. Some of these absolutely large scale data analysis when you do it on notion will recommend Opus, right? When you triage an email inbox, if we're charging you to do that on Opus, we're ripping you off and ourselves. Think about where your traffic patterns are. And then think about how Frontier Lab model providers are structured today. I mean, it's functionally an oligopoly, right? And that's fine because they're racing to the top. And I think the top is really hard and really important. This is not to say that products don't have a place for frontier difficult tasks. I want everyone to nod and understand that's not what this talk is about. Understand when you need those tasks and it's not everything. The problem with those tasks are is keep in mind how pricing is incentivized. You can figure out who these players are. Either you are the best model. Everything above what AI can't do today is your market. You can basically price it as high as you kind of want. If you're slightly behind that best model, all you need to be is like a dollar per million tokens cheaper and you have the rest of the market. You know that economic theory about gas stations where the best gas stations are the ones that are right next to each other because they cover east and west the most. Yeah. It's the same with model pricing, which means that price does not correlate with capability growth. So for this complex task, understand what capabilities you need, but be the expert on what complexity is. And keep in mind that who handles complexity changes. Um, oftentimes you'll see applied AI companies really be super outspoken on marketing with a specific lab. That's always kind of a red flag for me when they're not model agnostic because if you look at this graph, it basically shows that they're behind every month, right? the new model and the new model provider of the best Frontier capabilities change and if you hit your ride with one particular provider in exchange for for instance a larger discount um you're doing a disservice to your customers like half of the time, right? So really think about if that discount is worth not having a Frontier product and remember that that optionality is your leverage. If you don't have the capability to walk at any point, you are stuck. And again, I think that's probably the most expensive decision you'll make regardless of what discount you get or the engineering work to have model interoperability. One option to navigate this is stay model agnostic. Have different models and capabilities in your system so that at any point if pricing seems unfair or untenable, you are not out of business. Notion's auto model does this really well. We have state-of-the-art models available always. Um, but we also have an auto model there at the top that handles about 75% of our traffic. Right? We have the ability to switch between models in our product and we also offer it to our customers so that they have access to these models without vendor lockin. That's part of our AI Switzerland approach. You guys love taking photos of slides. This is the slide. Okay, model agnostic playbook. This is how you do it. Build for multimodal. It is hard to kill the cache and switch models mid-transcript. I understand that we invest in that technology. It doesn't even have to be per thread. Just think about your harness as model interoperability. Think about the cost per capability per second, not just the tokens. Here's a great example. We posted this review when we um announced our partnership with Parallel as our web search provider. If you were to look at just latency of a single call or just cost, parallel might not be the cheapest. But if you have expertise in entire web search trajectories, you'll see how it differs. The granularity of this eval is what lets us make the best decisions for our customers because we understand all of the trade-offs on entire trajectories, not just single calls. Switch fast and often. I think we talked about that. And give them something back. That expertise on use cases is also very valuable to Frontier Labs. We find that our evals and our early access program partnerships actually help us a lot with Frontier Labs and is something that we can exchange instead of extraordinarily large commits and I don't think the discount is ever worth the lost in optionality. That's a perspective you can choose to keep or not. The second option is moderate tasks understanding open weights place there. um openweight models are really strong enough to handle these tasks and the possibility to RL on top of them has also kind of expanded the up market growth that they can cover. I view openw weight models as basically lowering the barrier to entry on cost for our customers and they also give you negotiation leverage. So it's kind of a credible alternative that's putting that downward pressure on pricing that if there's an igopoly of two or three providers at the top is unavailable right now otherwise. I think Kimmy 26 was probably the first time that we really saw a model that outperformed 52, GPT52, GLM 52 now is another 52 bombshell in the villa that also probably does best here. But it's no longer the case where open weight models are good for just SFT on small tasks. Really think about without RL if they're capable enough for what you need. Um, and again, don't just think about external benchmarks. Be able to have expertise on your system. What are your tool errors? What's the actual latency that you need? Right? Here's an example of a benchmark that we posted. It's a little bit stale on purpose, right? But you get the idea. Philip at Base 10 this showed this slide once and I've stolen it ever since. Um, thank you. Are you here, buddy? Okay. Well, chat, hi. Um, well, he could come up and say it better, but the idea is that you don't have to be at the top, right? I'm not trying to make a case that open weight is the best model out there. Um, the case being made, however, is that um, the gap gets covered eventually. So, if the tasks that you're having today are good enough, then in six months, they're probably covered by open weight. So, be prepared now. And the last thing is CPUs over GPUs. Um, we've we've recently launched something at notion called workers. I don't think that the GPU is necessary for every job. A lot of the jobs that we have are actually serving um discrete pieces of code. Like you don't need an LLM to turn a CSV into a PDF. You don't need an LLM to talk to notion tool calls if we have a CLI. You definitely don't need an LLM to do deterministic SQL queries. This is where people become token poor very quick. And I think the last option here besides open weight CPUs and optionality is actually governance. Um there's a lot of AI governance. Um one is visibility. Um understanding who's using the data, understanding its maintainability and control. When you have model optionality, you can offer a lot more to your customers. Um here's an example of how that governance works in notion. So final tips again, think about architecture, think about open weight, and build value that transcends tokens. So we're going to depart Token Town. I know I said welcome to Token Town. We're going to spend the next 10 minutes really thinking about what to do next. So I think the challenge of the next six months doesn't have to do with capabilities. I think it has to do with security. Let's start there. There's this concept called the lethal trifecta. Simon Wilson, I think, crafted this. If you have access to private data, exposure to untrusted content, whether it be through ingestion, MCP, email, right? And the ability to ex to communicate externally, and that can include like payloads in a web search. The second you have that system, you're exposing risk. And in fact, the more autonomous your system is, the more unsupervised this risk is. I think that this is what builds valuable product, not just capability. Same with sandboxes and computers. We talked about this, but it really is something that builds better determinism in your product and also better token economics for your customers in multi-agent orchestration. Understanding what agents see and do and what persists. I think persistence of enterprise knowledge is something that's actually really not discussed enough. It's starting to be with some recent launches, you know. Oh, there is audio. So don't have your workflows look like this. And I think this is where most software factories are today, right? It's like actually your entire engineering time just spends time babysitting the factory, right? I mean, I get it. Ours started off like this. Agent orchestration is one of the most difficult tasks of making factories work. So okay, this is me telling T pay to tell people to buy notion AI. And the reason I included this slide is that I'm going to sell notion for a second. It's my job. Always be closing. Always be selling. Always be hiring. come find me. But I'm going to talk for a second about how Notion does this today. We already have the ability to inspect tasks. And you can imagine any task that you look at um in a notion document, you can have Claude actually go ahead and scope out what you need. We've launched this manage agent capability today. So if I go ahead to the top of this task, I can actually ask Claude agent to scope out the task, right? Ideally, it's working. Um, and you'll see it'll actually populate um an entire spec of what needs to be done. In this example, it's not ready. It's going to ask me a question. Keep in mind, this isn't a markdown file. This is an active document. Um, let's say I don't actually know the question and I go ahead and I ask my team um what to do. Imagine that you can kind of tag in your team into these systems. MJS are PM So in this example, she doesn't know. Usually she does, but multi-agent orchestration is important. Maybe Claude Code isn't the best at customer voice, but Decagon is, right? You can ask DecaGon agents, we're proud partners with them as well, to collect the right data that you need. Okay, in this example, we think we know enough. We're going to go ahead and actually um iterate through some of this flow. I'm going to skip ahead a little bit. We asked our TL what we needed. He replied again. It's a collaborative file, not just a markdown. And we can have Claude actually go ahead and spin up the PR. Hopefully, this is looking a little familiar now. This is kind of the vision of software factories. It's what we're trying to host. Okay, Claude put up a PR. Maybe that's not enough. Um maybe I want to go ahead and ask Codeex what it thinks. Great. Found two issues. You can think about this scaling in an actual factory. So today in notion, you're actually able to orchestrate these agents together and you're not committing to a lab. You're committing to the concept that AI is augmenting and automating what you do. This is real. I asked Rejieve if I could post this. This is how it works today internally at notion. Almost all of our polish and large feedback like this is actually coordinated um through our software factories both in terms of writing to the right teams and also having coding agents take the first step. Versel does this as well from staging to shipping to closing. And we see massive ROI gains from our customers. That's over three minutes saved on a given task. Imagine that at scale. So I think we're trying our hardest to think about the factory lens. We cannot do this without optionality. And we cannot do this without conviction that we understand what models are required for which tasks. It's really wild out there you guys. I get it. The market is really young. It's exceptionally opaque. It's moving fast. I'm super grateful for communities like AI engineer to bring us together and like talk openly about these things and how we navigate it. Um I think we owe it to all of our customers to get it right and to be critical thinkers about how we navigate this together. I'm chronically online fortunately. Um you can always DM me on Twitter, you can email me, you can find me after this. Um but thank you for yapping with me and thinking about this problem and have a good day. is for uh it's just got so much in there. It really helps write better code and structure your code better and uh helps with architecture, spinning up new services for uh and and for us on the agents team really helping uh design and build the the core agent loop. So you'll see throughout this presentation sprinkled in um how effect on our team uh has paid off in dividends. So we we really love effect here at open gov and we encourage other folks to try it out and um yeah let's keep going the effect native loop. So originally we were on lang graph and that was fine until the team really started to scale uh and our use cases started to evolve. So we decided to move over to our own kind of effect native agent loop to have full regency over this uh agent loop such that if we have complex use cases or features that we need to build, we could kind of get in we we had full control of the of the agent loop. And not only that, but now we're fully on effect. So all the cool things you get with effect is now propagated throughout the entire agent loop like the tracing structure currency, the logging, everything is more fine grading control and it it really allows us to really unlock the full potential uh having our own agent loop from the ground up. Um so another thing I wanted to mention is on the left side you'll see a code example. This is really the basics of the effect loop that we're using. Uh we're using this thing called the effect AI package. And in that package, there's this thing called um there's a chat and a language model. So with the chat, you can instantiate like an a chat for example. And then you could stream text using um that that kind of stream text function. You could pass in a prompt. And what's cool is uh with a language model under the hood of since we're kind of doing dependency injection, we could pass in a different language model if we were to uh hot swap to another one for example. So really just having full control of our own agent loop just kind of gives us all the levers and it really just unlocks the full capabilities of the model and uh for the team as well to have full agency over this this loop. Another thing I wanted to mention is the agentto agent protocol. So here on the agents team, we've had a lot of success with this protocol. So this protocol being the protocol that Google created um kind of an open protocol for agents to intercommunicate. But um we found this very useful for uh defining our agent routes for example in the back end and our model and our schema to follow this kind of uh agent protocol. So we modeled so for example there's this thing called an agent card which you see here and it's got the name of the agent a description etc right and having this kind of rigorous protocol this rigorous spec really helped drive our development and drive alignment because you know all we had to do was um align with this spec and follow this spec and we knew that this was kind of the contract that our front end and backend and would both consume and and produce. So, um this uh I would say also has been uh very helpful for us and and what's really cool is A2A has a lot of extensions, right? So, you could extend the protocol uh add in like metadata. Uh there's also A2UI. Um so, lots of fun stuff uh with A2A protocol, but uh this is kind of what's worked for us. So just sharing that with with you folks feedback and eval. So here the quote is shipping is the start not the finish. So what we do here uh on the agency team is we have kind of multiple ways we do evals and collect feedback. Um obviously you know we'll have folks uh call in or or email us or or just let us know and tell us but the main way is we have this thumbs up and thumbs down mechanism. And here uh someone is able to tell us, hey, this this worked really well. This was a great response or that wasn't a great response. And that signal we take and we're able to iterate on uh and we could take it back and help improve uh you know the response in the future. Um we also have automated evals. So in in the in RCI we we have evals that run against real completion. So we could test the prompt against hey did it hit some tools? Did it do what it's supposed to do? And that also helps with our accuracy. So, uh those automated evals in conjunction with collecting feedback really help us um improve our our our tools, our skills, um our harness and and that's really how we're able to iterate so fast and so quickly. Humans in the loop. So this is a really cool feature we built where we deterministically interrupt the agent loop. If there is a tool call approval required. So if an agent tries to make a tool call that it needs human approval for it'll show this UI and the human uh can click accept or reject. So explicitly rejecting or explicitly accepting uh the action that the agent is trying to make. And this ensures that uh you know we're building trust and also ensuring that uh you know we're being safe especially when the agent is trying to do a mutating operation and always always always making sure that um humans are in the driver's seat sandboxing. So another thing that we uh worked on um kind of similar to the safety slide we just saw was um whenever an agent tries to execute code or tries to create files, it does so in a sandbox. So we gave our agents sandboxes such that it could spin up these sandboxes on demand and it could use those sandboxes to honestly write code, execute code, create files and it's kind of this safe ephemeral isolated space such that the agent can can can take action in there and not and we don't have to worry about u any risk to you know our our production systems. Um, and it's it's really cool because they also get uh tied uh teared down at the end. So, um, in this example, I said, "Hey, create a PDF uh for the folks of the AI Engineer Conference 2026 and um, allow me to download it so I can share it with them." And you could see that the agent created this fighting slop with slop. My name is Vibb and I'm going to talk about something that is a little I would say maybe a little silly at first. I'm going to show you our team's engineering practices really quickly. We do no code reviews. We require every engineer to work on things in parallel and we have no standardization in how people do AI and I know immediately what almost all of you are thinking. We're probably a Zoomer YC startup and I can guarantee you I'm clearly a millennial. So what do we actually do at our company without code reviews? Well, we about three years ago we decided to build a programming language. That's something that has absolutely no room for slop. is something that has to work every single time exactly the same way. It's something that you can't just change a year later or a month later because you made a bad design decision. You have to be correct. And for the last three years, we've been in an onslaught of war against slot. And when I first met this enemy, I went to my great mentor, Slop Sue, and he taught me something. To to defeat the slop, we must become the slop. So we began and we prepared and then we started winning. So when we think about it, what is slop? Slop is just any code you don't read. And whether any of you admit it or not, this is the least amount of slop that your codebase will ever have. Cherish it. So we started fighting back against this slop and we started fighting back with slop. So how do we go ship a stable programming language with these engineering practices? Well, the first skirmish we ever had was a skirmish of standards. The hard part about hiring great engineers is you sadly can't tell them what to do. Some of them want to use clouds. Some of them want to use codec. Some of them want want to use the latest thing that they just found on hackernews. So instead of trying to hold standards in our codebase, we did something that is an invariant. We built an architecture.md file. Instead of using cloudm just pick something that every model can just understand. This file has to be incredibly small and it can only have things that will not change for months or for years. In our case, it's the layers of the compiler. You go deeper into the compiler, tell the agent to just talk to at least one other person. That slows it down a little bit. So now we have standards. So anyone can use whatever they want. But the real foe we faced was actually the battle of design. Everyone here knows that you have to write perfect design docs. And we have a very simple rule in our team. Code can be slop, writing cannot. And of course, if I tell every engineer this, they write beautiful writing and they handw write everything. They don't use AI. Well, sadly not. So, we built a design tool, design doc tool. What this design doc tool does, it's a replacement for both notion and GitHub effectively for design docs. It allows versioning, commenting, all the stuff you want. And obviously, we do this. People use this. Well, sadly not. We built another tool on top of that. And this tool was a Slack integration for that tool. Every time a design doc got updated, this channel got notifications. And what ended up happening is this channel became the most popular channel in our company really fast. At 2 am someone shipped a new design doc. Three people started reading it right away because it's just interesting. The most interesting stuff is design docs that are not going to change. But this wasn't enough. All of this is actually backed by markdown files and simple CLI scripts that make it treat like GitHub without being GitHub itself. So now agents can go do this. But the real problem with all this is I built this and I hit a little bit of AI psychosis and I started shipping 10 design docs a day and soon the team was fighting my slop. So we had to go in at the last rule. This last rule was if you're going to ship a design doc you require people to actually go read it. And with this last standard we suddenly had design docs that are incredibly high quality. But what about the battle of architecture? You how do you have your codebase converge? We built another tool. This tool basically visualizes our dependency graph internally with some external dependencies as well and allows us to watch the codebase change. It has semantic boundaries individual packages. But what's more interesting is we can go build CLI tools that guarantee that certain invariants can't be broken. And what this does is when Claude builds a new package or adds a dependency that's leaky, we now have CI/CD changing or or a simple git commit history that tells us exactly where things break. And by this we're actually able to make our architecture change. We haven't changed our architecture in the last three or four months. But as much as we might do design docs and as much as we might have stable code, would you genuinely ship code without reading it? Would you trust your team to go do that? And think about a programming language. A programming language has so many invariants. You have generics, you have closures, you have memory allocation, you have FFI boundaries. Could you trust that system? Python has bugs 25 years later. Well, here's where we did something slightly different. What we did was we built a system that actually has agents constantly running and creating BAML programs. We take these BAML programs. One second. And we have agents try and spin something up from scratch. We then look at the entire claw transcript, see what tools it used, see what happened. And obviously, we as humans can inspect them. But more importantly, we can have agents go inspect them. and agents find what was good, what was bad, and not just what was bad in terms of what was incorrect in the language, but what took three tool calls when it should have only taken one. And then we can go ahead and find issues. And we can have humans collaborate with these issues to figure out which ones are real, which ones are hallucinations, which ones are don't have taste, as much as I hate to use that word. And then we can have agents go ahead and create fixes to these problems and go address them. And most importantly, instead of trying to just detect these issues, we can go one step further. What if you could find language features and instead of guessing what was good, guessing what skill was good, you could go and AB test it. You could figure out which ones took less tool calls, which one took uh which one made less errors, which one produced the correct outcome and deterministically know what's going on. The point is you can start building datadriven systems without ever writing a single line of code. And the thing that really I care about the most over here is not that any one of these tools is specifically what you should go build, but the fact of the matter is in order to build a programming language, it wouldn't have taken eight people. It wouldn't have taken less than two years. It would have taken hundreds and thousands and tens of thousands of manh hours and then you would still have a broken system. And today we can just spend billions of tokens and make it work and we can make it stable. And you could you too can go home and build these internal tools and these sloppy tools to make sure that your code bases can ship without really having to read necessarily every single line of code because your engineers aren't going to. And I think we can start winning this battle against slop. And as we win this battle, slop can be defeated. But sadly, I have a sad thing to say. I think we're still going to lose the war. I think the reason that we're going to lose this war is because some of the foundational stuff that we try and go use itself is broken. How many of you have used TypeScript? Probably most of you hopefully at this point or at least your agents have. So something around there. Um did you know that TypeScript's main design goal is to strike a balance between correctness and productivity? And there's an asterisk here because what they really mean is human productivity. And if you think about it, there are things you would never do in a programming language at the very core layer if you were designing in a world where humans never wrote a single line of code. Let me show you what that really means. I'm going to write something and try and guess what this code does. Pretty safe. What about this one? or even more so this one. Why do we turn things to strings when we sort them? This is just slop baked into the language whether you like it or not. What about this? I love this part of TypeScript. And you know what? My agent loves this part of Typescript. This is slop baked into the language. And whether you like it or not, the systems will have slop if you build using these tools. Oh, I'm sorry, wrong talk. But if you think about what JavaScript does, JavaScript exists and then after JavaScript existed, we started building systems to layer it on. We built coffecript, then TypeScript, and now we're trying to build effect. But thing is the thing underneath is already broken and more so the way we write code is also different now. So why are we trying to patch something like this? Why don't we just try and do something a little different? And I think what we might need if we try and go do that is basically going to be a madeup language. So let me show you what BAML really can do and when you start thinking from first principles how you can try and combat slop from a very foundational layer itself. I keep talking about not reading code. Does it even matter? Well, let me show you a new way to think about code. And this isn't to say we all have to go do this right away. But what if every single time I looked at code Whoops. What if every single time I looked at code, what I really saw was not the code itself, but a quick little thing that could actually visualize all the code for me. As I clicked around, it took me to exact lines of code that was linked to. If I wanted to have a slightly broader view, I could zoom in and click around and have it expand, and I could navigate my code bases more interestingly. I'm going to let this run really quickly, but while it runs, I'll show you a different pipeline. Without any of you ever reading the code, you know, I'm setting up stuff and I have an agent loop because the semantic boundaries in there. I can expand this. I can keep expanding this and I can say, "Nope, that's too much slop. Let's let that be slop and walk away." So, instead of having to understand all the code, I can opt into what parts of the code I want to read and understand and go to the exact lines when I really care about them. But if we go back to the previous pipeline that was running, what if while it's running, I can actually get a full execution trace in a world where we don't read all the code, the only way to understand the code is actually by the execution trace and actually by seeing exactly how much time was spent on what parts of my program at any given time. If you want to go and actually track your program through, think about how slow your program would be if you had to go trace everything in Python or Typescript. It's untenable. And the best part here is if you start from first principles, you can make this effectively zero performance cost. Not only can we make it great for humans, but because it's all built for agents anyway, you can go ahead and make it so that every single file has a tracing system that Claude can navigate through. So Claude can find what were bugs, what were errors, and what were inefficiencies and start optimizing your code without you having to do it yourself. And I think if we go start thinking about it from this way, it's not so much about reading all the code, but it's more so about as a human understanding the system that you're working with. And the tools that you can build can give you information about the system that you're working with. But I think there's another layer to it. We've spent decades building ID tooling and that think about how long it took before someone like me who does not know how to escape Vim to this day can finally start using VS Code. It was a beautiful day when that happened. I became a real programmer. Well, according to some people, I'm still not because I can't write Vim code. But what does agent first tooling look like? I think we're all familiar with GP. So I'm not going to go and talk about it, but I will talk about rip grep because gp should not be used anywhere. If I wanted to g through my codebase and understand what it was, I would rip grap say something like calculate and it would give me a bunch of code where everything was being used and maybe it would be somewhat useful. But what if you could instead just start describing code and say, can you describe calculate for me? What if it came with all the dock strings? What if it came with the actual source code? And what if it also told you everywhere it was actually used under the hood? We can make something that used to be multiple tool calls a single tool call all of a sudden. What if the way you wanted to learn about libraries that you were using instead of having to do a web search, you just did you just you could just ask for any external library as well and it would just give it to you. Because when I first learn started learning how to code, one valuable lesson I had was the code is always a source of truth. Don't read anything but the code itself. The docs may lie. The um the actual description or architecture file or read me file will definitely lie, but the code cannot lie except if you're working on some weird architectures. And then when you go down this road, you go from not reading the code to understand the architecture. You go from not searching the code to understanding exactly what you're getting in everyone tool call. But what's the next thing you do? Well, the last thing I do to truly understand code is I run the code. So, what if every single thing you ran, every single function you ever wrote was immediately available? And I'll pop this code over here was immediately available as a simple CLI command. So, if I run AD, add AD becomes a CLI command that has A and B parameters attached to it. And I can just run it really quickly and see what happens. What if every single CLI tool I had could be packed into a li into a CLI that's completely standalone that I can just run without ever having to actually execute any of the code and is now a total CLI binary that has function just bundled in. Suddenly we can build really quick tooling where agents don't have to go GP through what's happening. Everything is type- safe. Everything is deterministic and everything is actually guessable. And the best part is imagine you could build on any system and your agents don't have to worry about deployments across Windows, Mac and Linux and you can just target any layer you want and it builds for any architecture including WASM systems. All of a sudden as an engineer you're supercharged. You're no longer bottlenecked by what you can do in the systems underneath you are preventing. You can just move very fast. You can move at agent speed. But a lot of the stuff that I've been talking about to this date has been about tooling. What if we tried to fix some of the real sins of JavaScript? Some of the stuff that is deep in the language. Not the sort stuff, but I mean more important stuff like errors. Have you seen error handling be beautiful ever other than Rust? Um what I see agents do over here is you do try catch and then they keep nesting try catch after try catch after try catch and eventually they give up and say console.log. some error happened and deal with it. What if we could do error handling from very first principles? What happens in that world? Well, I showed you add, multiply, subtract. I didn't show you divide. Divide is dangerous. It's spooky. So, let's go look at divide. You can see over here, divide throws a division by zero error. But what else happens? The function actually knows that it throws division by zero error without you having to write any any code. If I go up to the calculate function which at some point calls divide, this function also knows is throws division by zero error. So error types now get inferred without you ever having to do any guess work. That means if you catch or handle errors, we can do exhaustive guarantees and the compiler can prove that you have handled the error or not handled the error. It's no more guessing. There's no unknowns. It's guaranteed to be proven. So if you wanted to ship an API where it guarantees that it never throws, well, this system is broken because it doesn't meet the constraints. It has two errors that you're not throwing. If you wanted to go catch that, well, I can write the code for that in a second, but you can start catching certain errors. Let me I'm just going to return a sentinel value for now. And now this parse thing which previously threw division by zero error is now guaranteed to no longer throw the division by zero error because if I catch any exceptions in here, I return a zero value every single time. The compiler and the tooling can do a lot of work for us. And we're already used to this in our code bases. We many of us probably don't know how compilers work under the hood and we trust them. code is a matter of trust. The reason that we don't tr use LM code blindly is because we don't trust it yet because the systems underneath them don't have enough rigidity. One more thing, but before I tell you all to go write a bunch of BAML code, because I've been there and I can tell you what someone would tell me if I said, "Hey, use this new programming language. It's going to solve all your problems." It's just going to become come with a whole slew of new problems. So we said, I think we'll lose the war on slop if we try to ask everyone to rewrite all their code in the world into this new system. So what does a solution like that look like where you don't have to rewrite all your code? Well, we what we started to do was we started to think about that about two years ago. And we said, what if you could use BAML not just standalone like I showed today, but from within any existing language of your choice from Python to TypeScript to Rust to Go to Ruby to Java to anything new that comes up even after it. What if every function in BAML is immediately accessible in the language of choice? So in this case, I'm calling the BAML calculate function directly from Python and it's completely type safe. Not only do we get calculate, we get calculate async in case some of us want to write async code. So BAML while it has no function coloring, it does give you the benefit of having to do whatever you want across your code. But what if you went a little bit sillier? What if you started passing around lambdas across language boundaries? I have a function here called with timeout. this function times out after a certain number of milliseconds and if this work doesn't complete and it's guaranteed to no matter how long it takes well in that world you can even pass Python lambdas across the bridge you can pass generics across the bridge you can pass closures it should just work so engineers don't have to go fuss with it and more importantly so when the agent does something the type system never lies the type system becomes the absolute center of truth that prevents invariance from entering your codebase And what I really wanted to talk about today was not any one specific thing, but it's this general concept. You can build incredibly complex systems without traditional systems like code reviews. You don't you can work in things in parallel and you can use AI however you want without requiring any sort of standardization. But the most important part is you have to be incredibly thoughtful about how your engineering team actually uses the systems under the hood. When we started building BAML, I didn't think it would be possible to build some of the software we did. And just yesterday, one of our engineers built a partial C compiler purely in BAML. So when I start pushing the boundaries of these systems and you stop reading the code in some ways, in my mind, it releases a floodgates for your engineering team to actually cover the gaps of what existed in your old process. Have you ever worked at a company that had no CI/CD? They said adding CI/CD would slow us down. They they do slow down for three months while they add it, but after that they move a lot faster. Our processes have to evolve if we're going to ship at agent speed. And remember, this is the least amount of slop your codebase will ever have to this date. So just embrace it and start fighting it back. I fell in love with software about 15 years ago and it was the first thing that truly changed the way I perceive the world. And I really genuinely don't want SOP to win. And I think we can all build a world of beautiful software. I think what it takes is I want each of you to go home today and build these sloppy tools. Make your systems more robust. Make your processes more robust. And then for the bravest of you, I want you to go back and think about these core foundation layer systems. Think about how they're broken and see if you can imagine a way to fix them. I think we do need a new git. I think we do need a new database. And yes, I think we need a new programming language. I'm Vibov and I work on Baml. Thank you Shan Gupta and I'm a software engineing tech lead at Meta working on building a training and inference infrastructure for the meta super tenis lab and their infrastructure organization. Today we're going to be talking about production events for aentic systems. When most people hear the word valuation, they think about benchmarks. A model scores 90% on a benchmark. A new version scores 92%. A team celebrates. But agent systems have fundamentally changed what the evaluation means. Today, the systems don't simply generate answers. They plan, they call tools, they retrieve information, they execute workflows, they interact with the production infrastructure. The question is no longer did the model generate the right answer. The question is did the system behave correctly. Today I would like to discuss how evaluation is evolving from model benchmarking into production infrastructure. This is the problem almost every AI organization is encountering today. Offline benchmarks continue improving. Yet production reliability often remains unpredictable. Why is that? Because benchmarks measure model capability. Production measures system behavior. A benchmark doesn't capture tool failure, API outage, context changes, user variability, longunning workflows. And as systems become more autonomous, the gap between the benchmark performance and production performance grows. The result is what many teams experience today. High benchmark scores, as you can see, but unreliable production behavior. Traditional ALM evaluation focus on outputs. But we should ask the question did the model produce a correct answer? Agentic systems force us to ask a different question. Did the system behave correctly? Behavior includes planning quality, tool usage, execution, workflow execution, recovery from failures, decision making. In other words, we are moving from evaluating answers to evaluating workflows. And that requires fundamentally different evaluation architectures. Many teams still think hallucinations are the primary AI failure modes. In production, they are often just one category. Agentic systems introduce an entire hierarchy of failure modes. At the very foundation, the memory failures, retrieval failures, safety failures. As you go up, you have to think about reasoning mistakes, poor planning, incorrect tool execution. At the highest layer, you have to think about multi- aent coordination failures. And this is why evaluating only model output misses the most production risk we observe. One of the most useful mindset shifts is to stop thinking like researchers and start thinking like a S sur or a production engineer. SR don't measure success using accuracy. They measure reliability, availability, latency, cost recovery and agentic systems require the same approach. The goal is not maximizing the benchmark scores. The goal is to maximize dependable outcomes. Reliability becomes the Nostra metric. Accuracy becomes the only input. In this pyramid is how I think personally think about modern AI evaluation systems. At the bottom you can see their benchmarks. They're useful. They're scalable. They're reputable. But the operational value is limited. In the middle there scenario based valuations. These simulate realistic workflows. And at the very top you see production telemetry. This is where the highest value evaluation signals come from. The surprising insight is that the most evaluation data often comes from real users interacting with real systems. Now let's talk about offline. So offline evaluations still matters but the methodology changes. Instead of evaluating prompts, we evaluate scenarios. For example, a customer support workflow, a code generation workflow, a research workflow. The agent operates inside that simulated environment. We measure the task completion rate, tool correctness, planning quality, resource usage which is which becomes exponentially high at high scale. The key takeaway 18 evaluation should be scenario driven not prompt driven. Once a system reaches production, every interaction becomes a signal. This is one of the biggest shifts in evaluation thinking. Production traffic is no longer just traffic. It becomes evaluation data. We collect execution traces, user outcomes, escalations, failures, feedback signals. Production is the largest and the most representative validation data any organization will ever have. Many organizations view humans as fallback systems. I think that's a wrong framing. Humans are the evaluators. They provide signals that automated systems cannot. They assess correctness, trust, usefulness, safety. These signals become really critical for calibrating evaluation pipelines and identifying blind spots in automated metrics. The most successful systems combine automated valuation with targeted human review. Now agent systems drift constantly. Model changes. You have a new version every couple of weeks or months. The prompts can change. Tools can change. User behavior can change. Hey everybody, my name is Kyle. I'm co-founder of a company called Human Layer and I'm here to talk about loops. I think we've all been building loops lately and I realized recently I think we're all doing it wrong. loops are really powerful, don't get me wrong, but so much of the discourse around them is hype driven and just really not helpful, right? We I think we have this idea just kind of as an industry somehow that we can like pipe a prompt and a loop to a coding agent and that we can build software this way, right? Maybe we're investing a lot of time in verifiers. Maybe you have six different code review agents. But at the end of the day, if we're doing this, we're still building 40,000 line PRs that just nobody wants to read, right? And this isn't to throw shade to Jeff Huntley, right? This is Ralph is an innovative uh it's a sharp tool that works very well for certain types of problems. It works very well if you're not building on a team and it works very well if you're not working on critical systems. But most of us are working on teams and we don't fit in that box. So today I want to talk about how to build loops that work in large complex code bases for systems that have real customers, real users, real regulatory obligations and service level agreements and everything else that keeps us from shipping yolo 40,000 line PRs straight to production. In other words, I want to talk about how to build loops for the real world. If you're not aware, uh, this post actually dates back to July. It went viral this past January, which is when a lot of us, I think, started building loops. And of course, much more recently, I'm sure you all are going to see this slide a lot this week. Uh, but Peter Steinberger said that we shouldn't be prompting coding agents anymore, right? We should just be designing loops that prompt our agents. Of course, Open Claw is notoriously built on loops. Loops build the code. Loops review the code. They merge and release the code. They find and fix the bugs. There's even loops for finding and fixing bugs and the loops that are merging the things, right? It's loops all the way down. It's uh Boris Turney also the creator of Cloud Code recently said that this is his entire job as an engineer now is just writing loops to prompt Claude. And eventually we might not even need loops, right? We're just gonna have like swarms of agents designing loops to prompt agents building swarms for loops and like I don't know somewhere we're like writing production code I assume and in fact all of our loops that we're building are producing so much code that we can't possibly read all of it right so we might as well just not read any of it right we're we're investing in verification and in code review but all this code is readon this was the thesis of a conference that uh was here in town last month. So, a lot of smart people at the Frontier Labs think that this is the future of software development. And if you're doing this, you're moving 10x faster and everybody else is getting left behind. Now, it's not clear how well this works yet. Uh took six months to fix the cloud code terminal flicker. The Open Code team wrote a renderer in a fraction of that time. And Open Claw, of course, also notoriously has stability issues. What is abundantly clear, however, is that this is really expensive if you don't work at a frontier lab and have an unlimited token budget. And all this code that we're writing is actually really expensive, right? Matt PCO talked about this recently. Uh, bad code is much more expensive in the age of agents than it it has ever been at any point in the past. So today I want to talk about what I think works in the real world and what we've started doing at human layer, which to be clear is still building loops, right? I think loops are super powerful, but we can design loops and still read the code. In fact, we can design loops that make it easier to read the code because the loops are making the code better. We can solve hard problems in complex code bases with loops and we can build our software factory incrementally. But uh to do this is going to take some real engineering y'all. So let's talk about control theory. Control theory is all about how we drive a dynamic system which would be your codebase towards some desired stable or optimal end state, right? You have a sensor that measures the current state of the world. You have your set point, right? The desired state of the world. And the difference between those two things is your measured error. You have a controller that reads that measured error and turns it into a control signal about an incremental change to apply to the system. We have an actuator that applies that change to the system which is undergoing disturbances in the meantime. And then we rememeasure recomputee our measured error and we're back where we started. Now this sounds really complicated and it can be. I have a twin brother actually who's an aerospace engineer. This is how they keep fighter jets from falling out of the sky. Uh but uh it's probably a little bit simpler than most of you all think. Does anyone have one of these? Uh a thermostat uses a control loop, right? Uh for for any of our European friends in the audience, it's part of something we have uh here in the states. It's called air conditioning. And uh most of us probably use control loops on a daily basis, right? Kubernetes autoscaling systems are built on control loops. Infrastructures code uses a desired state, current state, iterative change like control loop pattern. Postgress's uh autovacuum and reacts virtual DOM both use or approximate control loops. Control loops are ideal when we have a system that we want to change, a problem we can measure, and a way to get feedback on the result of that change. Like good software engineers have always been taught to do, control loops change a system incrementally instead of just trying to get straight to the end state immediately all at once and risk blowing everything up, right? They help us to avoid oversteering and destabilizing the system and it minimizes risk. So control loops are the opposite of what I'm going to call a blind Ralph loop. They're how we avoid PRs that look like this because nobody wants to review this, right? Which is not to say that all Ralph loops are blind loops. The best Ralphs are actually applying control theory. I know Jeff Huntley is out in the hall somewhere wandering around. If you go talk to him, he's going to tell you the same thing, right? That Ralph is a a teaching device. And I think some of us read it a little too literally, but this is how we should have always been building loops. But the other issue with Ralph loops is they're not incremental, right? It's just a bash loop. So we have to build a gentic control loops. And to do that, we start by defining a set point, which is the desired end state of our codebase with respect to some property of it. And we add a sensor. There's a lot of ways to build a sensor. It can be strictly deterministic, your ESLint rules, your agp, your pack work, or it can be non-deterministic. You can have an agent and a skill and a bunch of natural language rules. And you could also just have a pipeline like a combination of the two. So, how do we build a gentic? Whoops. There we go. Now, uh, this is all theory, right? Practically speaking, and because we're using agents, we can blur the lines a little bit between system components. So, Aiden buys React Doctor, for example, is fantastic. It is, uh, it's a great way to catch all of the React slot that Claude snuck into your codebase last week. But, uh, it's a hybrid sensor and controller. It tells you what are all the problems with your React code, and also, by the way, what are the top three things you should fix and how do you fix them? Similarly, our controller and actuator might actually just be a single agent deciding on an incremental change to make and then applying it in the same context window. But I want to zoom in on the controller a little bit because without one or without a welltuned one, we might make too large of a change all at once or we might make the wrong change entirely. And if you put that in a loop, you're in trouble pretty quickly. So, we can use control loops to root out bad patterns and to clean up our code. But we can actually use them for all sorts of things, right? We could make sure that our API is compliant with someone else's open API spec. We can make sure that our MCP server is compliant with whatever version of the uh the MCP specification that we're currently on. Haven't checked. You could mirror a project from Python into TypeScript or vice versa. You could even maintain your uh VE-based slop fork of Nex.js against the upstream. The key questions are can we find something we can measure? Can we apply changes incrementally and can we get feedback on the quality of those changes? To illustrate that, I'm going to walk through a control loop that we use internally at human layer. Uh for our loop, we are incrementally migrating our RPC API to effect. We adopted it for some of our racer prone code. We like it, so we're adopting it across the rest of our codebase. If you've never seen effects code before, the code on the right is just the kind of trivial procedure on the left rewritten in effect. Uh the syntax is really weird. We're psychos. We really like it. It's not for everybody. That's okay. Uh, this isn't a talk about effects, so we'll keep moving. Clicker's not working. Cool. So, step one, we have to build our sensor to find unmigrated procedures. We can have an agent do this or we could use GP or RIP GP, but instead we're going to use as GP because it's really powerful. It's a great tool to have in your toolbox for building loops. It's language agnostic. it's out of band from your TypeScript config or eslint rules which if you're a TypeScript developer you have watched Claude disable those with inline comments. Uh but so we can just write a simple rule that finds unmigrated procedures uh based on the pattern above and we over time we can even layer on more rules that describe other patterns we want to get rid of with granular include and exclude paths. If you have a multilingual monor repo like we do, uh it'll work for any language you could possibly imagine. And we can just scan our codebase and it'll produce a long list of violations. Uh way too long. In fact, it'll give you about 50 keys per violation. So, we're just going to filter it down to four. And we're going to sort it deterministically. Why are we doing that? At the beginning, I said this was going to be practical. And so, we're going to step outside of our control loop paradigm for a second. Because before we start incrementally migrating procedures one at a time, we need to enforce that all new procedures are using effect. Right? So we're going to run a full scan once on main, sort all the violations deterministically and track it in our version control. And then on every new PR, we can see if the branch added any unmigrated procedures, right? So this is our control loop and our system is undergoing disturbances. In this case, uh all of our teammates shipping cloud slot and this is how we make sure that they're not undoing our loop's work. This doesn't map directly to a part of the control loop, but we can kind of like squint at it a little bit and call it a disturbance dampener. So, now that we've stopped the bleeding, we can actually design our controller. For a simple controller, we could just deterministically pick the first violation from the list. You can use bash and jq, or we could get a little cleverer and use aspmigrated procedure and always pick the smallest one to reduce the risk. Uh, we could have an agent make the decision if we really want to. I don't think you should ever send an agent to do deterministic code's job, but you certainly can. In fact, depending on the complexity, we could have the agent pick the procedure to migrate and just do it at the same time like we just talked about. But we can make this even more powerful, right? Because we're not just migrating to effect for the sake of it. We're doing it because it's helpful for handling errors and for helping us instrument our code better. And so what we could do if we want to get really clever is we can look at our telemetry and figure out which procedures have the most errors or the least instrumentation or has a gap in our APM. Right? And when we send a control signal to our actuator agent, we can include not just the procedure to migrate but also all the data about the things that we're trying to fix with this migration so that the actuator agent can actually make the code better instead of just doing a onetoone migration. ma'am. There we go. So, next is building our actuator. Our actuator is just an agent plus a skill. Um, bring your CLI coding agent of choice. You should spend a lot of time on the skill. Not all of that should be up front. You'll want to iterate on it over time based on what works. At human layer, we like to build out what we call golden patterns by hand before setting the agent loose. These are just like idiomatic handwritten examples for the agent to follow because they're just pattern replicators and otherwise you're getting what's in the docs or what the agent knows from the internet. And so we pipe the skill plus our control signal into our actuator agent. And the skill of course should include a response template and the agent's going to work and work and work and it'll produce a final response. And then we're going to deterministically commit and push and create a PR using the final message as our PR description. Now all we have to do is actually run the loop, right? Uh my recommendation is to use GitHub actions or your GitLab or your CircleCI or whatever else you're using because it has access to your code. It has access to your secrets and it has great dispatch and scheduling primitives, right? We don't need a new cluster for this. So we can write a workflow that runs a single iteration of the loop sense, control, actuate, and creates a PR and then we can schedule this to run once a day. And every morning we walk into the office to a small incremental PR that's low risk. And when we first did this it was actually really frustrating and we turned the loop off and it uh because we had to constantly update the skill. We had to constantly check out the branch, change the skill, change the code, commit and push and our loop was actually really high friction, right? But there's a better way to do this uh where we can put a human on the loop in a really low friction way to resteer it when it goes wrong. And the way to do this is to just create a feedback file that's tracked in version control just as a markdown file. Right? We can deterministically load it into our actuator agents context every time that it runs after we run the controller. Then we can add a label to the PR. Right? Each workflow needs to be able to identify PRs that are created since there might be a bunch of different loops running and we only want workflows to respond to feedback from comments on their PRs. And we're going to add a comment trigger to each loop workflow. So that when a user leaves a slashiterate comment on the PR, uh the loop workflow is going to pick that up. It's going to deterministically load all of the PR context, the diff, the comments, the review comments, the description into the agents context along with the skill, and it's going to instruct the agent to fix the code, but also to update that feedback file. Right? Looks kind of like this. And the benefit of doing this way is that now that feedback file with instructions is tracked in your version control. you can see how you've changed it over time. You can revert it if you need to. So, the next thing we're going to do is add flow control. Because the other problem that we had when we did this was that if we were at a customer site for a week or if we were traveling or spent six days working on slides instead of writing code, uh the PRs from all of our loops would just stack up. They'd duplicate work. They'd conflict and we wouldn't get around to doing it. And like the loop's work is important, but it's not that important. And so now we just had all this like junk we had to deal with that wasn't important. So this is actually a really easy problem to fix uh because each loop and its workflow has a label that gets attached to PRs. When the workflow first runs uh before we check out the code and install the dependencies and run our sense actu or sense control actuate steps, we can just check and see if the last PR that we created or any PR with the loops label on it is open. And if so, we just shut down, right? because this means that the last time that a human uh reviewed the code from this loop was before the loop ran, right? No human reviewed the last output. So there's no reason to stack up even more work for humans to review. This way we have exactly one PR at most open per loop at a time. No stacking, no duplication, hopefully no conflicts. And of course, once you're feeling confident in the loop, we're going to want to speed it up, right? I have 150 RPC procedures to migrate. If I do one at a time, it's going to take six months, which is way longer than I want to wait. Fortunately, there's a lot of ways to pick up the the velocity of our loop. Uh we could have our controller pick three procedures to migrate instead of one at a time or five. Uh we could have our controller pick three or five and then do each of those in a separate implementation phase, which will be both cheaper and more reliable since each migration gets its own context window. Or we could just run the workflow four times and give one PR to each of four people on the team. So let's put it all together. We built a control loop that improves our code incrementally and we're actually reading the code. It has adaptive flow control so we're not creating a bunch of loop or a bunch of work that nobody wants to review and we can rest steer it on the fly in a super low friction way. If you want to try this yourself uh we built a skill, please try it out. My Twitter handle is down there on the bottom. Please share it. I would love to see what you build. And if you get excited by this, uh at Human Layer, we're hiring here in San Francisco. And if you're working on mission critical systems and want to figure out how to get more out of AI, we'd love to chat. Thank you so much. In 2026, coding agents will quietly retire their first software platform. Not because it's bad, simply because the platform is unnecessary. I am Dominic Turno. I am founder and CEO of Resonate. Resonate is a durable execution platform built with minimalism and simplicity as its core technical values and these properties will play a central role in this talk. At Resonate, we have a working theory where software engineering is headed. Generalpurpose implementations will increasingly be replaced by bespoke implementations generated on demand. Not as a new library, a new framework or a new platform, but as a minimal extension of the infrastructure that is already in place. If this theory holds true, reuse will move upstream. Instead of reusing a general purpose implementation, we will reuse a specification and we will derive a bespoke implementation from it. In fact, we can build many bespoke implementations tailor made for the infrastructure that is already in place. We just have to ask the agent. At this point, the prompt is a platform. Resonate is a dual execution platform. We have an implementation of the Resonate server. We have implementations of the Resonate SDK for TypeScript, Python, Rust, Go, and Java. So, we have to ask what does this new reality mean for us? If implementations become generatable, where does our value live? and our answer our value moves from implementation to specification. Now this changes how we think about Resonate. The product is no longer the implementation. The product is the specification the protocol and from that protocol we want to derive multiple server implementations. One is a general purpose resonate server, our reference implementation. Others are implementations built with infrastructure partners. For customers and partners, this means durable execution right on top of their existing infrastructure with minimal additional dependencies. So the question is no longer can we build a server. The question is, can we repeatedly synthesize trusted servers from the same specification? And if so, how? When we talk about agentic engineering, we focus all of our attention on verification. How do we know the result is correct? But today, I want to focus on the specification instead. And more importantly, how can agents participate in specifying the system, not just building or verifying it. Now, Resonate is partnering with multiple infrastructure providers to bring durable executions natively to their technology stack. One of them is Senadia, the company behind Nats.io, an open-source messaging system designed for building modern distributed systems. For the rest of this presentation, we will use Resonate on Nats.io to explore our agentic engineering practices. How do we go from specification to implementation? First, we need to level set our mental model. This picture is a common view of agent decoding. There's an agent, there's a specification, and then there's an implementation. And for many applications that is enough but it is not enough for what we are trying to do because we are not trying to generate one implementation from a specification. We are trying to generate multiple target specific implementations from the specification. So the specification must not take any aspect of an implementation into account. The specification must not assume a concrete database schema or concrete indices. The specification must not even assume a relational database with tables and transactions at all. It must not assume a key value store. It must not assume weak consistency. It must not assume strong consistency. The specification must be abstract. Only the implementation must be concrete. So we ask the agent to follow the abstract specification and generate a concrete implementation. Specifically at first we ask the agent build a resonate server in rust on top of posgress and the agent failed. The gap between the abstract specification and the concrete implementation was too large. The agent generated a system that worked on the happy path. It passed the basic tests, but it was not correct. It broke on the concurrency. It broke on the process failure. It broke on the network failure. The implementation was closer to a prototype, but not a production system. So, we amended the process. Instead of asking the agent to jump directly from abstract spec to concrete implementation, we inserted an intermediary artifact, the concrete specification. That concrete specification was derived interactively with the agent. But the human was the main driver. For Postgress that meant making target specific decisions explicit, the data schema, the indices, the SQL queries, the transaction boundaries. Once those decisions were written down, the agent was indeed able to implement the production system. So this worked, but it also revealed the limitations. The agent helped us build the system, but the agent did not help us design the system. And if the specification is a reusable product, then that's not enough. Now the next step is obvious. Agents have to move upstream. But how? When we started building resonate on NATO, we changed the question. We did not ask can the agent build the production system. Instead we ask what does the agent need in order to design the system first and build the system second. So we gave the agent access to a deterministic simulation environment. And we gave it a different task. Do not build the production system. Build a simulated implementation. The simulated implementation is not the product. It is executable design. Its purpose is to discover the correct algorithm under partial order under partial failure. And once these algorithms are discovered, tested and verified in simulation, then we ask the agent to write the concrete specification. And only then do we ask the agent to write the production implementation. So the process becomes abstract specification, simulation implementation, concrete specification and then concrete implementation. This is a point where the agent moves upstream. Humans are still involved in the design process, but now the agent is a driver. Two ingredients make this possible. Minimalism and simplicity. Unfortunately, minimalism and simplicity are not the starting point. They are the finish line. We spent three years making the protocol smaller and simpler. Every time we ran into a problem, we ask, "What can we take away? What abstraction can we erase? What property can we remove? What relationship can we break?" The result is a very small protocol centered around two objects, a durable promise and a durable task. That simplicity matters because even simple concurrent distributed protocol have a complex state and behavior space. So in other terms, implementing even simple protocols on top of a few simple primitives is tough. Let's make this concrete with NATS.NATS gives us a small set of primitives. We can build on cues, a key value store and delayed or scheduled messages. These are not resonate concepts. These are the concepts of the target platform. So the design question becomes how can we express the resonate protocol using only these primitives? Let's focus on the key value store. The key value store is versioned. We create a key with value fu. Then we update it to bar. Then we update it to bass. So the latest value is bass at version two. Most of the time when we read the key that is exactly what we get a fresh read. And if all reads were fresh the design would be straightforward. But sometimes the read is stale. Here the latest value is still bass at version two. But the read returns fu at version zero. That is not corruption. That is not a bug in the key value store. That is a valid read under the consistency model of the target platform. And that matters because our implementation cannot be correct only when the target behaves conveniently. The implementation has to be correct when the target behaves legally. So the simulation environment has to expose exactly this kind of behavior. Fresh reads, stale reads, and the version information that tells us which world we are in. Unfortunately, we do not know the read was stale simply by reading. We will find out later when we try to write here. We read version zero. So, we try to update version zero. But the key has already moved on. The right fails. That is the moment the target tells us the world you saw is not the current world. Building always correct applications on top of a concurrency model that allows occasional stale reads is not simple. Not for humans, not for agents. So, how do we set up our agent for success? What tools does our agent need to ace this task instead of falling flat on its face? Agents thrive on feedback. Immediate, unambiguous feedback. Not just feedback that shows this went wrong. Feedback that shows why and how this went wrong. What stale value was returned? What logic was triggered? What ride failed and which invariant broke because of that. So we built a deterministic simulation testing environment in Python. And inside that environment, we simulated the parts of nuts.io we depend on here for example is the simulated key value store. It keeps a full version history for every key on get the simulated store sometimes return the latest version but sometimes controlled by the deterministic random generator. The store returns an older version. On update the store enforces optimistic concurrency. The write only succeeds if the version you read is still the latest version. Otherwise, it raises. This gives the agent a store that behaves like the real store in the ways that matter for correctness. But unlike the real target, the simulation is deterministic. It's repeatable and it's inspectable. So when the agent writes the wrong algorithm, we can reproduce the exact execution. that broke it and the agent can repair the algorithm against that trace. But deterministic simulation does more than just inject stale reads. It lets us expose facts the real platform hides. We call this the forbidden fruit. In production, when you read from the key value store, you only get the value in the version you observed. You do not get to know whether that read was fresh or stale. You do not get to see the latest value you missed. And you shouldn't get that information because real code cannot depend on it. But in simulation, we can record it. Here every get emits a trace event. If the read is fresh, the trace says this was fresh. If the read is stale, the trace says this was stale. This is what you got and this is what the latest value was. That information is forbidden to the algorithm, but it is incredibly useful to the agent. It lets us explore failures in terms the agent can act on. Now this is what a trace event looks like. The production code only receives the result. It sees the promise was pending. This is all the real platform would tell us. But the simulation also records the type of the read. This read was a stale read. And it records the latest value that was hidden from the algorithm. The latest value says the same promise is already settled. That difference is exactly the kind of fact an agent needs when it's debugging a distributed algorithm. Not just the invariant failed. But the invariant failed because the algorithm made a decision from a stale view of the world. Again, the algorithm is not allowed to depend on this information, but the agent is allowed to use it to explain why the algorithm it designed was wrong. Cause and effect becomes visible. The agent does not just learn that the system is wrong. It learns why the system is wrong. And with this approach, the agent was able to close the gap. First, the agent built a proof of concept in the deterministic simulator verified by fast testing. From the proof of concept, the agent derived a concrete specification where we already knew the algorithm was correct. And like before from the concrete specification, the agent derived an implementation. Deterministic simulation lets agents participate in the design, not just in the implementation. Humans are still in the design process, but this time the agent is the driver. From a single abstract specification, the agent designed and built the platform via simulation to concrete specification to concrete implementation. The prompt is a platform and the specification is a product. Thank you very much for watching. If you have any questions, please don't hesitate to reach out. You will find me in Resonates Discord. Hey everyone, I'm So I'm the CEO and co-founder of Starite Search. And today my talk is user signals die after retrieval boundary. So we'll look into uh what are agents essentially why agent fails, what is uh the cause of fails in retrieval particularly and how to make actually signal cross the retrieval boundary and how to make your agent basically outcome fair. So uh let's get started. What is an agent? An agent is an LLM that has agency to reason, invoke tools, uh interact with the real world, retrieve uh the memory to complete the task. One major loop here is missing is uh learning. It should also learn from what worked and what it didn't work. Suppose uh if I have to uh explain what is agent is I can explain with react agent. So if I have to explain uh what agent is I'll explain it with react agent. So basically user prompt the agent uh execute it in a loop uh kind to a retriever search and then pause when the task is complete. This is very basic react architecture. One thing that is missing is how to make agent learn from the outcome. So agent keeps failing at the same task got reported 85% of AI just failing. So it's in McKenzie's 2025 report. The problem came out to be most of the time is that retrieval is static. 73% of uh our app pipeline fails because of retrieval not generation and context stuffing. So a recent uh uh post from Ram Shria the XCO of Pine cone said uh we have been optimizing for the wrong thing. You are paying a lot for your agent's memory. It is probably broken and we have been optimizing for the wrong thing. Hey. Hey. Hey. Heat. Hey, heat. Hey, heat. Heat. Heat. Heat. Heat. Heat. Heat. Heat. Heat. Heat. Heat. N. Heat. Heat. Heat. Heat. Heat. Heat. Heat. Heat. Heat. Heat. Heat. Heat. Heat. N. Heat. Heat. Hey, hey, hey. Ladies and gentlemen, please put your hands together and welcome back our MC, member of the technical staff at Keycard, Ally How. Welcome back to our afternoon keynotes. I hope you all had an amazing day so far. I know I certainly have. I've enjoyed exploring the different talks across all of our different 18 different tracks. I've enjoyed exploring the expo session and I've enjoyed talking and networking with all of you. A engineer is a really special place where we can all come together in one space and have really interesting conversations that push the boundaries of what's next. It's a really powerful thing to get AI security engineers and AI engineers into the same room and understand how we can unblock um shipping because of security issues, ship faster and increase our engineering velocity. It's also really exciting to get the same people that are building the models in the same room with the people that are using them so we can understand what actually works and help us define what's next. I'm super excited for the rest of our content today, but I want to take a moment to thank our amazing sponsors that make all of this possible. Let's take a round of applause for our presenting sponsor, Microsoft. I also want to recognize our lab and platinum sponsors. Also, our gold sponsors. Round of applause for them as well. And last but not least, I want to thank our silver and bronze sponsors, which there are innumeable amount of those as well. It sterling takes a lot of people to put on this event. Um, and so super thankful to all of our different sponsors, thankful for all of the people that are here that make this community possible. Um, I know we've heard a lot about software factories today. And they're super interesting. We're all like very um allured by the promise of what the productivity and the unlock that they can deliver. But in practice, they can be more difficult than in theory. And I'm really excited because our next round of speakers are going to help us understand the best practices for loop engineering and help us understand how we can create software factories that actually work and don't produce slob. I'm super excited to introduce our very first speaker of the afternoon keynote sessions. Um, this speaker is a seasoned AIE speaker. Um he just told me this is his fourth time he's spoken at AI engineer which is incredible. Um this speaker is known for raging the war on slop. He is known for coining the the term context engineering and he is known for creating the research plan implement framework that we know and love. It's my honor to introduce um Jack Sworthis, co-founder and CEO of human layer to talk about harness engineering is not enough why software factories fail. Please welcome to the stage Jack. What's up everybody? How we doing guys? Give it up for all the great speakers today so far. Um, all right. This is uh harness engineering is not enough and why software factories fail. And we're gonna click maybe. Oh, that's way too many slides. Hold on, guys. Okay. Um, so we're all racing to put AI coding into production and uh there's been lots been said about loop engineering and uh we should probably write more loops and uh yeah, I don't know. I guess we're doing loops now. uh strong DM built a lights off software factory where nobody even reads the code and the prevailing narrative is we should just spend more tokens you are the bottleneck the models are good enough code is free just ship more stuff but at the same time we are starting to see the cracks our friend uh Mario at AI Engineer Europe begged us to slow down because companies that should not be having outages because of coding agents are having outages due due to coding agent mishaps. Um, code bases are falling apart faster than they ever have before. And our friends at Farosai actually even did a report since we all picked up all these AI coding tools in January, maybe February. Um, pull request code review quality is way down. We're having more comments, longer comments, and tons of PRs being merged without any review at all. Incidents are way up, bugs per developer are way up. And uh, many people will tell you that you're holding it wrong. that's the only reason you're not. Well, maybe you are, but that's not the point. Um, I've spoken a lot about how to hold it better when it comes to working with AI. Uh, probably a million views on YouTube at this point across a bunch of different talks. Um, and the basic thing is like as engineers, we've been told that if token maxing isn't working, then it's a skill issue. You just need to spend more tokens. Uh, let go of reading the code. that with enough harness engineering, if we maybe sprinkle some magic words, adversarial review on enough of our PR bots, that we can get the best of both worlds, 10 to 100x faster, high quality, and nobody has to do that thing we all hate called code review. Uh, I'm here to convince you today that this is in fact not a scale issue. That no amount of harness engineering or loops maxing can solve what is fundamentally a model training issue. That's why we say the harness is not enough. Um, and to understand this, we kind of have to grapple and dig into how coding models are trained. I'm going to talk about what I think the shortcomings are with some of the current benchmarks and what better ones might look like. And we'll talk about how to move faster safely. In the meantime, um, it's going to sound like a rant, uh, but there is hope here. Uh I'm going to talk about our journey and a bunch of the landmines we've hit uh building in this world. A bunch of exciting new techniques that we've been working with uh a lot of our users and customers to develop and I think how we all as a community get to the next chapter of agentic engineering after whatever this thing that we're in. Um so we use a lot of words here. I'm going to zoom out a little bit. I want to give you kind of like a brief history of the software factory. Um and it's actually I don't I I just learned this last week. It was the term software factory was defined at a NATO conference in 1968. Uh we're going to start around 2022, like right before AI started coming around. Um and basically in a typical 2022 software factory, you will have some people building stuff. You'll have engineers, you'll have PMs, maybe you have some sort of leadership team that is driving the vision here, and they all decide that stuff needs to get done. And so you put it in a tracker, a linear, a Jira, a beads, some sort of state machine that tracks what needs to be done. And then someone goes and grabs something off of there and they build the thing. And there may be some automated testing in that process, maybe some ma manual testing in that process. At a certain point, we make this pull request thing says, "Okay, cool. We got to run a bunch of checks, automated stuff. A human's going to review the change and review the code. And perhaps we might even have uh a human pull it down and test it somehow. And if anything goes wrong here, we loop back to someone builds the thing. Uh, and eventually we're ready for prod. And so we ship it to production. And once it's in prod, it makes contact with our users. And users do uh a thing that uh we all love. Uh users love to complain. I I love our users. Uh but yeah, they're going to ask for things. They're going to find bugs. They're going to file feature requests. Uh and that goes back to your team. You might also add monitoring. And so uh you know what do we want more than anything else? We want to wake up engineers at 3 in the morning when something breaks so they can get dragged out of bud to try to go fix it. Uh and we go on and on in this loop. Uh and we ship a bunch of code. Um, and one thing that we noticed here is that uh, teams figured this out decades ago is that this someone builds the thing step is usually going to take hours or days in most cases. And the review part will also take hours or days for large things. And so teams started doing these upfront planning, architecture, proposals, sprint planning, and they would collaborate this on on these things as a team uh with the hopes that we might decrease the percent chance that something would need to be reworked that we would be able to reduce the time spent in reviewing every line of code because we aligned on everything ahead of time. This brings us to the agentic software factory. Uh every company and their mother is talking about how they built a coding agent factory that ships 75% of their code. now uh literally everybody uh and so if we look at the software factory from 2022 uh we just replace someone builds the thing with an agent builds the thing and we have an orchestration and a harness and a sandbox and a model and computer use and I'm not going to get into like the details of that you can watch a hundred talks about that this week I'm sure um but now the building part takes minutes or hours but this human part still takes hours or days if you're going to review the code and you're going to test the changes and so we bring in agentic code review and we bring in agentic regression testing Uh, and it makes this part faster, but it's probably still the bottleneck. But we can do more loops here. Why not? Let's do some more loops. So, we can route all incidents straight into the factory. Why does someone need to get woken up uh and try to fix it when they could just wake up to a pull request and uh maybe that fixes the issue for you? You can take all the user feedback and just stick it straight into the factory so that uh people ask for stuff and it gets built. And now your only job is how much things can you stuff into the queue of stuff to do and how fast can you review and test the changes? Which brings us of course to I'm sure you know the lightsoft software factory where basically Dan Shapiro coined this is we no longer read the code. We say you know what this is going great that code review thing no thanks. We're just not going to do that anymore. Uh and we invest into all these other parts of the system your testing your monitoring your rollout everything else. we just write more code and build those systems better. And now our job really is just how how much stuff can we ask the agent to build. I am going to pause that does not work. Uh and this is why software factories fail. Um as as an aside, what I'm going to say has nothing to do with vibe coding. So Addy had this uh great post. I'm going to just go literally take his quote verbatim. a developer vibe coding a side project a dozen people will ever run and a team keeping a 10-year-old enterprise system alive for another quarter share almost no constraints worth naming and most of what you hear on the internet is one of these groups of people telling the other group of people how to live their lives if you love vibe coding please go on um at human layer what we care about is how do we help people solve hard problems in complex code bases um we use the word brownfield a lot which historically has meant like some 10-year-old Java thing. I actually think agents really start to struggle after maybe 3 to 6 months, especially with the pace at which we can ship. Now, um you can ask me how I know this and I will tell you that it is because in July 2025, we tried this. We went full lights off and uh if you have tried this seriously for a number of months, you probably found at least one issue that the agent couldn't solve. even with your most advanced prompting. You do research, you do reproductions, you just you have to go and dig into that codebase that you stopped reading three months ago to try to figure out what's broken. And in the meantime, your site was down, your users were pissed, and you were, if you were like me, you were probably miserable reading all this slop code that you let slip into your system. And what I want to get to is basically models have a shortcoming. um they can't maintain and improve codebase quality over time, not without a decent amount of human steering. Um and when I say maintainability, I'm basically talking about issues like it becomes really really hard to make a change in one part of the codebase without breaking other parts of the codebase. This is Martin Fowler shotgun surgery textbook code smell. Um I'm not going to say much more about maintainability. There's a bunch of books that you can go read about it. In fact, John Austerhood is actually here speaking this week, so you can go ask him in person about the philosophy of software design if you want to. Um, but it brings us to this question of like why can't models do software maintainability. Um, and you may also be saying, "But Dex, you know, surely the models have gotten much better since then." Um, they've gotten better in some ways, but they're still about the same in others. Um, if you want to solve one-off problems or vibe code a new marketing site, yes, they got way better since 2025 and 2024, but as far as improving codebase quality, I think uh they have not gotten much better. Now, I cannot prove this because there are no good benchmarks for a model's ability to maintain codebased quality. And I'll get into like where we're going with that. Um, but if you've worked with coding agents for a while, a lot of people are posting about this. It's just like you probably have this vibe that they they generally make things worse over time and make the codebase harder to work in. And to figure out why this happens, I want to zoom out to the first great coding agent. Why did cloud code go from nothing to four billion? And I think now they're at nine billion in revenue in under a year because they were great CLI agents before cloud code. You had aer, you had codebuff. There was a bunch of tools in this category. They had all the same tools, read, write, edit, grab, bash. Um, so what was the difference? The difference was was that the this was the first time that a model lab trained a model against the harness that they were going to distribute it to users in. Um, and it got really really good. This is just some of the tools, but it got really really good at calling these sorts of tools in an agentic loop. In fact, the OpenAI team did a talk in November about basically if you are a uh harness builder and you don't own the model weights and you can't RL the model in your harness, you will always be at a disadvantage compared to somebody who owns both the model and the harness. Um, and I'm going to site a couple slides from my buddy Calvin French Owen who was a MTS on Codeex during the initial launch. Um, but LM are just next token predictors. Uh, this is a slide from over a year ago where basically as you're doing your agentic loop, context window goes in, next step comes out. problems. We're going to generate a bunch of we're going to give it a problem and we're going to generate a bunch of traces, try to solve the problem a bunch of different times. We're going to score them all on correctness and did the test pass and all this stuff. Uh, and then we're going to reinforce. We're going to make the bad behavior less likely and we're going to update the weights to make the good behavior more likely. Um, this one of the classic ones here is bench multilingual. Uh, they're about 15-minute tasks. They're from open source repos like Reddus and jQ and Django and all this stuff. and they have binary one or zero rewards on did you fix the problem you were trying to fix and did you do it without breaking anything else. Um and we look at actually a real problem from one of these benchmarks. This is fastlane which is a Ruby project. Um basically there was some issue where we weren't checking for nil and we have a stack trace blow up because you have a null pointer exception. And in this um in this benchmark you have a base commit that we're going to check out before the issue was solved by a human in the past. We're going to give it a test patch that says here's what the behavior should be afterwards. We have a golden patch. Both these are hidden from the model. Uh, and so we have the agent go try to solve the problem. We store its patch. We undo all the changes it made to any test files because I'm sure you've seen models comment out tests just to get things working. And then um we're going to apply our golden test patch. Uh, and then we're going to run the test. Old test and did the new test pass? And if they both pass then, uh, then we get the reward. Otherwise, we don't. Um, and so models are trying to get the test to pass. There's no way in this system that we can penalize it for poor program design or for eroding the maintainability of our systems. That's why we get things like this try catches around things that probably don't need a try catch or things like this. I think by Bob gave us this example earlier of casting things to other things just so the model can just just it just wants to get the test to pass. Um, and so if you can't verify the uh maintainability of the code, it gets way harder to train on this stuff. Um, so you remember this picture. Verifying code quality and maintainability is orders of magnitude harder than the code runs and the test pass because the cost function of bad architecture is measured in months and years. If you have a coding episode and then you only find out months later that like somebody vied this a little bit too hard. It's really hard to propagate that reward signal back across the gap. And now the frontier is getting better slowly. And since I know someone's going to be in the YouTube comments about this, yes, I know benchmarks and verifiers are different and they actually have to be separate data sets, but they're shaped the same and the the structure of these benchmarks is directionally correct. So, we're going to look at these as like what is the future of evaluating code maintainability. Um, there's a really cool one called SWE Marathon from Abundant AI where they do like 400hour tasks of like clone all of Microsoft Excel, every single feature. Uh, and they have some sophisticated reward channel stuff. uh deep suite from data curve is also like large tasks on oss repos that are not actually in the training set because they were never actually built in the real world. Uh and then you have frontier code from cognition um which is multipr tasks. They do interesting things like hey if the model writes tests that don't fail on the pre- patch code then it gets penalized and we have a judge model that says okay uh did this follow all of our code quality rules. Um, so we're getting better, but I think models judging quality can only go so far. Uh, because if the new model, if the model knew what good code looks like, it would probably write it in the first place. Uh, and review agents and throwing more tokens at the problem, it can raise the floor. Um, but we're still constrained by what we can teach during RL. Um, and so I will I will posit that for now we're stuck reading the code. Uh, but we can still move pretty fast. And of course there's a world where this is solved uh in the future. And if you want to just keep yoloing prompts until you get to GPT7, you don't have to think about this. By all means, please. Uh, but bitter lesson be damned. We've got some problems to solve. So, let's engineer our way out of this. Um, so turning the lights back on, we're going to put the code review back. Uh, we're going to embrace this approach of like how do we plan up front to reduce the chance that we have a long or uh difficult review process. We're going to find leverage. We're going to use AI to help with this. Um, the first thing we're going to do is we're going to do some sort of product review. understanding what problem we're solving, what's the desired behavior, maybe looking at mockups. Here's a product review I was working on yesterday with a mockup of a new feature. Um, once we have our product review, we're going to, and by the way, we don't small stuff still just go straight to the agent. Um, but once we have the product review, we're going to also do architecture, system architecture. A lot of people have been doing this for a while. Component contracts, data models, constraints. Um, this is an example of a doc that we build to understand how these systems are going to fit together and what's like the highle picture of it. From there, we do something uh that I think is really underemphasized in uh agentic coding these days, which is program design. I think people assume that once you get the architecture right, the model can just cook. Um but we I we often look into the types and the method signatures, the program layout and the call stacks. And so here's some examples. I don't think you'll be able to read this one, but this is like the level of abstraction we're at is how are we actually going to lay this stuff out and how are these systems going to interact? Uh Dylan Mullroy from Cloudflare talks a lot about how he's using these call graphs as part of his planning process. I think this is exactly right. Um and then once we've done the pro program design, we can do this thing called vertical slices. Um which is the order of implementation, multi-reo coordination. How are we going to build this across our entire system and how are we going to check it along the way? I've talked a little bit about how models have horizontal plans. I won't go too deep into it. If you want to learn more about this, you can go watch our talk from AI engineer Miami. um couple shots of a dock like this going through the tests and the steps in between each phase. Um the main idea here is 30 minutes over here in pre-planning and alignment can save you hours in review and so it's actually feasible to still read every line of code. Um we're skip this part. Uh basically the the summary here is like you don't have too many PRs. If you're drowning in PRs, you actually have too many bad PRs. Um because a good PR is a joy to to review. It's it's you're just reading through like, "Yep, this is great. This is what we discussed. This is what we talked about." Um but even if a PR needs 20% rework, which is generous for a lot of AI AI vibecoded slop um it's an it's an emotional and intellectual burden on both the reviewer and the submitter. Um and so if you use model assisted planning and alignment, your alignment is shorter because you use AI to get all the information at once. your code review is faster because you aligned up front and your coding is faster because AI did it. And so you're now you're actually really moving faster, but you're still reading everything and you're still owning the code. So closing advice, um, it's easy to hear all this and be a little bummed out. Uh, I really like the world where we just yolo everything and we can just like not have to ever read code ever again. But, uh, we're engineers and these are just constraints and models are good at certain things and they're not good at other things. And so go figure out how to solve problems given a set of constraints. Uh use loops. They're great. Go solve hard problems. Seek leverage. Um if you want to help with this, um we're building human layer. Human layer is an AI IDE and collaboration platform. It's building blocks for your software factory. Um and soon to be better verifiers for software quality. Um we've got sort of a Figma for cloud code and codec style collaborative workspace. It walks you through the workflows for doing this sort of work. And uh we are talking to design partners. We are hiring founding engineers here in San Francisco. And uh these slides are live. You can go get them right now. You can try human layer at human layer.com. Uh it's free for small teams. Go solve hard problems in complex code bases. Thank you all for your energy. Please welcome to the stage the research scholar at Linet's Labs, Eric Meyer. Well, um, can you go back one slide? Sorry. All right. Good afternoon, everybody. Thanks for being here after a long day of talks, exhibits, side effects. Oh, sorry, that was a side event. Um, I hope that, um, you have as much fun watching this talk as I had creating it. Um, let me first get this out of the way. This is not a product pitch or announcement or anything. It's a 20inut tutorial of how you can use elementary type systems and compiler knowledge to make AI provably safe. And I'm sharing all my secrets with you today. Um hopefully to kind of inspire some of you that next year you will have a booth downstairs where you have kind like you know created a provably safe agentic harness. Um or who knows maybe some of you have already solved it. Let me know and then you know we can grab a coffee instead of doing this talk. Um with that out of the way let's get going. um while I was preparing these slides and I'm sorry that I was multitasking but I was site um vip coding on the site um and then when my attention waned for a second because I was trying to convince the model to draw some pictures that it didn't want to do and you will see some of these pictures later you can guess which ones were rejected suddenly when cloud code deleted one of my files And I'm sure this has happened to you before. Um, or maybe not. Maybe you always kind of like, you know, run everything with no permissions and then you say, "Yes, yes, yes." But I like to live dangerously. Um, but I'm convinced that if there's anything between the model's goal and where the model currently is, it will do everything that it can to reach that goal, including killing us or deleting your files or deleting your database. So, I think that these models are intrinsically very very dangerous and we have to tame them. So, that's what my talk is about. Um so let's get like you know start this story. Um and it's I think a very very sad story but also a scary story of how we as an industry got to this point where we are about to let normal people the general public give control of their computers their finances their whole personal lives over to AI agents and we don't have any protection in place and I think that's very sad and very Gary. Um, so let me tell you the story how we got there and I will like have some characters like Claude and we will see Dario, Daniela, Sam, Bernie, but um the main character is is our friendly pit cla here. Um, I think you can all remember um November 30, 2022. This was kind of like a very special day in in history because this was the first time that you could speak to your computer. You could say summarize my emails and it would you know um answer you in perfect English. Um I think for me at least that was magic. But I think most of us didn't realize that by introducing this innocent looking function here LLM that takes a question and returns an answer that that would open Pandora's box and that would change our history forever. Um but before we go continue the story this conference is called AI engineer. All right. So, we are engineers and maybe we're the last generation of engineers that still understand what this is, what code is and or maybe most of you have already forgotten what code is because all your code is written by agents. But if we look at this signature here, it says it the LLM takes a question, returns an answer. The question and answers are not strings. They're very complicated JSON structures and they get more complicated every day every time a new release of APIs comes out. But for this talk, we can just assume that question and answer are just opaque types. We we don't care about how they look like. We do care about what they represent. Um now anyway the euphoria of like these LLMs as being great tools didn't last very long and just when we thought that we have eradicated the small pox of computer science SQL injection it came back with a vengeance because the bad guys discovered that you can trick LLMs using prompt injection and LLMs have no distinction make no distinction between code and and and text and so they are very very easy to trick and this I think is a bigger problem than SQL injection ever was. Um but it was not prompt injection only that made LLMs kind of like have a bad rep. LLMs are trained on the whole internet and there's like a lot of good stuff on the internet but also a lot of bad stuff like how do you create a bomb? How do you synthesize drugs? How do you hack into people's systems? And the leaders of the big foundation labs, they got a little bit worried that the that the government would interfere and regulated the industry. So they told their PhD researchers, go find a solution for this problem right now and quick. Come on, solve it before you know the the government steps in. Um, and here the PhD types, since they're PhD types, they thought long and hard about the safety problem. And they came up with a new interface for LLMs. That's this kind of scary on the right. Look at that. What does it say? There's like some sigma Greek symbols. There's props, whatever. Well, that is lean. Probably you have heard of lean. Anyone here heard of lean? lean is now like the hot thing, right? Like VCs are are writing like multi-billion dollar checks if you just say that you're doing something with lean and of course these PhD types researchers are using lean and you have to suffer because of that. Um now let's first look at the signature in a slightly simpler language called um deafne and what this thing says is that the llm takes a question returns an answer it requires this question to be proper which means that it's not an offensive question and then the model returns a safe uh answer and this thing is proved automatically. So if you give it a proper question it gives you a safe answer. Um, now I think there's too much attention for lean. I'm a recovering typaholic and math addict. Um, I love lean, but there's many, many other tier improvers and model checkers out there like Isabel, Rock, PVS, TA Plus. Um, but lean is the grease that kind like keeps the VC money pumps going. So, I will use lean um today. So here here's the kind like you know the the interface again in lean and now in lean you don't do automatically improving. If you're like a lean expert you will say Eric well we have grind in lean but let's like you know put that aside for a minute. Um but in lean you have to both show that the how to compute the the result type and you have to do the proof by hand. Um so it's it's slightly different than um the definite example. But if you think about this thing for just a single nancond, you will realize that it's impossible to write a formal proof that an answer is safe or a question is proper. Um and that is why there are at least 100 startups down here in the exhibition hall that are using LLMs as a judge because this is not something that you can formally specify. But does it mean that an answer is safe? That's not a mathematical property. Um, and of course, if you own a foundation model like these guys, you don't need external LLMs as a judge. You just um bake it into the weights and you call it, the model is aligned. Um, but unfortunately trying to bake alignment into the model is not foolproof and models get routinely jailbroken. So they had to go to the pope and ask it to kind of like you know um bless their model that it's safe. Um now I think it's terrible if like a model says something offensive but those are just words and ultimately the words are are like they just like you know they drip off your body. They don't do anything. Some human has to act on words to make them dangerous. Um and so maybe that is what they mean by broadly safe um when entropic talks about safety. Um because it's still a human involved. But then something terrible happened. Something really terrible happened that changed the world forever and that is in June 2023, OpenAI announced tool call support in GPT4. And of course all the other vendors rushed out to copy this. This is called the principle of minimum differentiation. And that is why all these APIs look the same. Um now the act of adding tool calls changes AI safety from a philosophical debate to something that causes real danger. You could say tool calls give the model clause in addition to a mouth. Or you can say tool calls is like handing a gun, a loaded gun to them. But of course, nobody listens to me. Everybody ignores what they say. And these guys just went ahead and have shipped tool calls. They just, you know, just just do it. Now let's go back to like this is AI engineering conference. So let's look at what is the difference in the signature of LLMs when they add a tool calls. And it's just that little IO there. And of course it messes up the the formatting of of the the um uh signature. But if you look at the picture there, what you show now suddenly Claude goes from like a nice puppy to a dangerous thing. Look, it has all these dangerous tools and now it becomes scary, right? I've never seen anything scarier than an LLM with tool calls. Um, now if you look at this, this is like like a small step for a type but a giant leap for chaos. Why is that? And that is because this IO says that in order to compute the answer, the agent has to go through the agentic loop and it's doing side effects. while it's producing the answer, it might empty your bank account. It might delete your files and then it gives you a safe answer. But who cares about the safe answer when all my files are gone, right? So that's why I say it's a giant leap for for chaos. Um, again, sorry this is engineering conference. Let's look at this type IO. And you don't have to understand it, but just see that there's a type there called real world. Yes, lean this esoteric thing has a type called real world. And why is that? Because something of type IO will mutate the real world. So it warns you don't use this because it can make irreversible side effects and like deleting your files. So Solomon hikes um last year this conference called an AI agent an LLM that's wrecking its environment in a loop. And I think he's a hero. I don't know if Solomon is here this year, but I think he should he deserves deserved a round of applause. Um, because I think this is the right definition of an AI agent. Um, by the way, this was one of the pictures that I had trouble to generate because it it clearly depicts violence and so it's kind of an unsafe thing, right? I I have a picture that depicts violence. Um, so are we doomed? Well, our agents have access to private data. They have untrusted content like the prompt injections and now we give them tools. Simon Wilson calls this the lethal trifecta. And what can we do about this? Well, um I don't know if you've seen the Dutch soccer fans, they have the famous march where they say to the left, left, left, or to the left, left, to the right, right, right. This is actually the secret to solving this problem. The Dutch team got eliminated yesterday, so you have to see me do the dance. Um, but all that we're doing is we're pushing this IO to the right, to the right. And what you now see is that the tool belt of Claude goes to the left, to the left, and suddenly Claude is a nice puppy again because instead of executing the agentic loop, it creates a plan and says, "Here is the plan to do the agentic loop." And now Bernie will take that plan and we'll execute it. And we all trust Bernie, right? Bernie is a good guy. All right. So just to kind like show it here. So in some sense what we're doing, we're airgapping the agentic loop from the agent. So we don't let the agent run the agentic loop before the agent run it. We want to be able to check it. All right. Now the problem is that if you get a value of type IO of A um that's a really a black box and the lean manual says that is a black box you cannot reason about it. So even though Claude now gives us this plan, there's we cannot look into this plan. Lean doesn't allow us to do it. By the way, this is another picture, right? That that promotes drugs use and the model let me do it. I'm a good hacker. You know, I can just make it do forbidden pictures. Um so if we look at the lean again, what you see here is that the model now computes an answer, but it doesn't compute the answer, right? it creates an an IO of answer. So this is a plan to generate the answer and then it creates a proof that this um that that plan is safe. And the nice thing is here that you can get at that proof without having to run the agentic loop. But unfortunately as I said like this proof if it's like something of type IO it's useless. Ah What can we do about that? So, I keep kind like moving you guys forward and then we never get to the final answer. But there's one less trick and you see the the researchers here are becoming more much more sophisticated. Instead of the flat 2D ones in the past, now they're like real people. Um, and what is better than creating a plan of type IO of A, it's creating a program that represents an expression of type IO of A. Oo, that sounds very meta, right? Um, not meta in terms of meta. I don't think they're very meta, but meta in the terms of like, you know, like meta, you you know, you know what I mean? Um, and again, it's a small step for a signature, but a giant leap for safety because now the model returns an expression, a program that represents a computation. If you know link or C, you will recognize that this is one of the tricks that I always use. Um, if you know lisp, this is of course second nature for you. Um, I cannot like you know have a talk without talking about monet. So if you ask yourself what is this expression thing? Well that's just a monet but it's not just a monet. It's a free monet. What is a free monet? It's a monet that loves tie dice. Um and now if you look at the the signature of the the um property to prove that something is safe, you see that it takes an expression of a computation that returns an answer. Um and if you have taken any compiler course in college, you know that it's trivial to do data flow analysis, type checking and so on on programs, right? So now we're safe. We're home safe. And Jeff Huntley wanted to remind you that we can solve the trifecta problem just by doing taint analysis on these expression on these programs. Okay, this is the last code I will show you because I'm running out of time. But just want to show you here that you know you now have a simple inductive recursive interpreter for this language and you have a simple inductive proof and the models can generate these proofs. So to um recapitulate like the summarize what we did is we went from unhinged LLMs that were like you know could give bad answers to ones that were aligned. Then we saw how tools wrecked it. Then we solved that by deferring execution. So by air gapping the LLM from the tools and then the real solution was to refy the plan into a program and a program that we could prove to be safe. Now you would say Eric, oh you're a genius. No, I'm my brain is the size of a peanut. This is something that's called proof carrying code and it was invented by academics in the 1990s and I'm just stealing it. Um, all right. At the higher level, if you didn't understand the code, three points. Agents are dangerous until proven safe. So, you should never ever let your agents do something unless you can absolutely prove that it's safe. And the language that this agents generated was not designed like normal users don't understand free monet. It's a machine that consumes it. It's a machine that generates it. It's a machine that proves it. So, we should stop designing languages for humans. And it's all basic, only requires programming 101. Um, do we go? All right, that's it. Um, the end of the story. If you're curious to play with this, a bunch of academics in particular now that I'm in from Harvard have implemented this. It's it's there on GitHub. It uses a slightly different language than what I use. It uses also a slightly different language than free monet but the idea is the same. The language doesn't matter. It's it's the um the principle that matters. So hopefully you've learned tonight that it is actually possible to have mathematically proven safe agentic compute and it only requires very elementary type systems and programming language machinery. Thank you so much. Please welcome to the stage the machine learning engineer model behavior at cursor Lee Robinson. All right. Hey everyone. Uh I'm excited to be here. Excited to be back at AI engineer and talk a little bit about how we're training models at cursor. So how we train the models and also how the model learns to train itself or recursive model improvement. So our goal at Cursor is to build the best possible AI models, which might make sense. You might have heard of this equation of if we just give the models more compute, we can get a better model out. And I think this is a helpful simplification of the problem, but I want to actually click in a few layers deeper in the talk today and talk about all the different pieces that go into training these models. So we can think about this loop. We put a model out into the world and then we get feedback from you all when you use the model. what goes well or places we can improve. We use that to scale and improve the data that we do for the next round of training. And we also then increase the amount of compute and scale up training overall to make a new model. And this is a loop that can just go over and over again. However, if you see my helpful snail or uh turtle to bunny meter down in the bottom right, it's pretty slow. This is going to be a serial process and you can only do in this instance one big run at a time. So, we want to make this a little bit faster. But I'll actually go another layer deeper and add some more color here. There's actually two loops, the outer loop and the inner loop. On the outer loop, we have the feedback coming in, but we also have data like online metrics. So, running AB tests and seeing what users prefer a different checkpoint of a model. That's going to then flow into hopefully making better highquality evals that help ensure we're getting the right behaviors we want out of the model. and also being able to create much more difficult problems for the models to try to solve where we then can kind of shape the rewards that we want to get during training. So we want to climb that inner loop as well. We have been training models for about a year at the large scale at cursor and I want to talk about some of our progress so far. So we put out composer 2.5 in May and it's now the most popular model in cursor which is exciting and we scaled up training here quite a bit by generating more RL environments trying out some new methods for learning and also just making more ambitious problems for the models to solve and the results have been pretty promising so far. Like I mentioned this is still a new effort for us. ML has really been in the blood of cursor since the start where we were training more specialized models for things like tab or code autocomplete but really in the past year we've staffed up and built a team with ambitions to train you know state-of-the-art models and we've made some pretty good progress just in the last 12 months people like composer right now I think because it is both fast and pretty smart and also cost effective and as we've heard from other speakers today I think there is a space in the market right now for that type of model in addition to also having the most uh intelligent models in the world and we think it's important to have a good selection of both of these type of things. So composer we think is serving a good niche here and when we released it we were honestly pretty impressed with some of the public evals. It did a little better than we expected on uh artificial analysis. It was a a pretty modest jump. However, there were a lot of behaviors that we found that we really wanted to improve for the next version of the model. Notably we wanted to have a much bigger and smarter model. We wanted to control every aspect of training. So ideally doing a full pre-train from scratch versus the previous open source base of Kimmy that we were using. We wanted to infuse new data so that we can make the model great outside of more things than just coding but more of a general model and then also just scale up every part of the training process. More data, more compute and really pushing RL as far as we can. So first I want to talk about improving the outer loop and then we'll drill drill into the inner loop. If you haven't used cursor in a while, you might think about it as this IDE or tab autocomplete thing. And in reality, uh the vast vast majority of our revenue today comes from agent usage. And that means that all of the data inside of cursor is also coming from agent usage. And we can use that to train better models. So for example, we kind of have two different buckets of feedback. On the external side, when you're using the product, you can thumbs up or thumbs down different responses and give feedback. And we use that to then classify places where, for example, composer maybe doesn't do as good of a job and we want to improve that for future versions. And then also on the internal side, we're heavy dog foodters of our models and our products. We're uh very critical and want to make sure we're using good models and we of course use them all day. So we have a good mix of manual reports, automated reports internally, and just lots of ways we're trying to get the best behaviors out of the model. And if we do that over and over and over again, we can get better models out into the world. But really, the place where we can make massive speed ups is improving that inner loop. So just to zoom back in on that again, we have these high quality evals. we have these very difficult training tasks and we want to climb these evals as quickly as possible so that we know if we make a new checkpoint of the model we're actually making progress on the things that we want to measure. So for example some of the evals that we have introduced or have already had are things like understanding what you really meant when you have included maybe 50 skill files. it gets kind of hard for the models to figure out your actual intent or trying to figure out the line between when you push back and ask the user to clarify a question versus when you trust their judgment and they said no I really wanted to do this there's a kind of a fine line and people have different preferences so a lot of these eval are trying to shape a lot of those different behaviors and also model what it feels like to be a software engineer we ask the models to do really ambitious things like hey we just had this sev could you have actually went and read through all the data dog logs read through Slack, read through notion, and came to the same conclusion or the same fix that we did. Uh, and a lot of models are just not very good at this today. And that uh backs a lot of the evals that we create based off these software engineering tasks. Now, as the models get smarter, they also find very creative ways to hack the evals. So, as we've been training for a new version of our model, we also noticed there was some interesting reward hacking going on. Um the models learned how to really just go back in the git history and figure out if there was a solution or a part of a solution. Uh they figured out good ways to go online and if it was a public eval just see if there was a fork of the eval anywhere they could look up the results from and this affected our own models as well as other models. So, we did a little research here and found that if we did just a couple small changes on measuring public uh evals, we could have a pretty noticeable uh change in the scores that were reported. So, first off, we would delete the git history at the start and we could restore it at the end so that wouldn't affect the run. And then also, we can have a network allow list or just some basic controls on the sites that the uh the agent can go and talk to. And I think this is helpful for public eval which often are the things that people are using to calibrate whether a model is good when it gets released. You know, you see that big chart of all the benchmark numbers. But this isn't really a true test of what it feels like to use these models. Like in reality, you have access to the internet. You can do whatever you want in the internet with these models. And you're definitely using git. So you want to be able to test the true capabilities of the models. And that's why we have cursor bench. We have this private eval set that is mostly made up of things that happen in our codebase which is held out from the eval so we ensure that the models aren't trained on it and it's based on those real world engineering tasks. Now another part of climbing that inner loop is trying to make very very difficult problems for the models to solve. As the models get better, you might have noticed if you're looking at an eval and all the models are scoring like 90%. It's probably time to retire that eval and try to get something more difficult and that the half-life of those eval will go down as the models get smarter. And to do this, it requires a lot of things. It requires some amount of researcher taste and what these problems should be. It requires a lot of compute. So you can try a lot of different ideas. Some of them are going to work, some of them are not going to work. And there's a race against the clock here. So you want to try as many in parallel as you can. Just to put a example to this of one of those type of problems. Let's say that on the left for example you have each one of those squares is representing files in a codebase. And then on the bottom you have the tests. One thing you can do is generate a very complex application or environment for a very ambitious application or task and then you can delete part of it. You can delete a feature. You can delete files and the test will then fail. And then you can ask these models to go and basically figure out however it wants to reimplement that feature and it has a very verifiable goal of all the test passing to be able to get some reward back at the end. And this actually works out pretty well and has allowed us to scale making these uh interesting problems for the you know the frontier models to solve. Additionally, we have found some new learning methods which I personally think are really interesting. The first one is you can teach the model to kind of coach itself. So for example, if you think about an RL roll out or a conversation with an agent, this can be hundreds of thousands of tokens. And if you think about trying to grade at the end of this where the model made a right decision or a wrong decision, it's kind of hard, right? You have all these tool calls, you have thinking blocks. It's pretty hard to figure out where to assign that credit to the root issue. So the more precise we can be, the better. You know, was it one of the tool calls? Was it a thinking block? It's pretty hard. And one thing that we've done to improve this process is something called textual feedback. So we want to zoom in on one specific part of that roll out. And ideally we can hint or kind of nudge to the model, hey by the way here's a way you could improve and then look at the probabilities again and nudge up the ones we want or you know downweight the ones we don't want. Uh for example on the left you have this student case where you have a roll out and it tries to call a tool and the tool call fails. it should have known that this tool was there but it just decided not to work for this time. We can then use a teacher or we can use the same model but we include this hint and we say hey as a reminder you have all of these tools available and then we like I mentioned we can just upvote or upwe the probabilities such that we can get the behaviors that we want and this example is with you know adherence to tool calling but we can really use this for anything. We can use this for making style changes. We can use this to get any behavior we want to influence the models during RL. And this has proven to be uh very valuable for us. Now, how we scale these loops both the inner and outer loops also comes down to scaling the amount of compute we have. Uh we announced back in March that we are partnering with SpaceX to get access to a lot more compute and this allows us to train very large models from scratch. not only the product but also the models down to the supercomputers or the data centers where we're training these models with Colossus and then increasingly to the chips as well with Terraab and that just allows you to do some pretty interesting things in taking advantage of that full stack. If you haven't seen Colossus, I think it's really interesting. Personally, they were able to train uh or able to build out this supercomputer in 122 days for 100,000 GPUs and then added another 100,000 GPUs in 92 days. So, very impressive. I had to do some pretty creative things to get this done and kind of take over this old factory in Memphis. And it's kind of shown they can stand up these data centers really quick, which is of course very helpful for our model training efforts. And for Terrafab, I think it's also very interesting that they're building their own chips. I mean, to put the size of this into perspective, if you just think about how large this physical structure is, I know you're all thinking it. It's like the size of a 100 bies, which for my for my folks from the south, you know, we love bies. I'm not even from the south and I love bies. This is like the crown jewel of the south, the premium gas station experience. It's it's a lot of stuff, but that just puts it into perspective, the size. So, going back to this equation at the start, more compute in, you get a better model out. I think it's sometimes hard to understand what does that compute even do? Where where do you actually put that compute? Let's say you have access to a bunch of GPUs. Like, what do I do with it? And I think it's helpful just to step through a few of the things. Of course, first you have actually serving the model to end users, but also you're serving up different checkpoints internally. You're running different AB tests. You're trying different variations of the model. You have the actual training process itself, but also the sub pieces from pre-training to mid-training to RL. And then also you're then training these derivative models to do other parts of the process like climbing the inner loop, which we'll talk about here in a second. you have the data generation and the reward generation. So creating those really ambitious problems that I talked about or when you're doing eval trying to create these rubrics for whether it was successful or not and give it some grade and then actually judging those scores. Um you also have the eval themselves. Ideally on every new checkpoint of the model you want to be continuously running evals to see if you're improving in the places that you're measuring as well as just developing new evals all the time. Like I mentioned, the the halflife of these evals, as models get smarter, you need to be really continuously investing in making these better. Um, and there's just the research itself. Ideally, you want to free up your team of researchers to be able to tweak the knobs to try ambitious ideas, experiment with new things, as well as do side runs. And this all is compute that needs to be, you know, allocated for somewhere. But what that ultimately turns into is ideally you can get in a state where you have multiple large training runs happening at the same time where the researchers are unblocked and they can go try their research and you're still kind of contributing back to this core flywheel. And if you do that and we revisit our speed meter in the bottom right, you're starting to get to a point where you're getting something that's like RSI or recursive model uh in improvement here where the models are improving much much faster. Then the bottleneck becomes how do you scale the folks actually training the models? How can you automate the more monotonous parts of machine learning or research so that you can get these useful models out into the world? And this is where I think it starts to get really interesting. If you think about the model as Mario, if you give it some tools, all of a sudden you're more like a Super Mario. And if you give it great context, everything about your organization, all the places that you work, you connect it to all your different tools. That context kind of turns it into the fire Mario or the Super Fire Mario. And just to kind of further prove this point and add a few examples here, I think for tools, a lot of these are pretty obvious. The models can write code with a with a harness. They can you run shell commands. They can look things up on the web. But I think increasingly even with these primitive versions of memory, like writing files. These last three, I think, are just starting to become really popular and uh more useful, which is the models and the harnesses should be able to use a computer exactly like you would. It doesn't need to be just inside of your guey or your CLI. It should be able to control every part of your computer. You as a human on Slack or on your tool is basically subscribing to Slack threads in your head so that you can follow them for updates. Ideally, you kind of want the models to just follow a thread and then ping you if it needs something. And just like we have code bases that store the code, increasingly as these models do more work for us, they kind of need like a Dropbox for themselves. Where do you store the slide decks? Right? You could put that in code, I guess, but I think there's an increasingly uh new opportunity here. And then for context, of course, you have all the different places you can hook up with MCPS, Slack, and notion, linear data dog, etc., and the codebase itself. But I think these last two are really interesting, which is increasingly we find that you have a human working with a team of agents, and then the agents can start working with the other agents. It's a little meta, but I think this will be a big trend in the next six months. Just to kind of put an example to this, we've created these tools and these systems where researchers can run experiments directly from Slack. We want to avoid this state of being bottlenecked on humans launching and reviewing and babysitting runs. And we actually have an entire team just working on automating every part of the research work that isn't uh you know isn't freeing up the researchers time to work on their most ambitious ideas. So every person on the ML team gets access to this fleet of agents. They can basically train models directly from Slack. And a few people on the team have taken this very far where they have these agent systems that can go and do a lot of work for them. Maybe they want to go create a bunch of very difficult problems for the models to uh try and solve or they want to create a whole bunch of new evals based on some good ideas that they have and they just want to let the models cook and go work for a while. But if something gets wrong, if the infrastructure goes down, if there's some blip somewhere, the model can message them on Slack or just page them directly and say, "Hey, this is really important. You don't want to lose six hours because your info was down. Like, you should go check this out right now." And this like humanto aagent coordination I think is just starting to be figured out and it will be an increasing trend. The last bit here is that the model is learning to train the next model and it it it's a little hard to wrap your brain around. The way I like to think about it is every time you release a new version of this intelligence then you can create or distill these derivative versions that you use to speed up other parts of the training process both the inner loop and the outer loop. So when you're trying to do your evals for example, you have different models for doing the judging and you have uh your reward models as well. So when you make the top level mo model smarter, it actually improves the whole system. If you think about the multiple training runs diagram I showed, I'm going to throw on a a new meter here, which is the brain to galaxy brain meter or the intelligence meter. You are bottlenecked here on the smartest model in your system. And if the smartest model then creates those derivative models, when you can improve that, you can actually make every single one of these loops much much better because you've raised the kind of floor of the intelligence. And this is how you start to get to something that feels like this recursive self-improvement, this model that is just improving all the time on your behalf. And especially as we bring more and more compute online, I think this is really going to help us scale our model efforts and hopefully make even more useful models for you all to use. Uh to conclude, I'd just like to thank everyone on the cursor engineering and ML and research teams who have been uh working hard to get a new model out to you all here very soon. Hopefully very very soon uh that we think will be a pretty notable improvement over our last model. And we're excited for you to try it. Thank you so much. Ladies and gentlemen, please put your hands together and welcome back our MC, member of the technical staff at Keycard, Ally Wow. Thank you. Wow, what an amazing first day of content here at AI Engineer. I think the biggest takeaway for me today after listening to all the amazing talks on software factories is that the raw materials for software factories exist right our context windows have gotten larger we have better memory model vision is improved we can actually verify the work we've got better AI security best practices now to understand patterns around agent identity and access control but we have to have the discipline to be able to wield all of the raw materials correctly in order to build software factories that actually work and that really resonated with me in some of the talks I heard this afternoon such as Dex's talk where I mentioned that one of the takeaways for me was that engineering as a practice is absolutely not dead. We might not be writing all of the code anymore and agents might be writing the code but engineering has to be part of that loop. Um especially if you want to write software factories that actually work and don't produce slop. So I hope everyone learned a lot today. I know I certainly did. And thank you so much for your curiosity, your optimism, your energy, and we'll see you back here tomorrow. Thank you so much. This is our third year doing the world's fair. We have so many events. You are helping us figure out what the future of engineering should look like. Down, hey, hey, hey, hey, hey. Come on, go go go. Hey, hey, hey.