Loading…

Multiplayer AI: Why your team (and its agents) need a group chat

Ryan chats with the GM of Slack, Rob Seaman, about how their new Code Channels feature is bringing multiplayer AI to your team chats.

The Stack Overflow Podcast cover art

SPONSORED BY SLACK BY SALESFORCE

In this episode, Ryan chats with the GM of Slack, Rob Seaman, about how their new Code Channels feature is bringing multiplayer AI to your team chats. They discuss how most interactions with coding agents become siloed context, why a party chat with devs and agents flattens writing code and code review into a single step, and why a Slack channel might be a better dev environment than a terminal.

Episode notes:

Check out the article Rob mentioned: Learning on the shop floor.

If you want to code multiplayer, check out Code Channels.

Connect with Rob by email at rseaman@slack-corp.com, on LinkedIn, or Twitter.

Congrats to Populist badge winner petro.sidlovskyy for dropping a great answer on What's the best way to ensure a base class's static constructor is called?.

TRANSCRIPT

[intro music]

Ryan Donovan

Hello, everyone, and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I'm your host, Ryan Donovan, and today we have a special episode sponsored by the fine folks at Slack, talking about multiplayer AI coding and how they are enabling changes in the SDLC to support that. My guest for that is the GM over at Slack, Rob Seaman. Welcome to the show, Rob.

Rob Seaman

How are you, Ryan? Thank you for having me, and happy to be here.

RD

That's my pleasure. So before we get into the topic today, can you give us a little, you know, quick flyover of how you got into software and technology?

RS

It's been a long time. I feel like I'm officially getting old at this point. I actually started in technology during the dot-com boom, for those of us that were around then in the late 90s, when everybody was moving everything online, I actually started as a post-sales consultant at a software company called Siebel, and I was doing implementations and honestly did kind of a hack around the product, and the product team asked me to come be a product manager and make it a feature, and I was like at the time, and it was just one of those lucky moments in my career. The person that asked me is now the CEO of GameSight. His name is Chuck Ganapathy, and he's still a mentor to this day. So anyway, I got lucky, got asked to join product, and basically stumbled into the career I've loved and industry that I've loved, and that's kind of defined my entire career.

RD

Nice. So today we're talking about multiplayer AI, something I've sort of heard recently tossed back and forth. What does that mean, and why should developers care about it?

RS

Yeah, you are hearing about it in multiple places, like I think one of the seminal pieces actually written on it was written by Toby Lookit, the CEO of Shopify. For the listeners out there, go check out his piece called Learning on the Shop Floor that he published on Twitter. I think it's amazing, and it talks about all the benefits of multiplayer. But I think we have an interesting role to play in that at Slack. But the benefits of multiplayer to me are, let me maybe define it first, and then talk a bit about the benefits. If you look at most of the AI tools that are out there today, they're largely single player, meaning a single human sitting in a terminal or a SaaS chat interface, prompting an agent on their own. I mean, there's a ton of benefit for that. We've all realized individual productivity gains in our personal lives and our professional lives. But the downside risk of that in a corporate scenario is that the AI learns, and the individual learns, but the individual's peers and the rest of the company doesn't learn from the experience that person is having with the AI. And I think there's a ton of exhaust from those interactions that can become knowledge artifacts and basically make entire teams and companies operate much faster. And to me, multiplayer AI is taking it out of that individual terminal or that SaaS chat window and putting it into a multiplayer space like a channel in Slack where people can work with the AI together and see what each other are doing and learn from each other's past experiences with the AI. So I think the most powerful thing about multiplayer AI is actually the exhaust of the interaction becoming a knowledge artifact for the rest of the company and effectively disseminating everything that's happening with the AI within a company just like that overnight.

RD

Yeah. I mean, engineering has always had a sort of a paradigm of pair programming, right? As a way to educate and collaborate. Are we talking to something like that with like a couple of folks on the channel with like, you know, a AI agent as a backpack or how multiplayer are we getting here?

RS

Yeah. I mean, it can be, you know, theoretically infinite people in a channel doing it, but it's typically a handful. You know, the way that we're doing it at Slack right now is we'll pull our coding agent into what we call code channels, the new product that we've launched. And it could be a couple of engineers, like in many cases, like I start something or a product manager or a designer starts something, we'll get to the point that we have a PR and then we'll pull in an engineer and be like, okay, we're not computer scientists, right? Obviously, like you should take a look at it if you think. I think over time, it's going to improve the overall quality of services and reduce duplication. We can frankly search and see much more of the coding that's happening across the company at this point. We're addressing issues that previously would have gone on to backlogs and not actually gotten addressed. And frankly, we're expanding the pool of builders by giving it to people that don't typically, you know, live in GitHub and an IDE.

RD

Right. So you can have somebody, you know, vibe coding a little script or tool for, you know, finance or marketing or something, and then call in an engineer once in a while to be like, hey, tap the brakes, you guys, right? Exactly.

RS

And we also do it with our own product. Like yesterday, I was, I pasted a URL into the composer in Slack and I went to put my cursor before the URL that I pasted and when I started typing, it was actually, it wasn't that the cursor wasn't at the beginning of the line, it was actually between the hyperlink icon and the URL itself. And so I just took a little video of it and mentioned our coding agent and said, hey, this is, this is, you know, a little whack. We should fix this. And it spun up a code channel and then I pulled in Chris Sullivan, one of our engineers, and he's like, oh, that is broken and that actually is a pretty good fix. So we should just go ahead and ship it, you know? So it's not just tools or net new applications, it can actually be your core service as well.

RD

Yeah. I mean, you talked about the terminal, terminals and chatbots are sort of the way that folks have been interacting with AI agents. Is this sort of like everybody interacting with a single AI agent or is there a buffer to sort of prevent everybody from like yammering at the agent at once?

RS

That's a little agent dependent. That's one of the things we've worked with the partners on. So when we launched Slack code, which includes code channels and session artifacts, we did it with OpenAI, Anthropic, Cognition, Vercel and GitHub and a few others that are coming along.

But a big part of that, that we worked on with them is making sure that the user experience of the agents isn't one too chatty and doesn't require a user to @ mention an agent every single time. And there's a delicate balance there. Like you don't want a user to have to think and @ mention the agent every single time, but you also don't want the agent ambiently listening and just responding to every single thing like that can be.

RD

Just burning tokens all day, right?

RS

Exactly. Burning tokens, being expensive and being annoying. And so I think they're getting a lot better at classifying the text that's coming through and figuring out if an LLM is even needed to go pursue some of these things. So it depends on the agent that you're using. Some handle situations differently, but we've got multiple with ours. We've got multiple people prompting it at the same time and it's quite powerful.

RD

Hmm. So can you give a little insight into like how it was used? I assume like you were testing the heck out of this dogfooding. So can you give a little insight into your own experiences with it?

RS

Yeah. I mean, a lot of, we talked about one of the things that we worked on during dogfooding just now. We have our own, so internally we have access to a number of coding agents. And so we put a wrapper around and built a custom Slack app that allowed us to basically emulate working with or hand off to multiple agents so we could test that. And then we gave it to our partners as well. And so we've been, honestly, it's been really, really quick how it came together and it's inspired by what we saw some of the frontier labs doing in Slack and some of the developers of the coding agents do. So we've been using it for a few months. We expanded it out to the partners over the course of the last month or so and it's just really kind of taken off. It's changed. It's funny. We were doing the press launch for this yesterday and Malte, the CTO for Purcell, who's just an amazing partner, congrats on their latest funding round, but said that 100% of the production software that he's writing, he's actually writing through Slack now. He still goes and does a lot of experimental stuff through the V0 agent in a terminal, but the majority of the production software he's writing is through the Purcell agent in Slack. You also heard Boris at Anthropic say a similar thing where, 65-70% of their code is actually getting written through Slack now with Claude.

RD

Yeah.

RS

It's been, it's almost in product, we would call these things desired paths, you know, there was a usage pattern that we saw happening amongst the frontier labs and the AI native companies that we've effectively productized and made, I think, more facile.

RD

Yeah. You talked about sort of spinning up these code channels and treating them, I assume a little bit more disposable. Do you have like recommended behaviors? Like do you spin up a code channel for a feature? Do you, you know, do it for a single bit of programming and then kill it? Or what's, what's the patterns you've seen?

RS

It's more of the latter So I think a feature is, is candidly too coarse grained. I think it's, it's more like at a, at a session level or, or an individual PR level that we're, I mean, you could have multiple PRs, but it's more like that, that, that session or a PR or a couple PR level than it is an entire feature. And they are ephemeral. And so they, that's one of the things that we worked on with code channels. It's a new channel type and we did this particularly so we didn't clutter up your sidebar, but also encouraged you to use it as much as makes sense for you. And so you'll see they actually show up in a new section in your sidebar on the left in Slack. And as soon as they're done and you spend down the infrastructure, it effectively archives the channel, leaves your sidebar, but it's still a searchable asset. So all of the content that happened in that particular channel, the session artifacts, the code itself remains searchable, but we spent a lot of time on two UX pieces. One was the, how they show up in your sidebar next to all the other work that you're doing and making sure it doesn't clutter it. And then two, the actual chattiness of the, of the interface with the agent. So it doesn't become annoying.

RD

So I know one of the sort of problems that's arisen, or at least become visible because of agentive coding is code review. And this seems like you're, you're mashing the sort of the code building and the code review together. Is that, is that accurate?

RS

Absolutely. That's exactly what's happening is like, it's kind of mashing the ideation, the coding and the code review all together, you know, cause you're seeing, I mean, frankly, it's a lot of the process that's getting mashed together. It's like problem identification, you know, screenshot, like this doesn't look right. Let's go ahead and fix it. Let's put together a plan for it. Here's the doc on the plan, pulling an engineer and be like, does that look right to you? Yeah, go execute, pull in another engineer to review the PR. So it's kind of, it's accelerating the entire funnel and pipeline, if you will, and kind of merging it all together into, into one searchable artifact, which is really cool.

RD

Yeah. Yeah. For those, those searchable artifacts, do you find/expect/ intend people to sort of push those searchable artifacts to, you know, things like a issue tracking system or comments in a PR or something?

RS

Yeah. That's actually up to the agent itself and it's configurable on a per agent basis. It was actually talking to a few people about this yesterday. So the way that we have ours kind of sits on top of, of multiple coding agents internally, but the way that we have ours set up is it'll actually send a link to the channel ID along with the artifacts. So that like that's written back to the PR. So at any given point, like if you want to be able to call back to the channel and pull down the entire conversation, you could. But one of the, one of the settings on these other agents is you could have it actually summarize the channel and write that as a basically a read me or a file into the, into the PR as well, if you wanted to. So you've got configurability there.

RD

That's cool. We talked about the, the sort of potentially infinite multiplayer with developers. Can you have multiple agents in a room?

RS

You can. So in, in any Slack channel, you can have multiple agents. We, we do not have a situation of a to a working and code channels yet. I think that's something that we'll see coming. We're seeing like right now we ensemble Slack bot with our coding agent. So we'll have Slack bot as an example, go help with the planning or like write a brief about a particular problem or goals. And then we'll hand that off to our coding agent, but they're not talking directly to each other, but that's something that's something we're working on.

RD

Yeah. Well, I always wonder, you know, with chatbots, AI agents sort of work primarily off of text. Do you need a protocol like A to A to have agents communicate together when you have them in the same Slack channel?

RS

You don't necessarily, but I think it's going to help us scale, you know, like frankly through Slack channels, they can communicate with each other already. But I think the protocol is going to help us scale and certainly scale the quality of the experience.

RD

Yeah. When Jamie was on the program, we talked a lot about context and how much context that Slack has, how much of that overall Slack context is available to the agents by being in these code channels?

RS

So it, it depends on the setup of the, of the company, but the way agents are effectively apps in Slack and they follow the same permissioning model, which is they can by default access any public channels in your workspace once they've been installed in your workspace and that they can access public channels, they can access the channel that they've been added into and then they can access like if that agent chooses to do so in the user ops and they can call our real time search API through the MCP server and use that users off to find additional contextual information from private channels or direct messages at that user's request. So by default, only public channels in the channel has been added to and then the user can opt into more.

RD

Yeah. So, you know, you talk about a lot of partners being involved in this. How much of this feature and this process was shaped by the interactions with those partners?

RS

Oh gosh. I quite a bit, frankly. I mean, we learned so much from Cognition, Vercel, Anthropic, OpenAI and how they use Codex as part of this. Like we have our own way of building the ergonomics of Slack code and code channels was driven a lot by how we build that Slack because I think we have a unique perspective on how to use Slack and we have probably the most complicated and high volume instance of Slack in the world. So a lot of the ergonomics were driven by us and our doc booting, but a lot of like how we actually shape the session artifacts, how, you know, the chattiness of the agents when they're ambiently listening in channel, like that was driven so much by the partners and just can't thank them enough.

RD

Yeah. I'm going to ask a question that feels a little obvious to me. Why do this in Slack instead of an IDE or existing terminal application?

RS

Yeah. I mean, I think that it's the multiplayer aspect, honestly. So it's, it's being able to one co-locate the coding with the impetus for the coding. And I think that that's something that a lot of people sleep on for lack of a better word when it comes to Slack is don't underestimate the proximity benefit of putting the functionality close to where the impetus for the functionality is. You know what I mean?

RD

Right. Yeah. Yeah.

RS

And so like, there's, there's just like a tremendous convenience affordance by having it right there. So you're not context switching. You're just guiding agents back and forth. And then you always have the option to punch out to the IDE and go a little bit deeper if you want to. So I think that's one of the key things we actually didn't talk about here with specifically code channels is that any given point you can kick out and open up VS code if you want or whatever it might be and go deeper and, and like more fully immersive kind of deep thought mode, if you will. But the ability to do all that and bring in other engineers and cross-functional partners and have those conversations reachable and searchable alongside your other work, honestly, that proximity benefit, as I mentioned, is, it's just massive.

RD

Yeah. When I've done previous jobs, sort of surveys on, on engineering teams about, you know, where they, where they do a lot of their work and a lot of times it's in the, the chat application, right?

RS

Yep. That's like the one constant to this day and I think forever in, in work is conversation and coordination and like having this accessible from the surface that most of the world actually does that from is a big benefit.

RD

Yeah. I mean, I've thought, I think since I first heard about agents and connecting to tools, I was like, Oh, there's going to be a single interface to everything at some point. Clearly if you have this massive Slack application at Slack with all these plugins, you probably think the answer is yes, but why should Slack be the central point of contact for your developer experience?

RS

Yeah. I mean, I think we, we are biased, obviously, I want to preface that and I want to tell everybody here that that is a goal, that is a goal of ours, but the overarching thing that drives us is providing an exceptional user experience and we're going to relentlessly focus on that. I think that having all the people you need, all the agents you need in one place in close proximity to where the coordination is happening, so you're not constantly context switching, is where this is going. And we think Slack has a tremendous opportunity to do that. And I want the listeners to know that we, that's a, that's a privileged position and a serious responsibility and one we do take very seriously. And so we're going to try and keep the product as exceptional as it's always been while we introduce these new usage paradigms and affordances for agents.

RD

Yeah. But, and I think it's, it's interesting that you're already building in sort of exits to other applications, like kicking back to the ID. Do you think about other applications as like, oh, maybe you need a sort of specialized ID for this?

RS

Absolutely. So I think this pattern of Slack code and code channels projects onto other things like jamming on a legal contract together, building out a presentation together. And I don't think everything should move into Slack. Actually, I should have been more clear about that. I think there's a lot of stuff that can move into Slack, but if we tried to put everything into Slack, it just would be unusable. And I think you wouldn't know that you get from some of these other tools where you can do deep like domain specific work. And I think we'll always have the need to pop out to those things. So I'll use presentations and legal contracts as an example is you can jam on those things together in like a legal contract together in a channel in Slack, but you're always going to need to pop out to like Microsoft Word or Harvey or whatever it might be to do like sophisticated redlining or deep thought work about a particular legal matter. But also presentations as well, like I love what Gamma recently built and pushed into Slack. Like you have an idea and you start jamming with the team and you actually start using the Gamma agent and Slack and it'll build a presentation for you. But if you want to go off and like fine tune that presentation and like draw, we should not force you to do that in Slack, punch out and go to a dedicated tool for that. And I think that's the case with IDEs as well. And there's going to be situations where you just need to punch out and like have a much larger surface, much more focused, less distraction and jam. And so we'll always provide the ability for you to do that.

RD

Yeah. So another the sort of patterns that have sort of evolved in agents is it's kind of a very long running high context situation. You know, you talk about them being sort of ephemeral channels for for individual PRs or commits or whatever. Do you find the sort of long running agent works well in code channels as well?

RS

Yes. And I would actually, we have a lot of work to do here in Slack to make long running agents more rediscoverable and engagable. And I would actually encourage you to talk to Katie Steigman, who is the product lead for Slack Code and Code Channels, who's also working on revamping our entire information architecture to be a little more, excuse me, AI forward and agent forward. But as you have these increasingly long agents that can accept much larger context windows and work on a particular task for a much longer period of time, you're inevitably going to invoke those from code channels and other places in Slack. But you need to be able to get back to them and see exactly what's happening. Like they need to be interrupted. They need your attention and ideally see those aggregated in one place. There was a really interesting open source project from LangChain called Agent Inbox before its time. But that type of thing, I think, needs to exist in Slack. And it's something we're working on. But yes, absolutely. That can happen from a code channel, but also from other channels within Slack as well.

RD

Yeah, yeah. I think LangChain was before its time in a lot of places. Were there, in creating the sort of code channels feature, were there any, you know, you talked about the changes in information design. Were there any things that you had to sort of work back into the the main product to sort of change it to make it make it work for code channels?

RS

Yeah, we've had this with Slackbot. We've had it with code channels where it's pushed change back into the core information architecture. So one of the things that the code channels, when we were first working on it, when you would mention an agent, it would just spin up a thread right there and where you created it. And that just got, one, it got a little bit noisy, didn't necessarily make sense to everybody else that was was in that particular thread, was difficult to re-navigate back to. And so that that forced us to actually say, hey, when you kick off a coding agent and it spins up a code channel, we're actually going to do it in a different place and then put it in a different place in the sidebar so that you can recall it much easier. So we changed how we handle, like we moved a little bit away from the thread model directly to its own channel, added new unfurls. But then you'll see we actually changed, I'm moving, I don't know if there's video here, but I'm pointing to the right audio medium. I'm pointing to the theoretical right side of my Slack where we have a secondary window which shows the session artifacts, the code that's generated itself as long as well as like a preview of what's being built. And that drove change into how we do windowing, but also that secondary pane that shows up to the right of the main window. And so it drove change kind of throughout the product as a result of this.

RD

Yeah, I've definitely seen folks want noisy feeds and bots quarantined in their own channel to maintain the integrity of a channel between humans. So that makes sense.

RS

Yeah, so this way we don't clutter the originating thread, but you can always, the cool thing is when you go into a code channel, at the top of the code channel, you can always get back to the originating thread. The agent has that contact that gives the human the way to get back there as well.

RD

So this is shipped fairly recently, is this conversation by the time folks hear this, it'll be out about a month or so. What's the sort of things that are, you know, in the near term? And then what's the sort of final vision of this?

RS

So in the near term, it's all about driving adoption and making sure it feels good in people's hands and it's solving the problem that we've set out to do. You know, we have really good traction internally, good traction with our partners, but now we need to go actually see it happening at customers of us and our partners, you know? And so I think there's a ton of fine tuning to make this like a mainstream way of working. I think longer term, there's so much that could potentially happen here. Like you mentioned a few things throughout this conversation. One is A to A, like we're going to be ensembling agents within a channel here, handing off to each other, et cetera. We in and of ourselves have an opportunity to play in the routing space, you know, when, especially as you move more and more of these users are non-engineers that are doing this, if a company's got, you know, inavailable models or inavailable coding agents, and you've got somebody like myself, who's not an engineer by training, who's just trying to fix a problem, you know, how do we route to the right thing that's actually going to accomplish the task in a way that's most budget friendly to the customer? I think we've got an opportunity to play in that as well.

RD

Yeah. I mean, I've been recently talking to folks, I think they're talking about having a very plug and play way of thinking about the agent harness itself. I think DeepSeek put out something like that. Are you ever considering having a sort of plug and play agent harness within Slack itself?

RS

Yeah, that's something we're absolutely open to. It's not something we have right now, but it's something, things are changing so fast right now.

RD

Sure. Yeah.

RS

Honestly, by the time this airs, we might have one or we may have just completely discarded the idea. You know, it's wild how fast everything is changing right now, but that's absolutely something we're open to.

RD

And the feature might have been built in a code channel, huh?

RS

Exactly. That's the cool thing is that it's really fun to, on a personal level, it's really fun to see our product design, engineering, marketing teams all together in there and our, you know, last several new big features have actually been ideated and shipped through code channels.

RD

Yeah. I understand that you had a little hackathon to sort of put this feature through its paces. Can you tell us a little bit about that?

RS

Yeah. I mean, it's something we try to do. It's part of dogfooding. We have a release process within Slack where we'll start with the team working on a feature, has access to it. Then we go to what we call a friends of, where we put a ring outside of that, where it's not quite to all Slack employees and all Salesforce employees, then a subset of customers, et cetera. But as part of this hackathon, we saw a number of things come through that the engineering team candidly might not have worked on. The first thing was a decision memory for Slack. So it's watching Slack conversations for questions your team's already settled and privately purposes the original decision, the reasoning behind it, whether it was reversed. So nobody relitigates the same call over again. We had agents that were being built for good. So these were reading the workplace activity patterns to flag early burnout signals and nudging boards, like mental recovery before it turns into a crisis. And then we had people building something, an agent that turned plain language Slack conversations into versions, interactive diagrams that live right in the thread. So it was really cool to just see what the team came up with once we expanded it beyond the team that is actually working on this feature.

RD

Yeah, I always like the internal hackathons. Part of one at a company and talked about a couple, and they seem like a sort of way of unleashing the wish list that every engineer has.

RS

We do them a couple of times a year, and we were actually just going back and forth on the schedule for the next one yesterday with Adam, our new head of engineering. And they're just such seminal cultural moments for us, too. And so many great features in Slack in particular have come out of our hackathons. We also did an external hackathon. So the Slack Agent Builder Challenge was Slack's inaugural Dev Day hackathon, which was an eight-week global virtual challenge that we launched at our inaugural Slack Dev Day. It drew about 5,000 registrants and 500 project submissions. And the winner was AreaLine, which turns plain language Slack conversations into versioned interactive diagrams that live right in the thread, which traces every change back to the discussion that prompted it. So we just wanted to take a moment to thank all of our participants. It was amazing to get the entire developer community involved.

RD

Yeah, that's awesome. That's a lot of response.

[transition music]

RD

It's that time of the show again, where we shout out somebody who came on to Stack Overflow, dropped some knowledge, shared some curiosity, and earned themselves a badge.Today, we're shouting out a Populous badge winner. Somebody dropped an answer that was so good, it outscored the accepted answer. So congrats to Petro Sidlovski for answering, what's the best way to ensure a base class's static constructor is called? If you're curious about that, we have the answer for you in the show notes. I'm Ryan Donovan. I edit the blog, host the podcast here at Stack Overflow. If you have questions, concerns, comments, topics to cover, please email me at podcast at stackoverflow.com. And if you want to connect with me directly, you can find me on LinkedIn.

RS

I'm Rob Seaman, the GM of Slack. Thank you for your time today. If you want to check out code channels, go to slack.com/slack-code. If you want to reach me, you can email me at rseaman@slack-corp.com. Find me on Twitter @rseaman or hit me up on LinkedIn.

RD

All right. Thanks.

[outro music]

Add to the discussion

Login with your stackoverflow.com account to take part in the discussion.