GitHub’s plan for Agents — Kyle Daigle, GitHub

I’m excited to work with Microsoft once again as the presenting sponsors of the AI Engineer World’s Fair! We’ll streaming live from MS Build today for a special crossover pod with our friends at No Priors and the one and only Satya Nadella. However we did not hold back with this interview - we asked all the burning questions about uptime and Copilot that we know you have in your minds. Lets go!

For almost two decades, GitHub has been the home of software, where both open source and closed flow, through commits, pull requests, reviews, actions, etc.

This ecosystem flourished as open-source maintainers and contributors would continue shipping code for the benefit of the community. However as coding agents began to ship mass quantities of code - growing 1400% in 2026, it marked a new era that was both extremely exciting and challenging for GitHub.

While these agents help more people ship more projects, they also significantly increase the floor of how much code is shipped, how often it is shipped, how many people commit code, and basically orders of magnitude multiples in every dimension of GitHub infrastructure:

Now GitHub inevitably experiences more pressure on their infrastructure which was originally designed around human developers moving at human speed. This has resulted in a very publicly notable uptime story:

So it begs the question of whether current systems around code can absorb what AI produces. Can CI/CD keep up when every idea becomes a build? Can open source maintainers survive floods of AI-generated slop contributions? Can GitHub preserve the human social contract of software while becoming the operating layer for agents?

Which brings us to the perfect person to answer these questions: GitHub COO Kyle Daigle. In this episode, he joins swyx to unpack what happens when AI doesn’t just autocomplete code, but starts changing how companies operate, how open source works, how pull requests get reviewed, and how GitHub itself has to scale.

We go deep on GitHub’s internal AI workflows: micro-skills, WorkIQ, MCP, Slack, Teams, email, Copilot workflows, the new Copilot desktop app, CLI, cloud agents, and how Kyle uses agents to look backwards across company context before deciding what to do next. Kyle also reflects on GitHub’s history building webhooks, APIs, Actions, npm, Dependabot, and Semmle, why the AI era is breaking GitHub in new ways, how Actions became a general-purpose compute layer, and what Copilot becomes after code completion.

Full Video Pod

We discuss:

* Kyle’s expanded role across GitHub

* How AI got Kyle coding again after years in leadership

* Why GitHub rolls out AI through existing workflows instead of forcing new tools

* WorkIQ, MCP, Slack, Teams, email, and GitHub as company context

* Why massive “mega-skills” are giving way to small, atomic micro-skills

* How AI changes summarization, communications, marketing, and analyst work

* Why former developers in leadership may have a unique advantage in the AI era

* Kyle’s “15 agents on Saturday” workflow

* How Kyle built an AI-generated executive presentation for CRO/CFO teams

* Why AI changes the chief of staff role without removing the human work

* GitHub Actions, webhooks, arbitrary code execution, and secure agent compute

* The npm acquisition, supply-chain security, 2FA, and token invalidation

* Slop forks, vendoring, and whether AI agents change dependency management

* What pull requests become when most PRs come from agents

* Prompt requests, vouching, AI review, and trust in open source

* What counts as a “developer” when AI lowers the barrier to building

* GitHub Spark, low-code, and why GitHub refuses to hide the code

* 14x commit growth, Actions load, databases, monorepos, and availability

* Copilot’s evolution from completion to CLI, desktop app, cloud agents, and SDK

* Context, memory, rules, and making GitHub “act like Kyle wants it to act”

* Ambient AI, OpenClaw, enterprise security, and the new operating system for agents

* What swyx should ask Satya Nadella about Microsoft’s AI future

Kyle Daigle

* LinkedIn: https://www.linkedin.com/in/kyledaigle

* X: https://x.com/kdaigle

Timestamps

00:00:00 Introduction

00:03:36 Why AI Got Kyle Coding Again

00:07:04 Running GitHub with AI: WorkIQ, MCP, Slack, Teams, and Skills

00:15:39 The Golden Age for Former Developers in Leadership

00:17:31 15 Agents on Saturday and AI-Generated Executive Work

00:20:20 How AI Changes the Chief of Staff Role

00:21:45 GitHub’s History: Actions, npm, Webhooks, and Open Source

00:28:45 Slop Forks, Vendoring, and AI Dependency Management

00:33:57 Pull Requests, Prompt Requests, and Trust in Agent-Generated Code

00:41:21 GitHub Stars, 200M+ Developers, and the New AI Builder Wave

00:45:15 GitHub Spark, Low-Code, and Why GitHub Still Shows the Code

00:47:38 GitHub’s Hardest Era: 14x Growth, Reliability, and Scale

00:59:21 Actions as the Compute Layer for CI/CD and Automation

01:02:04 The State and Future of GitHub Copilot

01:08:24 Ambient AI, Background Agents, and the Future of the SDLC

01:13:09 OpenClaw, Enterprise Security, and the New OS for Agents

01:18:03 Build Announcements, WorkIQ, FoundryIQ, and Microsoft Context

01:21:41 What Should swyx Ask Satya?

Transcript

Introduction: Kyle Daigle’s Expanded Role at GitHub and Microsoft

Swyx [00:00:00]: We’re here with Kyle Daigle, COO of GitHub. Welcome.

Kyle [00:00:07]: Hey, thanks for having me.

Swyx [00:00:08]: You’re not just CEO of GitHub. People know you as that. You have a new role.

Kyle [00:00:11]: So I have an expanded role now. I’ve been working at GitHub for thirteen years and doing all things developer. Joined as a developer myself. And now, I’m also responsible as the CMO of Developer for Microsoft. And so all the kind of learnings and passion for developers and how we work with them and how we communicate and how we bring our products to market, we’re also bringing that expertise to the broader Microsoft ecosystem and helping every developer that uses a Microsoft product or would like to have a sort of similar experience that they’ve had with GitHub over the years. So it’s a different role in some ways, but it’s also just building on the experience that I’ve had at GitHub of just sort of tell the truth, be authentic, show people how to use it and then let the products speak for themselves. Now just doing that with, all of Microsoft.

Swyx [00:01:09]: We’ll be releasing this in conjunction with Build. You got lots of stuff planned, and we can sort of touch on that whenever it’s appropriate. I think one of the interesting things is I rarely meet a COO who’s also a CMO. I think you’re a very outward facing and you’re very confident publicly. That’s rare. Do you actually view yourself as COO? What’s What is your thing?

From GitHub Developer to COO/CMO: Building the Platform and Operating GitHub

Kyle [00:01:33]: I think for me, it’s been funny. The titles have always been, a— have always felt a little strange to me. I joined GitHub as a developer? I wrote so much of the

Swyx [00:01:46]: Let’s bring that up. You wrote the back ends?

Kyle [00:01:48]: I was going through, I was going through, some old photos, when folks were talking about how things were being built or how there was a build GitHub. I built, webhooks and worked with teams building the API, built the platform layer. Anything that integrated with GitHub, up until really twenty eighteen, I built or ran the engineering teams. And that’s kind of where my the beginning of my passion always was helping people build things, deliver them to, their customers. And so being a developer, building for developers was always super unique. In a— I think as my role expanded, it became my ability to talk to not just developers, but also enterprise customers or business leaders and have this translation layer. And then through all those years, GitHub has always operated pretty uniquely. Post-pandemic, working remotely was not as novel as it was when GitHub started in two thousand and eight. But all that expertise of running remote teams, doing it well, became this sort of bigger role, ultimately turning into the COO role of how do we operate GitHub in the way that GitHub’s always operated after the Microsoft acquisition. And kind of so on from there. So like for me, I think the— I’ve, I still code. I love coding but the problem has always been, people. It’s a much harder problem to both support our own employees, a harder problem to communicate to developers and enterprise buyers what we’re building why it matters, ‘cause those are two very different messages. And so getting to work in the mix of COO, CMO, also just being a dev, I think is what’s kept me at GitHub for so long.

AI Workflows for Leadership: Commits, Retrospectives, and Context

Swyx [00:03:40]: Apparently, you have— your commits have gone up. What’s this? What’s going on?

Kyle [00:03:45]: Rui’s called me out pretty aggressively. So I think— as you can imagine, right, you can see my normal era of being a dev In the twenty thirteen, twenty fourteen era, and then moving into management, and then ultimately the COO role. I think what you see there is me, really getting back to coding thanks to AI. I— similar to, attaching problems between how to market and how to operate a business and how to code, I find, building agents and workflows that are connecting very disparate problems to be what’s driving this. So that’s, some of it’s writing software. A lot of it is, connecting a ton of a different data sources to, help me out. But that is completely me really diving in on the AI side in trying out our tools, trying out everyone’s tools, But building for me, building for the non-technical leader, though I’m technical and how we’re, able to use these tools more than just the simple, call and response that I think a lot of the non-technical, your employers, you have to get— you have to use AI, and so everyone uses, ChatGPT or Copilot or Claude or whatever. To really get into, how is this going to help me out, it— I find that it’s not the I need to write a blog post, I need to those simple examples. Helping people find the workflows of, “Okay, I need you to go through all the PRs today. I need you to go through everything that we’ve posted online. I need you to go through what we did the last three months. Go through all of my Obsidian notes for any mentions of this then go through my transcripts at work.” We use, Teams, so, using WorkIQ, go call that MCP server, grab all the transcripts, go through all the Slack, and then build me out the plan of, what this week’s messaging actually was. That’s something that was, impossible because for me, I find AI in a what most of this launch here is actually, less building forward. It’s actually, a recursive loop backwards. I’m always looking at what had happened first. Go back through the week and tell me what we did, what worked, what didn’t work? And then tell me in the next three or four days-What would you tweak based on this sort of like looking backwards and then looking ahead a little bit? I find that to be so much more valuable, especially for like non-technical, because that retrospection is actually LLMs are very good at that. Like finding all the patterns, pulling them out, and then applying that retrospection to just a couple of days or just like a short period of time. Is all a bunch of apps that I’ve built and launched a bunch of, internal tools. I use the new, GitHub Copilot app, the desktop app with workflows. Every time I crack open my laptop, it’s running workflows for me. It’s just a ton of different stuff and of course, it all ends up on, it all ends up on GitHub.

Swyx [00:06:47]: Of course. That’s where, that’s where, stuff is hosted. Man, there’s so much to ask you. I was going to leave the how do you run a company with AI thing at the end. I have to ask one— double click one thing. You said, you are looking back at the week. You’re, you’re understanding what happens. When you say we That’s three thousand people. How?

Rolling Out AI Internally: Skills, CLIs, and Company Context

Kyle [00:07:09]: I think when we started rolling out AI internally beyond engineering, right? One of the things that I was really, passionate about is like we have to do this in a way where no one has to change how they work. I don’t want to have to teach you a tool. I don’t want to have to teach you something new. And so for us, we tried out a few tools. Most of them don’t work because I got to get you on board? I got to teach you how to use it. What we’ve actually ended up doing is we’ve built like a set of skills internally. We have we each have our set of skills, and we’ve just been distributing even to the non-technical folks, the CLI. And then effectively, we’re just giving it access to like read about everything that we’re writing. So that’s for us, that’s usually GitHub, Teams, Email, and Slack. So Teams for, video chat, generally speaking.

Swyx [00:08:03]: Teams and Slack?

Kyle [00:08:04]: so we use Teams for video communication, but we don’t use it for chat. W-we— GitHub for a long history, right? We’re always

Swyx [00:08:13]: Also Slack

Kyle [00:08:14]: Talking about ChatOps and like everything is built into Slack. Like every command, every flow.

Swyx [00:08:18]: So even though you have been acquired for I don’t know, eight years now

Kyle [00:08:22]: we still

Swyx [00:08:23]: You still use Slack?

Kyle [00:08:23]: it’s a purpose-built tool for us, and I think the reality is that moving off of it would be so bluntly expensive? Simply because all the tooling is, baked in with that paradigm. And they both have their pros and cons but they don’t work the same way at all. We still use a bunch of different tools Because it’s the purpose-built tools that We need. And then

Swyx [00:08:47]: Well, the same doesn’t go for the rest of Microsoft, presumably.

Kyle [00:08:50]: like the like various teams like operate

Swyx [00:08:53]: They make their own decisions

Kyle [00:08:54]: Various ways. I think it just matters what you’re trying to what you’re trying to do. But we do we do work across kind of every tool that we use, and then by giving everyone access to all of that context and the new WorkIQ MCP server, which is quite cool if you do live in the M365 like world. I can ask it all these backwards-facing questions, and it’s incredibly important for our teams that are working remotely. There’s a lot of stuff you miss when you’re not in an office, and we are spread out all over the world. So most of that is looking back. And then we post, we post either auto-automatically into GitHub issues or discussions, these sorts of like findings or like our industry reports. Like what’s happening this morning, today, yesterday. A little automation gets run. We’ll use the app. We might use GitHub Actions like with, our agentic workflows just to go do that run, and then we push it into GitHub, and w-we keep having a conversation. So usually for us, it’s about that sort of like looking back, looking forward on the non-technical side. And then of course for a lot of those folks, it’s also building an app, pushing it to GitHub pages or pushing it somewhere to host it et cetera. But it’s just like enabling everyone with that power of it’s going to take me a week to figure this out. Instead, we’re going “Okay I built a skill. Let’s put it into a repo. We’ll all share that skill together, and then we’ll use the CLI or now the app-” “just to run it.”

Micro Skills vs. Mega Skills: How GitHub Uses AI at Work

Swyx [00:10:26]: All right. I think, I think we’re going straight into like the team management and productivity thing. I think a lot of people are getting various levels of LLM psychosis. How do you manage the bloat of skills? Like everyone Has their thing, and they’re Like trying to promote it to the rest of their peers in their org, right? And obviously, whoever becomes a skill influencer internally becomes like an AI leader, right? Of sorts. I assume you have those.

Kyle [00:10:50]: like I think we have

Swyx [00:10:52]: And I assume it’s a mess a Yeah.

Kyle [00:10:54]: there’s like I— like I think the reality is there’s two pieces. Like first is I think that we’re ending the era of these like massive, beautiful, perfect skills that are just like not any of those things. ‘cause for a while, right every tweet every day is like go download the skills, the perfectly managed thing to do this entire workflow. And I think that like what we’ve found and what— I was just with my team, this week, and we were talking about the skill side, and we’re really talking about these like incredibly micro skills that are just doing one thing for us very well Versus a skill that’s going to do I said, that full report. That doesn’t really exist on our side anymore. It’s usually how do— like a single skill that’s going to identify the most important marketing information given any MCP server. Like this is the most important thing. Less about stitch a bunch of tools together and have it produce this mega output because then weeks go by, months go by, things change, and you want to tweak

Swyx [00:11:58]: It’s brittle

Kyle [00:11:58]: Your mega skill and you’re screwed? You can’t do that. And so now we’re really just talking about the Legos we’re using and just letting the instruction book be something we’re all putting together. Whereas I think a lot of AI skills for a while have been that mega instruction book style.

Swyx [00:12:15]: I’ve, thought a lot about Postel’s law. I don’t know if that’s a term that is, means things to folks. It’s the idea that you should be liberal in what you accept and strict in what you output, right? And I think that’s like a good framing principle for skills. This is my skills, obviously on GitHub. I feel like everyone should have like how like some repos In GitHub are special repos? I feel like we should sort of reify the slash skills and everyone like give it some kind of special presentation. Anyway, so, yeah, this is one of those like download Download anything, transcribe anything, and then you can string together the atomic skills that do one thing well Into like some kind of orchestration skill that calls other skills. I assume, does that match?

Kyle [00:12:56]: I like I think so. I think that the

Swyx [00:13:00]: Summarize anything.

Kyle [00:13:01]: Like I think the- For me, summarizing something for I do communications and PR and analyst relations and marketing and customer activities, and so my summarize everything is very different for each one of those like Contexts. What ‘Cause if I’m summarizing something for an analyst, that’s a very different thing than, probably how I’m going to summarize something for like a customer meeting or an engagement. So that’s I think like the difference when we’re talking about the like the tools I might use on Saturday or the skills I might use on a Saturday when it’s just for Kyle. Yeah, those are kind of like they have an atomic actual tool underneath or maybe skill, and then Kyle cares about X. But I think when we’re talking about work and enabling the the marketers, communicators there, it’s the atomic, this is what good summarization is, and then this is what I care about as for marketing for communications For whatever. And that I think is like the interesting matrix problem when we go from like a developer set of concerns to all kinds of different professions, is that what that word means to me is different than it means to you is different than it means to the analyst or the salesperson, and that’s where I think the matrix mess is that we’re starting to like still starting to find. It’s about these mega skills but they’re all just slight permutations, but those permutations are really important. It’s the difference between someone reading this and going “Did AI make this?” what Or “This makes total sense, and I would expect this when I’m giving a briefing to Gartner,” or like whatever else.

Swyx [00:14:37]: I think the beauty of it maybe is that you don’t have to be that careful about what goes in there. It doesn’t have to exactly fit as long as it like roughly is contained in there. I used to complain about plugin hell, basically. Like when you have a framework and then you have a hundred things that you need to integrate, everyone does like the GitHub used to be bloated full of these things. And now we don’t need them anymore ‘cause now you just use skills.

Former Developers in Leadership: AI as a Creation Multiplier

Kyle [00:15:00]: And like I think the most magical thing is the just that like I can just also crack it open. Like Like yes, I could go like change the how the plugin is coded, or like I could go do that now with AI, but I think there’s just something more magical about getting a response back and being “That’s not right,” and then you just crack the skill open, you just type English words and it’s different. That building block is just, I think very unique. Once I get everyone to kind of understand how to best how to best make those changes to get the most power out of them.

Swyx [00:15:36]: Is there a— you have a your peer group that Of people like you. Is there a common framing for Something I’m feeling is, which is true, is that is this a golden age for former developers who are now in leadership? Because you can wield the tools, you would know the right words, you’re maybe not too close to the details. Doesn’t matter. But like you’re more effective than someone who doesn’t come from that background.

Kyle [00:15:59]: I think that like the secret has always been your ability to identify patterns and solve problems, and I think that for folks that like myself that don’t code day to day anymore, that has made me successful as a developer, made me successful as a COO and now CMO. And so now that I have access to get and write code, I’m now applying that sort of like pattern finding and problem solving, and I know enough still about how to then go and say, “Oh, I want to make an app, but I don’t want to break into jail or create something that’s not going to be able to work or to be deployed scale or whatever.” that ability to apply all that additional business knowledge and still code I think is what makes that so interesting to me. Slightly different than I think some of the other like technical leaders that became business leaders and now are going back to their apps and updating them. Good for them? But I think the more, much more interesting thing is, well, now I have this whole new set of expertise over ten plus years. Why not take that and use that as a developer with these AI tools? So I definitely think that makes me more powerful, but I think that’s true for like every dev as well. Most of the dev friends I still have also have some other underlying skill and passion. There’s really talented, very kind of linear computer science software devs, absolutely. I just find that the folks that came from a different career, went to school for something else, went off and did this random thing, and then became a software dev, or were a dev, did a random thing, came back. Learning that extra set of information, learning those extra skills, and now having the power of an AI where I can crank up fifteen agents on Saturday while my kids are doing lacrosse, That’s like really powerful. And I think it gets me back to that feeling of like creation, and it’s very hard to replicate that in most other senses? That first time you build an app and you click it and you show someone that’s magical. And so being able to do that not just in code, but across all kinds of different assets that’s, that’s huge. We were doing we’re doing our every year we do our revenue planning. We talk about okay, what is it going to look like for next year? And of course as you imagine, there’s, slideshows everywhere talking about what are we going to talk about, what’s the narrative, et cetera. And so as you said I’m “Okay, well, I could probably just like build something to build this and then that way I don’t have to go build the whole spreadsheet or I have to pass it to my team.” So we went through this process, and I got all the information and used the skills I mentioned. I built like a little app just to make it so I could look at some of the information in a SQLite database, more easily. And I ultimately built this entire presentation without touching any of it and I was “Okay, I’m just going to present this to our CRO, the CFO, their teams,” without mentioning I’d built it with AI. I like built a skill to make it look very much not AI driven. Just not pretty.

AI-Generated Presentations, Human Taste, and the Changing Chief of Staff Role

Swyx [00:19:03]: Like a design. Yeah.

Kyle [00:19:03]: Not pretty. But just like very clearly not AI. Kind of like don’t do anything interesting.

Swyx [00:19:08]: That’s, yeah, that is valuable.

Kyle [00:19:08]: Just go Exactly. We did the whole thing through. It used my notes from Obsidian, it used all the context I mentioned before, the plans, and Never came up once that it was AI generated.

Swyx [00:19:20]: It didn’t matter.

Kyle [00:19:20]: Never once. D It didn’t matter. And so now I take

Swyx [00:19:23]: This is a tool

Kyle [00:19:23]: I can take that tool and go, “Look, I don’t want you to go build slideshows.” They’re just helping us share information with each other. If this thing can do it With a little bit of crafting from you and then we can look at it together, awesome. There’s no value in all that extra work. I think that the ability to, make it look humanly bad and and build a little app to, manipulate the data I think is part of, that upside for devs that are now in leadership roles. Because, the thing that I feel like I said before, this that’s all a people, that’s all a people problem. I know if you’ve used a coworker or not to build a slide deck, unless you spent a bunch of time to not do it.

Swyx [00:20:07]: I know, but like it was so, I think there’s a certain charm to just being blatantly AI. ‘Cause I think that you’re well, you’re just honest about There may be mistakes here that I cannot vouch for. So how much value is there? But anyway I think, actually the real question I want to ask is, there’s a— You were a chief of staff To Thomas. And in the pre-AI world, the that job would’ve been a chief of staff job of like Can you prep me these slides and all that? And now you do it yourself.

Kyle [00:20:35]: I still, I still have a chief of staff. Because, the difference is it’s sort of the discussion every time we have some sort of technology evolution is it’s not that the jobs the roles don’t all go away, they just change? And so yeah, I don’t have someone spending all their time building out slides for me and presentations ‘cause I don’t need that anymore. But now I need that person that is able to go and find all the different connections between humans in those discussions to help me find out, okay, I should be meeting with this group and this team, and they have an opportunity, and I’m going to be in San Francisco today, I’m going to be in Seattle tomorrow. Those sorts of human connection aspects are still incredibly valuable and has always been a big part of that chief of staff role. But now just like chiefs of staff are not opening up, letters to process, they’re doing emails. What It’s the same thing. And now they’re, they’re not building out as many of these presentations because they have the the ability to have a AI take it on for, and share that with me and great. Let’s keep moving ‘cause it’s allowing us to go faster and make better decisions more quickly.

Swyx [00:21:45]: Awesome. Well, so we can dive into more sort of, Productivity insights as you go. I did want to do a little bit of a brief history of colleague and hub. Because, we started here. And then you also involved the NPM acquisition. I did, I do want to touch upon that. And then more recently, I just want to bring up to present day where we’re having uptime issues Which transparently we’ve already Addressed publicly, but we’ll, we’ll discuss in the pod. Did I miss anything? Like what, any other major highlights? Obviously, it’s, it’s a lot of years to cover.

A Brief History of GitHub: Webhooks, Actions, Acquisitions, and Platform Evolution

Kyle [00:22:15]: No the I think one of one highlight was right before the acquisition closed in twenty eighteen, I got to launch the first version of Actions

Swyx [00:22:27]: Oh

Kyle [00:22:27]: At GitHub Universe. So it was O

Swyx [00:22:29]: They’re that young?

Kyle [00:22:30]: It was October of twenty eighteen, I think. Yeah. Yeah.

Swyx [00:22:33]: Gee, Jesus.

Kyle [00:22:34]: I got to I was the engineering leader on that project and got to launch that. And then, yeah, we did acquisitions of NPM you said, Semmle, Dependabot Pul Panda a whole bunch of things. That was a big

Swyx [00:22:47]: Pul Panda.

Kyle [00:22:48]: Abi is doing well.

Swyx [00:22:51]: DX. Holy crap.

Kyle [00:22:52]: Did well on DX. I and like that was a that was the big shift, after the acquisition. I had to join the sort of business side.

Swyx [00:23:00]: So I need to hit you on some of these things ‘cause you were there. Right? And how often do I get to talk to someone who was there? But yeah, Actions. Is that the number one source of security issues on GitHub?

Kyle [00:23:11]: Oh, sh I think that the number one source of, security issues is probably like all, the literal code in everyone’s like underlying repositories. I would say back further than that is, if you remember I had to show in this graph was this is, I’m, didn’t say this before, this is ultimately webhooks.

Swyx [00:23:30]: You yeah.

Kyle [00:23:31]: Like circa whatever it was.

Swyx [00:23:32]: It says Hookshot in there.

Kyle [00:23:32]: I forget. Yeah. Yeah, Hookshot’s in there. And so like back then, it says GitHub Services. Do you see, it says Hookshot FE for front end, and then it says GitHub Services. GitHub Services back in the old days, right? You we had a repository that was Ruby code, and you could write any Ruby code in there, and then we would execute that On your behalf As a service, and then that way if an if you were trying to integrate with something, it didn’t we would run it for you.

Swyx [00:23:57]: And of course no containers ‘cause

Kyle [00:23:58]: No, ‘cause it was

Swyx [00:23:59]: Well, no containers

Kyle [00:24:00]: Twenty fourteen. And so there was some isolation obviously, but it was mostly the separations on the server level. That’s like an example as long as the very old version of Pages, which ran on its own containerization infrastructure, not on Actions.

Swyx [00:24:15]: Which like all-time great product.

Kyle [00:24:16]: Pages powers the internet at this point to some degree. Those were places where like clearly there were no like issues like to my knowledge. But it was those things where I’m looking at and going “Okay, well we can’t be running arbitrary Ruby code,” like on everyone’s behalf. Then containerizing all of that up intoUh into actions now where yeah the containerization, is r-really good. The pinning most folks aren’t pinning it the like to a particular

Swyx [00:24:48]: Images

Kyle [00:24:48]: Sha, et cetera like their workflows, and so that’s a big that’s a big place Of pain for folks if they’re just doing similar to any dependency management, just V1 or newest or latest, I think. But, that journey from that day to “Okay, we’re just going to run all this arbitrary code, and, it’ll basically be okay,” to now, no, we have, really good containerization. We have a new, underlying, ag-agent, containerization, service. It’s like we’re using it under the hood. It’s through Azure. They recently announced it. The Azure, Dev Compute, but it’s, very fast, very fast compute to be able to, spin up your own cloud agents, or whatnot. We’re using it under the hood for some parts of the new,

Swyx [00:25:36]: Microsoft Dev Box?

Kyle [00:25:37]: No. Dev Compute, yeah.

Swyx [00:25:41]: Hmm. Not finding it just yet.

Kyle [00:25:44]: Oh, it’s, it’s in there somewhere.

Swyx [00:25:46]: All right. Well, we’ll cut that out.

Kyle [00:25:47]: Sorry. But with, Dev Compute, you can, run, really fast, spin up really, small VMs really quickly, so you’re doing a tool call

Swyx [00:25:58]: Same concept

Kyle [00:25:58]: Just do it containerize exact-exactly. So we’re using that so definitely moving that direction to protect us from every every piece of code that we’re ultimately running.

Swyx [00:26:07]: look, that grows into the full SDLC? Code hosting was just the start and and then it’s grown beyond that. Let’s talk about NPM may-maybe ‘cause I think that’s also, a very major point in the industry. I do think, it was looking for a home. It was, kind of struggling as a business, right? I don’t know, I don’t know how you would characterize that whole acquisition and how it

NPM, Package Security, and Keeping the Internet Running

Kyle [00:26:33]: like when we were talking to the team, I think the big thing for the both of us was to find a way to keep NPM, which was basically powering the internet then and way more so now to some degree running. Keep it going keep continuing to scale. It was having scaling problems, if I recall, back at that time. They were doing some rewrites. It

Swyx [00:27:00]: that’s cute compared to now.

Kyle [00:27:01]: Well, that’s the thing is like when I’m talking to folks now, there’s there’s so many more underlying uses of NPM than there were back when we had them join in with GitHub. But that was ultimately the goal. It was really okay, we used to have pages. We have, the world’s code. Let’s make sure that we can keep NPM running well for the world. And we put a bunch of time and investment into fixing some of the underlying backend, changes, some of which we talked about some of the manifest work, et cetera. And then now, really trying to bring the the security posture of NPM up to speed. But, it is a unique challenge in that every move that we make to make it more secure will break a lot of people. And security is paramount. And also, we take it very seriously. We’re, the any time that we have a problem with GitHub or we make a change that makes us more secure but hurts, there’s, a snow day for developers or a really bad fire that they have to go put out. And so we’ve, have changed the 2FA policies. We’ve changed the way the tokens work. When we find tokens that have been exposed or potentially, exposed, we invalidate them, and

Swyx [00:28:22]: I love that feature in GitHub. Yeah, it’s great

Kyle [00:28:23]: That creates issues, but, the but that’s the thing is we’re trying to push the community, forward without necessarily, doing something that is going to break the contract that’s been for 15 years or close to it or some amount of years on NPM.

Slop Forks, Vendoring, and the Future of Open Source Supply Chains

Swyx [00:28:43]: I think the— So now we’re talking about, open source and publishing. And I think there’s something here with what people are calling slop forks, which, I think Malta from Vercel is doing. And, part of me thinks, well, the way to get past any vulnerabilities, we just, let’s just get rid of the concept of NPM. And we only publish source code. And anytime you want to import it you have your coding agent look at it and then adapt whatever subset you’re going to use into your vendor it. But, the AI vendor it. Is that realistic? I don’t know. Is it— Will that solve all our security issues? I don’t know.

Kyle [00:29:24]: I don’t think it’ll solve I so Mitchell was just talking Mitchell Hashimoto Was just talking about this today, and I think that I-in some ways, it’s all all things, old or new again? Yeah, absolutely vendoring everything. Like I do I do remember twenty thirteen, twenty fourteen.

Swyx [00:29:42]: This is Yeah. Let’s, we must return to

Kyle [00:29:43]: That’s what is We were vendoring everything. We were having actual discussions around, or at least I remember we were “Should we take this full thing?” “Why is this so big? We only need this one file.” And so I do think there’s something true there where having either taking only what you need or the dependencies just getting incredibly small over time, I think will help to some degree, but it’s not going to solve the fundamental problem, I don’t think, because the vulnerabilities in an agent looking at them, there’s time and time again, there’s a million different ways in which we can convince an agent that this thing is, secure or not and pull it in. Or we can do static code analysis or runtime testing to say whether the code works or not. That is, I think, the step that needs to continue to be, invested in. The question is just on, how much scope. Should it be this enormous project that I’m pulling down, or should it be this piece? Either most companies are running some amount of security checking on the on the packages that they’re bringing in or vendoring. That I think won’t change. That’s like what advanced security does to some degree, Socket does some degree. Like everyone is doing a piece of that. How we each do that like especially when we’re talking to enterprise customers, is just like very different. No there’s no one wants one single way to do it. And I think that’s always been GitHub’s, unique position in the world. I talk a lot to maintainers, I talk a lot to folks about this. It’s we’re— we rarely start like a process and a practice and like push it onto the community. We usually wait for the sort of like RFC process socially or literally, everyone agreeing, and then we’ll cement something in. Because otherwise we’re

Maintainers, RFCs, Vouching, and the Social Layer of Trust

Swyx [00:31:35]: That fits your role in the ecosystem, yeah

Kyle [00:31:36]: We’re GitHub. Yeah, we don’t want to shape the whole thing. We want it to be figured out. But like how do you balance that like sort of Role in the industry to keep everything as secure as is possible and make sure that you’re you’re not going to be compromised as a human, ‘cause that’s usually how it all happens. And Not not create a process or lock us into a flow that you’re not going to or like Mitchell’s not going to or other open source projects aren’t going to like. That’s always been a tricky balance for us, and I think that’s something that we haven’t talked about enough is we’re not going to be able to fix everything for everyone in a way that everyone is going to like. So tell, help us, tell us what is working. When Mitchell was talking about, the Upvote, the up

Swyx [00:32:22]: I was going to bring up his thing. Yeah.

Kyle [00:32:23]: I forget what it Yeah. When he’s talking to us, I was chatting with him and talking to him about this and I put it on Twitter and we talked to, also over DM, was “We’re going to keep working.” but I think the important thing is I do actually want to hear what isn’t working for you. And as, be as specific and clear for your project as is possible. And to every piece of credit over the many years that we’ve known each other through the industry, he’s always done that and I appreciate that ‘cause there are places that we need to fix up, and we hear from him, and we’ll fix up just like we do all other kinds of maintainers. But that that process between making those types of improvements and being more secure and like creating, I forget what he calls it’s not the proof process, not the claims process. Do what I’m talking about? He has that he his projects have a way for you to kind of like,

Swyx [00:33:13]: Vouch

Kyle [00:33:13]: Vouch. Thank you. Yeah. He has like the vouch system for saying, “Hey, you should accept my PRs.” That’s been

Swyx [00:33:20]: I just built this into GitHub. I don’t know.

Kyle [00:33:22]: Well, see, but that’s the thing is that you say that and like he and his community really likes this and then I’ll go talk to other maintainers and other maintainers, globally, and they’re “No, this doesn’t work for me.” And that is the tension, but also the kind of beauty of GitHub, depending on which way you look at it is we want to help maintainers, so we create all these tools to let you have more control over how much you take in from AI and PRs. But you can also use this. What You can go use this project, and if it takes off and becomes the kind of mostly standard, then yeah, we probably wouldn’t enforce it but we would add it in because that’s the flow that we tend to do?

Swyx [00:34:02]: I hear a lot of people don’t know the history of the pull request. And like like that’s how, that’s something that GitHub standardized basically.

Kyle [00:34:08]: Yeah. It was a very messy process Like beforehand, and now the we have the benefit of it being the process? And now we have to go and Figure out the next best process or what adaptations change, or what does a pull request look like when eighty percent of your PRs are just coming from your agents and not From other devs?

Swyx [00:34:31]: Do you like the prompt request idea from Peter?

Kyle [00:34:34]: like I think that for each like each idea I think has its merits. I’m not, I’m not avoiding saying anything good or bad, but I feel like I’ve seen a version of we have that we have entire Thomas’ store. Take all the assets of what you’ve built and put that in. I think that’s got great ideas. There’s all these various permutations of the PR flow, but I think the reason why there’s not a single answer is ultimately we’re trying to codify trust. We’re trying to say “Okay, if Sean reviews this I’m going to trust it because you’re Sean or you’re the senior dev or you’re the whatever.” And right now, when we are working in a flow where an agent writes code and another agent reviews code and then Kyle goes and looks at it the trust is kind of diffuse. And most of the tools that we’re talking about are talking more about verification flows. We have more assets to look at, so I can probably say whether this is a good PR or not. But that still doesn’t solve, I think, the human problem of I’m looking at a PR and I want to know if I can trust it. And we’re still, we still tend to use human signals for that? Mitchell approving it or Kyle approving it or whatever. And so I think that’s, I think that’s why most of these options haven’t really solved it is because, it’s a social problem ultimately. It’s a it’s a human problem to review it and agree. Or you fully trust the tool and you’re imbuing that tool with full trust Which I think in some cases that absolutely exists.

AI-Generated PRs, Trust, and the Waymo Analogy

Swyx [00:36:08]: And so like in the same way that there will be a tipping point in society when we don’t allow humans to drive anymore Because machines are measurably better than Than humans. I’m looking for that tipping point, right? Like Mythos is ridiculously expensive. Someday we’ll have Mythos on a desktop. I don’t know. Will, does that change the equation?

Kyle [00:36:30]: I think it’s more I took a Waymo here, and I was on my phone and not looking around at all. There are other, self-driving, vehicles that I would not trust while, staring at the road. And I think that trust is something that is

Swyx [00:36:48]: Is this a Zoox thing? What is it

Kyle [00:36:50]: I think that is both. I think that is both. Like

Swyx [00:36:53]: There’s Zoox in this robo taxi. That’s it. It’s

Kyle [00:36:56]: Well, depending on what level Of self-driving. But, my point is sort of that I think part of that is I strongly believe that’s, a mixture of verifiable proof. Like how many accidents, how much data, and so on, and the human aspect of how I feel when I’m in this car, what it tells me, et cetera. And so that’s why I think some of the like Some of these some of our AI tools tend to, imbue me with more of that feeling of trust, even if the data says this is 100% accurate. I feel like it takes more time for us to go, “Should I trust this or not?” And that’s in the soft sense of, startups with high agency, weekend projects, and open source. And then there’s enterprises and regulated industries and everything else, and that is an even harder problem to go solve because even when it is fully verified, not only do you have to have trust from the humans on the team, you probably have to have trust from multinational,

Swyx [00:37:55]: Oh my God

Kyle [00:37:55]: Multi governments around the world and regulating agencies. And so that’s where I feel like until we tip over to your point on the sort of like human EQ side of it. I feel okay this feels okay I’ve been proven enough. Then the ball will start to roll a lot faster, where we’ll end up getting to the “Okay, we can trust this,” and feel good about it in the Most difficult of cases.

Reputation, Sponsors, Stars, and Bot Activity on GitHub

Swyx [00:38:18]: If human trust is the thing that matters, I feel like GitHub as the developer social network could maybe do more there. Like vouchers are one system But, we have star counts, and then we have Contributor rights, and that’s it. And I feel like there should be more in that space. I don’t know if there’s any other design decisions there.

Kyle [00:38:37]: I think that one of the places that we don’t really expose right now in this sort of way is, some degree of like hard trust and support, which would like for me is like sponsors is a good example of that.

Swyx [00:38:49]: Ah.

Kyle [00:38:49]: It like costs you something. To prove that I believe in your project and I trust you To some degree or I want to support you at the very least.

Swyx [00:38:56]: Solve payments for open source. Why not?

Kyle [00:38:58]: I think that I think that like as we keep moving forward, right, there’s more and more projects where I’m, adding more and more dollars into sponsors personally because I want to like support them, but I also like know of I’ve probably never met them in person, but, I know of enough of their work that I want to support them. I think the thing that I don’t love about stars or commit counts or anything else is ultimately, even with all of the various, abuse and de-spamming and deduplication work that we do or anti-abuse work that we do, these are all, not active social signals. They’re passive ones that are ultimately gamifiable. And you may trust me, but another open source maintainer may not. And on what heuristic should you be, trusting me? That I think, is kind of where some of our thinking is right now. What signal from me is most important to you? You— If you can define that potentially, honestly in an agentic workflow that’s what we see some of these open source projects do, where you have GitHub actions, and then you have like an agentic workflow that’s calling AI, and you’re setting these rules. Like if Kyle has submitted and gotten accepted PRs across any given project and has a social handle tied to his account in GitHub, and that social account’s older than a certain amount. Really complex measures that matter to you ‘cause most open source projects have that heuristic built into their heads, if not written down in the contributing guidelines. You could take that and then go apply that and then just say, “Oh, we’re not going to accept this PR.” Building something that is, I think, malleable to everyone’s needs, is a little bit better, rather than going “Hmm, this account’s too young.” Because what happens? The attackers just go and go and create a multitude of accounts, and they wait Until it ages up. Needs to have a certain amount of stars. That’s how star inflation happens. Need to have a certain amount of repos

Swyx [00:40:46]: Oh my God. Yeah

Kyle [00:40:47]: With PRs. They all just create repos and submit PRs to each other, and then they come in and do something nefarious. And so, it’s hard. It’s hard to find the measure. So I think we’re, we’re looking more at how can we provide you tools so you can kind of choose what’s best for you. And of course, we’ll give you some standards. But the trust vector, gets down to I don’t know, some version of like human digital ID like everyone’s been talking about. Like how do I prove that it’s me

Swyx [00:41:13]: Give me your eyeballs

Kyle [00:41:14]: On the internet. Give me your eyeballs. Exactly.

Swyx [00:41:18]: The I got to keep moving on Topics, but obviously I can go all day on this stuff because, I’ve been involved in GitHub and open source My entire professional career. Stars. Very superficial. Everyone knows it. But I think time to one hundred thousand stars is the fastest I’ve ever seen. Like people just reached that in I don’t know, months. And then like at the same time I don’t trust it right? Like how many of these are real or bot or like whatever. I don’t know how to ask this but like what can we do about it? Like

Kyle [00:41:49]: Just

Swyx [00:41:49]: Is stars broken? Is stars fine?

Kyle [00:41:51]: I think that there’s kind of two, there’s like two pieces. Obviously we’re constantly like trying to find ways in which like your users are producing spam, which would, I would include like be like only doing star gamification. When we find them, we pluck ‘em out and we,

Swyx [00:42:08]: But it’s like a Whac-A-Mole

Kyle [00:42:10]: It’s a hundred percent like a Whac-A-Mole

Swyx [00:42:11]: There’s no way

Kyle [00:42:11]: Now, powered by AI to be helpful. But I think more so what I’m seeing is, a lot of the like fastest time to X tends to be because we’re now inviting so many more people into like software development on GitHub That like the zeitgeist is just swarming? And it’s

Swyx [00:42:32]: It’s not just developers anymore

Kyle [00:42:33]: And it’s not you and I. Like like however you want to say like what a developer is it’s not just folks who have been coding for a very long time. It’s folks that have maybe started coding or only joined in since the AI era. And now

Swyx [00:42:44]: what’s the latest Octoverse number? I know eighty million was my lastRem- member that a number of developers on GitHub

Kyle [00:42:50]: Oh, we’re over 200 million now.

Swyx [00:42:53]: Okay. Well, so you see?

Kyle [00:42:55]: Like over 200 million developers now.

Swyx [00:42:56]: But it’s not developers, right? It’s, it’s people with a GitHub account.

What Counts as a Developer in the AI Era?

Kyle [00:43:00]: So, so this is, this is the biggest debate that I would say, everyone loves to have at GitHub at this point. From my perspective, right, I think that there’s, there’s clearly a difference between, professional enterprise developer and then developers. But I think that I think that the idea that we should be I don’t know, splitting hairs or segmenting developers in the early era of software development is, not worth our not worth the time. So

Swyx [00:43:29]: When you get into gatekeeping

Kyle [00:43:31]: 100%

Swyx [00:43:31]: What is a developer?

Kyle [00:43:31]: 100%. ‘Cause I wasn’t a developer when I started writing code? I was going to

Swyx [00:43:36]: Oh, no. I made— I cloned a thing, seven years before I learned to code. And then I and then I wrote about my learning to code journey, and people Just called me a fraud ‘cause I had a GitHub account. And I’m “Well, no, I just use GitHub, but I don’t know-” “I didn’t know what I was doing.”

Kyle [00:43:49]: I I remember that. I remember those sets of posts, and like that’s, that’s b******t. So I fight very clearly on the line of, if you create code, if you have an idea and you create it into some way of, I’m, I’m going to run it and use the app right now, you may still use AI in that moment, but that’s okay. At some point you’re going to do the next thing. You’re going to create a big— You’re going to have to learn about this database. You’re going to fix a bug, whatever. We’re all on some same journey, and those people are also hearing about the great new agent skill package or a new CLI tool or a new whatever. And those projects are going up because you want to be a part of this moment, just like I wanted to be a part of the Ruby community when Ruby was popping off when I started becoming a developer, and now I can just click the star button. And so I think that yes, there’s clearly some amount of like spamming and game gamification that we’re working against, but I really think we’re just seeing this whole new cohort of folks that are moving from technology to technology because they’re not working on a 20-year-old software application. They’re working on a side app that they built on the weekend for their friends or for their new idea or whatever. And that’s how you see these enormous charts going up and to the right with With stars.

Swyx [00:44:59]: I think something that’s remarkable is the persistence or, that GitHub extends to those folks. Usually when I see platforms go into a new audience, they usually have to, have like a second platform with a different name that wraps the main platform. But somehow GitHub has been able to sort of persist and extend, and it’s friendly and whatever? So it’s, it’s nice.

Spark, Low-Code, and Always Showing the Code

Kyle [00:45:19]: I that’s partially why I think as we’ve tried to move into I don’t know, more like low-code-y things. We so we started working on Spark as like a way to, build an app and run it. I think that the reality is that we anytime we try to, kind of put even a veneer on top of it without when we put a veneer on top of something, we still always show you the code. That’s kind of like a tenant. We’re never going to, hide the code from you ever, because what

Swyx [00:45:52]: Why would you?

Kyle [00:45:52]: That’s, yeah, that’s the whole point? However, I think that what we learned with things like Spark is that really the value of Spark for most devs is, easy runtime. And you may have a runtime or a host that you’re going to use for that or you just build something and run it but, the package of making that even more simple isn’t really needed for folks that are trying to build software and not just trying to build, an app, which is, slightly different, a slightly different goal. So I want to get you in, I want to get you comfortable. I think the best thing for me as, someone that did not traditionally come into software dev way back, I want anyone to be able to breach that chasm and not be in the I don’t know, I feel like we’re, we’re still in an era of, STEM. I’ve got a 12-year-old and an eight-year-old, and it’s “We got to get ‘em into STEM,”? Over and over. And I like I do, I do the things that good parents do. I was “Oh, you want to do coding?” “Yes, I want to do coding.” Do coding classes. But now they’re just not afraid of doing software. And that’s, I think, the thing that’s honestly kept me at GitHub for so long. Anyone should be able to go and build a thing, just like I can go change a light switch in my house. I’m not going to go into the breaker box ‘cause I’ll probably kill myself? But, I can go change that light switch. Everyone should be able to go and say, “This fricking app doesn’t do what I want. I want it to work like this.” And that I think, is what’s kind of kept us all connected with GitHub through the years and some and during the easiest of times or in the hard times because of that opportunity of, we’re the home for all developers, and we want everyone to be able to have that feeling that we’ve had of, had an idea, I created it and holy s**t here it is.

Swyx [00:47:37]: Here it is. All right, I’m going to try to do more spicy questions.

GitHub’s Hardest Scaling Moment: Growth, Agents, and Uptime

Kyle [00:47:42]: Great.

Swyx [00:47:42]: Is it an easy time now or a hard time?

Kyle [00:47:45]: Oh at GitHub? It’s a hard time. Like, it’s a hard time and also, I was just with my team and I said, “This is also, the best and most exciting time that I think I can remember at GitHub.” Because

Swyx [00:47:57]: Best of times, worst of times. It’s never one

Kyle [00:47:59]: ‘cause we’ve we were talking about Octoverse reports and, usually we do an Octoverse report once a year, and we look at the numbers, and we say, “Oh my goodness.” I was at Universe in October saying, “This was the fastest year of growth that we’ve ever had,” right? And now we’re doing more in a month than we did in a year last year.

Swyx [00:48:20]: You’re talking about PRs.

Kyle [00:48:21]: Commits.

Swyx [00:48:21]: Commits, yeah.

Kyle [00:48:22]: PRs. Kind of like you name i