Speed, Quality, and AI: You Can't Have It All (Or Can You?)

Hello, everybody. I'm Gawe. I'm an engineer with Z and I want to start with some hot takes. Can anybody tell me their favorite React framework that they use? Next JS? I hear Next JS here. Let me write that quickly down. Anybody think that their framework is better than Next JS? Any Next JS haters here that want an alternative? Don't stack start. Nice. Any other frameworks? React Router? And do you guys use any tools with those frameworks? ESLint is pretty standard these days, but the front-end ecosystem, always moving fast. Maybe there are some new linters, some other cool new tools that anybody is using? Not all at once. Okay. Oxlint. Nice. And last but not least, something that's moving even faster than the front-end ecosystem is of course agents. So does anybody have an agent that they use in their day-to-day work? I'm guessing some people are using agents here, so don't be shy. I know it's a big group, but anybody have an agent? Cloud Code? Okay. Anybody using a different agent than Cloud, or are we all Cloud fans here? CodeX? And do we have maybe one more that we can try? Cursor. All right.

So what I want to do now is I prepared a little skill called the React Summit demo skill, and I prepared some offline data with information about the talks that happened today. And what I'm going to do is for the frameworks that were just mentioned, I'm going to build a new project with that framework and possibly a tool that was mentioned in the agent that was required. Because in Z we support a lot of different languages, a lot of different tools, but also a lot of different agents. So let's start with the Z agent. I have the Z agent selected here. But in the Z agent we support a lot of providers out of the box. So as a few people already mentioned, CodeX, for example, you can sign in through either the OpenAI subscription or your ChetGPT subscription. I'm already signed in with my ChetGPT subscription. So let's create a React Summit demo. And we have some options. Next yes. People are probably using Biome here, so let's include Biome there as well. And let's have this start.

Because we're going to create multiple projects, I'm going to create a new work tree now. And you see a new entry here. Besides our own agents, we support external agents. We have our own protocol for that called the agent client protocol. And it's an abstraction on top of harnesses that agents can implement. And then other clients can use their own UI on top of it.

So I think somebody mentioned Cursor. I don't think I have a Cursor subscription at the moment. So we can maybe try another external agent. I have a few installed here. If you want more, we support a bunch of different agents from the ACP registry. So let's use in this case Gemini. It's going to load now. It's starting to harness in the background. And then we still have our set UI that we're used to. So create a React summit demo with, and I think we had Donstack start and Oxalint. So while that's running, we can create yet another work tree.

In the background, these agents are still running. And another thing that we have is called terminal threads. So if you open terminal threads here, it, as the name says, opens another terminal. Maybe some agents are not supported by either ACP or our own set agent. One good example of that is Cloud Code. We have support for Cloud Code, both in our set agent and in ACP. But Entropiq also announced that their subscription is going to change and that third parties can't use subscription anymore. So it will be based from specific tokens. But in this case, you can still run Cloud as any terminal and it's still an entry inside of set here, still running parallel from all the other agents.

At this point, we got a question from Gemini that's just accepted. And I will now leave the fate of my demo a bit in the hands of these agents. So while these are running, I wanted to quickly talk about what Z is. If you haven't heard of Z yet, we're building a code editor. It's written in Rust. We don't include any binary for Electron or any web technologies like that. We do this by creating our own UI framework, also in Rust, called GPUI.

And we support all the major platforms like Mac OS, Linux, and Windows. Even though it's Rust, it might be fun to see that this is our syntax for GPUI components. If you're a web developer and you've seen Tailwind before, this might look very familiar to you, like the margin top, the gaps, children, and even in the children, we sort of have components. This was quite fun for me. I am a front-end engineer at Z. But even if I look at this Rust code, I can still understand what's happening here, read it, and even help writing new UIs in our editor.

We have three things that we find very important when we're working on Z, which is first of all speed. It's a tool that you use every day. We value collaboration very much. And as I started in the beginning, we have agentic workflow supported. Of course, talking about speed is a bit hard. You kind of have to feel it. I've been using VS Code for a long time, always thought it was OK. And then I started using Z, and you really feel the difference of being able to switch around, click on things and see instant reaction coming.

Of course, talking about speed is a bit hard. You kind of have to feel it. I've been using VS Code for a long time, always thought it was OK. And then I started using Z, and you really feel the difference of being able to switch around, click on things and see instant reaction coming.

One example of showing this off is if we go to the BUN codebase, you might have heard that BUN recently was rewritten to Rust. They had this massive PR of more than a million lines of changes. But if I scroll through this, we have no problem of viewing this diff. I can open files, I can go back, I can scroll up. If you try to open this PR in GitHub, for example, you're not a happy user. It's going to take a while to load things or even open things.

Another cool thing about this speed is you might be working on multiple projects. I work on the Z.dev website, but also on our cloud codebase, which does our APIs and our customer-facing dashboards. And in this case, I already have the BUN project open. I can switch to the Z.dev project. My dev server is running here, I have my code here. If I need to switch to another project, I go to our cloud codebase. Dev server is still running. I can switch between all these projects without any issue instantly, and it gets out of the way in my workflow.

Then another thing we find very important is collaboration. We are a fully remote company. We have people across the whole world, from India to Europe, from North America to South America, but we still highly value working together with our colleagues. It's really important to bounce ideas off each other, work together, get to a certain task. And for this, we have collaboration supported inside of Z. As you can see on the side here, we have channels, and you can see here some rooms, for example, and my colleagues are actually working together right now.

We should probably not join them, because that might be a bit confusing, but if I... Let's just join a room. Sure, sure, and let me mute myself in case somebody joins. I'm not in this channel. If anybody else is using Z and they join this channel, we can talk together through voice, but that's only a small part. You can do that in Slack, you can do that in themes. But the really cool thing is that... Okay, you can share your screen. But even cooler is that you can share your project as well. If we're both in a channel together and I share my project, we can directly simultaneously edit this code base together.

It's... Ah, somebody even joined me. You can write code together. It's sort of like a Google Docs document or a notion. You will see multiple cursors in the code moving around. If you want to follow a colleague, you can follow them. If they open new files, the file is open for you as well. It is as if you're working on a local project. And yeah, it's how we work together. We're across the whole world, but we still hang out in these channels almost every day to work together on features. And yeah, it's a really nice way to be in the same program to do all your work.

And then the third pillar that we find really important is the agentic workflows. We already started that before this. And if you might have seen it before, we already got a notification of an agent that's ready. In this case, it's Gemini again, sadly asking for more permissions. So let's allow a bunch of things. And while these agents are running, we can see they started building something here already. We have some changes, and you can follow the agent around what it's doing at that moment. Since they're in different work trees, I can easily switch between these.

Ah, did I not start a prompt here? Oh boy. Let's see if that can quickly still do something. So yeah, here we have already one that's finished. In this case, it built an application with Next.js 16, uses PMPM, Tailwind, and BIOM. And it already gave me the URL where this application is currently running. I can see what the agent did, but I can also tell it to do extra things that it needs to solve. For example, in the corner here, we already see some issues. Let's make a screenshot of that. We can paste it back to the agent and say, fix these issues.

While this is running, we can check out the other one again, which is sadly still asking for more permissions. But as you can see on the side here, it didn't add a gitignore for the Node modules yet. Which is a shame. But yeah, as you can see, we're now making some changes here. We told it to fix the issues. And since this is our set agent, we can see the changes in real time. If you want to have more context, we can open it. The file instantly loads with all the LSP and language features that you would like from it. Let's see if we now refresh this. It actually solved the issue, but you can also reference code, for example. So if we go here and we see this title, you think, okay, maybe this title can be a bit better. So if you search for this text, we can find it here. I can select this code and through a key combination, reference it here back again.

And I can say, change the copy of this text. In this case, it also added Biome. We have a few languages supported by default, which is Rust, but here, of course, more importantly, TypeScript, React, and Tailwind. And also even ESLint. So if you want to get up and running, you can use it without doing anything crazy. But as we said, the frontend ecosystem always moving fast.

If you're using something like Biome or ErcsLint, you can go to our extensions. And for example, search for Biome. We can install it. And I hope that now we can immediately see the errors coming from Biome in our editor. So even if you're using new tools like Biome or ErcsLint, we got your back.

Let's see. Cloud code is probably still working. Gemini is still asking for permissions. Yeah, as I said, this demo is an agentic demo. I kind of put my faith into them that they could fix this for me. Hopefully, at least, it gives some insight in how you can run these simultaneously. If you still want to write code or fix some things by hand, we also have our own edit prediction model called Zeta.

So if, for example, I say here const hi. I don't know if I can complete that. Maybe if we try. And here you see, I don't know if people can see it, but it has light gray suggestions. And if I then tap, it auto-completes the code that you might have wanted to write. It's running NPM Lint. Does it already have something working?

Cloud code is here as well. We have an ErcsLint file here. Don't think so. Oh, man. Gemini, what are you doing? But yeah. Any tool you want to use, well, okay. There it goes. It's finally finished. So here again, it tells me that the project was created. And it used OxLint. So let's see if we have an index file.

If I go here now, I can, like I showed before, reference this back, for example. But I can also, I think, if I put a console log here, we don't get any errors because this time we're using OxLint. So again, we can go to extensions, install OxLint here. And if it helps us out this time, it shows an error. And if not, you kind of have to trust my word on this, but luckily you saw it with bio, so it is working. If we go to this project, I think this had Tailwind.

So yeah, as I said, it comes out of the box. If I want to add a margin top here, you don't need to do anything fancy. The colors are included, the autocomplete is included. So if you're a React dev, which you probably are if you're here, you can download Z and get started.

Cloud code is finished now as well. I don't think it likes modules, node modules this time. But the terminal threads are a bit less integrated as in we don't have our own Z UI that we can show you there. So it's just a terminal as you're used to with cloud code. But that doesn't mean that Z doesn't benefit you.

You can still, well, it's not a great diff because of the node modules. Ah, here we go. You can still use our other features to help you out after, for example, cloud code in the terminal created a bunch of code for you. You can view the diffs in Z. You can, well, maybe not the logs. You can reference this code. And just like before, I can give it the shortcut to even reference it back to the terminal. So, yeah, it was a bit of a demo of how you can use agents in Z.

We think of ourselves as a very open platform. We support hopefully the agent that you use because we understand that companies have different needs. So we have all these agents, languages support, and overall we're a super fast editor that hopefully helps you out in your day-to-day work. If this demo was interesting or you want to try out Z for yourself, as I said, we support all the major platforms. You can go to z.dev.com to get started.

If you're here today with your company, we also have a business subscription. If your procurement department has specific needs about certain settings that need to be configured organization-wide, you can go to the Z business website which gives you a bit more information if that's helpful to you. And last but not least, yesterday we put out a blog post about DeltaDB and our next big vision. Definitely check out the website. We have a blog post about what that is and you can also sign up with your information to request early access if you're interested in that.

So first, our audience are a bunch of frontend people. Gabor, please tell me you have themes. We have themes and I can maybe even show something cool. We have these themes that you can install. If that theme doesn't fit your requirements, you can go to z.dev.com, slash theme builder, and here you have a little preview of Z in your browser. If you want to change any colors, you can do that here. You can make it blue, for example. You can change the surface background to pink, make the most crazy theme you want, and from there on out, you can export it, use it in Z, and you have your own custom theme.

You can make it blue, for example. You can change the surface background to pink, make the most crazy theme you want, and from there on out, you can export it, use it in Z, and you have your own custom theme. Woo! I love how you get this question and you get so enthusiastic that you jump to your laptop and show and tell. It'll show and tell. I love it. Thank you.

All right. Next question is from Anonymous. Does launching an agent from the UI, like you showed, automatically create a new work tree? No, you can have multiple threads in the same work tree as well. You can create a work tree yourself and then start an agent in there. If you then create ... When you're in that work tree and you create another thread, it will use that work tree automatically. If you start a new chat, you can also, in the dropdown, choose from which existing work tree you want to start that thread. Very convenient.

Next up, if you had to choose one option, will AI and editors eventually ensure 100% code quality automatically, or will human code reviews always be the ultimate bottleneck? Nice choice of words. I still think a human in the loop is important. As I said, we do a lot of pair programming. Changed over time as well. In the beginning, we were writing code together. These days, we even do pair programming with the agents in the loop. But then, it's quite nice, because you don't have a random PR without much context that you give to another colleague.

That way, we can work together as colleagues, as humans, with the agents in the loop to also verify what is it doing, how did this come to this. And with another human next to you, it's quite nice to also not accept things too easily. If the agents spit something out, and you think, okay, sure, that's good enough. But if you're with another colleague next to you, you might have a bit more reason to, okay, but let's see how we can actually improve this. So agents are great, and they're really improving over time. But yeah, I still think at this point, a human in the loop is nice to have.

As far as we can see now, humans in the loop. I also can't look into the future, sadly. We'll ask again in like three months. Any plans to add first-class support for playwrite, for example, having a green play button for each test? We actually have support for tests already. If it recognizes that you're using a certain testing framework, you get a little green button next to the test. I'm not 100% confident at this point if playwrite's one of them, but we support the general implementation of those tests. If this specific person knows that playwrite isn't supported, definitely open a GitHub issue and we can have a look to support that as well. Cool, thanks.

Can I have the agents talk or engage with one another? I think currently we don't have that, but you can reference all the threads, for example, in a new agent session. So you can, for example, let it know what happened before in a different thread. And we recently also added something cool that one thread can actually, the agent can create new threads. So if you're working on something, one big feature, but while you're looking at the code, you come across something that you might want to fix as well, but you don't want to get out of your workflow, you can quickly tell the agent, okay, can you maybe start a separate thread to fix this? But now we continue with the feature that we're working on. Is that then in a different Git work tree or it's in the same work tree, just fixed on top of what's still running? I'm not 100% sure. I think it's a new work tree because otherwise it might mess it up. But don't pin me on that exactly. I won't pin you.

But don't pin me on that exactly. I won't pin you. Next up, IntelliJ is powerful when it comes to shortcuts. What about Zed? Yeah, we have almost anything that you do in the IDE. We have tasks for that, kind of like VS Code, you can bring up a command palette to interact with those tasks. And each task, you can also assign to a certain keyboard shortcuts. We think we have sensible default shortcuts built in. But if you have specific workflows or needs, we have an actual keyboard shortcut editor built inside of Zed, where you can record your own keyboard shortcuts, assign it to a specific task. And the system is quite powerful that you can even have conditions that certain things should only happen in a specific context.

Like, for example, if you're in an agent thread, but not in a code file, for example. And jumping on top of that, maybe more important than an editor, an importer for keyboard shortcuts. Because I know from like VS Code that you can export as a JSON, and it would be great to just import what I already have. I don't think we have an importer yet. But we do come with a few built-in key maps that are based on, for example, VS Code, IntelliJ, and a bunch of other editors. So if you're coming from another editor, and you want to try it out, it should be, hopefully, a seamless experience to at least bring the things you know from another editor.

Unless if you've modified the defaults in your previous editor heavily. Fair enough. It's a fun project to build, like the theme builder. Yeah. PR is welcome. Yeah. Do you have UI for git conflict resolution? Nice. Yeah, we have git support built in. So as you showed it quickly, we have the git diff. And if you have merge conflicts, they will also show up. It's not a fancy three-way merge conflict resolution or something. But yeah, it's... Something. Yeah. So please resolve your conflicts.

Yeah. Nice. Good question. Yeah. Our founders also worked on Adam. And Adam kind of resulted in Electron. So it's a funny journey. And from that, they also learned that if we want a very performant editor that can do all these crazy instant stuff, the web technology is not good enough for that. Sad to say as a web developer myself. But that's why we chose Rust. Because we know with Rust, all these things were possible. I wasn't there at that point yet. But I know that at that point, the UI libraries for Rust weren't that great yet. So that's why they decided to create our own UI framework.

Which is a journey. Because we all expect very basic things to work. If you see a scroll bar, it's not that hard. It's just overflow. And you get a scroll bar. In this case, we had to build the scroll bars ourselves. We had to create the buttons ourselves. Last week, a colleague of mine wanted to implement a feature that had inset shadows. We didn't have inset shadows yet. So we needed to create the inset shadows. But yeah. Right now, we have most of the UI elements there. And that's also how we can get it this performant. And then, this is super tailored to Zed's use case, I guess.

And that's also how we can get it this performant. And then, this is super tailored to Zed's use case, I guess. Your UI library. But is this something, if I wanted, I could get it? Or it's not open source? Yeah. So, the whole codebase is open source. Including our UI framework. There are already a few companies who are using it. There's one crazy financial application with big charts and data moving around. They're using GPUI. There are also a few repositories that have more ready components built on top of it. Kind of like ZedCM. If you're familiar with that. So people can already start using it. But yeah. We might introduce breaking API changes here and there. So that's a risk you're sort of taking. It's for you.

Yeah. All right. Next and last question that we can do on stage. Would you talk a little about Zed support for MCP, agent skills, or any other related concepts you think are appropriate? Yeah. We have support for MCP servers. You can configure them in our settings UI. And we support all the different MCP servers. If you need to be authenticated, you can authenticate as well. I think last week or the week before that, we shipped support for agent skills. So you can also now use those. It automatically recognizes global skills that you have already installed in another editor. For example, we can either reference it manually, like I did with React Summit skill. Or if the agents can pick it up themselves to see if they need a specific skill. Cool. And you're right at the zero timer. That's one Dutch skill. Yeah. All right.

That's all the time we have for Q&A with Gawa. If anyone else wants to continue the conversation about Zed or the whole presentation, Gawa is going to go to the Q&A booth over there. So everyone, please give one last round of applause for Gawa.