Making AI multiplayer with Maggie Appleton from GitHub Next @ AIE Europe

Hi, everyone. We're at AI Engineers Europe, and I'm joined by Maggie Appleton from GitHub. Hi. Welcome.

I've wanted to interview you for a very long time, so this is very exciting. Could you tell us about your talk? Because I think it's gonna be very relevant to everyone listening. Hopefully.

Yes. The talk is called one developer, two dozen agents zero alignment, the case for why we need more collaborative AI engineering. And the thesis is, at the moment, pretty much all coding agents that everyone works with are in one person's terminal on their own computer. Right?

It's single player, like, across the board. The dream that we're being sold is, like, one developer and two dozen agents will do the work of a whole development team, right, with a scaling up a single person. But the problem is when you scale up individual productivity of one person, that doesn't lead to alignment across the team. And in order to build software, you have to communicate and coordinate with people.

Otherwise, you get what I'm seeing across other people's companies and even within our own is, like, you know, not just hairy merge conflicts when people work on huge features without communicating properly about who's touching what files, but people might build duplicate features. People are building features no one asked for. It's so fast and easy to do it. No one's planning around.

No one's aligning enough. No one's agreeing on what you're going to build ahead of time, and then you just end up shoving, like, a 100 really mediocre or bad features into a product because you didn't carefully decide what you all wanted to build together and do it really well. Like, this is, like, a totally a collaboration communication problem, not a go faster at writing code problem. So this is what feels to me is missing Yes.

Is we need multiplayer in real time Yeah. Like collaboration agentic coding spaces. So this isn't like we're gonna plan it in Slack, and then you'll just go over to your, like, solo Claude CLI instance and do it. Has It to be like everyone has to be in the same workspace the entire way through, so that planning and development are like a continuous cycle.

Right? It's not like you just, like, plan and then you build it. It's like you build something, you discuss what you build, you figure out why it's wrong. It's like a prototype.

Yeah. Test it. You build something else. Right?

This is like a very, like, iterative. We've all seen the stupid startup meme of, like, you build a skateboard and then a bicycle and then a car, you know? Like but it but it's kind of true. It's kind of true.

So the whole pitch of my talk was, we are missing these rich collaborative environments that bring human context into the picture too, because when you're deciding what you want to build, the information isn't in the code base. It's in people's heads, and this is political things, who's in charge and who gets to make decisions. It's financial and business strategy. It's research from your user researchers or your customer service people about what people want.

You need the full organization human context in your context window as you are writing code. You can't just take the code that exists and, like, your mediocre prompt and, like, do it and, like, make a plan with Chord, again, locally that no one else can see. No one else can see your plan with Chord. Yeah.

And then you just tell Chord to do the plan. And then at the very end, you put up a PR and everyone's like, well, we didn't want this or need this or this doesn't solve the problem. And by that point, it's too late. You're at the end of the process.

And I feel like people are trying to make PRs the place where you do collaboration and alignment, and PRs are terrible places for doing collaboration and alignment because they are the end product that are designed to review code at the end of a process. And it's like a lot of info I don't know. It's like it's very hard to, like, reason and discuss, like, about a PR for, like In comments. Yeah.

On, like, a not in real time, like Yeah. Not live website, like, from a kind of outdated. GitHub dot com that is doing really good work in a sense of, like, it's upholding holding up the whole industry of, know, doing all these PRs and issues. But it's it's really old.

It's, like, built on, like, Ruby on Rails from 2018 Yeah. Or probably before, frankly. And we all know it's not fast, and it's not real time, and it's not synchronous, and you can't see your coworkers there live working with you, and you can't just type a quick message to them. Have to, like, type a comment, click post, refresh the page.

It's not. It's 2026. Wow. So GitHub internally is building other tools that make synchronous real time collaboration easier.

But within my team, I work on the GitHub Next team, which is, the r and d labs. Super cool. What we call the fuck around and find out. I swear.

We kinda just build stuff that's riskier than the main business would do. Yeah. Yeah. We have built a research prototype that I showed in my tour that is a live real time collaborative workspace for agentic development.

It's called ACE, which stands for agentic collaboration environment, which is a bit of a cheesy acronym, but, you know, ACE. Nice. And it's a little bit like Slack, but with coding agents. And so you have all these, like, what we call sessions.

It's like a channel in Slack. You can type. Your coworkers can type. It's a chat.

Right? But you also have coding agents in the chat, and you are all prompting the coding agents together. You are all in a shared session, and the coding agent can see your whole chat. So it's, like, shared context, and you can make plans since multiplayer plans.

You can also each other's curses. You can write the plan together. You know, this is not one person working alone. It's people actually working together.

Yeah. And every session you're in is also connected to a micro VM in the cloud, so a sandbox computer in the cloud. So you're not working locally on your own machine because that causes problems. Right?

If you are working on something, you want your coworker to take a look. They'll, like, stash their work, check out a Git branch. If you're with work WorkTrees driving up the wall, everyone's, like, going hard on WorkTrees because you need some solution to parallel work streams. I find WorkTrees really difficult to work with personally.

And, also, again, I can't just pull my coworker into my live development environment and have them write the same code and run the same thing. It's like so anyway, we put computers in the cloud. We work on computers in the cloud, and then everyone's using the same computer because they're just, like, connected to it. Yeah.

So everyone can run terminal commands from Ace and see the same output. Everyone can spin up the dev server and see the same output. So you're working in these parallel streams all actually on the same dump users together, but still with these, like, parallel work streams, right, at these parallel sessions. So you can hop between them really fast, just like you would with WorkTrees in a local desktop app like Callcode or Codex or whatever these do.

Yeah. This makes sense because I guess it's, the most useful context is probably the stuff that is being worked on at this point in time. Yeah. A lot of you know?

And then that's that's just invisible, basically, at the moment. Yeah. So Pretty much. You're kind of stabbing in the dark.

You you might have had to stand up in the morning when someone told you, but, you know, so, like, I don't I don't wanna out myself, but sometimes you might not be you might be paying attention to your own update, but, like Exactly. You know, in in massive granular detail to everyone else's paying if it feels close to what you're working on. Yeah. And there's so many times where you're, yeah, you're working on a feature alone at your computer, and you just need to, like, ask your coworker a question about it.

But then you have to think about how do I explain what's happening to them? How do I explain this bug? How do I explain to them what I've already discussed with the agent? Like, that's a big thing is we have these long chats with these agents.

Yeah. And sometimes we make these, like, long markdown plans at the end of them. And then we if we're lucky, we get to share those with our coworkers and they can kinda see this plain markdown file they can't edit. It's a really bad workflow, but at the same time, they don't know what we talk to the model about.

Yeah. So they don't have our chat history, which is like they are given this random markdown file that to them looks like, okay. I don't know if this is your idea. I don't know if this is Ward's idea or Codex's idea.

Like, it's just sort of there's no transparency into how you got to what you what you built or what you made or what your output was. Yeah. People just either get the code at the very end, which doesn't explain anything, which is why reviewing PRs is awful in the age of a gender fair eye. Or if they're lucky, again, they get these interim outputs, which are like markdown plans or maybe like a write up, But it's still just like, how do I engage with this?

How do I how do I give you feedback on this? How do I edit this? And again, they can't touch your code. It's on your computer.

It's just there's so much friction and and so much isolation of the work, and we just need to bring everything into the cloud in real time. I don't know how else you're gonna get team alignment and team coordination with this otherwise local fragmented experience. And when when that context is available to the agents, like, does it just do do you find it just does better work, or is it, like, something that needs a lot of I don't know if it does necessarily higher quality work, let's say.

I think at this point, coding agents are at a level where they're pretty much capable of anything, but it it just is all in, like, what are you prompting it to build? And the right thing to build is the thing that you and your team all agree that you should build. Also Exactly the wrong thing. But yeah.

Yeah. Or something that is, like, actually informed by, user research insights. What is the product leader's vision? What do the leaders want?

What do you have enough money to sustain or something if you're going to build something in the cloud? All of these Everything you build as a developer has to be informed by business and users and design. And and I feel like we're just at the moment, DevTools have always struggled by being very isolated from the rest of the clearly works infrastructure and tools. And even more so, I know now we're kinda getting designers to work in the terminal, but that to me is the wrong way around.

Like Yeah. It's not that you bring everyone else into this, frankly, like 1980s. It's like a nice retro moment. Think we're having.

Yeah. Yeah. CLIs are like a cool thing to do. I don't really believe the CLI is the best UX we could have for developers by a wide margin.

They're nice for now. Developers love them. But at the same time, it's like you're losing, again, collaboration cloud in real time, nice UX, like, rich interfaces. I still believe that stuff is all super valuable.

The GUI is not like a a sham that we've been sold Yeah. Last and day. I wanted to ask you one kind of like it's more like, I guess, human psychology question here, but, like, in Goghelli's, if I pronounce that correctly, but pragmatic engineers conversation, he was talking about, like, token maxing that I'd never heard of of, like What's token max? So, apparently, the big, like like, Meta and the big big tech companies, there's some performance measurement around, like, how well you're utilizing AI.

And so some people are actually building, like, complete garbage stuff just to, like, get Burn tokens. Up. So you're like, in the bottom 25% or something like that. And I just wonder, like, if if the whole development process is, like, visible, do you think there's any, like, ways that have you I mean, have you observed, like, the people work differently and stuff if, like, the everything is, like, collaborate because it goes from, like Yeah.

Being you're in your own little world to, like, the sat right next to each other. Yeah. Yeah. Like, you actually ask each other's opinions for Yeah.

Why. Because, like, again, you know, the tools always shape the workflow. Right? Like, what is available to you at any one moment and what is lowest friction is what you were forced to.

And it's really high friction to ask your coworker to, like, jump into your session and help you get programmed or, hey. Look at this, Monique. Paul is saying this is the right architecture decision, but I don't know that that definitely is. Like and we're about to commit to it.

And, you know, I'd like to go over to Slack. You know, you try to describe the situation. You try to maybe upload some planet route. It's it's all really high friction, and you're much less likely to do it.

But we find working in Ace, we're all much more likely to ask each other's opinions really frequently. And then you can just jump in and you see how your coworkers prompt the agents and how they're using them. And that alone, just knowledge sharing and, like, having transparency and how everyone's using the models is really helpful. Yeah.

Because otherwise, course, people also have their own local setups with kind of like crazy skills files and stuff. Yeah. Yeah. Yeah.

But it's hard to, like, get all that in the ace at the moment, but we're working on it. It's like making it so even though just bring in, frankly, what is changing our day to day basis of the primitives of like, authentic voting. But so people still do stuff locally. But when we are working in ACE, it's like, see, yeah, you see how people prompt, you see the kind of plans they write.

You you pretty much can just jump in and, like, comment on their session while they're working, which we are working on some privacy stuff because some people are like it's like the hovering cursor in Figma. Like, you're designing and someone just comes in and hangs out, and then you just, like, will leave immediately. You're like, I'm no longer designing in this file. Yeah.

Yeah. So there's some of that effect. I mean, we're a small team, so we don't have Yeah. Yeah.

Yeah. And we're all quite senior one very in like, innovative, collaborative people, I guess. But I can totally see a junior not wanting some senior to see all the stuff and asking an agent. Sure.

Then you go locally and you're like, okay, explain what a VM is to bring or something, know, the stuff you should know. But I think it will only be good. It's like, again, knowledge sharing, transparency. We, of course, will have private sessions so you can talk to agents privately without everyone seeing.

But by default, everything is open. All the sessions are open. You can all see what everyone on the team's working on. And because of this, then we have some really interesting second order things we can do.

So, like, I'm really interested in proactive agents. So we have a dashboard, and when you come in in the morning, it can summarize what everyone else has been working on because it has the full context of what everyone else has been working on. So it can say, you know, Nate's been building this feature, and David's been debugging this security issue. And, like, everyone's moving so fast right now.

It's so hard to keep up with what you're Yeah. Yeah. Yeah. A 100%.

I wanna try and solve that problem as part of Ace. We all kinda have our pet our pet features. We Yeah. Like, make really good.

Mine is, like, the proactive agents in the dashboard. Like, I wanna come in. It reminds me what I was doing because I can't even keep up with what I was last Yeah. Yeah.

Like, you have these PRs that opened from last week. You haven't resolved this issue. You logged. And then it's also like, and your coworkers are doing this stuff.

So then I know, oh, Nate's touching the composer files. If I want to do my composer work, I need to go check what he's working on first. Has he shipped that PR? Because otherwise, merge conflicts.

Are we building the same features? Like, again, it all comes down to, like, agreeing with everyone what you're building, making sure you're not duplicating the work, making sure your features don't clash. This is, like, boring, old school, clever issue. That's But it's, yeah, super, super important.

It's being stretched right now. Yeah. Okay. Probably my last question.

What are you most excited about at the moment? Oh, okay. I mean, it is this piece of the like, what we're building is an agentic coding environment. And of course, you have to care about, like, what is the development experience?

But I feel like that not that it's solved, but so many people are working on that problem that I don't wanna work on it. Like the whole, like, you know, how do we optimize which tool calls get the right context into the window? And like, what's the you know, do you need to touch code? If you do need to touch code, how do you get it there?

I don't honestly care. Like, because other people are working on it, and I trust it will be good. But I care so much more about this, like, human social layer to the development work of how kinda intelligently like, I wanna be working, and then then I want the coding agent to be like, hey. I noticed you're about to, like, refactor the message component.

Turkle built that six months ago. Let's bring him in, proactively pull him into the session, give him an update on what's happening. Like, I don't know how to do it where it doesn't feel invasive or it's like in because nothing is worse than, like, an agent incorrectly notifying you about something that doesn't matter. Right?

Yeah. But if you could do it well, there's I think there's this really rich world that I wanna explore where it is, like, helping bring in the social fabric connections. Yeah. It's operating on the level of, like, what are the user research people talking about, and what are the salespeople talking about, and what are the customer insights from people?

And, like, help make those connections for you, help pollinate conversations between people, help bring in the correct context at the correct time. But the context is not coding files. It's, like, conversations happening elsewhere in the business that you need to know about that's relevant to the thing you're about to work on. Yeah.

Or, like, opportunities you might not think of. Like, this other team over here is researching something similar to you. How could it help connect those in a way that, again, is not extremely noisy and annoying, which is the true challenge? Because then you just shut it down.

You don't even Can you imagine if the Slack bot, like, pinged you, like, five times every morning being like, hey. Hey. Have you thought about talking to, like, 10 in sales? Yeah.

You're gonna we're just gonna block that out. Yeah. Yeah. Yeah.

Or just, like, it's gonna be the permanently white that you don't check that channel and Yeah. Yeah. Yeah. So there's a lot to do around there.

It kind of involves it involves memory and personal preferences and but it has to understand, like, what role everyone has on the team, what they're currently working on, what their expertise is so that it knows to say, hey, if you're working on scaling systems, you should go talk to, like, Jared, like, or if you're working on, you know, something with the interface, you need to go talk to Mary. Like, have intelligent understanding of everyone on your team and how to, like, bring them in in a way where you it then relieves you of the cognitive overhead of you having to constantly understand all these social roles and, like, who makes decisions and who has expertise, all the politics of work.

To some degree, I think you could improve that. I don't wanna be like, oh, there's some great perfect product we can build. It's gonna it's not being annoying, but there's some low hanging fruit we could, for sure, work on. Yeah.

Yeah. Oh, that's amazing. I am very excited. We're we're using GitHub, and we're building everything, and it's yeah, excited to see how it evolves.

Yeah. Hopefully, go I mean, it's in ACE is in research preview. Well, I mean, we're we'll put it into technical preview soon. Right now, it's just in a research So can people will people be able to try it out?

Within I don't even know if I'm allowed to say a time frame. Yeah. Yeah. But it's maximum a few bugs.

Okay. And that's and then we're gonna release it in technical preview, which is the GitHub where I feel like this is a prototype that we're letting you play with. We mostly need to get people in and learn more about how people collaborate and then iterate from there, you know, kinda work in public. Amazing.

Yeah. Thanks so much, Maggie. Yeah. Thanks for having some time.