Tecnología Informal

It was a very fun part of being at an in-person job—all the learning that takes place when you're literally watching someone code.

There are so many programmers in the world and it's such a diverse market of people who work differently. I think we can be very successful while being below 50% of developers or whatnot, but we do need to get to a much, much bigger scale than we're at now.

---

Introduction

Welcome to Tecnología Informal. Today, we have another guest in English. Usually, I do a lot of these interviews in Spanish, but I'm getting lots of founders and technical people on the podcast so we can have some conversations about the state of the art in the industry.

Actually, I think this is a very special episode—just like the one before I had with Dax Raad about SST—because I'm talking to someone that builds a product I use. So I have lots of questions from the point of view of a user and as a product engineer.

Today, we have Max Brunsfeld. He's one of the co-founders of Zed. He's also, I don't know if he counts as a co-founder of Atom, but he was a main contributor—original maker of Atom, part of the Atom core team, though not quite a founder on that one.

We're going to be talking about editors, about his time at GitHub (where he built and worked on Atom and Tree-sitter), and about what's happening in the editor wars and Zed.

So, Max, I'll pass the mic to you for a self-introduction.

---

Max Brunsfeld: Background and Early Career

Yeah, thanks for having me on. I'm Max. I've kind of ended up working on developer tools for most of my programming career. After getting started working on other kinds of startups at Pivotal Labs, like Gabriel mentioned, I formed a lot of my experience as a software engineer through pair programming. I came to believe that that sort of apprentice-style learning is really important for developing skill in programming.

Since then, I've worked at GitHub, spent a lot of time working on parsing technology—like Gabriel mentioned, Tree-sitter is a project of mine. Then, about four years back, my two Atom teammates, Nathan and Antonio, let me know they were starting a startup. I joined them, very excited to work with them again, and we've been working on Zed ever since.

---

On Developer Tools and Pair Programming

Gabriel: Did you always want to work on developer tools? How did you start your career working at different startups and end up in this particular niche?

Max: I don't think I intended that. I came out of college as a physics major, thought I was going to get into the hard sciences. But I met Nathan (the founder and CEO of Zed) early on, just as I was about to graduate. He was a programmer and showed me how fun and cool of a job that was.

Early on, when I learned programming, I always had fun with the tools. At the time, it was Vim—I was configuring Vim, doing everything I could to make myself productive. I always connected to that part.

At Pivotal, there was this programming scene—lots of new programmers would come in, and you got to pair with really good people. You'd sit at the computer with them all day, showing your techniques, like, "Hey, look what I just learned how to do in Vim," whether it was refactoring a test or using a few keystrokes to get something done fast.

---

The Shift to Remote and the Lost Art of Pair Programming

A recurring theme I have when I interview people or talk to my community is that in the last five years, as the world went remote—crazy remote with the pandemic—a lot of the organic pair programming sessions disappeared. What was very organic, like seeing someone work and having a little exchange, is now mostly gone. The only time you'll see how someone uses an editor is in an interview process, and they're not using bindings, just their very vanilla setups. I think it's a bit of a lost art, and there's some real damage in the industry because of this.

Max: That's very true. It was a fun part of my job—the tooling aspect and the oral knowledge transfer of coding with people. We've brought that back in a way that works for us at Zed, which we could get into later. But it was a very fun part of being at an in-person job—all the learning that takes place when you're literally watching someone code.

When you're in person, you might end up coding with people and not even call it "pair programming." That can be a polarizing word—people say, "No, I don't pair program," but you might still walk over to someone's desk and code with them for a bit if you have questions. Even though I don't think pair programming with a capital P and all its methodology is for everybody, just being able to talk through a problem with someone in a lightweight way is for everybody. There's so much you can learn that way.

I'm from the time where if you left your computer unattended, someone would install a prank extension on your computer. You had to watch out.

---

Pivotal Labs and the Culture of Agile

Most people in my audience are younger and might not even know what Pivotal Labs was. I barely remember—it was a very influential company around agile programming. Pair programming was a big thing there. I remember they were thought leaders about DDD, test-driven development, and Pivotal Tracker. I used it—it was like Trello, right? Kanban board.

Max: Yeah, its innovation was that it had this estimation thing—you'd do planning poker by putting points on stories. We have a lot to answer for from that era.

Gabriel: When you worked at Pivotal, was it in Portland? Was there an office there?

Max: I was in San Francisco at that time. I lived in Oakland but commuted to San Francisco every day, to their main office. For people not familiar, they had this methodology that ran the company—everyone showed up at 9:05, breakfast was served to encourage you to be there on time, and right after breakfast, you'd pair up for the day and rotate every day. It was very rigidly attached to agile methodology.

We didn't take all of that practice wholesale at our own company, but there were definitely things about it that worked so well that we did keep. Pivotal had a strong ability to hire young, smart people with potential and no experience, put them on a team, and pretty soon they'd be leading projects because they ramped up so fast with the pairing. TDD enforced discipline, so you could move fast with confidence—every change had tests and CI. It was a fun place to work for a while, until I didn't want to live in the Bay Area anymore.

---

Leaving the Bay Area and Moving to Portland

Gabriel: What didn't you like about the Bay Area?

Max: I love the Bay Area—I'm from there—but I wanted to live in a small town. I moved to a small town in the woods in Northern California. Even still, I prefer a smaller city, a place that's easier to live. For how much I love the Bay Area, I just don't want to be there all the time.

Gabriel: I left the Bay Area too. I considered moving to Portland when I was going to have a kid. San Francisco didn't seem like a nice place to raise a family, so I looked at different American cities—Seattle, then Portland. I'm from Buenos Aires, which is a metropolis, so for me, San Francisco is a small town, and then Portland is a really small town. But it's beautifully lush, green, all parks, trekking. I heard Pok Pok closed—is that true?

Max: Pok Pok closed, yeah. But the restaurant scene remains strong.

Gabriel: When you moved back to Portland, was that for GitHub?

Max: That was just because I wanted to be in a city, but one where I could bike across town—Portland's great for that. I liked the tall trees throughout the city. Part of the motivation for changing jobs to work at GitHub was wanting to leave the Bay Area, and GitHub was influential about being a remote company. Nathan had gone to work there, working on Atom, so I joined the Atom team. Moving to GitHub allowed me to live wherever I wanted, which was great.

---

Working on Atom and Open Source

Gabriel: When you moved into Atom, was that the first time you worked on an editor? It's a very different product than building web.

Max: Yeah, it was. At Pivotal, I worked on a lot of different projects—iOS apps, C# Windows apps, backend services—so I'd done other stuff besides web development, but definitely a lot of web. Atom was a very new thing—Electron was being created at the time, so that created this interesting Node.js application environment. It was a shift, and the fact that it was open source was a cool and fun change. The way you talked to customers was just on GitHub, like any open source project.

Gabriel: Tell me more about that. One of my biggest debts as a software engineer is not participating much in open source. I find it daunting—so many rules, so many new things. How did you live that transition? How would you recommend someone start contributing to Zed?

Max: There's a big mix of ways people contribute to Zed. Some have very specific domain knowledge—like how Zed should be packaged on some flavor of Linux, or how a certain language server should be invoked for PHP. They can come along and fix one little thing we don't have the depth to care about, and that's awesome.

Others go deep, diving into core parts of Zed—like how a certain part of the editor is rendered or how we scan the file system. Some contributors we've even hired as a result of their contributions. For example, right now my focus at Zed is porting it to Windows, and the port was started by someone from China who made big, deep contributions to the core of Zed.

So, when I say it's daunting, it is daunting. Meaningful contributions require you to really understand the architecture and way of working of the application. It takes time to understand an editor and have some domain knowledge to be effective.

Gabriel: But because Zed is written in Rust and packaged in a standard way, it's easier for people with Rust experience to jump in, right?

Max: Definitely. Rust has clear conventions, and we mostly abide by them. So people can come in, clone the repo, run cargo build, and it just works. The compiler is strict, and the language server is good, so people can get quick feedback. Atom, by contrast, was very nonstandard at the time—custom packaging, a mix of client-side JavaScript and Node.js. So even though we've reinvented the wheel a lot, it's all in standard Rust style, so people can apply their knowledge.

---

Atom as a Product and Its Business Rationale

Gabriel: I have questions about Atom as a product. Suppose GitHub says, "We should have an editor." It was never meant to be paid, so what was the product goal? Was it market share, more people using GitHub? How did you measure success?

Max: That's a great question. It was not easy to measure success. Fundamentally, Atom was not a business decision. One of the founders of GitHub, Chris Wanstroth, was an Emacs user and dreamed of a modern take on Emacs where JavaScript was the scripting language instead of Lisp. He started building it. The business justification was, if anything, after the fact. GitHub was making a lot of money from other reasons and poured money into different things. There was never a super clear story. Many people I talk to now don't even know Atom was associated with GitHub. There wasn't a strong brand tie. It had features that integrated with GitHub, but so did lots of other editors. Atom was important for its own sake—to build something cool—not to funnel users into GitHub.com.

Gabriel: I wish my business was successful enough to have those kinds of projects! You were there when GitHub got bought by Microsoft, right? At some point, there was Atom and VS Code, which is a commercial project. How did that play out?

Max: The Atom team basically got disbanded, gradually. Nathan and Antonio got moved onto something else—they had been working on CRDT technology for real-time collaboration in Atom, which got redirected to be more about Codespaces and less about Atom. I got moved to other code parsing stuff at GitHub. It made sense—VS Code had come out after Atom but was better at that point. People had spent years making the editor widget good, so they were able to pass Atom in most ways. It made sense to kill Atom, basically.

---

Editor Journeys and Market Dynamics

Gabriel: I'll tell you my story with editors. I started coding in Java, so my first editor was Eclipse, maybe JetBrains. Then I went to a terminal editor—finally, no slow code editor, just Vim bindings. Then I went to San Francisco and everyone was using Sublime. You end up using the tools everyone at the company uses because of shared configurations. Sublime was decent—light and fast.

When I joined Robinhood in 2020, everyone was using VS Code. It was the thing you had to use, otherwise nothing would work. But I remember thinking it was really slow—laggy. That's how I ended up using Zed. You guys released it, it was Rust-based, the new trend, and it was fast. I tried it, saw the response rate, and that was it.

But as a product, I know why I use Zed—I'm a two-person company, my developer can do whatever he wants, and I barely write code now. But how do you see placing an editor in the market when decisions are so top-down in organizations?

Max: I see what you're saying about wanting to use the same editor, but I don't think decisions are very top-down. They're still mostly bottom-up at a lot of companies. From our experience, we have shared Slack channels with people at different companies—there's usually an early adopter who loves trying new tools, tries Zed, tells coworkers, and we try to have tight feedback loops to address their pain points. It's more "land and expand"—solve the pain of a group so there can be a team at the company using Zed.

We'd love for there to be teams at companies using Zed, especially because we have this Zed collaboration system, which is still nascent but is a small piece of where we want to go with collaboration. To find utility in that, you need teammates using Zed.

---

Live Collaboration and the Vision for Zed

Gabriel: I'm going to make a terrible confession: because I'm the only one using Zed in my company of three people, I haven't even tested the live collaboration tools. But what's the vision here? It's a main part of your pitch or branding—this is baked in. What's the vision?

Max: Starting from where we are today, we rely on it a lot as a company. When I come in to work in the morning and open Zed, we have the Zed collaboration panel where you can see your company, set up channels (like Slack channels, but Zed channels). They're places to collaborate, with a markdown document that's cloud-hosted and collaboratively editable, kind of like a wiki.

You can see collaboration sessions going on—like seeing a Slack huddle, but it's a coding session. I can see who's coding together on what topic and join them by clicking. There's less coordination needed to get into a live collaboration session.

Once you join, you can share your project. For those who haven't used a tool like this, you have a Zed window representing the other person's project, and you can still use the language server, set breakpoints, debug, and interact with code as normal, but it's all over the internet, interacting with files on their machine. Edits are synced in real time using CRDTs—data structures that let you have eventually consistent documents, like Google Docs.

This is already key to how we run our company. Coming from Pivotal Labs, we want a culture of generalists who switch projects and ramp up quickly, and pair programming or real-time collaboration is really helpful for that. We hire a lot of people who are young in their career, and they become effective contributors.

But where we want to go is not just about real-time collaboration. It's also about things you'd use GitHub pull requests for—working at different times, collaborating asynchronously. Rather than going to the browser to leave comments and then going back to the IDE to fix them, we want that flow to be all in Zed. You'd leave comments on the code as metadata, and others could respond in Zed while interacting with your branch.

Gabriel: What I think would be powerful is if you could just keep the review cycle entirely in Zed—someone has a branch, you say, "Hey, this should be written this other way," and instead of talking about it, you just put another commit on top. The other person can see the review history and why the change was made. It's clunky to go to another UI to see comments, then go to the IDE to change it. This is persuasive—there's something here.

Max: Exactly. And even beyond clunkiness, if you want to learn from that discussion after the fact, the flow is usually: run git blame, get a SHA, find the PR, and then find the corresponding place in the code. We envision those comments stored in our own data store, tied to the code, so you can find them from the code later without jumping through hoops. We'd still use Git, but we'd have our own version control system of sorts built into the editor that captures this collaboration data, distributed like Git, rather than just in GitHub's database.

---

Supporting More Use Cases and Language Preferences

Gabriel: You mentioned you talk to teams, ask about their pain points, and try to solve them for more adoption. What's a typical pain point on an editor like Zed?

Max: One we made a lot of progress on recently is Python monorepos. People have multiple Python apps in a repo, each with its own virtual environment. The tooling needs to do special things for that—detecting and configuring which virtual environment to use, spawning language servers per environment. That's not something we hit in our own dogfooding; it came from users at different companies. So we spun up a group to focus on that.

Gabriel: So it's about supporting more use cases—main features are clear, but to get more users, you need more support for weird use cases. You must be a master of multiple languages. Do you have a ranking of top and worst languages?

Max: I've used a lot of languages. My favorite is Rust, even though it's not perfect. The biggest pain point is compile times—seriously, compile times, compile times, and compile times. The iterative flow of changing a file and rerunning is slow compared to Go, but everything else about Rust I love. It helps us move fast and accept contributions with confidence because the compiler checks so much.

C# is also pretty cool—I didn't code in it a ton, but it was my first statically typed language with good IDE support. Java seems cool too, though I haven't really used it.

Gabriel: And the bad ones?

Max: Don't love Ruby, don't love Python. I did a lot of Ruby at Pivotal Labs—Rails is still a cool accomplishment, but it taught me a lot of wrong lessons. In the Rails world, it was cool to abstract everything as much as possible, do metaprogramming to make everything a one-liner. Now I think that's a waste of time. It wasn't baked into the language, just the style of the community.

---

Tree-sitter and Language Parsing

Gabriel: I don't think my audience knows about Tree-sitter. Max built a parser for code—when you want to do analysis like search, syntax highlighting, or code folding, you build an abstract syntax tree. Tree-sitter parses the entire thing and, when you make changes, knows which part of the tree to recalculate, so it's efficient and works across multiple languages.

GitHub uses Ruby, and I can't imagine building an AST with metaprogramming. Does it work?

Max: You can parse Ruby with Tree-sitter. When we were getting the Ruby parser to work, I learned a lot about the weird rules. There are ways I would code in Ruby where I couldn't even explain technically what was going on. Writing a parser is a fun way to learn the whole thing.

---

AI, Language Popularity, and the Future

Gabriel: Dax Raad mentions on Twitter that with AI, the more training and solutions you have on the internet for a language, the better AI solutions you get. So TypeScript is popular, and it's going to accelerate. Do you think in 10 years, 95% of people will be doing TypeScript and the rest specific solutions?

Max: I don't think so. It's true that LLMs are really good at TypeScript and Python because there's a lot of solved problems in those languages. But as LLMs move beyond pre-training and into reinforcement learning, I think languages with more types and compiler checks will catch up in terms of how well LLMs can work with them.

My experience coding in Rust in the Zed codebase with LLMs has been underwhelming compared to building a React app, but the new models are getting better at dealing with novel code. It's not just about language, but also about the problem you're solving. LLMs are good at generalizing, and as they're trained with RL on coding, other languages will catch up.

Gabriel: You're a big language types guy. I went from Java to Ruby and was happy, but types have won. Maybe in 10 years, when LLMs write all the code, we won't need types anymore.

Max: I think LLMs are going to like types too. I started out coding in Ruby and JavaScript, but I wouldn't go back. I really like being able to command-click, go to definitions, etc.

---

Choosing a Stack: Rust, Electron, and Performance

Gabriel: When Zed was announced, Rust was hitting a popularity peak. All the Electron apps had similar issues—Atom was kind of slow, and lots of Electron apps suck (WhatsApp, Spotify, Slack). Then Linear came out—wonderful experience, and it's an Electron app. What's going on? What do you think about all this?

Max: It's not impossible to make Electron apps fast—JavaScript is fast, V8 is impressive. But if performance is a big priority, it's not the most straightforward path. On Atom, after the beta, we realized performance was a big problem and focused on it for years. We dropped components to C++ to use threads, but then you have to bridge with JavaScript, which is tough. Maybe Linear isn't doing a ton of expensive computations on the client. Superhuman is another fast JavaScript app. It's doable, but if you're doing a lot of computation in the app, it's tough to go the distance with Electron.

Gabriel: Do you think you're a pioneer of a trend of more applications moving into Rust or C++ client applications again?

Max: I wouldn't say we pioneered it—others were writing things in Rust—but it's still not super common. We had to build our own UI framework and a lot of stuff ourselves. I think it'll become more popular because Rust is a nice way to develop an app.

Gabriel: At OpenSea, we had to decide the stack for a microservice—do we favor performance or talent availability? It's a huge issue to choose Rust; you need people who know or want to work on Rust. TypeScript works for everyone. We also had a microservice in Go, and it just worked perfectly from the get-go. You can make TypeScript fast, but it makes you work for it.

Max: Hiring is definitely affected by looking for Rust engineers, but because we hire people all over the world, it's not a problem. Lots of passionate, young programmers like Rust and are interested in jobs using it. It's been a win for us—it's a filter and a draw for the type of people we're looking for.

Gabriel: Rust has a language market fit with dev tooling. Every company with internal dev tooling has a Rust developer working on it.

Max: I think that's right.

---

The New Editor Wars and AI

Gabriel: If someone had asked me three years ago if there would be another huge editor war, I would have said no. But here we are—VS Code with extensions like Cursor, Windsurf, etc. I'm surprised an extension of VS Code could be so successful. AI is changing how developers work. What's your vision on how editors are competing for attention right now?

Max: AI is definitely the main reason people are trying new tools—there are all these AI-driven innovations in how to write code. The role of the editor is changing. People are doing less typing and more looking at generated code, making small changes, and prompting models to make further changes.

I'm not worried about the IDE or editor losing importance altogether. I still think code is something humans deal with. I don't think it would be good for LLMs to abstract over code completely, with humans only interacting via prompts. There's a need to go from a non-deterministic system to a deterministic one and deploy that.

I think AI might prompt us to create different programming languages, since humans can only review so much code, and LLMs can generate thousands of lines quickly. But I still think you'll interact with code, and tools like jump to definition, parsing, syntax highlighting, and collaboration will remain important.

The workflow will change, and we don't know what it'll be yet. We're trying to stay up with the latest ways of coding. For a while, we were catching up in the AI space, since we didn't start as an AI coding company. But now, AI is always going to be a major part of what Zed does.

What's cool is that the Editor Wars now have a new component: what is the UX that's important? We're not just competing on the same features, but on new paradigms. Cursor pioneered edit prediction—tab, tab, tab to write code. Maybe there will be further changes we can pioneer. The Editor Wars are more dynamic now than 10 years ago.

Gabriel: Why do you think VS Code fell so behind? Microsoft made Copilot and then disappeared.

Max: I wouldn't count them out. None of the features of Cursor or VS Code forks are hard to replicate, and Microsoft has infinite resources. I think they're still in the mix. Maybe they were slow to embrace new UX paradigms, but I don't know why.

---

The Economics of Editors and AI

Gabriel: The economics of running an editor always seemed rough—developers are price sensitive, editors are open source, and people don't assign a high price unless the company pays. But AI broke price sensitivity. Now people spend $1,000 in tokens. The price economics are completely whack, and editors are bundled with AI.

Max: It's interesting—people are finding a lot of value in AI coding and are willing to pay for it, or their company is. Maybe the habit of not spending money on editors has been broken. Companies already spend a lot on adjacent tools like GitHub Enterprise. It's not unusual to spend a decent amount per month per seat on something that facilitates developer collaboration. That's the space we want to be in.

I want Zed to be something a solo dev or new grad can use for free, but we can make money by offering business features to companies—facilitating team collaboration. Now we also have a side business of reselling LLM compute. We let you use your own Anthropic account, but many users prefer to have it integrated with the editor. So that's a business we're in, though it wasn't how we envisioned making money when we started.

Gabriel: I worked in finance—have you heard of "PFOF" (payment for order flow)? It's like reselling tokens—guessing which LLM is cheapest for a query, routing it, and splitting the price improvement. Editors might make more money with that mechanism, since companies are willing to spend uncapped amounts on infrastructure, and now LLMs work that way. Some people will spend thousands when they spent nothing before.

When you look at statistics of people using Zed, how many use AI, and how much of their code is written with AI?

Max: I don't have exact numbers, but the number of people who use AI through us is a small fraction of Zed users. But people are spending a fair amount on tokens. We recently had to change our pricing—no more fixed subscription rate, because we were losing money. People would pay $20/month, but the average usage was well above that, closer to $50.

I don't think it'll be common to have uncapped spending—big companies will want a cap. But you can get a lot of value at a reasonable level, maybe a couple hundred a month. There are a lot of power LLM users in that camp.

Gabriel: I saw a tweet by Jared from Bun—he spends $4,000/month on Claude. That's crazy.

Max: We have a leaderboard in our company for who spends the most. A couple people are really good at it. As a founder, that's a poor incentive design!

---

The Future of Zed and Editor Market Share

Gabriel: What's your vision for five years from now? If you get Zed product-wise where you want it—live collaboration working well, AI agent always there—when do you get to win? When do you get to say, "I'm the editor most people choose"? Do you have an idea of where you are now and where you need to be?

Max: We're not where we need to be yet. We're in the conversation now—on Stack Overflow surveys, we're not "other," we're Zed. There are teams at big companies using Zed, but the team thing is important. We need to get to a big enough mass that team-based features are useful.

We don't need to win 100% of the market. There are so many programmers in the world, such a diverse market of people who work differently, that we can be very successful while being below 50% of developers. But we do need to get to a much bigger scale than we're at now.

Gabriel: I ran a poll in my community today—about 20% use Zed. You're not in the "other" section, so that's good.

One last question: I understand you need to build a network effect with live collaboration, but I don't understand why Cursor achieved network effect dynamics without a network effect feature. It just became the de facto tool to test. What made the adoption so quick?

Max: To give them credit, they did a really good job. As soon as LLMs got powerful enough, they found a UX that made sense—tab completion, good prompting tools, adding context to the prompt. It wasn't rocket science, but they came up with good solutions. Now, a lot of things have copied that, including us. The latest innovations haven't come from Cursor—agents and such are coming from terminal tools and elsewhere. But at the time, they were leading UX innovators.

Because their appeal isn't network-based, it's very individual. The space isn't so dominated by Cursor now. There are other strategies, like Dax Raad with open code, building new interfaces and ways to work.

Gabriel: To be honest, I'll never choose VS Code over Zed simply because it's not snappy. I can't go back to JIRA either—I have to use Linear now. I hope you are the last mover and win the market over time because you have a better fundamental product.

Max: We need to keep making it faster and keep it fast as we add more features.

Gabriel: Thanks for being here and for the interview. Your experience and background, working on a product that's one of the best out there—if I talk about the top 10 products a software developer should be thinking about, Zed is definitely one of them.

Max: That's awesome to hear. Thanks for having me on. It was a really fun conversation.

---

Final Promo

Muchas empresas pierden semanas entrevistando a cientos de candidatos que no van a pasar la vara técnica que tienen. Para eso estamos nosotros. Nosotros te vamos a buscar los perfiles y te vamos a presentar solo lo que tiene mucha calidad y no perder el tiempo de tus programadores. Si tu empresa está contratando, o si vos estás buscando talento para tu empresa, no dudes en visitar silver.dev y pedir un quote.

---