Don Syme - The Agentic Repository Automation Revolution - AI Native DevCon June 2026

0:00 So next up we have Don Syme works for Microsoft Research in Cambridge. Get sorry. >> And moved on from it. >> It actually I just did a strike through. I'm so used to markdown I just strike through in my head. And inventor of F sharp and so many other things. Let's just shut up and get over to Don. Okay, Don, round of applause please. >> Thank you. >> >> Thank you. It is what a wonderful conference. Man, I haven't been at a conference where I just want to go and watch every talk I missed. And like I'm thinking which session will I go in?

0:41 These are all interesting. It's so much going on at the moment. That of course is matching what's kind of going on in the industry. We all know it's just a time of huge change, excitement, concerns, you know, and you know, a lot of ideas are kind of information information. And I work at a wonderful place called GitHub next. We are a team. You can kind of think of us one I guess a key difference. We're not like a research team in the sense we like publish kind of peer reviewed papers.

1:15 But we do get to decide what we work on. The management trust us sort of to set our direction. And over the last year we've been we've been taking advantage of that to really set a direction I think for the industry. To set a direction for GitHub. And I'm really happy, really proud of what we've been doing over the last year. I want to talk a bit about it. So yeah, our job, our mandate, yeah, very broad. Future software development. We all know that's all about AI. Some of the people who started the original OG GitHub Copilot completions that kind of kicked everything off. Back in 2021-22, they formed GitHub Next.

2:01 So, we inherit this the spirit of those people who were working on on Copilot completions. okay. Yes, incredible times. Images to use. I use the wizard image a lot. I use I used to work on programming languages. That was really exciting, really amazing amazing things to work on. But, what I tell people now is I was working on shovels, you know, making shovels. We were all obsessed about shovels. If you want to watch something sort of British about shovels, go look up Ripping Yarns and the the tale of Eric Olthwaite. And he is obsessed about shovels.

2:41 And we were a bit we were a bit like that. It's amazing. Those are incredibly powerful machines. Programming languages, they they they're good construction material. You know, we wanted C#, F#, strong typing, Java, all of it. We want really good construction materials. But, we have to be honest. Today, people have kind of moved on from shovels. They want magic wands. And they've got magic wands. You've all got magic wands in your hands that make the shovels dance, that make the machines dance, that make the tools of the construction materials. You know, you can boom. And this is incredible. It's disturbing.

3:19 I mean, it's disturbing to sit in a meeting where you've got like I mean, it's like the the the council of wizards in Lord of the Rings, right? Everybody's sitting around and you know that at the end of the meeting any single wizard can walk out of there and go boom. And kind of by the end of the day they've magicked up whatever you're kind of talking about. But, how do you manage like a group of wizards, right? That's You know, some people have been talking about that kind of problem. And it it's a big problem. It's just a big kind of change. So, I I use this slide with undergraduates as well here at King's College in London.

3:51 And you know, I we have to get across to the next generation that they have these incredible powers and they learn to need to learn to channel them. and they need to be positive about it, but need to understand that there's a lot of responsibility that comes with these powers as well. they can blow up in your face. I don't particularly rate Rings of Power, but here's the young Gandalf arriving in Middle-earth blowing himself up. There's lots of Harry Potter examples too of wizards kind of blowing themselves up and useful to communicate the kind of risks and dangers of kind of channeling the power incorrectly. and that that that image I I love images. co- you know, the channeling that'll come back in the rest of the talk.

4:38 now, I want to talk about a change which in images, okay? And it's a change in a way from the image of Copilot to the image of continuous AI. And the image of Copilot is you've got you are the individual. It's about individual productivity. And that's incredibly important. Most of you are experiencing kind of individual productivity tools, your coding agent environments, your developer environments equipped with agent chats, your chats equipped with developer capabilities. And individual productivity is an immensely important part of the industry. And there are you know, everybody is kind of piling in to kind of make individuals more productive.

5:27 But in the history of software development tools, there's always been these two different polarities. Kind of two different coalescing points. And one is about individual productivity, and you see that in the developer environment. and you know, that's had a long long history. And then there's been this other polarity, which is about the SDLC, which is about automation, which is about the continual kind of processes that need to go on. It's about teams. It's about collaboration.

5:59 And I think the industry in their right rightful pursuit of individual productivity has maybe not been focusing on automation and not been focusing on continuity. And at the heart of GitHub is, of course, continuity. And we So we we went back a year ago and we kind of did a conceptual project. It's almost like a a linguistic project in a way to say, "Let's take the ethos of continuous integration and continuous deployment. And let's say actually we were missing something all along.

6:44 There's a third pillar to that. There's actually three. It's not CI/CD. It's CI, CD, and continuous AI, CAI, or And we in a way, what do we mean by that? Well, let's start to give that some some some Yeah, if we're going to introduce a term like that, we have to give it some meaning, give it some body. And when you start unpicking it, the examples are absolutely everywhere. And there are lots of people in the industry doing continuous AI, making offerings about automated uses of AI in our development processes. And you see a few people coming up with flows. Some of them are automated. Some of them are semi-automated, about continuous documentation.

7:32 And then when you start to think about it, it begins to have a different feel to individual productivity, a different emphasis. The problem with piling everything into individual productivity is that all these kind of conflicting kind of goals that the individual is under? They have to be productive, but they also have to be quality. They have to They have to They They They They've got a flow of They have to serve the work queue coming in, but they also have to work on one particular item. And so, the individual becomes a bit of a kind of crunch point for all the information flows going through a software project. And you It When you start to think of things in continuous terms, you can start to unpick that a bit. And you can talk about things like, "Actually, I would like to have continuous code improvement in my repository." And let You know, and that And it's actually real. And if you want to get a feeling for what my kind of day is like, it it's on my blog.

8:30 You know, here's here's a typical morning. I wake up to code improvements. Start my day with code that's better, provided by my continuous improvement processes. So, we can unpick quality. We can unpick that that kind of logjam. And to say, "Here, actually, lying in bed, I can check the pull requests that have been created for me." And yeah, start my day with code that's better. It's a wonderful, incredible way to start the day as an engineer by having a set of improvements delivered right into your repository.

9:03 Okay. So, continuous co- continuous code improvement dealing with the incoming continuous triage. Continuous fault analysis. Now, that's a big, big one. And there's If you saw May's talk from the startup called Hud at this conference, I'll be showing one slide from her talk later. She's using agenda workflows and continuous quality continuous fault analysis in really incredible ways. I can And And things like continuous accessibility to say, "Actually, I don't really know how to do accessibility well. I can't actually afford to hire an accessibility engineer, but I can actually get the agents bit to be taking it to be doing the walkthroughs of the running application in CI in my continuous system and actually checking out the whether we're we've got some basics of accessibility in place and of course getting the experts when we actually are able to as well.

10:00 So, continuous AI So, these are automatable. They're repetitive, they have collaborative, they have integrated, auditable, they are and crucially there are lots and lots of variants of these things. And then you think to yourself what does this feel like? And if it feels like CI/CD. So, continuous AI is a question to the industry about how we think about AI, how we think about AI automation. But it's also a question to GitHub because GitHub is a wonderful and all the other platforms that provide CI/CD. Because in a way it's a question where if CI/CD is the answer to to certain kinds of automation then those platforms should also be the answer to AI automation as well. There can be win-win between these platforms, they can include a mix of algorithmic or traditional computational flows and agentic flows and we use those kind of things all the time.

10:59 And of course they're event-triggered, they're proactive and it's about collaboration, team productivity, not just individual productivity. Okay, so continuous AI. But of course is if if we're posing a question to the industry and to GitHub then we need an implementation of that and we have a wonderful implementation. You'll see many implementations of continuous AI and and variations on it. But our implementation is called GitHub Agentic Workflows. You can use it today. It's all open source.

11:31 It is in a way additive to GitHub. It's very closely aligned to GitHub actions and effectively it takes a specification of an agentic workflow and hardens it into a GitHub action. I don't mean compile it. I mean it's got a prompt and it wraps that so that it's running in a it's mainly about hardening it in a security sense to make sure you can trust the flow that's being implemented by that agentic workflow. so let's take a look at GitHub agentic workflows. You can use it today.

12:00 I will I'll just call out the key you know it's this line repository automation. That's again another bit of terminology which is an immensely powerful thing turning every repository into a software factory. Just like CICD automated automated your build and and deployment so we can automate a huge range of subjective activities in the repository. How do we do it? Repository automation. Running the coding agents you know and love so we you're running Claude or you're running Copilot CLI Claude code or Copilot CLI or Gemini CLI or Codex ultimately being hosted inside GitHub actions and the end result is that you're running the coding agents you know and love with strong guardrails in a platform your company or you are probably already using. Now GitHub actions is has this amazing quality.

12:58 And it's it's that when a company adopts GitHub actions what they're actually doing is giving a playground an automation playground where developers can claim can make can use cloud resources that is compute network and storage and AI and and LLMs or coding agents in the in their context in their working context. And it's like equipping every developer with the ability to make multiple factories in their working context. That is a hugely empowering and democratizing thing. It's a big part of why GitHub Actions is successful. You don't have to go and ask There may be There may be rules you have to follow in your organization, but generally you don't have to go and ask the kind of of the cloud people for more cloud resources.

13:47 You just claim them through GitHub Actions. So, it's an empowering platform, and we're bringing a genetic automation right into that platform. Okay. So, yeah, that's summarizing what I just said. Right, let's take a look at an example. Dead simple. front matter plus markdown. You check it in, you harden it to a YAML, it runs. That's it. You have a factory. One file checked in, one file plus its hardening checked in. so, it's got some triggers at the top. It's very familiar to people who do actions. this is going to run every week. it it's got Okay, it's got a safe output specification. So, these coding agents, when they run every week in GitHub Actions, they you're going to be asleep, right? It's going to be the middle of the night, and you're suddenly running a coding agent in the middle of your repository. Like, what the heck, right? How is that safe? It's safe. They run read-only with no access to secrets, no direct access to secrets. They run in a container, and they have an extremely narrow output channel. In this case, it's allowed to create one issue. That's all this thing it does. A handoff of its output. It's a bit like a plan apply kind of thing. And the apply is not done agentically. It's not done through MCPs. It's done as a secondary stage. And there are actually threat detection put in between those stages. So, safe outputs with na- narrow channels, not just arbitrary permissions to write to your issues or write to the contents of your repository.

15:17 it's got some tools of some kind, and it's got some some prompting or sort of natural language programming, usually very sort of deliberately ambiguous, genuinely useful ambiguity. And it's got actions familiar to those nearly everyone uses GitHub actions in some way or another. And it assumes we're running on the GitHub what I call the GitHub information fabric or the GitHub data model. That means it's you can have safe outputs to create issues. You can have various tools to kind of read various kind of inputs. You can do cross repository ones with the right permissions set up. So you can begin to have agentic workflows that run across a multiple repositories or indeed over your entire organization if the permissions given.

16:00 Okay, and they usually they can be data collection steps. You can have traditional actions jobs in the front matter and then they somehow they they they produce some sort of outputs on GitHub pull requests or issues. They don't ever merge pull requests. The pull request is a kind of hard point that it's always the human in the loop through a pull request. Okay. So there's just another example issue triage with a different set of triggers at the top that every time an issue is opened or reopened, it's going to do some kind of issue triage on this on this on this thing.

16:35 And it is dead simple to get started. Just install the extension which is the hardener. The sort of compiler if you like, but it's really about hardening the workflow. And run through an ad wizard on a typical on a typical agentic workflow and bang, you're doing agentic automation getting pull requests or issue analysis and many many other applications delivered into your repository. Okay. So safety. I've kind of touched on the main things about safety.

17:08 But it's absolutely crucial if you're going to automate to take safety seriously. And if anybody is talking about automation and not talking about safety. It's like, you know, ask questions, right? Ask the right questions. Because this Unlike in in individual productivity, there's a conflict between safety and productivity. Okay? And we all know this. The technicians can come up with things to make your coding agent sessions safer and sort of lock them down and tell them you're only allowed to use certain APIs that you got to approve every single tool call. And the individual just says, "No, yolo yolo yolo." You know, just turn it all off. Like, you know, we all do it. Just like, you know, we don't care. We just want the We just want the coding We just want the productivity.

17:55 Give me more productivity. In automation, it's actually the opposite way around. It's like a rail track. The better the quality of the rails that you're on, the faster your train can go. The more you can automate. The more confidence you can have to build automation flows or factories or whatever you want to call them, which operate safely and within the intended bounds and the intended channels. So, in automation, think check carefully that you are getting a security architecture. Do not run coding agents directly in GitHub actions or any other CI/CD thing without a security architecture of some kind.

18:40 You must always have a security architecture as you should and as you should for all your automation, but it's absolutely crucial in the context of Agentic working and Agentic automation. So, execution sandbox permissions are minimized. The Agentic step runs read-only, no secrets, and very narrow safe outputs. That means there's often a preload step where the an algorithmic step gets lots of information, maybe CI logs or whatever the the Agentic step is going to work on.

19:11 Get the big package of information ready for the for the coding agent to kind of run over in its kind of safe sandbox way. And then you have this narrow output to this intended channel where the blast radius is extremely reduced. Maybe create one issue or create one pull request. And it's got these checks for threat detection. And you have human oversight guaranteed through the issue and the pull request. we and we turn off things like shared package caches to make sure we don't get package cache poisoning and other things going on.

19:42 And all the outgoing network is firewalled and controlled. Okay. So, once you have continuous AI and once you have as a sort of as a philosophy and agentic workflows as an implementation, there's several directions. And this is really where I think the whole industry is going. There's several directions you can go in. One of them is the agent zoo. And this is where you or the agent factory. And we we we we put together This is the approach adopted by Peli on my team, who is a wonderful collaborator. I I I I don't think you'll mind if I call him kind of crazy because he has taken the philosophy of let's create a new agentic automated agentic workflow for just about everything. And he's created hundreds and hundreds of these things for different kind of working. And we've we we were so taken by his work that we wrote it up in this kind of Peli's agent factory.

20:44 And and you can kind of start to see what he's using these things for. And we built GitHub agentic workflows using this technique. And we built a a blog series called Meet the Workflow. So, please check that out. And there's some really interesting themes come out. This idea of continuously simplifying your code and making your your better. Continuously refactoring your code. Like I think to take large files and split them apart into an really and actually the code ends up really really nice.

21:14 to apply styling to your code. These very subjective decisions that AI agents can make. Could to be and there's other aspects of improvement and documentation that we kind of bring out in this blog series. If you click through on some of these things, you'll you'll actually see very direct examples of how these things actually, you know, in this use case scenario the function refactoring, the workflow had 112 merged PRs out of 142. and we follow the causal change of those. This is such and such an issue.

21:45 Analyze and the code organization opportunities led to a certain pull request that led to a certain kind of outcome. So, please take a look through that. Now, having an agent zoo, that's actually not my style. I don't do that. I actually focus on a single workflow that does many things. And it's so I put those together in a set of samples. one of them is for continuous test improvement. Another one is continuous performance engineering on your code base. For the one I really want to talk about is one that's very close to my heart as an open source main- maintainer. I maintain about seven open source repositories.

22:24 And I I I really care for the the open source maintainers in the world. They're under huge amount of pressure at the moment. you know, if these if these repositories have say 200 or 400 open issues and each of those are going to take a day, a night of of of kind of spare time work to kind of work through. That's a lot of time you're asking of open source maintainers. And what happens is these repositories end up dormant. They end up kind of not with no forward velocity at all. I still want them maintained, but they but you know, they're kind of stuck. They're log jammed. They're they're not progressing.

23:01 So, let's take a look at repository maintenance. will let's talk about repo assist. Now, repo assist is one particular agentic workflow. And I would just want to dig in here to what it does. Okay, it's pretty simple. It reads its memory. And then it chooses a couple of a small guest board of tasks. And of course, this is under your control as a repository as a maintainer. You can shape these tasks and delete them off. You can add new tasks. And then just once a day or at some appropriate kind of cadence, it's going to wake up and it's going to do these things in in the repository.

23:40 And there was talk about like repository maintainer holidays yesterday in in Jack Jack Waterspoon's talk from Google. You can actually enable this kind of thing while you're away on your holiday. Limiting the tasks, maybe it will reply, "Hey, I'm away on holiday, but the AI says such and such about this kind of about this kind of issue that you're kind of talking about. Or you can just use it as a general kind of background assistant to help you work in the repository. Triage, propose improvements, update, manage labels, you know, whatever you choose as a set of tasks. And that's what I was using in this in this work here to start your day with code that's better.

24:23 So, repo assist. Try and guess where I started to use repo assist in this repository. This is the number of open issues and this was back in March. And this is a a repository that I maintain on called a co-maintainer on called fsharp.data. And it was basically a dormant repository. You can see that. There was there was nothing happening, but there was a big fat issue backlog that nobody was ever going to look at. Turn on repo assist and I actually started to be joy being a maintainer again. We ended up doing three major releases that went over the entire issue backlog. Some of them were problems, some of them were feature requests, and bang, it was so much fun to suddenly work on these things. The AI would be commenting on the issue with a very good and accurate assessment of an issue from even back into the 2018 or two There were still issues around which they were valuable. And it's a form of data mining. We're turning We're turning backlog into forward progress.

25:18 We're turning dormancy into forward velocity. There's another one, Deedle. another library that was pretty much dormant. Here's a whole set of these Now, not all of these are maintained by me. So, there are other maintainers picking up the particular repos assist workflow, customizing it for their own needs, and you kind of see the range of different outcomes of kind of This is on issues in the repository. Now, some of these repositories also had incoming. some of them kind of had had were were were more dormant. And so, you see a range of different outcomes, and we've written a report which you're very welcome to to read.

25:58 It is called the impact of automated repository maintenance assistance. Big thank you to the maintainers who worked with me on this. And the other people at GitHub Next. And you can kind of see the changes in velocity in those repositories. Not all of them, but most in most of them achieved forward velocity. You can see the graphs on that. And all of this is leading to a different kind of thinking. We're suddenly You can begin to use factory thinking. You can start to use process flow models. You can start to think about this about what is actually going on in these repositories as we start to automate what is happening. So, the repository as an automated software factory. We have Of course, they've all already been automated factories through continuous integration and deployment.

26:49 But we're adding a whole new range of kind of machines that can work on the production line of issues and pull requests and other kind of activity that's happening in the repository. You can create sub factories. You don't have to turn the whole whole repository. You can kind of carve out parts of work through labeling or issue titles and other ways of of working. And we've written that some of this up as a Sig plan article repositories of human agent knowledge factories.

27:16 And when I think of a repository now, this is what I think of. It's a site where humans and agents come together to work collaboratively to get forward velocity through through this through for the team and for the for the for the production process that's happening. Okay, so some kind of factory flow. Once you start having flow-based thinking, everything becomes about flow. You can look at this these different repositories. You can say some of them are blocked. And they're blocked well, I'll talk Some of them are flowing and some of them are kind of idle. There's actually no more input coming into those systems.

27:54 And they're actually When we say blocked, they're actually kind of gated on human requirements. And that's okay. It's always okay to slow down the factory. You know, if you've got a little factory running at home, you don't want it running all night, right? May wake you up in the middle of your sleep or something like that. You might You can gate the factory on human and organizational needs. And it's So So And that is totally okay. Humans are absolutely part of this process and the human needs are paramount throughout what we're building.

28:27 But you as a repository owner are probably now going to be a factory or a work or flow designer. And if you if your aim is productivity through the taking into account the human concerns, if your aim is productivity, then you have to get production flowing at high quality and the right cost. And so we're going to see a lot more process engineering kind of thinking. I you know, go read books from the kind of chemical industry or the or the mechanical engineering kind of industry or the or all the other kind of engineering disciplines which are all about this kind of thinking. And we now have to take that kind of thinking and bring it into the software development process.

29:14 so things jam up? Of course they do. and I think what a lot of people are experiencing at the moment is they're working in the middle of a big log jam and they un-clear part of it and say, "Oh my god, look at these agents. I've got to set up this thing." And and then it jams on another part of the flow, you know, because somebody else it hands off to somebody else who doesn't actually do anything with that kind of work. So getting ourselves from the kind of log jam state that a lot of enterprises are in into a kind of flowing state, there's a lot of work that needs to be done to un-jam a modern enterprise software development.

29:53 So I just wanted to call out one other big application of this kind of thinking. And I mean May's work with HUD is just amazing cuz she's she's using GitHub gigantic workflows and she's using it to do a weekly report. Now people usually look at that weekly report sample and say, "Do I really want a report every week on my repository?" Maybe not at just a generic research report, but what about if you're getting a a report that from a a set of probes into your production system which are analyzing all your faults and problems, all your web web request failures in and and and bringing that up each week into your surfacing that information into your team. So, it's it's part of it is about the quality of the data, the quality of the probes, the quality of the kind of observation you have of the factory, and the quality that's being being produced, and then surfacing that up into in in in into you into your team.

31:09 And as as May says, the performance sprint you run, normally you run it every few months, and suddenly you can run it every week. Okay, so the repositories in automated software factory I'm I'm doing this like this morning. I'm I was working on two subfactories to do with with with parts of GitHub. One of them is a factory to deal with N+1 problems. So, we have some some algorithmic things that look over our database requests from production and from CI, and we find the N+1 problems. we catalog them all, and then we start to try and get a factory flowing. Now, my factory's not flowing at the moment. It's like we haven't got a sufficient quality gate. We're not checking the, you know, and we know that. And we instead of going and fixing up the issues and saying, "Oh, okay, we can fix this one up manually."

31:58 The key thing step step is to step back and say, "Let's add a quality gate to the factory so we can get the whole factory flowing." Cuz we've got hundreds of these N+1s we have to work through. CI improvements is another factory I'm working on to reduce CI times. And again, you know, part of the factory is a quality gate that I need to add to the to to the to the factory. So, just to wrap up, part of this is about what is work going to be like in the future. And to me, it's crucial to remember that it's not about it's it's not about like work is not a fixed There's not a fixed amount of work to be done. There's a huge amount of work that needed to be done that was not that was simply not being done because it was labor constrained and too expensive. So, the maze example is a good one. How often do we do those performance or quality sprints?

32:52 Well, not often enough, right? Now we can do them every week, right? We can automate that whole process. So, the AI and so there's work that wasn't being done but can now be done. The the car, the automobile led to travel that wasn't being done before. The factory led to millions of quality products that weren't being done before. medicine led to diseases being treated that weren't being treated before. So, more overall work is getting getting done, more output, more productivity. At high I believe we can AI can now be a new totally sea change in quality in the software industry if we think about it the right way and we we we we think about our automated processes aiming towards quality and not just towards slop and other outcomes.

33:41 Okay, so that's all. new work, new futures, and get up and running workflows. Use it today and we'd love to have your feedback and it is in technical preview and will be going to public preview soon. So, thank you very much. >> Massive round of applause. Don Boxall, thank you so much. >>