Friends Don’t Let Friends Agent Alone

All right, so we're good then. If you haven't heard of us, we build a code editor similar to Sublime or VS Code or JetBrains or choose whichever one you like. We hope that you're where your last next editor. So if you try us and you stick with us. And we care a lot about collaboration, both with humans and now with AI.

So we have ways to run agents and share your projects with your teammates, interact with the code like it's on your own machine. And there, what I do, I'm a Rust engineer. I ship lots of code. I'm also an engineering manager and I'm also a project lead for our agent's team. I wear a lot of hats.

And as mentioned, I'm also a lead maintainer for the agent client protocol, which is the ability to embed too many agents to count at this point into your products, like coding editors like Zed. So you can bring your own harness. You can use our agent or you can bring your own harness or someone else's harness and use it. Needless to say, I have some thoughts about how we should be using agents because I spend a lot of time thinking about them.

And a common refrain I hear is like, everything has changed. And I think like sometimes we feel that way, right? Everything has changed. And if you look, like in the last couple of years, we went from like, I don't know, just writing code by hand for those of us who remember. And like, maybe you got something from your LSP. That was cool. And like tab, tab, tabs, we had like chats, then agents. And now we're like, I don't know. You got your open claw texting your friends and emailing for you. And there's just agents running everywhere and who knows what's next.

So obviously a lot has changed in a very short amount of time. But I also want to say I think nothing has changed. I've heard this a few times today. And what do I mean by this? I think everything about how we do our day to day work, what we may be identified ourselves as, as engineers in terms of what I do and in my day to day tasks. Yes, a lot has changed. But I also think in the same amount of time, nothing fundamentally has changed about us as humans. I think we have we are very adaptable creatures. So we've adapted to a lot of externalities that are changing around us. But I think like we are fundamentally still the same humans who have some of the same struggles that are maybe amplified or we feel differently. But I think if we look back, I think we've actually struggled with some of these things in our teams even before AI coding agents came on board.

I think one is that's very obvious. Now it's like cognitive load, right? Just like these models, our brains have this like finite context window. We can only like keep so much in our heads at once. And I think that like with we always felt this, like we want to do so many things. There's so many things we want to do and we like try and multitask. But there's like limits to what we can maintain and keep track and keep focused on. And I think now that we have these agents, now I can finally burn through my entire backlog. And I'm going to like spawn a hundred agents and I'll get all these tickets done. And you can try. But I think ultimately, in reality, you don't always finish everything well, if you try and do a hundred things at once. Because I don't know about you, but when I try to do this, I come back and I find like this diff from an agent and I'm like, oh, what was happening here? What what what was this trying to solve? Is this diff any good? I don't know.

I'm going to jump back to this other thread and then again and again and again. And then like maybe you got a good demo on demo day at your with your team and you got, you know, claps for, oh, that was really cool. But I can never actually made it to your users. Right. And you didn't finish it. And so I think that we feel this more acutely now that we have all these tokens to spend.

And I think as we think about this, like, yeah, making code cheap to generate doesn't make understanding cheap to skip. Like our job is actually to comprehend the work that we're doing. And I think in order to do that, we need to be able to focus and use what limited cognitive load we have to get a task done. And then the team topologies book, they pull in some other research on different types of cognitive load. And there's one of them is the intrinsic. So like fundamental to the problem space. So how do I create a new method? Like if we want to do our job, we need to know how to like how does my language work. Right. So you need this to get your task done. Good thing is AI is good at this. Right. So we can get some help here. This is an area of cognitive load we want to lessen.

And we have the extraneous, like, how do I get my tasks done? Like, how do I deploy it? What config do I need to change? Again, maybe AI or just normal automation we've been doing for years can also help this. So I don't have to think about it. And what are we trying to optimize? We're trying to think more about this germane cognitive load. Or like in Brooks' like, no silver bullet paper. Like there's this accidental complexity, which are the other two in the essential complexity. What's the thing you're actually trying to accomplish? And and this is what we need. We need this germane cognitive load focused on something so that we can actually learn so that we can think about how does service A work with service B.

Like if we think like everyone's like trying to do more and more agents, right? And we want to orchestrate them. Like, well, if you're lovely, if you're moving yourself up, you need to think about these problems. And do you actually think you can solve 100 of these problems at once? Like, probably not. So you need the focus. You need to be able to learn what the problems are trying to solve. And I think at least for me, like the thing that I'm trying to figure out when I'm using these agents is how can I still have focus and engagement? How can I still get into that flow state I used to get into when I would have those late-night coding sessions?

Even when I'm not writing the code, how can the next day can I be in the shower and have understood the problem so much, even if I didn't write thousands of lines of code to have a thought of like, ah, we need to change this. And I think if I'm jumping between 20 different chats at once, solving 20 different problems, I at least have a very hard time doing this. And so I think we need to think about how can we be creating this focus for ourselves and in our teams? Because I think this is what our job has always been. Right. As we build, we learn the problem that we're trying to solve. And I think there's always been something very tactile, so very tangible as we write the code.

Right. We experience this. But now we have to adapt. Right. There's a new way of this. And how do we still learn? How do we still grow and not just click merge at whatever it gives us? I think another struggle we've had is alignment. We might be this has been in several talks today, right? Like we might be making individuals faster, but if the company itself is not actually aligned, then like you're not actually going to move any faster. You're going to have people hitting these bottlenecks faster because they're waiting on some decision, some approval, whatever.

And I think a lot of this is like if AI, if the tokens are pulling lots of people in different directions, you're not actually moving forward. So how can you align the company? So everyone is like focusing all of this AI token spend in a direction that actually moves the needle. Because I think AI is a multiplier of both the good and bad parts of our teams. I think that if someone is really good at building a product, I guess it's going to make them faster. But if your team isn't able to be aligned or isn't able to figure out what we should build, right, then you might be building the wrong things faster. You might be generating a 10 year old legacy code base in 10 weeks. Right. Like we may just be creating a huge mess that no one understands.

And I think this has also been mentioned multiple times today, which is that the bottleneck was never writing the code. If I look back at my career, most of my job as a software engineer was actually trying to figure out what code we should write, going around, figuring out what does this business want to do, what are the objectives we're trying to achieve. And then I want to codify that into like lines of code that actually carry out like the code is like the ultimate spec, right. It's it's got lines of code to express the state what's going to happen. And but figuring out what those things are. That was like always our job.

And I think this was always the case and we just feel it more now because now we're not actually writing the code. We can get it in 30 seconds. But like, is it right? That's where we have to like figure out how to align as a company. And the other struggle, I think we've always hit right as silos, this bus factor thing. Like, ah, this person always does a database. It'll be faster if we just give them the same ticket, they'll get done faster. I would need to like load up all this context to figure out how to solve it. But then on vacation for a week, well, I guess we can't touch that for a week. Now, if you give like entire portions of your business to one engineer and there are hundreds of agents and then they want to take a vacation for a week, have you just created like the biggest silo of all?

And you don't have that on your computer. So are we just creating more and more silos? And again, I think like having the ability to have a single person do more, I think this is great, but it can also be more painful because you have that single person is now also in their own way a bottleneck. The good news is, like I said, I think we've actually been struggling with these problems for a while and some really smart people, much smarter than me, have proposed solutions for them.

One is pair programming, which a few years ago, I didn't do at all. Not only in the last five years, I've adopted it. And now I kind of push it pretty hard on my teams because I think it provides certain benefits. And I think the biggest one is that you kind of get this alignment thing for free. Not entirely, but I think part of pair programming is having to explain your idea to another human. And the problem with agents can kind of work as a pair and I use them sometimes when I'm working by myself in this way.

They're very eager to please and they're not going to question you. They're going to say, ah, you're right. And then you'll point something out. You're right again. I think you can use skills and make it more confrontational. I don't know. But I think having to convince another person of your idea, it sharpens your own communication of it, makes you think about it and they get to provide some pushback. And I think through this, you can both explore an idea together and align on it. And I also think there's something to having another person working with you, whether remotely or literally, Adam's sitting next to you that provides this focus and accountability.

And I think through this, you can both explore an idea together and align on it. And I also think there's something to having another person working with you, whether remotely or literally, Adam's sitting next to you that provides this focus and accountability. I at least find I'm much less likely to go check Twitter or Slack or the CI job or whatever, go through all my tabs because there's someone else I'm working with. And it's not about someone watching me. I think it's just that we are now working on the goal together and I respect this person, they respect me and we're both bringing ourselves to the to the job. And I think this is helpful. Maybe I'm just really bad at multitasking and you all are like, this is not a problem for me, but at least for me, this helps me stay in the zone to really wrestle with the problem, to think about it and to get this learning and engagement that I want. And this has been true before and I found it to be still true with agents.

And I think what's important now is pairing was also helpful for knowledge sharing about different parts of the codebase. But now I also get to see how do you prompt your agent? What skills are you using? Whatever, we can all share these knowledge together. It's not like we're all working on our own ways of working this way. We're all learning, right? We're all learning. But I do think that pair programming, for those of you who've tried it, we have to adjust now that we aren't doing the typing. I think there's some things that worked well when one of us was typing. Right. There was like kind of a bottleneck there. That bottleneck's gone. So how do we do this? My colleague is here who I forced to do this with me. Hopefully he enjoys it. But anyway, I get like we'll kick off an agent overnight on like a big task or, you know, we'll sit down and kick off the agent together. What problem do we want to do? Write the prompt, kick it off. And then we sit in and go through the review together. And I can share my project and we can share the same diff and edit the diff together. And I found this to actually be like quite nice because then I'm interrogating this code with another person. We're asking different questions.

And then, you know, why is it like this? Well, let's ask the agent. So the agent is like running to like answer the question of why I did it this way. Well, we're talking more about what do we want? What problem are we solving? How do we want to do this? And I've also found that it makes sure I don't settle for fine, at least for me. Right. Sometimes I kick it off and compiles.

I really want to be done with this task. Yeah, I think it does it. It's good enough. Like let's merge. And I find that when I'm pairing to someone, one of us will then be like, hmm, I don't think that was like quite good enough. I think we could push it further. And you know what? It only takes a couple more minutes to ask the agent to change it. So it's not that much like big of a time difference. But there's something that I think we as humans engage with differently when we're with other humans that helps us actually achieve what we have as a team have decided we want to achieve.

And so I would encourage you all to take some time to review a PR. Don't just like throw your agent five coded thing to someone else in GitHub and wait for them to press the green button. Invite them to go through it together and talk through it. Maybe you can explain how you prompted the agent. Why it's this way. What questions did the agent ask you? And you can like talk through these trade-offs and decide. And guess what? The also really great thing about this code being really cheap to write is you can throw it away and just start again because like, but it takes another five minutes. Like, yeah.

So I think, like, engage with your teammates in this way. And I think this is, I think, like what helps at the team level. And then I think in order for this to be successful, what's the environment that the team is in? What's the environment of your company to make this successful? I've spent most of my career in small and medium company size companies. I think several of you are in much larger companies than mine. I would honestly like you could just read this book, read this book. It explains, I take a lot from this book, and they explain how to apply this, these sorts of principles at a much larger way. How to take domain driven design surprisingly works really well at an organization level. And there's tons of case studies in here from real companies that seems to work for them. I can't say, but I don't know. I trust them. And the book is really good. And mainly it's about identifying what each team does and actually reducing communication between those teams or at least identifying the types of communication that should happen between teams within your company. And, yeah, we all think collaboration is good.

I actually really value collaboration. But not all collaboration is good, because if everyone in your company has to collaborate to get anything done, that's not good. Right. And especially when there's so much happening. So I think that there's a lot to be still learned from this. So go read the book. It'll give you a lot of practical ways to organize your teams. But the whole point is, how do we optimize for fast flow of value? And I think we have to optimize for this now because the floodgates have been opened and it's like spilling out everywhere.

So how can we direct all of this energy and these tokens in a way that we can benefit from? And I think tucked away in the conclusion of this book is that they kind of explain, here's how you can organize your whole organization. But this isn't enough. None of these changes do anything unless you have a few prerequisites. One is a healthy organizational culture. Do you trust the engineers on your team? Do you give them autonomy to make decisions? Because if you really want people to move faster, I think that's actually the key. You trust them. And how can you engender that trust? That's what you're going to figure out with your organization. But if you trust and let them do something on their own and make decisions on their own and trust that they're going to do the right thing, then they can move. And then you can potentially correct afterwards.

How do you give them the information they need to understand the business direction to actually achieve that thing? But I think without this layer of trust and autonomy, no amount of tokens will speed up your business. I also think good engineering practices, this has been said multiple times today, are more important than ever. If you want to move fast, there's this slow is smooth, smooth is fast, right? You need to make sure that everything unblocks. If CI is stuck or whatever, make sure that CI is running smoothly, that deployments are running smoothly, that you have the tests you need to have trust in your system and also the metrics to make sure if something's gone wrong. If you have these in place, then you can also move much faster.

And I think this in some ways for me is the most important. Does everyone at your company understand the business vision? What is the mission of your company? And can they take ownership to carry it out? Because if we all want everyone to start acting like architects and engineering managers or CEOs of their own little systems within your company, they need to be crystal clear. On where that company is going to make sure that their decisions are moving in that direction. And I think that's on us as leaders to make sure that everyone is aligned in this direction.

Now, I'm talking to a bunch of tech leaders. So, of course, this has to be an answer, right? We have to build the tools. It'll solve all of our problems. But I actually think like we all feel this, right? Like there's a bunch of tools we've been using for decades that are just feeling like they can't bear the weight of all this, these changes in this code that's being written. And so this is something that we at ZED are very passionate about and we're actively working towards building. I know lots of you are also doing this. I think we need to all continue to build the tooling we need to operate in this new environment.

If anyone on your team wants, we have this new ZED for business thing so you guys can collaborate together using ZED. And we are also check our website later today. But we're working on something I think is going to be really cool around how we as teams can collaborate together with multiple agents and bring that conversation into the code base itself. So those learnings that you're having can be shared across your entire team. And this is something that we take very seriously as a team. And we want to offer to you too. Yeah, so tech leadership. That's what we do.

But I think in a lot of ways, we are ultimately people leaders. And as convenient as it would be if we could just optimize and we're all just these like rational brains on a stick all the time. We also need other things, right? And we need to care for the people that we work with. And there's more that motivates us than just a bunch of metrics or this or that.

I think like if you want people to move quickly and to care about your business, you need to give them autonomy, mastery, and purpose. And I think this is actually at least for me a challenge, because sometimes it's hard for me to not make an analogy of these coding agents with like a slot machine where there's like this phenomenon of like near misses. I got close enough if I just click it again, it'll work this time. Or, yeah, I'll just keep clicking this button and I get this dopamine rush. And it feels great. And I feel so productive.

But am I actually achieving it? And I think this is why I don't know if you felt it, but like sometimes I feel like I just need to unplug and take a break because it's so addictive to just keep. I feel like I should always be working. And then you get people now feeling like, am I an AI vampire? Do we all have AI psychosis? And I think we have to be attentive to this on our teams. What are we incentivizing? What are we pushing people towards? Because ultimately, if we all become burned out shells of ourselves, we're also not going to be very productive.

So I think we need to be thinking, is AI an instrument to unlock our potential? Are we letting ourselves become the instrument that just smashes the button until I get completely automated away? Because smashing the button can be automated. And I think in order to figure this out, I think we need to do this together. And I would encourage you all to take more time in your day-to-day work to work with the other humans that are with you as we all navigate what this new world means for us. Thank you.

Yes. So let's go for this one. That's a real concept. But reality for us says that time constraints are so hard that having two people instead of just one in CodeReview would be really nice. But just not possible when we have so much customer pressure. How to solve that? Yeah, this is actually the exact same thing said to me in a different form. By managers in the past, when I pushed for peer review on my team, couldn't we have two people typing code? Won't that be twice as fast? I actually think this is faster. I have found that going through a code review with people is faster than waiting for them to review and come back with questions and go through the cycle. So if you're optimizing for getting a PR actually reviewed and merged, I think this is actually a faster approach to do it synchronously. And I think because you're able to align faster and there's less fuzziness. So I would say give it a try. You're going to have people say, yeah, I've always had people say this, like it'll be faster to people typing. But like every time I've worked on that pair programming ship faster than the ones that didn't. So I don't know. That's all. It's anecdotal. But it's all I have to go off of.

Yes. And by the way, just to follow up on that and before I forgot to mention, one thing you mentioned in your session reminded me of what I heard just less than a week ago in San Francisco at Microsoft Build event. And the session by Scott Hanselman and Mark Krasinovich from Microsoft. So their whole session was dedicated to what do you do with junior developers? Because it's a real challenge, right? Companies, many of them just stop hiring junior developers. And what they suggested, these two very smart people who are my colleagues, they wrote actually a kind of white paper article about the concept. They think that they can solve that. And that's really basically what you just mentioned, when the special type of pair programming, we can call it like that. When senior developer and junior developer sit together and do not just code, but prompt agent and senior developer explains their own chain of thoughts, their intent, motivation, how they use this agent. So I think it's very close to what you just mentioned.

Totally. I mean, yeah, this is the, I find it to be the best way to onboard new people. Even if I've, I use Rust, I've used Rust for a while onboarding new people to the Rust language. Like what I used to do is just like, hey, you literally type F and space, like they don't know what this is, right? And you talk them through it. And then eventually, like within a couple of weeks, they're like, OK, write this method. They know what that means. Right? And so, yeah, I think this can translate to these new AI skills. Exactly. So instead of just giving simple, simple tasks like to implement this algorithm, to implement this, because these simple tasks can be handled by AI. Right. So it's not something that you want to send to your junior developer. Instead of that, you better see it and do this together and explain it.

And then they call this concept preceptorship. So I strongly recommend you to watch this session. It's available online now. But we, I think we have time for more questions and they are keep them coming. By the way, folks, this one just just got special attention. How to motivate team members to leave their little silos and start pair programming more. So going back to this topic again. Yeah. No, I mean, this is like Zed we've, we've always done pair programming. And I think we went through a phase actually, where like people have this binary thinking of like, well, I have the agent now. Like we don't want to watch the agent together. We can't pair program anymore. And it was that kind of a very binary decision. And this has been like as we've all adjusted, we're still figuring this out. But I think as leaders, if you want to try this, I think the best way to do this is to say that you want people to do this more. I don't think mandating it works. Right. But I think also engaging with your teammates and inviting them to a pair session with you.

I think people don't understand the benefit until they try it for themselves. And I think it's on us to lead that way. There are times where it's not the right tool, and I also don't pair program all the time. Sometimes I need time to make up my own mind about a problem to then bring to a teammate. Figuring out where this is helpful is crucial, but it's a useful tool to use part of the time. Inviting people to try pair programming can be the best way to advocate for its benefits.

Real-time pair programming may not always be feasible, especially in globally distributed teams. Exploring asynchronous pair programming with tools to track session intent could be an entrepreneurial idea. Synchronous pairing combined with tag teaming in distributed teams can ensure continuous focus on tasks despite time zone differences. This approach of a 24-hour cycle of collaboration can be highly effective in maintaining productivity and collaboration.

Super practical advice can be shared in a concise manner within limited time frames. Embracing different forms of collaboration, whether real-time or asynchronous, can enhance team dynamics and outcomes. Adapting to the challenges of global team structures by implementing various pairing strategies demonstrates flexibility and commitment to effective teamwork.

So what about kind of asynchronous pair programming? Because also I believe tooling is not quite good in that field. So maybe for people who have like entrepreneurship mindset, maybe some idea to check. Just for example, you go through this agent session of senior developer and you have a chance to somehow stop at this time point and ask your question. Hey, why did you went for this? And considering there is no like people who is able to answer, maybe AI can help tracking your session intent. Right? Yeah, I think I think I guess the answer are two things. Like there's ways we're exploring this at Zedd, but I think also like we're a globally distributed team. Not very many people live in the same place. So we do synchronous pairing, but we also do like tag teaming. We have people in lots of time zones. And so we will have people on a team and one person will finish. Maybe there's like an hour to overlap of a handoff, then they work, and then the next person comes online. And we kind of this 24 hour cycle going where we're kind of all still focused on the same task, but kind of working together. And I think this is also very effective.

Yeah, yeah. Super practical advice. And we have literally 10 seconds. So be very, very, very fast and concise. How do you increase the speed for the rest of the company? Like business decision and product owners translating desires to tickets? Yeah, I think this is our job as tech leaders to work with like to do stakeholder management. I think this can only come from the organization leadership itself. I think this has to be part of your culture, that you value this. You can push for it from your end. But I think there has to be like real change and real need that gets an uphill battle. I've done it in the past at other companies. It's not always fun, but I think it's ultimately the most effective way to unblock your team. So absolutely. Be inclusive. That's a very, very summary of it.

Thank you so much, Ben. Thank you. Huge round of applause to Ben.