The Age of Async Agents — Cognition's Walden Yan & OpenInspect's Cole Murray

Yes.

or, you know, how how it felt from your side. In retrospect, you know, we always thought it was ramping up, but then even now, over the last three, four months from today, we've this has been ramping up even faster. So it's it's almost funny to be talking about how, like, big of a leap Sonnet 3.

7 was and we honestly, a lot of it was stripping out parts of Devon that were no longer needed with that jump in intelligence. But I also just think that a lot of the recent leaps, especially, you you look at models like Opus and late stage GPT models, they are reaching levels of autonomy where people are actually fighting that they actually can't just be hands off. And people who were once debating, Oh, you know, do I need to be in the weeds with my model, in the IDE?

Can I just completely move it off into the cloud? That's more serious conversation and we've seen that in all of our growth charts. Internally, there's this funny graph where our usage has of PRs or our merged PRs has grown seven x since Yes.

I forgot what it I think Dev maybe tweeted that. Yeah. Yes.

It grew like seven x over like the last, I think it was like two months, three months, something like that. And then you see our engineering headcount growth, it's, like, gone up by, like, 10% or something. Like, we were we were afraid to release this.

like a it's a big shift right now. And so it makes sense that a lot of people are now thinking about, you know, buying Devon but also maybe like you're trying to build their own and there's lots of I have a lot of fun building Devon so I can see why other people would want to build their own Cloud Agents as well. And I believe it's good to hear like what what initially inspired you to try to build OpenInspect?

was like, didn't try to go make it then something you you monetize. There are a lot of I think these open source projects would then go I mean, they try to like raise vSphere. That's why I went to OpenDebin.

Yeah. Yeah. And how did you think about that?

I thought that was very interesting.

yeah, there's multiple layers to this practice. And actually, it's funny you mentioned the infrastructure because when we got started building Devon as well, we had to go figure out how to make the infrastructure as well because You had to build this two years before everyone else, you know? Yeah.

Yeah. Exactly. I agree.

And Including, like, the Mortar's side. It was not very polished at the start. Like, when we just built it off of raw VMs from cloud providers like EC2, the boot up time was so slow, I think.

And especially the then, like, turning off the machines, saving them, and then be able to bring them back up again when you want Devon to wake up again later, it would just be out cold for ten minutes because that's just how long these systems took. They were not built for this repeated down and up usage. And so, we actually had to go do all of that.

And as a result now, one thing we offer when we go and sell Devon to people is you don't have to worry about all the compute side of things. We'll make it work. We'll make it work in your cloud if you wanted to.

Aside from the product and I want to go into the agents and tuning of the intelligence part later. But I think a big part of what we do at Cognition as well is to just make sure that your company learns and uses and adopts these coding agents because I think for especially the largest enterprises in the world, you find that there is a lot of people who want to move over to using AI for their day to day workloads. But because of the way projects are planned, because not everyone is literate in using AI in these ways, having a team of engineers who can actually go in and onboard you, set up all the integrations you need, the automations you need to really get to that level of, you know, leverage with AI is super helpful.

And so, we do that, we show up as thought partners to the customers that we work with as well. So, let's talk about architectural stuff.

The other thing that this allows you to do is reuse any existing infrastructure you have for Dev Boxes, And so you don't have to worry as much about making a new type of Dev Box that has all the dependencies the brain needs, as you mentioned, the secrets the brain needs as well. Like, one thing that we've seen some customers run into is like, you have a GitHub app and you want Devin, your agent, whatever, be able to interact with GitHub through this application. But then you have different users with different actual permissions.

If they are all interacting through the same GitHub app and there's no actual separation between the system that decides what it does and the actual secrets on the machine, then you kind of run to an issue where, okay, it's hard to do the separation. But in practice with Devon, it's much easier because we just say whatever you put on the machine, that is like kind of the scope of basically what the user is free to do, what the agent is free to do. So only put the most scoped secrets on that machine.

And then the brain is fully not accessible from the machine. So you don't have to worry about messing with any of the most secure parts of the brain if the user is free to do whatever they want with the machine.

a lot of other players do well is how do you manage what's actually on the box? And this can be complex for many reasons. Like, let's say you have a big repository that's changing and updating a lot with changing dependencies.

How do you make sure that the working environment of the agent actually stays up to date, has all the credentials it needs to, let's say, run the app and test it, all the things you want your autonomous So, it's repo setup. Yeah, exactly. So, internally, at Cognition, we call this repo setup.

The hardest part of it's been a perennial problem since the start of the company of how do we help people get this set up. Because not everyone just has, you know, working cloud environments, working out of the box. And do you find this to be a common problem with how you deal with your clients?

Yeah. This is a very common problem. And through my consulting, this is a lot of what I help teams do.

direction we saw some of our friends take early on was using Docker containers as a level of abstraction for their models. There's lots of reasons, I think, why Docker containers are not great. One thing is Docker containers are not really a true security boundary for one.

But the other is like, if you're running real applications, a lot of times those applications use Docker. And then you have to think about Docker and Docker, which is like really weird. And so, I think part of the really hard challenge of getting VMs to work, why did we do that?

Well, it was because we realized that you actually needed full VMs to be able to do these types of things. And especially nowadays where there's actually value in running the application and clicking around and sending you screen recordings of these things, the value just kind of keeps adding on top of that. But it is a decision I see people run into when they try to build their own systems is, oh, do we, like, addition to this, do we put the agent in the machine or out of the machine?

Do we use Docker? Do we use something else? What do you recommend people nowadays?

Another thing that we've been thinking a lot about is kind of like different VM service offerings. Have you had customers where they needed, like, macOS specific VMs or, like, Windows specific VMs? Not yet.

There are, like, many technologies in the world that only work on specific types of machines. Right? If you're building a dot net application, it has to run on Windows.

Or, like, you know, maybe more commonly if you wanna build iOS or macOS. Yeah. Does commission support choices like that?

The fundamental architecture we do, because we do the separation, it does support. But the actual work in progress is happening right now on these. Another thing that we've actually recently added support now for, it's in beta, is doing Android development.

To do that, we needed to support, I think, nested virtualization within our machines because the VM itself is virtualized Firecracker instance and then you have to then run another Android emulator inside. And, you know, there's like weird performance issues that like, you know which is why it's like still in beta. We have to think through these problems.

Yeah. Idea of problem? Think that when people think about the ability of an AI to run your app and test it, I think they actually over index on the computer use part of it because computer use, in my mind, is the literal, okay, you want you know a button you wanna click.

Can you emit the right coordinates to go click that button? I think testing is actually a really interesting problem solving for these AIs because if you wanted to do arbitrary testing, like imagine you make a change that spans the front end and the back end, maybe even some other, like even more deeply nested service. To actually test that change, we have to reason through how do you first run these applications to all orchestrate with each other over the right version of the code, then, okay, how do I trigger the feature or how do I make the thing actually happen?

And this can kind of get arbitrarily hard. Like, maybe you have to be an admin, maybe a certain thing has to be feature flagged on, maybe you have to like run two sessions and then send us a very specific word into one of them to trigger a specific behavior. And figuring out how do you do that requires a lot of code based context, requires a lot of orchestration that we've specifically done.

And in some cases, found that you actually no one frontier model can actually do this full end to end task itself. We've seen cases where we actually had to orchestrate different frontier models together to kind of solve this problem together. That is where we spend most of our time when we think about this testing problem, not so much the computer use part.

Computer use, for what it's worth, has gotten a lot better with recent models and it's it's made that part of the job certainly easier.

apparently, like, way better in terms of the division stuff, which is gonna be encompassing computer use. Having evals for all these as well is something that like takes a while to build up and having the evals be right is tricky as well.

Annotations at the bottom was also a big difference for me when I added those. Yeah. It's just like, what am I looking at?

What are you trying to Yeah. Exactly. There's a surprising long tail of small details that ends up making a big difference for this kind of end metric of like how fast do you actually merge the code in.

One experience that we spent a lot of time tuning early on was what is the right experience on GitHub for these tools? Sure. Because I think most tools out there, when you build the agent, you'll think about, oh, like, it will create the PR for you.

We try to take that a step further and say, oh, like, what if we actually made sure you could interact Devin with Devin directly on GitHub? And so we made sure that you can comment on GitHub and Devin would actually receive those comments and address them back. But there's actually quite a bit of tuning you have to do here because you can imagine that actually, like, we recently have dev review, for example.

So when Dan fixes its own comments, you might be scared that it'll look maybe I'll infinite loop, but we've put a lot of work into making sure it doesn't, both by making sure that the comments are high signal, but also that the agent is thoughtful about what comments that immediately goes and tries to fix and what comments is like, Wait a second, I think you're wrong. Actually, that's one of my favorite moments is when Devin tells me that I'm wrong when I try to get to do something different. Yeah.

But tuning that behavior, like, actually makes a big difference in terms of how you just will get up experiences.

most common thing that people end up requesting that they still need on top of OpenInspect when you help them go implement it?

thing we've found is so, like, MCPs, obviously, has been a really big explosion of, oh, you can go integrate it with all these different things. But to actually get the integration right and get the right experience, oftentimes, we found out we had to go build our own ad hoc things. Think Slack is a great example of Like, you could give your agent a Slack NCP and, okay, you can post messages back to you on Slack.

But we actually use Devin like a coworker in Slack and that's how it's been built from the ground up. But to do that, you actually need to support webhooks that come back, right? And then Devin has to respond in a natural way and then hopefully don't spam your threads too much and annoy the people in your company, so you gotta tune that experience just right.

Especially, there's a lot of back and forth.

you could have something that's more expressive than MCP. That kind of like goes both ways, like not just a set of tools but like a proper system that interacts back and lets it have the right experience with all these interfaces. So, there actually is sampling in the MCP spec but nobody Right?

Uses so, I think that's the other part is like actually we found that when the SAP spec starts to get too complicated, it starts to lose its original promise of being like a simple one step connect. Now then we have to go figure out how to support all these different variations of things and it starts to look a lot like just building their first party integrations in a lot of use cases now.

that can be addressed. But I think as a whole, it's a very difficult retrieval problem. Oh my god.

Yeah. Ramp didn't write anything about memory? I see zero search results.

Memory can be quite tricky to get right. Because it's the retrieval, but also the generation of the memory is that can be really tricky. Like, you don't want it to just Yeah.

Like, okay, whatever very specific data.

The first version of memory that kind of like stuck around for a while was a system we have called Knowledge. Yeah. And the idea was we wanted it to pick up things over time and not need the user to be proactive about teaching Devin things.

So, anytime you remind Devin, wait, no, that's not quite the way you're supposed to use Git. Like, we actually want Devin to say, hey, do you want me to actually just remember this for the future and for you to just basically quickly approve or reject and for it to build up over time? Because I find that, like, 95%, I think, some crazy style like that of the memories that Devon has are all through these auto generated things.

Like, very few people actually just want to sit down and write big docs on, okay, here's how you're supposed to work with the technology, etcetera. The generation in the retrieval has been something that we've been trying to tune a lot over the years. Generation.

Like, you don't want it to remember something like like if you asked one time to like, oh, please open it as a draft PR. You don't want be like, oh, everyone forever now should get their PRs as draft PRs. But you do want some kind of common beer maybe you want to say.

Like, oh, Cole generally likes things to be created as draft PRs. Same with retrieval. Like, you know, if you have thousands of these memories, how do you actually make sure they're retrieved at the right time?

And that can be quite tricky to do right without exploding the context of a bunch of useless information.

Exactly. Yeah. Today, the so the things they could do is it could edit memories.

I see. And so if your memory used to say like, oh, Cole likes to open everything as like a draft PR, then you can imagine, no, don't do that. Then it'll say, oh, do you want me to update the memory to be COL now?

I want everything as, you know, open PRs. I think that at the same time, we don't know if this is gonna be the final version of the system. Whatever we have here will probably translate into the new system that we'll be coming up with.

But I think one big difference between two years ago and today is these agents are really good at using anything that resembles a file system natively. And so part of us is thinking, oh, should we rebuild memories to feel more like a file system that we let the agent navigate on its own? That's been an interesting exploration.

One thing we've been trying to do to push the boundaries of how you use agents at your company is letting an agent basically have a very similar file, like a memory. Md or something, and just kind of like be your permanent PM for a specific set of issues maybe. So, have like some Slack channels internally, maybe a Slack channel dedicated to a specific product like DeepWiki maybe.

And you can imagine that you want a Devon that never stops, it's just always awake, but it has this memory doc that it can just maintain for itself about, okay, what are the number one priorities of what we have to fix and prioritize? Who is responsible for some upcoming work? Maybe they'll even tag Devon will even tag you on some recurring basis.

Yeah. And so, it's been an interesting move to see, okay, how can we actually use Devon for more than just engineering? Can we actually upstream, above the engineering process?

And maybe it's just Devon creating tickets, which then maybe some humans do, but then maybe other Devons do. Yeah. One of my more fun automations is go research competitors and just suggest stuff to me on a weekly basis.

You know, we might change it soon. I I guess OpenInspect, in the time you've been around, has there been anything you tried to implement, which then you had to like undo and like do a different way?

I think one of the surprising things we've seen is that a lot of the ways that these separate agents work with each other and you want them to paralyze their work has still mostly followed the same manager sub agents regime. And a lot of people, I think, are excited about this world where you have swarms of agents that kind of, you know, talk with each other all over the place. We've actually given Devon an MCP so they can just go arbitrarily message other Devons and create new Devons, etcetera.

But I guess it somehow creates a really chaotic world in that sense. And so we've still found that most practical use on a day to day basis has been one single event. Yeah.

Figuring out how to segregate the work and get have other devons work on it in, like, a relatively isolated sense, each with their own boxes Yeah. Not sharing machines. So there's, like, a very little room for conflict is kind of the regime that you have to create today.

which is exactly what Devon has, I think. I think there will be a revision to that post at some point. Okay.

Tell us about it. Think multi agents were very much not at all possible a year ago. You do see more multi agent experiments today, but you can kind of argue, are they really multi agents or are they just kind of just like tool calls?

You know, like there are people who will create sub agents to go look for XYZ file or XYZ implementation. Has really nice context management benefits because all of the tool calls and tokens that it spends then get collapsed back to just the answer for the main agent. There's lot of benefits to doing this.

We basically have Devin do this with DeepWookie, make a call out to DeepWookie, give you back the results. But that feels like a tool call. You know?

It's not like these two collaborators actually talking back and forth with each other. But I think the thing that gives me the most bullishness that multi agents might actually be possible is actually what I said earlier about Devin will actually sometimes tell me I'm wrong and push back. And I think that demonstrates a level of maturity in communication today that makes a multi agent world possible.

Like, when can two agents who have seen different information come back to each other and actually figure out who is right, what what is the correct implementation? They're not just, you know, yes men. Claude, I guess, is like used to just say, like, you know, what is it?

You're you're right or You're absolutely right. You're absolutely right. Yeah.

Yeah.

fed a swarm of agents together and built a browser.

We found a surprising success of like, don't do a swarm or anything. Just have one dev in, you know, it does its own context management. Just let it keep running for a while and give it some crazy tasks.

I think we asked it to rebuild a Windows OS system. Yes. And it managed to do it, just like, you know, going on for long enough.

Was this Andrew's thing? Yeah, yeah. Okay.

There were lots of demos that we ended up not posting because at some point we'd just be posting way too much a bunch of end of demos. But I love that because it kind of shows that I think the multi agent thing it still has like a bit of exciting sexiness to it, which is maybe still beyond still like the actual delta it adds to the capabilities of these systems. But it's absolutely the future.

I think we're, you know, we're heading that direction and we can see the progress being made there already. Yeah.

Yeah. We've also run experiments internally where we've basically tried to build entire products, like true products that we knew we would eventually ship, but for now let's try to see if we can do it just by purely vibe coding on top of each other, auto merge, no code review at all. And then there's this kind of benchmark of how many weeks can you go onto this for before you say we have to trash this codebase.

Actually, reread it from Star Trek. Yeah. Did you find?

I think we found that the state of the art in December was you could probably run this for about two weeks. By the end of those two weeks, you'd find that, hey, you want to change the color of a button? Well, it turns out this button is implemented in 10 different places and they have all these different variations and, oh, you forgot one of them and actually it's a slightly different color, one spline.

Okay, this is too much to work with. Let's actually try to do code review at the same time and make sure that we're on top of our stuff, we're actually cleaning it up a bit and making sure it's done in a scalable way. Yeah.

And the the meme that I have for What timeline? Alright. Is is do you think that statement will be true on?

Well, guess, generally on the topic of like where humans can be useful, I found that some of these like really deep infra problems, sometimes just having a heroine that just has really deep expertise can make a big difference. I've actually seen this come into play when actually building agents. So, we've had a few friends now try building their own coding agents and I think one same problem that I recurrently heard a lot of them run into was this problem of like, Oh, GREP is really slow on our agents' machines.

And so, a lot of them, I assume because they're using AI and they themselves don't have super deep infra background knowledge, say, okay, we're gonna go build our own custom Grep Index, it's gonna be really fast, and use that as a way around this problem. When we ran into this problem about, like, know, maybe a year and a half ago when we were in the early days of building Devon, We obviously didn't have AI, we just asked how to do this. You could just slap off a new grep index.

What do you mean you hand coded Devin? What? Yeah.

Can you believe we hand wrote this code? And we had our info people who are really amazing, they were looking into it and they're like, Oh, you know what? We realized that actually the root cause of this problem is actually super simple but fine grained detail, which is that a lot of these virtual machines, actually underlying them don't use real file systems, they use these network file systems where things are actually cached over the network actually in S3.

So, when you're grepping, you're actually making network calls every time you're doing these things. That's why grep is extremely slow on these machines. And so, again, it goes back to, you know, what is all of the crazy info work that we had to do to actually get these machines working.

If you try to do this yourself, you know, there are tons of small details like this. And so we had to eventually go swap out that network file system. Yeah, I think there's a write up about it, right?

So I listed one about the virtual Oh, that was a whole other thing. That's a different thing. The block diff file storage format.

Yeah, yeah, I'll bring it Which is a file system format that we built so that the VMs could be spun up and down very quickly. Basically, the intuition behind this is imagine you have a terabyte of disk and your agent only wrote 100 lines of code on top of that disk. How long does it take to save and bring up that disk?

And most systems, because you're not optimizing for this case, it's just on the order of a terabyte of work because you have to save all of that and bring it back up. In our system, we try to build a file system that incrementally builds on top of each other. So, every time you save and bring the machine back up, you're only doing work that is proportional to effectively the diff in the file system.

Yeah. And so, this shaves off a lot of time in the boot up process of Devon. I think this is actually now outdated.

We have a newer system inside of Devon. But, yeah, there's a lot of tiny details you have to get right here to actually get the day to day experience of Devon to be good. It's like not technically agents, but it is agent infra.

And when you sell an agent as a company, you sell agent plus agent infra. Yeah. At least the way we do it and the other the nice thing about having the agent infra being done together is, you know, you we kind of get to deploy Devon in whatever environment we want now.

We don't need to wait for some underlying infra provider to also go and support VPC or on prem or Fed GovCloud, for instance. So we can actually go and out, okay, since we're on the infrastructure, how can we get that set up for you?

Well, what are like how are the customers you work with, do they generally try to then go set up a contract with another one of these third party providers? Do they try to do the VMs in house?

Modal is great. Especially, I think the the container offering is like the most natural. And so especially if you are willing to, you know, forgo like the full VM requirements, modal is like a really vast place you can kind of spin something up on.

Yeah. Is there a point so models vary Python.

I don't know if Yeah. I don't know. You have numbers?

I don't know. The the one thing I don't like about Python is whenever an AI, whenever it's Python, it always does like, the weirdest patterns. Oh, because it's, like, mixing two and three or what?

Yeah. Think it's it's something mixing two and three. Yeah.

Like, the I don't know if you see this. It always tries to do, like, has attribute on objects. It's like Yeah.

Oh, my god. But it's like Sure.

coding that you have to put guards in? So we were talking just before this about OPUS 4.7.

One of the things this new model likes to do is it writes lots of comments. Not like it'll comment on every line, but it'll write paragraph PRDs on top of every function.

to its credit, these aren't slop descriptions like they were before. Like, Oh, here's what this function does. It's like, Oh, here's actually the reasoning and why we chose this approach and what the alternatives were and why we shouldn't do those alternatives.

Still too much information. But I wonder if this actually might be directionally correct if you want systems that can self maintain themselves in the long run. Like write the specs in All the context in the code as well, yeah.

So you approve? I but at the same time, it's this tricky problem. Like, maybe we'll just give our users a setting or something for how verbose you want it to be.

I haven't loved it. I like the comment, please, like, get rid of it. You know?

Yeah. Yeah. Yeah.

But I I could see a world where maybe something of the sort becomes reality. Don't know if you guys know about Git AI. Yes.

Yeah. We've talked about it. Yeah.

Git AI, the idea behind it if you run an agent, the actual prompts you send to the agent should be stored alongside the code inside the Git metadata so that future agents can reference it, maybe code review bots can reference it. And it's kind of an ideal world where, you know, your context for why decisions are made constantly lives beside your code. And so it's like maybe a more hidden version of this, like, right massive PRDs for every comment sort of approach.

Yeah.

still use it. The one thing that I think we try to recommend teams as they use more AI agents, it goes back to this local testing thing. In the end of the day, you want your agent to be able do the full thing, not just write the code but actually run it and test it.

And a lot of code bases were not necessarily built for this from the start. For example, you probably do want a local DB setup and local Docker Compose and Postgres in order to have it so that you don't need to give your agent any crazy prod credentials to actually run and test its code. We've also internally done a big shift to make a lot of our core components of code testable as purely local dev without needing to actually integrate with any live services for this reason.

And honestly, the older the company, the more you have to change to shift in this direction.

making that shift the larger the code base, the harder it is. I guess if you did build it correctly from the very start, I think it'd be possible. But also, there are a lot of companies in the world that got started before Docker was the thing.

And so Yeah, yeah, yeah. You're kind of forced to make a migration at some point. Well, Devin's good very good at making mock servers.

Alright. So so if I say, RT was not that Yeah. Interested in Yeah.

Yeah. The leak. We didn't spend that much time on it.

gap this is trying to close is, again, how do you make the testing process as fast as possible? When it can test on its own and send you a video, it's freaking magical. Sometimes there are just really difficult things you can that you do just need to like pull down locally to test.

And, you know, we just want Windsurf to just kind of be your like local command center of all your agents. Like, your your background ones, your local ones, and you can imagine, oh, okay, this agent needs me to review something, I'll pull that down, move my other agents to the background, go test it. Okay.

Boom. Done. Onto the next one.

Right? You have some issue you gotta fix in the background, just click, like, approve. Okay.

Set up start a background agent to go fix it. I'd love a world where I'd have to leave this window. You know, then maybe the other window I gotta figure out how to stop spending so much time in Slack, but maybe, you know, someday I'll wanna get those too as well.

Yeah.

So, the funny thing here is that the behavior between local agents and cloud agents, I think, is actually a bit different in their I ideal think local agents, you want them to be a bit more fast and let the user make the call on things, actually don't try to autonomously go test things. The background agent mode where you go start it off, I think the agent should just assume the next message I send the user should just have everything that the user needs from me And not run and stop keep running and don't stop until you have the testing. Okay.

So that's just a slightly different prompt. Yes. But for many reasons, because of all the work we do to make sure that Devon works with different Git providers, that it works with different OSs and VMs, we want as much of that logic to be shared as possible.

So for our own practical purposes, we try to share as much of it as possible. Yeah. Yeah.

I mean, I can't imagine how much work it is to transition back and forth. Congrats on shipping this.

Maybe use cases. What do you find to be the biggest things that your clients are trying to do with their cloud agents today?

Yeah. Yeah. Was drinking his water.

Yeah. Yeah. The thing I wanted to talk about was use cases.

What do you think are the main things that your clients come to you today about, hey, this is why we want to go set up Cloud Agents?

The only things I'd add on top of that, I think I've seen is continual security scanning, continual security review is a very big one as well. The SRE use case, internally we think about it as auto triage because we just want every message that comes in and that's an alert, that's a bug report, to have Devon just start triaging it before anything else. And we've leaned into this use case so much though that we've basically tried to make it so that you don't ever have to leave Slack to interact with this.

So again, making the interactions with Devin super fluid from the moment the report comes in to it responds to a report and be able to ask questions right there with full care based context about all the issues. Very related to customer support as well. I think one thing that we found is CLIs can sometimes be very difficult for people who aren't technical to go and use.

But, you know, an online chat interface that anyone can go and ask questions and is super intuitive and doesn't assume you have any technical knowledge but does have access to all parts of your codebase. Super useful for support, for salespeople, anyone who might need to have their questions answered about the codebase. So that's a great call out.

go that high for sure. Yeah, yeah, yeah. I think that this is also, I think, going to be a big theme of the coming year is we're going to see very expensive, very smart Frontier models.

And we're also going to see people who say, you know what? I don't need the Frontier anymore for a lot of the work I do. Because some Frontier models actually are good enough for a lot of the work.

Also, Shada, you'll pioneer SmartFriend, which is a mix. I'm really interested in a world where you basically have hybrid frontier and sub frontier systems where you use sub frontier parts to be really, really fast, really efficient, and call out to the frontier part of the system so that you can still get frontier performance for the most part.

Lots to look forward to. Yeah. There's a real zeitgeist in the space right now, I think, for companies to want to turn themselves into these autonomous coding factories.

And, yeah, we're doing a lot to try to support that. And so, know, any listeners are welcome to to come chat to us about that, whether using Devon or, you know, working with us. Yeah.

Hiring? Yes. Of course.

I think people underestimate the the role of like really high taste product engineers