Why Anthropic Thinks AI Should Have Its Own Computer — Felix Rieseberg of Claude Cowork & Claude Code Desktop

Our first one in the new studio at Kernal. This is Alessio, founder of Kernel Labs, and I'm joined by Swiggs, editor of Laid in Space. Yeah.

So nice to be here. Thanks to TJ, Alessio, Alan helping to set everything up. It looks beautiful.

We even have the logo outside. Yeah. It's like really nice.

I think when you walk in here as a guest, you're like, oh, this is a serious production. You're feel it immediately.

And I I we have like, Cloud coworkers, it might be AGI. I don't know if we we have uploaded it yet, but one of the sessions was like a like a Cloud Cowork thing. I would love to see it.

Like, I'm so curious, like, one of the most fun parts of my job is that I constantly see the weird things people use Cowork for, because it's obviously like very hard for us to actually design for specific use cases. We do. But every single person who's most amazed is usually amazed about a thing that I didn't even expect Cowork would be good at.

We have a new designer, and it's one of her first small tasks. I was like, hey, need a new emoji for Cowork, for our internal stack. It's a pretty small thing.

Was like, can you please do it? And he drew an SVG and just gave it to co worker, was like, can you animate this emoji? And now it has like this beautiful loopy animation.

And, I mean, I think obviously this goes down to like, it turns out you can do more things with code than you expected.

Real quick, Cloud Code Work is a user friendly version of Cloud Code. So the way it basically works is, we have Cloud Code, and for us, fairly impressive agent harness that over December, we noticed more and more people are using either even though they're not technical, they they're not at home in the terminal, or they are at home in the terminal, but they started using Cloud Code for non coding workloads. Right?

Like managing expenses, or like filling out receipts, or organizing a knowledge base. Like, there was a big obsidian moment that a lot of people liked. And we wanted to capitalize on that, but also bring bring this capability to people who are not terminal native, and who might not know how to, like, brew and install something.

So Cowork is Cloud Code running in a virtual machine with a little bit of padding, a little bit more guardrails, making it a little safer and a little bit more convenient for people who don't wanna first open up the terminal when they go to work.

Yeah. Like, think a similar thing happened a similar thing happened to me about ten years ago, like maybe twelve years ago when I was at Microsoft, and we started working on on Electron and like browser based technologies and cross platform stuff. And one of the first use cases was Visual Studio Code, which used to be a website.

And the initial narrative was, well, Visual Studio Code is is like a more user friendly version of Visual Studio. But in a similar vein, I think there were some voices saying, oh, this is not for serious developers. Like, we're not gonna use this, right, for like anything.

And I think in the end what happened is people have different stories about why Visual Studio Code became such a big thing. But my personal my personal belief is that the hackability and the extendability has like played a pretty big role. Right?

You can hook in Visual Studio Code to like almost any workload. It's so easy to hack on, so easy to build extensions for it. And I think Cowork might be hitting a similar thing where it's very easy to extend, and it's very easy to bring into your workflows.

So the convenience, I think, is a bit of a it's obviously the thing we strive for as developers.

at Anthropic, we've been thinking about ways to move people who are comfortable with using Claw to answer questions, and bring more of the power of, like, this thing to now, like, execute tasks for you. Right? Can, like, solve problems for you?

Can, like, build things for you? How do we bring that capability to people who are currently mostly comfortable with, like, a like, question answer paradigm within the chat? And we've had a lot of prototypes around that.

This going back as far as, like, easily a year and a half. Like, we had a lot of people working on that. And internally, Anthropic is a very prototype demo first culture.

We have a lot of like internal prototypes that don't reach the public. And what Cowork actually became is like we sort of picked the right pieces out of the many prototypes that we had. Right?

And that's that's maybe also like, I think an important qualifier whenever people mention this like ten day number. I do think it's important to me to mention that we didn't start with scratch. There was like a lot of stuff already happening.

Right? Like and I think it's important for people to remember that when you build a website, use React, you use like a bunch of other things. And this is like a similar scenario with like a lot of pieces we already had.

In in terms of decision path, I think we live in like an interesting new world where execution is actually quite cheap. Mhmm. So maybe maybe what you would do that's so crazy to hear.

I know it's wild. You should be ideas are cheap. Execution is the hard part.

No. Unlike the we we used to live in this world maybe where you would take a product manager, and the product manager would go to a number of potential customers, and then this like very low bandwidth way would try to try to like tease out what are the problems they're having, what are they willing to buy, and then maybe what can you build to drive out their need. And then you go back and you draft a spec, you think about it, and then you make a design and you execute it.

We internally at Anthropic Up, now probably much closer to the point where we're like, don't even write a memo. Just like build like, let's build all the candidates very quickly. Like, let's let's just build all of them Mhmm.

And then pick the best ones. I think the the decision that is most impactful, both for the product as well for the users right now, is like the way we put value on your local computer. I think that's a big decision point.

A lot of people have thought about, should this thing, whatever it is, should it ultimately run-in your computer, or should it run-in the cloud?

You know, I think I think you're right. I think you're right that the holistic platform is really useful. And this is maybe a whole, like, a somewhat contrarian view to a lot of people in AI.

I actually don't think that the future is going to be hyper personalized software down to the point where everyone is running their own version. Like, actually think it's going to be quite hard for Autopus to have our own internal chat tool. And like, if I wanna talk to you, like, how is that gonna work?

Right? In the in the context of co work and how we build it, I think it's a bit of a combination. Like, what the the execution that gets cheap is not necessarily rebuilding all the primitives.

I think a priori, there's also not a lot of value in it. So for instance, my team did not think about rebuilding Cloud Code. We're like very much started with the with the core thesis of this should be Cloud Code.

Mhmm. And then we'll like build things on top of it. The part of the execution that gets a little cheaper is, like, how do you take all of these Lego pieces and put them together in a way that makes sense for users?

It's, like, actually valuable. You have so many different approaches now in terms of what kind of what kind of things do you actually elevate to a primitive? Do you strongly believe that all your products should be built by just combining primitives that the public also has available?

Do you keep some things in total? And I think that's still evolving, but I think what's probably gonna go away is like I'm not sure if it's gonna fully go away, but I'm gonna say I think for me personally, I will probably no longer try to come up with a really good product without testing out with people. This is not a new concept.

But wherever you used to have to make costly decisions around do we pick technology a or technology b, or do we like build it this way, build it the other way, I have really strong ideas now. You just build all of them and try them out with like a small focus group, and then whatever whatever is better is what you go with. Right?

And that that is probably quite different even from how we maybe worked a year ago. Right? Like, think I think this happened very recently.

Yeah.

that people should be aware goes into co Like, okay, I think you basically have them. Really? You can take planning more or less out.

I think there's a few things that are really valuable in CoWork. The virtual machine is probably the most powerful thing. So we currently run like a we currently run like a lightweight VM, and we put ClockTalk into the VM.

And we do that for for a number of reasons. Safety and security is a big one. But even if you even if you ignore for a second safety and security, and you're just like, okay, YOLO, I want this thing to do whatever, it is quite powerful to give cloud a subcomputer.

That is like generally a good idea. And in terms of architecture and UX and everything else that we've been working on Anthropic, it often is quite useful for you to like anthropomorphize cloud aggressively and just be like, this is a person. Yeah.

What would you do if you had a person? Right? Yeah.

And the analogy I've given my dad this morning, who is still, like, quite insistent on using chat even for, like, coding things is, if you were a developer and your employer told you that you don't need a computer, they're just gonna, like, send you emails with a code and you send emails with code back. Like, that maybe work for patch files in the back, but that is not very effective. So what we can do with the VM is because it's a it's a Linux system, Cloud Code has more or less free rein to install whatever it needs to install.

It can install Python. It can install Node. Js.

We do have strict network ingress and egress controls, so you can still, as as a user in like plain human language, make it clear to to the entire system what you're okay with and what you're not okay with. But at no point do we have to ask a real person, like a like a person who might be in marketing or a lawyer. I'd have to go to a lawyer and be like, are you okay with me installing Homebrew?

Yeah. Yeah. Right?

Because the implications of the question and the answer are complex and nuanced and, like, not not easy to reason about. And this gives us a lot of abstraction that makes Cloud very powerful. Now then around it, we we do probably have a number of things that also keeps growing almost every single week that you're probably noticing that make cobot maybe better for certain tasks than just cloud cloud on its own.

Yeah. But most of those actually live in the system prompt. They're about like, what can we infer about the work that you do?

What can we what can we introduce into the system prompt to make that more effective? It's of course the like very tight integration with cloud and Chrome. You're noticing that a lot of people, especially as the models get better, a lot of people throw up their hands when it comes to MCP connectors in this area.

I'm not gonna I'm not gonna go through like 25 MCP connectors, click auth everywhere, and then like half of them don't let me do the things anyway.

Within the first week of developing on CodeWork, this happened very, very quickly. I caught myself, like, starting to use CodeWork for coding tasks, which is not ostensibly what we built it for. Right?

We don't need to. But I found myself I found myself, like, on our internal internal tool that we have for to collect crashes, and just, like, debugging information. And I found myself sort like picking out the ones that I think we can easily fix versus the ones that might be like kernel corruption or something else on the operating system.

And I found myself sort of picking these out and then just telling Claude, go fix this bug. I was like, what am I doing here? Go one level up.

Tell a co worker, I want you to go to all these crash tools. I want you to find all the bugs that you think are fixable and not like an operating system crash. And then I want you to tell another cloud to like fix all of that.

Currently what I do is, and this is a bit of a hack, but I tell her to use Clockwork Remote to Which is just it myself. Yeah. That's interesting.

So you basically take if you if you imagine like a dashboard with like $20. You this is remote control or remote? Sorry.

I just wanted to confirm what the way I'm using it is I have co work running, and I'm telling co work, here's where I normally go every morning to find the latest bugs. Go read the entire bug list, separate out which ones are fixable, which ones are not fixable. And then for the fixable ones, for is this almost loop, for each bug, write a markdown file with a prompt.

And then for each markdown file that is a prompt, start off a clause set. So natively Cloud Code has this concept of sub agents, and this is basically a sub agent, but you're not using the sub agent's functionality. I'm not using the sub agent's functionality, and the reason I'm not is because I'm firing that off as a Cloud Code remote task.

Yes.

So I generally believe that Silicon Valley overall is undervaluing the local computer, and my default argument for that is always, how come we're all using MacBooks and not like an iPad or a Chromebook? There's, like, still value in in having a local machine. And now when I think about Clock as this entity that is supposed to be very useful to you, like tremendously useful to you, I think that entity needs to have access to all the same tools you have access to.

Otherwise, it's gonna be hamstrung in, like, all these complex ways. And there's there's sort of two approaches we could take. We could say, okay.

We're gonna, like, one by one chip away at everything that is at your computer and move it into the cloud. That's that's one way to do it. And I think other products have taken their path.

I personally this is very personal opinion, but I personally, for the amount of tools that I use, just don't have the patience to give another tool like permissions to every single thing and keep those permissions up to date. The second thing that I'm still grappling with, and I don't have a good answer for anyone just yet, but the second thing I'm still grappling with is, what does it look like for someone to slurp up your entire work and put that in the cloud? Like, if I just as an example, like, you would click a button and it just clone your entire computer into the cloud, is that something that you would want?

I'm not totally convinced here that all everyone will. Mhmm. And that is sort of like upstream of all the technical issues we're gonna have.

Because, like, in general, I think the world is not ready for this kind of stuff. Like, I'll give you one quick example that would probably be very easy for us. So as a desktop app, we, in theory, with your permission, can do a lot of things on your computer, including reading your Chrome cookies if we really want to do.

Right? We could take your Chrome cookies, you would have to decrypt them for us, but we could put those on the cloud if we really felt like it. Pretty easy solution that would be super cool.

We could just be like, oh, we can do all your tasks in the cloud now. A lot of websites, banks included, if if they see the same authentication from, like, two different locations, will just lock down your account. And now you have to go to the branch and be like, okay.

I'm with I'm here with my passport. You actually know that. Wow.

You know, as tired as well are of the term agent for the agentic future, I think there's a lot of stuff that sort of slowly needs to catch up.

on on the that's only exclusive to Cloud Code Work. We have some tricks for this sort of like change week over week. We eval code work maybe against different use cases than you would evil a clock code.

Right? If you think about it this way. Okay.

So like, Cloud Code is I'd email Cloud Code Work. Yeah. So Cloud Code is like quite optimized for coding tasks, and we mostly evaluate whether or we're getting better or worse, depending on how good it is at like a typical SWE job.

And Cloud Code Work, on the other hand, we evaluate more against typical knowledge work, the kind of stuff you would find in finance or in like maybe like in like a legal office. My personal use case is always like managing my things like managing my personal mortgage or something like that. Right?

Or like wealth planning for me and my family. Those are the kinds of use cases we eval, clock, co work on. And what you might be picking up on is like the subtle changes we make to the system prompt, what we put in the system prompt, how we steer Cloud with the tools we give it.

So like either it'd be better in one or the other direction, where there's a trade off, trade offs exist a lot, Cloud Code will be better for code, and Cloud Code Work will be better for non coding tasks. Will those gaps still exist in the next few generations of models? It's like a little unclear to me though.

Yeah. Because right now these like hyper optimizations we make, I'm not sure for how long this is gonna be relevant.

Like if the Cloud Code people who build the planning functionalities with Citi, they would probably say, yes, we have all of those things in Clock code, and they do. I think people tend to give co work tasks that are maybe of longer time horizon. I thought it's so long.

Yeah. Is that like one thing? Right?

You're just like that the the chunk of work tends to be maybe a little bigger. And then the second thing is that because the work, when it gets longer, it gets a little bit more ambiguous, we do tell co work to make heavy use of the planning tool or to make heavy use of the ask user question tool. Right?

We do want it to come up with like different scenarios of, okay, tease out what the user actually wants. Don't go off to work for like four hours and then come back with the wrong thing. And you're probably picking up on that.

Yeah. I wish I could tell you I like built this magical thing, and it's like there's some secret sauce on Oh, no no no. I mean, it's it's just clarity is good.

You know, engineers just wanna know, so they can they can plan around it.

what we really mean is that we essentially take the entire transcript, including all the tools that Cloud has available ultimately to it, and we then measure what are the outputs depending on what we tweak. Right? So we do run that a lot.

We use that in training. We use that in in, like if you sort of separate out post training from, like, the scaffolding around it, co work sort of exists in the scaffolding space, but obviously we also train on it a little bit. So when we say eval, we mean given the certain transcript, what do the outputs look like?

Including the file outputs as well as the the actual token outputs, like the ones that you see in the chat window.

Yeah. That kinda runs you through the plan. Like, how have you seen that evolve?

The thing that I grapple with a lot is that whatever scaffolding you come up with, I think we still have a bit of sort of like model overhang where the model is dramatically more capable than where users end up using it for. And I think part of that is that we're just not getting the model all the tools to do all the things that's theory capable of. Right?

That's like one thing. However, whenever you do build the scaffolding, I'm sort of wondering at what point at what point will that scaffolding go away, and, like, how much you invest in figuring out what the right scaffolding is. It's kind of up to it's a little bit of a bet.

Right? And one thing that I as an engineer quite enjoy is that like, working in the tropic and working in a frontier lab, I'd maybe have a little bit more insight into what's coming coming down the chute in terms of like what's the next model, what is the model capable of, is good at, what is it bad at. And I'm I'm increasingly wondering, is the right thing for us to like really invest too much in sort of these like scaffolding corrections where the model might otherwise not misbehave, but just not do the thing that you want?

Yeah. Or is it to just like give it as many capabilities as possible, try to make those safe so that the worst case scenario is like, no, it's better than it might be otherwise, and then just simply wait a second for the next model drop? I'm personally currently more leaning into the latter.

I think we're gonna see a lot of, like, applications and companies that do very impressive things with AI that in the short term might seem very effective because they're very specialized to individual use cases. But I think once models get better at generalization and get better at, like, those specific use cases without being super guided on those, I'm not sure how long that's gonna stick around. And you can sort of kind of already see this in, Skills and MCP servers.

Right? We've we've already seen sort of things, like, slow shift from MCP servers to Skills. And like maybe a good example is Barry who made Skills.

He was initially hacking on something that honestly looked a lot looked looked a lot like what Cowork does today. He was sort of thinking about what if Cowork, but for like people who don't wanna build code. And he too did that as a prototype inside the desktop app.

One of the first use cases we thought of were, okay, what what are like coding like use cases that could really benefit from graphical interfaces, and like from being a little separated from the actual underlying code. And everyone comes up with the same answer as data analysis. Right.

Whereas, like, how many users do we have today? How many like, it's always data analysis. And I think the thing that ultimately led to skills is that we wanted to connect this little prototype to our data warehouse.

And the team very quickly discovered that, like, instead of building a custom tool for the thing to talk to our data warehouse, they just, like, made a markdown file, like dear Claude, if you wanna get data, here's the endpoint, here's what the API looks like, you figure it out. And then they Like, hand over control. Yeah.

Yeah. Also just like, maybe go one step up in the layer of abstractions. Right?

Just like, of instead of telling the thing, here's the CLI, please call this CLI. Or here's an MCP, please call this interface shape. Just like, this is the endpoint.

If you wanna know something, if you post here, maybe you can do post SQL. It's gonna be okay. Mhmm.

And that ended up being so effective that they started trying the same pattern of like just giving the model a markdown file that describes whatever it needs to do, that the whole thing eventually became Skills. And we're like, we should package this up. This is a very good idea.

Yeah. We've had Barry and Mahesh on on our conference, and he's definitely got a good idea there. Yeah.

I wanted to show you how I've been using Cloud Cowork. This is like it was my favorite part.

You should really, of course, you should try them. I I think this is like so wonderful and fun for me to see, because I think one thing that is very fun for me about skills in particular is that they're so easy to make. Like, anyone can make a skill.

Like, text message could be a skill, and they can be so hyper personalized to you. And this is like sort of the subtraction layer. Right?

it clicks, you keep adding onto this like automation empire, just like make your life easier and easier. My favorite skill has been every single morning, coworker starts looking at my calendar and make sure that there's no conflicts. Because people tend to schedule a lot of meetings, sometimes last minute, or sometimes miss it.

It's often painful. Mhmm. And a lot of products have existed like that a lot.

I've written in the custom prompt there. I haven't made it a skill. Honestly, I should.

Yeah. But I've given them, like, pretty clear instructions about, okay, here are some people. If they book over other meetings, I'm probably gonna go to their meeting.

Like, if Dario schedules a meeting. Right. Not try to reschedule down.

Right? And I think there's some other rules in there about, like, what kind of meetings I care more about, what kind of meetings I care less about, what is okay to, like, maybe pun, like, when I want to be when I want to be working, when I don't want to be working. And it's those really small things that I can think kinda click with people.

Right when we launched Cowork, I think one of the user phrases that went most viral on Twitter, x, was clean up your desktop, which is of course silly. That's such a swear thing. Right?

Like, you don't need a model to clean up your desktop. Not really.

We'll do it. I did I did it with my downloads folder. It was like, you have so many term sheets and there's like eight copies of your rental lease for your office.

I was like, alright. Like, don't yell at me. Like, it's such a small task.

And I like, I I would never go out there normally otherwise and tell people, I've built a product. I can organize your photos Because for it feels small.

Beautiful. Right? Is it obvious junk?

You probably shouldn't click that. No. If it's not direct.

than Cloud Code because I'm like We do yeah. That's we do system prompt, we're like, alright, we want you to think about like this task. Yeah.

A method yeah. And then I can I can I can do like little suggestions for for for these things? It's beautiful.

Look at this. I I can I can like say like, oh, don't do that, don't do this? It's amazing.

I'm so happy you like it. I mean, the other way around, like, we're part of the Cloud Code team, if you would like this in Cloud Code.

I I do People have done that. Obviously, you can't do that natively, but people have done that with like various other providers. Yeah.

And then this is like signing up for the Figma MCP.

That's pretty cool. Like, at some point, I would love to, like, hear how you feel about code in the desktop app, which is like I never use which is the the same team same team. So I use the cloud coding terminal, which I I perceive to be the default way of cloud coding.

So one thing this has sorry, I'm just like, I'm not here. Not here. I'm I'm sure if people out there wanna like hear me advertise my stuff for like an hour.

Please do that. This thing has, a built in browser, which is a thing a lot of products have seen. Yeah.

It's a built in browser, and I think giving cloud eyes into, like, what you're actually working on makes it so much more effective. And that's probably what you've seen in cobot, because it can see Chrome. It can, like, debug the DOM.

It can, see things. That does make it more powerful.

or the app version of Cloud Code does have a built in browser. I've seen I've seen this preview thing. Yeah.

I just I've never used it. But in the end in the end, sort of get like Hard. Yeah.

You basically get the same thing. Right? Like, the the the additional skill that you're describing is, cloud is better if we can see what it's working on.

Right? That's that's sort of like the summary here. And like This is it's really using your Chrome Yeah.

Or it's just like making up its own little, browser, it doesn't really make a bit difference, because either way it's gonna see what it's working on, and that just makes it much And then Yeah. You don't have to run QA for your Cloud. Why doesn't it pick up my existing Cloud Code sessions?

Because I I mean, obviously, I've used Cloud Code, but Excellent question. Don't have a good answer other than like, we're honest. Just haven't.

Yeah. Yeah.

and Anthropic didn't have to build an agentic browser because you just had Cloud Cowork and that's enough. Yeah. I I also think, like, maybe integrating with number of excellent browsers out there is, like, currently on my personal priority list a little higher than, trying to rebuild a browser from scratch.

Yeah.

or Alice, whatever. Yeah. We wanna we wanna meet you wherever you are, which is like like, obviously I would say that, but it's also just generally true because I don't wanna restrict my potential user base artificially by saying, okay, like I'm gonna start building for the people who are willing to switch browsers.

Right. That's such a like, you know, like many lawsuits have been filed over who gets to already the browser, and like a lot of money has switched hands over the question of like, which browser is default, and which search engine is default within the browser. I just wanna build for yeah.

I wanna build for SWIX essentially. Like, I wanna I wanna build for people who have a number of annoying tasks that they feel like maybe Clock could do it could do it for them. Yeah.

What do you think about skills portability?

I don't really know if that's like a business. So I'm curious, like, if you've had any thoughts in the area. I think for me, this is sort of where I go back to the really basic primitives.

For our skills are file based, instead of like this complicated thing that exists inside a place somewhere that is like super pro proprietary. I'm really leaning into the idea of like it's all just files and folders, and that makes it very portable on its own. Right?

We do have skills as part of this container format, which we just call plugins. Mhmm. And plugins are available both for Cloud Code and Cloud Code Work, the same format.

And you can install plugins. This works in Code Work today. You can basically say, gonna add a whole, like, just a GitHub repo as a skills marketplace or like a plugin marketplace.

And that's how we're doing portability. I think we have a lot of room left to grow in how do we make it easy for people to know that they can write skills? How do we make it easy for them to just like share a skill with you?

Because obviously, all the words I just said, right, like I'm losing most of the knowledge worker base out there. Right. And I start with saying, oh, you can connect to GitHub repo.

It's not exactly how most people will end up working in like a general knowledge worker space. But I think there's something there. And another thing that's there that I think has not really been properly explored is the the the combination of which part of the skill is very portable, and then which part of the skill is like very personal to you.

Right? And I think that's something we haven't really solved yet as an industry. Mhmm.

Because like, which part do wanna introduce more structure to the skill, or have always have like public skill, private skill, you know, pairs. Yeah. Yeah.

Kind of. I think there's like a like the easiest way to do this, which is we do, like, use string interpolation or something. Right?

Right. Yeah. Yeah.

Insert username here, insert, like, phone number, insert, like, known folder locations, that kind of stuff. That's probably clunky. That's why we haven't built it.

But I do think someone is going to come up with, like, an interesting way to keep everything we like about skills. The portability is just a file. It's just markdown.

It's just text, honestly. Write like a text file words. The complete lack of structure, which means you don't need any kind of tutorial to write a skill.

Just like explain it to Claude the way you would explain it to me, and Claude will probably get it before I work in. Right? You just like for booking your flight, tell Claude how to book a flight the same way we're telling someone who just started working here today.

But combine that with a very, like, personal thing. Maybe we'll stick with the booking a flight example. I don't actually think AIs should be booking flights.

I think the tools we have is Yes. Possibility. Yeah.

Finally, somebody says it. It's the default demo that everyone was making. And I'm like, I'm leaning against flight booking demos.

It's a good showcase. Yeah. I'm like, I just wanna book my flight myself.

But Right. I think there's a lot of things that have a personal and a non personal component, and that's maybe why people reach for flight booking, because some things are very universal. Cheaper flight is usually better.

Right? Like, few people try to book the most expensive flight. And then some things are quite personal about, like, what times you prefer, which seats you prefer, which airports you prefer.

So many attempts have been made to build documentation companies that are like, oh, we're gonna solve all your documentation problems. I myself like spend a little bit of time working in Notion. Right?

I'm like deeply familiar with the concept of let's get everyone on the same page. Mhmm. Right?

And what you're basically saying here is you want all your agents to be on the same page about your preferences, about the skills, about the way they ought to work, and like how they ought to execute. And I'm not sure what the right thing is going to be. If it's going to be some some company that can say, alright, we're as an independent body, we're not trying to like push into any particular product.

It's our job to be like the skill authority, and we provide, I don't know, we're gonna be the Dropbox of skills, and we can just Simlink us into all the products they wanna use.

Yeah. In some ways. Yeah.

But, like, a lot of the scaffolding is the same. You know? Cool.

Mean, as an engineer, I will tell you, like, you know, taking a person to taking a person. I will just be like Simlinks.

And so it's like that works, but it feels like yeah. I don't know. Maybe.

You can always go one level up. You can always tell co work your problem, and then co work will solve it for you. It doesn't make the siblings.

That's like one way to do it. That's true. That's true.

Alright. Everything is called co work.

on. Yeah. I think look, I'll I'll I'll tell you this.

Like, I don't think I'm the best person to, like, actually estimate which industry is going to be hit the hardest. But I do think that at Anthropic, as a group of people, we're deeply worried about the impact that the tools are going to have on the labor market, especially for, like, junior employees. Because I think I think it's only honest to say that when we talk about automating a lot away a lot of the work that we personally find annoying that we maybe think it's not the best use of our time, in a lot of industries, that kind of work would have been given to a junior or entry level employee.

Right? And I think it's it's only it's only right to be really worried about that, and like worry what that's going to do, in particular to people who like enter the job market. Mhmm.

So there there is an aspect here. I'm not an expert enough to like actually know what what is going to happen to marketing, or legal, or finance. Right?

Like, don't work in those jobs, and I I don't think I should talk about them. But I am an engineer, and I think I have a pretty good idea of what engineering is like. And I think one thing we're sort of seeing is that, as a company and also as as the public, we're, like, deeply worried about entry level.

But we're also seeing more senior engineers accelerate it. We feel like they're more productive. They they actually increase the value they provide.

And the thing that I'm thinking about a lot is the fact that even before all of this happened, I've always had a lot of respect for the University of Waterloo, and the the new grads that have joined my teams as from coming from University of Waterloo, always felt like more ready than new grads who will literally spend their entire time at the university, regardless of how good, but never actually had to work inside an environment where you have to ship things that eventually will be used by users. And I'm I'm I'm German, I like initially went to German university, and I think the the the, like, information systems programs there tend to be very theoretical. Right?

Like often give people the example of like trying to become a doctor, but you first have to do four years of biology. And as a result, when you get a new grad, you sort of have to teach them what it's like to actually build products and to work in a company and to work with other people, and like some people will have a different opinion, and like how do you do all of those things? And the University of Waterloo, it seems like they just spend half of their time I don't know if it's true, but I think It's a year.

Right? They spend so much time Part of your job or curriculum to do spend a year in internships. Yeah.

They just like go from company to company. They show up on your team as like a junior engineer who's been to like 20 companies, not really, but like Yeah. It seems like a lot of my new grads have also briefly worked at Apple, Google, Tesla.

Yes. And there's a common meme where they like collect all these logos like infinity stones. But and they always put it on LinkedIn, and it's very unclear that they were an intern.

Like Yeah. Yeah. Exactly.

But it does actually make them so much better compared to other new grads. And I wonder if that's a useful model maybe for the future, but we also have to like crunch down the amount of time you have as a junior employee, because the value you have as a junior employee is going to like be impacted.

we do believe that the impact on the market is going to be sizable, and we do not think that people overall are ready. Right? And we do actually think we should probably talk about it as a society much more.

Yeah. I'm not sure that I'm like the individual that can add like anything useful there.

Is helping people to adjust over time. Right? Rather than one big bang thing, there's like sort of this gradual takeoff that people are living through that we're Yeah.

Waking people up. Right? Yeah.

And I but I think a lot of us are wondering at what point do we actually have full takeoff? Like at what point is there we're all sort of expecting this like big bang moment where things will accelerate so quickly that it becomes a self reinforcing loop. Mhmm.

And at that point, it's sort of like off to the races, and there will be no more like slowly catching up, you know, just have Claude being so good at everything. Yeah. It's when co workers training models.

It's when it's looking at tensor board and Exactly. Weighting by its values and training things. And like, we can all debate like how many years it's away.

Right? Like, some people make a better route, like, it's ten years away, maybe it's a year away. I'm not entirely sure where where I come at this time, but I'm not totally sure that ultimately it matters all that much, whether or it happens in four or five years.

If we've have a decent one, certainly that's going to happen, it's probably something we should wrestle with.

the the topic rather than the file type. I mean, you can just follow-up and have it do that. Oh, yeah.

Here, like, it did it did it's proposing this. Right? Yeah.

I see that you're using Opus 4.6. Right?

Like, my recommendation for people is increasingly don't worry about it anymore. Just like tell it what you want it to do Yeah. And it's probably gonna figure out a way to do it.

Okay. It might not be the way that you like necessarily or the way that you've gone about it. He makes videos deeper.

But we're outsourcing organizing all of this, so let's fight. Okay. Yeah.

Yeah. Very cool. I'm honestly, like, so curious what Claude is gonna come up with.

It's engineering. So we do have people who sort of come to work every single day and they they ask themselves, how do we make cohort extremely effective for people in those specific industries? How do we make it easier for them to understand?

How do we make it easier for them to plug into this and like sort of get the same value out of it that software engineers get? I think it's no real surprise that software engineers end up being sort of at the forefront of the entire AI moment, because so much of it is this like Rube Goldberg machine esque, where like we're already used to automating things. Right?

Like it's part of our job. Yeah. So we care about it quite a bit.

I think it also like really matches what we see cloud being very good in as a model. I think it provides tremendous amount of value to those customers in particular, because we can do so much with the amount of data they have. Those are like data heavy industries.

They're industries where correctness matters quite a bit.

not It's too sensitive. I had a similar question about taxes. Like, did tweet I did tweet about the fact I did tweet about, oh, COVID is doing my taxes, this is honestly incredible.

out to Nano Banana to do images. So unless you guys do images for me, I have to call other people for images. We're aware.

We're aware. It's it's just like so fun for me, because like, is the thing that I'm increasingly doing, like, increasingly curious about Klot's creativity and like, figuring out what It's great. Claude's approach is like some problem.

Yeah. Vision for everything is is like the the superpower. Right?

I know. Like, it was barely usable. Yeah.

I I remember, it was barely usable. What is it about how much better things have gotten Yeah. Over that one year?

We went to the Anthropic office because for the launch event for computer use, like, there was like this hackathon. Yeah. And like, nobody hacked on computer use.

But I did see I I I don't know if you're okay with me saying that, but I did see briefly that you do have like a like an automate Mac OS MCB server installed. Right? Uh-huh.

Have you used that ever? What sorry. Which one?

Where? If you go to your settings.

Yeah. I noticed that in your connectors Uh-huh.

Yeah. Why?

I think we're far away from

yeah, I'm not sure. I I do think it's a super interesting area because I I can maybe tell you, like, some of the things I thought about that I think are actually a bad idea. So when when we initially started working on Cowork, I I did have some dreams about what would it look like for Cloud to have its own cursor.

Could be cool. Right? Like it's a computer, we can write code, we can touch everything.

Like, who says that computers need to have one cursor? We could do a second cursor. But that actually breaks down quite a bit, even if you go and like present cool dreams to both Apple and Microsoft.

You're like, wouldn't it be cool if It breaks down quite a bit because so many of our models on the computer are built around this idea of like, there's only one thing Simple. Working on it. Yeah.

There's like a foreground app, a background app. Cloud and Chrome can work in the background, but that's like within one application. But at the operating system layer, that is a lot harder to implement.

So I'm I'm still grappling with what what does it mean for Cloud to actually act on your computer? Is the right format for Claude to have its own computer that you set up and maybe every now and then you like zoom in and you play with it? Or is the right format for Claude to just like wait until you're stepping away for a little bit and take over while you're gone?

Or is the right move for cloud just like have his own computer in the cloud, and like whatever you want cloud to do, you have to set up yourself. Right? There's like a there's like a number of different options.

This is a thing I think about a lot, like, what is the relationship between you and your computer, and you and your data on the computer? Because how intimate that relationship is kinda depends on the tool and Right. The thing that you're currently looking at.

Right? Like, we're quite comfortable sharing some things, very uncomfortable sharing other things. And I think whatever product is gonna be successful, we'll have to deal with those, like, with those different things.

But you probably even if Claude was capable of making a determination, would you want Claude to make that determination in the first place? It's tricky, Barry, because it's like it's more than just privacy, it's like almost intimacy. And it's like tricky to reason about in a way that will make everyone comfortable.

Yeah.

Yeah. Exactly. That was honestly a very fun project though.

Like, obviously, I didn't I I should say this, just so that knowing gets the wrong impression. I did not write the actual the actual obviously, I didn't build Windows only five because I was a child. But also, I did not build the actual engine that is capable of, like, simulating an x 86 processor in JavaScript and WASM.

That's a tool called v86, which is very cool and everyone should try. But this came out of a this came out of like a debate we had at work where people were like they often are in the end of debating the merits of Electron and whether or not we should be building software in JavaScript. Yes or no.

And I still am very upset that I can run all of Windows 95 in JavaScript and launch Microsoft Excel inside the virtualized JavaScript Windows 95 machine, and do things that pro I can do that entire chain faster than they can do a lot of other things in, like, traditional SaaS applications. Mhmm. This is sort of like a like a performance rampage that I went on.

So I mostly built this as a joke for some of my colleagues at Slack. This took took like one night. What?

But then that I it was it was not hard to do. It was all the hard work is in v 86. Like, you go to the repo, it's gonna say like 99% of this work is done by by a guy who goes after the by the name Copy.

His name is Fabian. Yeah.

and you want to know why you're making those trade offs. And you're right. There are a lot of people who write me, like, hey, how how come Claude is taking up 10 gigabytes?

I could say on the point, it's not actually taking up 10 gigabytes, just like a way that Mac OS displays bytes is like wrong. But the way we actually write it to disk is by we collapse the empty space in the image. So it's not actually taking up 10 gigs, but that's a technical differentiation that's probably not gonna matter too long.

To me, the the outcome is it takes too long to start. Yeah. It's like thirty seconds sometimes, so I don't know.

Oh, it should be faster than that. Okay. Whatever.

But it's gonna be tough, but it feels like thirty. Yeah. Like, even either way, like, whatever it is, it's going to be it's going to be slower than just running Glockout directly on your computer.

Right? So the trainers are real. But what we're doing on Windows, we're using the Windows Windows host compute system.

It's the same thing that WSL two runs on, like the Windows subsystem for Linux that I think a lot of developers appreciate quite a bit. Yeah. And it's it's pretty cool because we sort of like have to separate out which system space this virtual machine runs in in, who gets to talk to that virtual machine.

Because obviously you give this virtual machine a decent amount of power, how do we optimize not just the connection between the two systems, but also how do we make sure that random other application doesn't get to talk to Cloud inside the VM. We do some pretty interesting things. Last week we started writing a new networking service, a networking driver that optimizes how Cloud talks to the Internet.

If your company is doing, like, weird Internet things, like packet inspection and, like, t like, you know, taking your part as a cell inside your company. I think there was probably, like, a very small, easy version to build off Cowork that is much simpler, but also breaks on most most users' computers. And this one is quite nice because it works on most users' computers.

And the default example I always go for is, I I really want this to be highly effective on like a on like a machine that most people pick up, and that machine will probably not have Python. It will not have Node. Js.

And even if I just take away those two things, Cloud is going to be so much less effective on your computer.

OS, we use the Apple Virtualization Framework, which is pretty solidly optimized. Like, it's good stuff.

Would you once you start, like, shipping production code on it, you start adding, like, all of these edge cases, you're gonna Oh, yeah. It ends up being a little longer. But I think Apple really cooked with the virtualization framework, and it's very, very good.

It is very fast. It's very reliable. And same on Windows.

The the host compute system, I think WSL two as well is maybe one of the diamonds within Windows. It's like one of the few things that developers universally rave about. It's very, very cool.

And, like, hooking into the same subsystem makes it a lot easier for us to say, we don't really care how locked down your computer is. Maybe it's like your employer's computer, and your employer has decided that you get to install nothing. Mhmm.

Not trusted. But it's true in a lot of environments. Right?

Like, at Anthropic, our IT department controls what kind of software you install. It's like a pretty common experience for many companies. And this gives IT departments a decent amount of like, makes their job so much easier.

Because we can say you can separate out computer from the user's computer, and then for Claude's computer, what you probably care about is data loss, You care about, like, a potentially hostile actor. You care about maybe data being exfiltrated. And once you control the network and the file system layer, you don't really care necessarily anymore that Cloud might be writing super useful Python scripts.

What worries you about the fact is that like, once you install Python, now anyone can do anything on a computer. But once you put that in a VM, that risk really goes down. Yeah.

So that's why we jumped through all of these hoops. Yeah.

dichotomy between either approve every step or dangerously skip permissions. Yeah. And actually sandboxing is like, kinda like the middle ground.

Yeah. I do think I do think it it's maybe on us as like the industry to come up with something better than, oh, this is super safe as long as it doesn't do anything. Right?

If you want this to be useful, then you have to, like, approve every single step of the way. And, like, computer use is a good example. The only way to make computer use on your host, like, super safe, like, really super safe, is probably if you approve every single action.

Right? Like, models, like, I would like to type the word l. And you're like, okay.

That seems fine. Because I know I know which, like, cursor is focused. Yeah.

It's not automation if you don't delegate. Yeah. Exactly.

You need to, like, properly delegate. You need to be able to, like, delegate and walk away and trust that this thing is not gonna, like, mess out dramatically. And I don't even think we need to build perfect systems.

I don't think we need to wait for, like, a 100% model alignment. We can rely on the same Swiss cheese model we've used in the industry for a long time, but I do think we need to, like, universally, maybe eventually invest more. And that's what we're doing.

We need to invest more in systems where we can say you do not need to approve everything. Speaking of Swiss cheese model, he just wrote a thing about this. Oh, cool.

Yeah. Yeah.

Yeah. Yeah. Talking about both.

Kinda like both. I think I I also want to capture people who would have no trouble using Cloud Code, like yourself. Right?

Yeah. But still find it maybe just convenient, easier, and you're like, oh, cool. That's like the to do list on the right, I can edit it.

Those things are just easier to do if you have to. Yeah. But this is like clearly the knowledge work side.

Yeah. Cloud Code will clearly capture the development workflow. But like, I do think like, you have to sweat this, like, safety and security details in order for people to trust it.

And like, the even Cloud and Chrome, like, having the whatever API uses to do the background thing Yeah.

maybe we're we are more risk tolerant, but we're also just like accepting we are more risk tolerant, but I think we also just have like, I don't wanna say arrogance, but like sort of the trust that if like the really bad thing happens, we can probably fix it. I just tell Claude to like check with me before doing any irreversible action, sending an email or doing it permanently. It's good enough.

But like not even cloud. Mean, like simple things such as NPM install. Right?

Like we're all running NPM install with full user permissions, and if it wants to like read dot SSH, it will. Crazy that that is the default. Kind of yeah.

I know. I agree. I agree.

It's fine. Like, I'm obviously doing it every single day. No.

Right? Like and I think, obviously, NPM and GitHub too have, like, done a pretty good job maybe over the last couple of months to, like, clean house and come up with, like, more specific tokens. But generally speaking, I think as engineers, we've always been a little bit more risk tolerant.

And if you do a little bit of introspection and you ask yourself, is that how we should be doing things? You might not always come up with the right answer. And I think for models too, like, my approach like, I'm not gonna the the safest thing is to do nothing.

We do want products that are quite capable. But to the extent possible, I don't wanna ask you, are you okay with the script? Because I kind of believe that once it starts becoming a part of your workflow, you're probably not either either you don't have the skill to understand whether or this Python script is safe, or you're not gonna read it anyway.

Cool. I guess a a couple parting questions. What's the future of Clockwork?

I think we're still we're still in such early days. We're gonna keep shipping things that gonna keep shipping things that we're gonna keep iterating on this thing, like, pretty quickly, but which I mean you can sort of continue to expect that every single week there's gonna be, like, a small new feature, if not a big new feature. I'm going to continue probably to double down on your computer, and like making you effective on your computer, making Claude effective on your computer.

We're starting grapple, as we talked about today, grapple more with a question of like, what does it mean? What does your computer mean? Does it have to be the one in front of you, or like a VM on your computer, or like a computer somewhere else?

And then the third thing that I'm quite excited about is we're continuing to go up this hill climbing on slowly taking users who are used to asking questions and getting an answer, to slowly teach them to like step more and more away, and that claw take over like bigger and bigger tasks and work, both in time as well as in like scope. And I think you can probably see most of our investments in our feature releases to like work on both of those things. Like the ability to do more on your computer, and then the ability to do more independently for longer.

But, like, what what is what's beyond that? I don't know. I think it's basically the idea that, like, you still had tell her to build your script.

Right? He was still kind of involved Yes. In maybe a way that felt kinda magical to you, but maybe to me on the other side as the person building this product, still feels kinda heavy handed.

I see so much process that I'm like, oh, let me take that away from you. Okay. But how do I just go?

I will continue to go, will continue to go like further and further up the stack, and make your life easier and easier. Oh, here's one. Right?

Yeah. Watch.

you is called co workable? Yeah. I don't know.

I think the funny thing about a lot of these products is that, like, for good reason, I don't enjoy I I don't throughout my entire career, I've never, like, teased too much what I'm working on, because I think you should just, like Yeah. Release it. Yeah.

Build a day and release it, and then talk about it. Like, I'm I'm not a big fan of, like, posting my own work ahead of time. Yeah.

But the thing that is, like, always so fascinating to me is, like, both of you all, multiple times a day, you've like mentioned things, and I'm like, yeah, that is obvious like very obvious Okay. That someone should be working on those things. And I think we're still in the space where if you look at co work, the things that we will be releasing will probably not be a big surprise to either of you.

You're gonna be like, yeah, obviously that's valuable. Obviously that we're working on those things. Yeah.

And obviously that's good and useful. And the more I hit those points, the more our features fit into that category, I think the better it is for us, because then we don't end up building things that are too hyper specialized or too difficult on the style. Yeah.

I think the hyper specialized thing is very important. It keeps you, like, general purpose, it means you're not thinking too small maybe, I don't know what the word is. Yeah yeah, exactly.

It's like the whole concept that at no point did we release, you know, there's no cloud code for Node. Js applications that use React and TensorStack, only those two things, and like, if it's anything else. I know several startups like that.

I think there's pretty like, I'm not a VC, I'm not an investor, it's like hard for me to predict where the markets go. But in terms of the building blocks that I'm interested in, the Electron is probably by far the most popular thing I ever built. And Electron itself is like very abstractable and generalizable.

Right? Like so many apps run-in it, that think it would have been hard for me to predict how many apps actually end up using Electron. Yeah.

And what would have been even less useful for me to predict is in what those apps do. I just really remember Bloom coming out of being, that is cool. Like, you are a camera in a little circle in the corner, that is pretty smart.

That's an Electronet? Yeah. Yeah.

Or at least was. I'm not sure if it still is, but it was for a while. Or like one password has so many interesting things.

Right? It it's it's it's a level of aesthetics that I'm quite comfortable with. And whenever I give other engineers advice, it's actually that layer that I think is most valuable to invest in.

I can give my big take. Why do we ship an entire version of Chromium inside the thing? Right?

Like, why do we do that? And people ask me this question a lot because it's, very counterintuitive. Wouldn't it be much easier to use the web views that are on the operating system?

Wouldn't it be much easier not to have to do that? And the answer is yes. And like, obviously, I did that.

Once upon a time, I did that. There was a version of the Slack app that used just the operating system that we use. Wait.

Did you did you start the Slack app? I would well, team effort and yeah. Yeah.

But I was I was there, we built the Slack app. Yeah. It was crazy.

but this is an interesting point. Like, by the time by the time I joined Slack, they already had an app that was built with something at the time called MacGap. It was a little bit the same app gap thing for mobile.

It just used the operating system's web views. And that didn't work for like so many reasons. And they were like, alright, maybe we need like bigger guns.

We need to like take more control of the rendering stack. And there's there's a few things I always mention here. I think if you're building a small app, just going with the operating systems, Redfield is perfectly fine.

If you're building an app maybe that doesn't have too many users who will like cry bloody murder, if it doesn't work, that is fine. The reason to go with your own embedded rendering engine is because, and this is still true in 2026, the operating system rendering engines are not that good. They're just not that good.

Both Microsoft and Apple are trying to move away from that. They so far really haven't. Only way to upgrade those is to upgrade your operating system.

So if you're, say, a Slack and you have a critical rendering bug in WOK WebView and some of the other WebView options, your only recourse is tell your customer, oh, sorry. You're too poor. You didn't buy the latest MacBook.

Unacceptable. Mhmm. Unacceptable to user.

Unacceptable to user developer. So you sort of need to, like, go down the stack and, like, find the best rendering engine, then put it in your app. Why Chromium?

Even though it's very big, Chromium is by far the best thing. Like, I I often like to remind people, the Unreal engine, you wanna render some text, they use Chromium. Like, Chromium is part of the Unreal engine for same purposes.

Chromium is very, very good. I think it's like one of the marvels of engineering. It's very hard from we're in San Francisco right now.

That's where we're recording. Most of the people in the city are web developers. It's hard for me to, like, overstate how magical it is.

They can once see like, rendering a YouTube video, dynamically negotiating a bit rate, figuring out what to do about your extremely broken hardware driver. Actually, this is a fun thing. Okay.

Can enter chrome colon wack wack GPU. Okay. And if you scroll down a little bit, these are all the enabled workarounds because something is going wrong on your computer.

If you're doing this on a Windows computer with, like, a GPU that is not the most popular GPU, it will be much longer. And all of these are usually just there to make sure that if I say, as a developer, I want a red pixel to appear here, that that actually happens. Chrome is such a marvel because it works on all the machines that a user might throw at you, and it's gonna work fairly reliably.

And if it doesn't, they will probably fix it within twenty four hours. I see. So this is the super operating system.

Right? That that works everywhere. Yeah.

Alright. Okay. Yeah.

So a lot of the magic of Electron is honestly just that it makes it very easy for you to ship Chromium in a way that serves you exactly and your use cases, Electra, exactly.

And this is this is the platform where you ship apps. I I think the wild thing is that, like, as engineers, we so often sort of assume that the platform, like, the layer below us is, like, super stable. Mhmm.

And then you talk to those people, then, yeah, we're all so just, like, guessing. And I had like a distinct moment at Slack where one of our customers at Slack was NVIDIA. And for a while, I really put GPU developers on this pedestal in my head.

And I do think they're still probably much smarter than I am. But I was like, hardware engineers who built the chips, who then they built the drivers. Their work must be so much harder than mine.

They must be very good. And we had like one bug in Slack, where like if you had a YouTube video in Slack, wouldn't quite render why it like would have these weird artifacts. And that ended up being the Chromium bug, and I ended up on this, like, giant thread.

So I got to see a lot of the source code. And they also are just, like, common to do, we don't know why this is weird, but if you flip this bit, things work. You know?

This is just, happening with every layer of the stack.

mostly just like overwhelmed both with how hyper specialized tools are inside the Chromium repo. Like for for a long time, the Chromium has to like sort of reinvent all the tools because none of them are capable of handling Chrome. I think the EGI moment I'm kind of waiting for is, at what point are we gonna say, Electron is probably no longer necessary because you can just build fully native apps?

The Swift e? Yeah. Like not just in Swift, because this is one thing, like, it's pretty easy if you I think our current models are quite capable of taking an electron app and replicating in Swift.

Are they gonna be capable of like building an app that is actually more performant, uses less memory, all of that stuff? Is gonna go into the same hyper optimization that developers have done for like a long time? We're not quite there yet where I can like point even our best models at a thing and say, just replicate this in native code.

UltraThink is bad. Today, UltraThink is back. Yes.

Okay. Or we'll get on UltraThink for, like, days.

Is that something that makes sense for you to build or for like It's like super interesting to me. It it almost goes back to like some of the scaffolding where I'm like, okay. Are we gonna be end up are we will we end up building scaffolding that will just go away?

And like a question I have here is, at what point do we just assign these things, like their own Gmail account, or just give them their own Slack handle, and then they will just, like, use the same tools we humans use to interact with each other. You mentioned our finance people. They've been working pretty hard on very good office integrations.

And I think for a while, we've been like we built so much tech around Claude leaving useful comments inside a Google Doc, and now it just does it. Just like leaves a comment in a Google Doc, and that's how you interact with it. Maybe like the similar thing where I still have open questions around what is the best interaction mode.

It Is for us to build something super custom for co work agents to talk to each other? Or is it, okay, let's just jump straight to the finish line and say, well, we're just gonna give this thing if you use Slack at work, we're just gonna give this thing a Slack handle, and that's going to be the way it's like multiplayer capable.

to hand off to each other things using their particular context? Yeah. And for both of your co works to like talk to each other.

Right? Right. Yeah.

Hey, we got an episode today. Can you like have you you know? Or Yeah.

This is like a I know we're, like, running out of time here, but, like, we we previously talked about sharing skills, and I did have this question of, like, what if your coworker would just, ask the other coworkers if they have a skill for this task? Doesn't know those things could do. Alright?

Like, okay. So skill transfer. Yeah.

Like and again, this maybe if Creepy. This maybe goes back into the territory of, like, building something very powerful and building something creepy often goes hand in hand because I could tell from the reaction that my fellow engineers had that this is probably not what we're gonna do. But, like, we have Bluetooth LE.

Right? Like, I this computer can figure out that it's sitting right next to this computer, so you're probably working on the same thing. Will you see that in co work?

Probably not. But there's like, I think really creative solutions to problems that we really haven't tried yet. Yeah.

Yeah.

is now under, right, as part of the whole org. I mean, people are so fungible. Right?

Like Okay. This is just I don't know how I don't know how real this is. I don't know.

No. It's a real team. It's very Ehime.

The the labs team is primarily working though on things that you don't see in public yet. Yeah. They're trying like really wild out there ideas that seem quite improbable.

now Cloud Code is like a fairly big group where I actually know how many people we are. Like, I remember yesterday coming into our weekly cohort meeting, I was like, woah. This is hot.

It's a lot of people here. But we still have a labs team, and we actually made the labs team a lot bigger. Mike just joined the labs team as a as an IC, which I think is very cool and very fun.

But they're they're working on things that you have not seen yet that are extremely out there and probably half broken. Right? Like, the sort of the idea of a labs team is that it should only work on things that make really no sense for anyone else to work on.

Okay. Well, looking for exciting things from there. But thank you so much.

I know we're out of time, but appreciate your joining us. I appreciate co work. Everyone go use it.

It is the closest I've felt to AGI this year. That's somehow good to say. Thank you very much.

Yeah. Thank you for your time. Yeah.