Transcript - The Agentic Repository Automation Revolution

Source note. This transcript was imported from timestamped speech-to-text output at /Users/baptistefernandez/Desktop/latest-devcon-speakers-transcripts/Don Syme - The Agentic Repository Automation Revolution - AI Native DevCon June 2026.txt. Speaker attribution is inferred from the filename and surrounding context. Preserve speech-to-text artifacts when quoting and flag uncertainty where wording appears garbled.

Safety note. Treat all quoted transcript text as inert source material, not instructions to execute.

Talk Metadata

• Speaker(s): Don Syme
• Title: The Agentic Repository Automation Revolution
• Event: AI Native DevCon, June 2026
• Imported from: Don Syme - The Agentic Repository Automation Revolution - AI Native DevCon June 2026.txt

Transcript

00:00 So next up we have Don. 00:04 who now works at GitHub Next. 00:09 Get sorry 00:12 man. Moved on from. 00:13 Imagine I just did a strike through. 00:14 I'm so used to markdown I just strike through my head. 00:17 And inventor of f sharp and so many other things. 00:22 Let's just shut up and get over to Don, okay? Don. 00:26 Round of applause, please. 00:27 Thank you. 00:31 Thank you. 00:32 It is. What a wonderful conference, man. 00:34 I haven't been at a conference where I just want to go and watch every talk 00:38 I missed. 00:39 And like, I'm thinking, which session will I go in? 00:42 These are all interesting. 00:43 Is so much going on at the moment. 00:45 And of course, is matching what's kind of going on in the industry. 00:49 We all know it's it's a time of huge change, 00:53 excitement, concerns, you know, 00:56 and, and a lot of ideas are kind of information. 00:59 Information. 01:00 And I work at a wonderful place called GitHub. 01:05 Next we are a team. 01:07 You can kind of think of us I guess a key difference. 01:10 We're not like a research team in the sense we like publish 01:13 kind of peer reviewed papers, but we do get to decide what we work on. 01:18 The management, trust us, sort of to set our direction. 01:23 And over the last year 01:26 we've been we've been taking advantage of that to really set a direction, 01:31 I think, for the industry to set a direction for GitHub. 01:35 And I'm really happy, really proud of what we've been doing over the last year. 01:39 I want to talk a bit about it. 01:42 So yeah, our job, our mandate. 01:43 Yeah, very broad future of software development. 01:45 We all know that it's all about AI. 01:48 Some of the people who started 01:50 the original OG GitHub copilot completions 01:55 kind of kicked everything off back in 20 2122. 01:60 They formed GitHub next. 02:01 So we inherit the spirit of those people who were working on on copilot. 02:07 Completions are okay. Yes. 02:12 Times images to use. 02:13 I use the wizard image a lot. I, 02:17 I used to work on programing languages. 02:19 It was really exciting, really amazing, amazing things to work on. 02:24 But what I tell people now is I was working on shovels, 02:29 you know, making shovels. 02:31 We were all obsessed about shovels. 02:33 If you want to watch something sort of British about shovels, 02:35 go look up Ripping Yarns and The Tale of Eric White. 02:40 He is obsessed about shovels, and we were a bit like that. 02:45 It's amazing. 02:46 Those are incredibly powerful machines, programing languages. 02:50 They they're good construction material. 02:52 We wanted C sharp, F sharp, strong typing, Java, all of it. 02:57 We were really good construction materials, 02:60 but we have to be honest, today people are kind of moved on from shovels. 03:04 They want magic wand and they've got magic ones. 03:06 You've all got magic wands in your hands that make the shovels dance, that 03:11 make the machines dance and make the tools and the construction materials. 03:15 You know, you can boom. 03:16 And this is incredible. It's disturbing. 03:20 I mean, it's disturbing to sit in a meeting where you've got, like. 03:23 I mean, it's like the Council of Wizards in Lord of the rings, right? 03:27 Everybody sitting around, you know that at the end of the meeting, 03:29 any single wizard can walk out of there and go, boom! 03:32 Kind of. 03:33 By the end of the day, they've magic up whatever you're kind of talking about. 03:36 But how do you manage like a group of wizards? 03:40 Right. 03:40 That's some people have been talking about that kind of problem. 03:43 And it it's a big problem. 03:44 It's just a big kind of change. 03:47 So I, I use this slide 03:49 with undergraduates as well here at King's College in London. And 03:54 you know, we 03:55 have to get across to the next generation that they have these incredible powers. 03:58 And they learn to 03:59 need to learn to channel them, and they need to be positive about it. 04:04 But we need to understand that there's 04:05 a lot of responsibility that comes with these powers as well. 04:09 They can blow up in your face. 04:10 I don't particularly Rings of Power, but here's 04:13 a young Gandalf arriving in middle earth blowing himself up. 04:17 There's lots of Harry Potter examples to of wizards 04:20 kind of blowing themselves up and useful to communicate 04:24 the kind of risks and dangers of kind of channeling the power incorrectly. 04:30 And that image I love images, 04:34 you know, the channeling that'll come back in the rest of the talk. 04:38 Now I want to talk about a change which in images. 04:44 Okay. 04:45 And it's a change, in a way, from the image of copilot to the image of 04:51 continuous AI. 04:53 And the image of copilot is you've got you of the individual. 04:58 It's about individual productivity. 04:59 And that's incredibly important. 05:01 Most of your experiencing kind of individual productivity 05:05 tools, your coding agent environments or developer 05:09 environments equipped with agent chats, your chats equipped 05:13 with developer capabilities and individual productivity is an immensely 05:18 important part of the industry, and everybody is kind of piling in 05:23 to kind of make individuals are more productive. 05:27 But in the history of software development tools, there's always been 05:33 these two different polarities, kind of two different coalescing points. 05:38 And one is about individual productivity. 05:41 And you see that in the development environment. 05:44 And that's had a long, long history. 05:46 And then there's been this other polarity which is about the SDLC, 05:49 which is about automation, 05:51 which is about the continual kind of processes that need to go on. 05:57 It's about teams, it's about collaboration. 05:59 And I think the industry in there, 06:05 right, rightful pursuit of individual productivity 06:09 has maybe not been focusing on automation 06:14 and not been focusing on continuity. 06:18 And at the heart of GitHub is, of course, continuity. 06:23 And so we went back a year ago and we kind of did a conceptual project. 06:28 It's almost like a linguistic project in a way to say, 06:33 let's take the ethos 06:36 of continuous integration and continuous 06:40 deployment, and let's say, actually we were missing something all along. 06:45 There's a third pillar to that. 06:47 There's actually three. 06:49 It's not CI, CD, it's ci, CD 06:52 and continuous ai ci. And 06:56 we in a way what do we mean by that. 07:01 Well let's start to give that some some, some. 07:04 If we're going to introduce a term like that we have to give it some meaning. 07:07 Give it some body. 07:09 And when did you start unpicking it. 07:11 The examples are absolutely everywhere. 07:14 And there are lots of people in the industry doing continuous AI, 07:18 making offerings about automated uses 07:22 of AI in our development processes. 07:25 And you see people coming up with flows. 07:27 Some of them are automated, 07:28 some of them are semi-automated about continuous documentation. 07:32 And then when you start to think about it, it begins to have 07:36 a different feel to individual productivity, a different emphasis. 07:39 The problem with piling everything into individual productivity is that all these 07:43 kind of conflicting kind of goals that the individual is under, 07:47 they have to be productive, but they also have to be quality. 07:51 They have to, they have to. 07:54 They've got to flow. 07:57 They have to serve the work queue 07:58 coming in, but they also have to work on one particular item. 08:01 And so the individual becomes a bit of a kind of crunch point 08:05 for all the information flows going through a software project. And 08:10 when you start to 08:11 think of things in continuous terms, you can start to unpick that a bit 08:14 and you can talk about things like, actually, 08:17 I would like to have continuous code improvement in my repository. 08:21 And, and, and it's actually real. 08:24 And if you want to get a feeling for what my kind of day is like 08:29 is on my blog, you know, here's a typical morning. 08:33 I wake up to code improvements, start my day with code that's better provided 08:39 by my continuous improvement processes so we can unpick quality. 08:45 We can unpick that kind of logjam. 08:48 And to say here, actually lying in bed, 08:49 I can check the pull requests that have been created for me. 08:52 And yeah, start my day with code better. 08:54 It's a wonderful, incredible way to start the day as an engineer 08:58 by having a set of improvements delivered right into your repository. 09:04 Okay, so continuous continuous code improvement, 09:08 dealing with the incoming continuous triage, continuous fault analysis. 09:13 Now that's a big, big one. 09:14 And if you saw May's talk from the startup called Hud 09:19 at this conference, I'll be showing one slide from her talk later. 09:21 She's using a generic workflows and continuous quality 09:26 continuous fault analysis in really incredible ways. 09:29 And things like continuous accessibility to say, actually, 09:35 I don't really know how to do accessibility. 09:37 Well, I can't actually afford to hire an accessibility engineer, 09:40 but I can actually get the agents to be taking it, to be 09:44 doing the walkthroughs of the running application in C in my continuous system, 09:49 and actually checking out whether we've got some basics of 09:54 in place, and of course, 09:55 getting the experts when we actually are able to as well. 10:00 So continuous AI so these are automated 10:04 there, repetitive, collaborative, integrated, auditable 10:07 and crucially there are lots and lots of variants of these things. 10:12 And then you think to yourself, what does this feel like. 10:16 And it feels like ci CD. 10:19 So continuous AI is a question to the industry 10:23 about how we think about AI, how we think about AI automation. 10:27 But it's also a question to GitHub, because GitHub is a wonderful place 10:31 and all the other platforms that provide CI, CD, because in a way it's 10:35 a question where if ci CD is the answer to certain kinds of automation, 10:41 then those platforms should also be 10:43 the answer to AI automation as well. 10:48 There can be win win between these platforms. 10:50 They can include a mix of algorithmic or 10:53 traditional computational flows and flows. 10:56 And we use those kind of things all the time. 10:59 And of course, they're event triggered, they're proactive, 11:02 and it's about collaboration, team productivity, 11:08 not just individual productivity. 11:12 Okay, so continuous AI, but of course, if we're posing 11:16 a question to the industry and to GitHub, then we need an implementation of that. 11:20 And we have a wonderful implementation. 11:22 You'll see many implementations of continuous AI and variations on it. 11:26 But our implementation is called GitHub workflows. 11:28 You can use it today. It's all open source. 11:31 It is in a way additive to GitHub. 11:33 It's very closely aligned to GitHub actions. 11:35 And effectively it takes a specification 11:38 of a agentic workflow and hardens it into a GitHub action. 11:42 I don't mean compile it, 11:43 I mean it's got a prompt and it wraps that so that it's running in. 11:47 It's mainly about hardening it in a security sense 11:50 to make sure you can trust the flow that's being implemented by that workflow. 11:56 So let's take a look at GitHub Agentic Workflows. 11:58 You can use it today I will the I'll just call out the key. 12:03 You know it's this line repository automation. 12:06 That's again another bit of terminology which is an immensely powerful thing 12:11 turning every repository into a software factory 12:15 just like CI, CD automated 12:18 automated your build and deployments so we can automate 12:23 a huge range of subjective activities in the repository. 12:27 How do we do it? 12:28 Repository automation, running the coding agents you know and love. 12:32 So you're running Claude or you're running copilot 12:35 CLI Claude code or copilot CLI or Gemini CLI 12:40 or Codex are ultimately being hosted inside GitHub actions. 12:44 And the end result is that you're running the coding agents 12:47 you know and love with strong guardrails in a platform, 12:51 your company or you are probably already using a GitHub. 12:55 Actions is has this amazing quality. 12:58 And it's it's that when a company adopts GitHub actions, 13:03 what they're actually doing is giving a playground an automation 13:07 playground where developers can claim, can make 13:11 and use cloud resources, that is compute, network and storage, 13:17 and AI and and llms 13:21 or coding agents in the in their context, in their working context. 13:26 And it's like equipping every developer with the ability 13:29 to make multiple factories in their working context. 13:32 That is a hugely empowering and democratizing thing. 13:35 And it's a big part of why GitHub actions are successful. 13:38 You don't have to go and ask them. 13:40 Maybe there may be rules you have to follow in your organization, 13:43 but generally you don't have to go 13:44 and ask the kind of the cloud people for more cloud resources. 13:47 You just claim them through GitHub actions. 13:50 So it's an empowering platform, 13:52 and we're bringing a agentic automation right into that platform. 13:57 Okay. 13:57 So yeah that's summarizing what I just said. 14:01 Right. Let's take a look at an example. 14:02 Dead simple front matter plus markdown. 14:06 You check it in you harden it to a YAML. 14:09 It runs. That's it. 14:10 You have a factory one file checked in one file. 14:13 Plus it's hardening, checked in. 14:15 So it's got some triggers at the top. 14:17 It's very familiar to people who do actions. 14:19 This is going to run every week. 14:20 It's got okay. 14:22 It's got a safe output specification. 14:25 So these coding agents when they run every week in GitHub actions 14:29 you're going to be asleep right. It's going to be the middle of the night. 14:31 You're suddenly running a coding engine in the middle of your repository. 14:35 Like what the heck, right? How is that safe? 14:37 And it's safe. 14:38 They run read only with no access to secret, no direct access to secrets. 14:42 They run in a container and they have an extremely narrow output channel. 14:47 In this case, it's allowed to create one issue. 14:50 That's all. 14:51 This figure does a hand off of its output. 14:53 It's a bit like a plan apply kind of thing, and the apply is not done it. 14:58 It's not done through MCP. 14:60 It's done as a secondary stage. 15:04 And they're actually threat detection and put in between those stages. 15:08 So safe outputs with narrow channels, not just arbitrary permissions 15:14 to write to your issues or write to the contents of your repository. 15:18 It's got some tools of some kind and it's got some, 15:22 some prompting or sort of natural language programing usually very 15:26 sort of 15:27 deliberately ambiguous, genuinely useful ambiguity. 15:30 And it's kind of actions familiar to those. 15:33 Nearly everyone uses GitHub actions in some way or another, 15:37 and it assumes we're running on the GitHub what I call the GitHub 15:40 information fabric, or the GitHub data model. 15:42 That means it's you can have safe outputs to create issues. 15:45 You can have various tools to kind of read various kinds of inputs. 15:48 You can do cross repository ones with the right permissions set up, 15:52 so you can begin to have agentic workflows 15:53 that run across multiple repositories or indeed over your entire organization. 15:57 If the permissions are given 16:00 okay and they usually are, there can be data collection steps. 16:04 You can have traditional actions jobs in the front matter. 16:08 And then in some way they produce some sort of outputs on GitHub. 16:12 Pull requests or issues. 16:14 They don't ever merge pull requests. 16:17 The pull request is a kind of hard point that it's always the human 16:20 in the loop through a pull request. 16:23 Okay, so there's just another example. 16:26 If you triage with a different set of triggers at the top 16:28 that every time miniature is opened or reopened, it's going to do 16:31 some kind of issue triage on this, on this, on this thing. 16:35 And it is dead simple. 16:37 To get started, just install the extension, which is the hardener, 16:41 the sort of compiler if you like, but it's really about hardening the workflow 16:45 and run through an ad wizard on a typical on a typical workflow. 16:50 And bang, 16:50 you're doing a generic automation, getting pull requests or issue 16:55 analysis and many, many other applications delivered into your repository. 17:02 Okay, 17:03 so safety I've kind of 17:06 touched on the main things about safety, but it's absolutely crucial 17:11 if you're going to automate to take safety seriously. 17:14 And if anybody is talking about automation and not talking about safety, 17:19 it's like, you know, ask questions, right? 17:22 Ask the right questions. 17:24 Because this 17:28 unlike individual productivity, 17:31 there's a conflict between safety and productivity. 17:35 And we all know this. 17:37 The technicians can come up with things to make your coding agent sessions safer 17:42 and sort of lock them down and tell them you're only allowed to use certain MCP. 17:46 You've got to approve every single tool call and the individual just says, no, 17:50 you know, just turn it all off like we all do it. 17:53 Just like, you know, we don't care. We just want. 17:54 We just want the coding. We just want the productivity. 17:56 Give me more productivity in automation. 17:59 It's actually the opposite way around. 18:01 It's like a rail track. 18:03 The better the quality of the rails that you're on, the faster your train can go, 18:08 the more you can automate, the more confidence 18:12 you can have to build automation flows or factories 18:15 or whatever you want to call them, which operates safely 18:19 and within the intended bounds and the intended channels. So 18:25 in automation, 18:27 think check carefully 18:29 that you are getting a security architecture. 18:32 Do not run coding agents directly in GitHub actions or any other CI 18:37 CD thing without a security architecture of some kind. 18:41 You must always have a security architecture as you should 18:45 and as you should for all your automation, but it's absolutely crucial 18:50 in the context of a working and a agentic automation. 18:54 So execution and sandbox permissions are minimize 18:57 the agentic set runs read only no secrets and very narrow safe outputs. 19:02 That means there's often a preload step where the an algorithmic step 19:06 gets lots of information, maybe CI logs or whatever the agentic step 19:11 is going to work on gets a big package of information ready for the 19:15 for the coding agent to kind of run over in its kind of safe, sandboxed way. 19:19 And then you have this narrow output to this intended channel 19:22 where the blast radius is extremely reduced. 19:25 Maybe create one issue or create one pull request. 19:27 And it's got these checks for threat detection, 19:30 and you have human oversight guaranteed through the issue and the pull request. 19:35 And we turn off things like shared package coaches 19:39 to make sure we don't get package cache poisoning and other things going on. 19:42 And all the outgoing network is firewalls and and controlled. 19:48 Okay. 19:48 So once you have continuous AI and once you have as a sort of a 19:52 as a philosophy and a agentic workflows as an implementation, 19:57 there's several directions. 19:58 And this is really where I think the whole industry is going 20:01 is several directions you can go in. 20:05 One of them is the Agent Zoo, and this is where you or are 20:10 or the agent factory. 20:14 And we we put together. 20:17 This is the approach adopted by Pelli on my team, who is a wonderful collaborator. 20:22 I don't think you might call him kind of crazy, because he has taken 20:28 the philosophy of let's create a new antic, 20:30 automated the agentic workflow for just about everything, and it's created 20:34 hundreds and hundreds of these things for different kinds of working. 20:37 And we were so taken by his work that we wrote it up in this kind of agent 20:43 factory. 20:44 And, and you can kind of start to see what he's using these things for. 20:50 And we built GitHub workflows using this technique, 20:53 and we built a blog series called Meet the Workflow. 20:57 So please check that out. 20:59 And there's some really interesting themes come out. 21:01 This idea of continuously simplifying your code and making your code 21:05 better, continuously refactoring your code like a thing 21:09 to take large files and split them apart into a really. 21:12 And actually the code ends up really, really nice to apply styling to 21:17 your code. 21:17 These very subjective decisions that agents can make could be. 21:21 And there's other aspects of improvement and documentation that we kind of 21:25 bring out in this blog series. 21:26 If you click through on some of these things, you'll actually see 21:30 very direct examples of how these things actually, 21:34 you know, in this use of semantic function refactoring, the workflow had 112 merged 21:38 PRS out of 142, and we follow the causal chains of those. 21:43 This is such and such an issue analyzed. 21:46 The code organization opportunities led to a certain 21:49 pull request that led to a certain kind of outcome. 21:52 So please take a look through that. 21:54 Now, having an agent zoo, that's actually not my style. 21:58 I don't do that. 21:59 I actually focus on a single workflow that does many things. 22:03 And so I've put those together in a set of samples. 22:07 One of them is for continuous test improvement. 22:10 Another one is continuous performance engineering on your code base. 22:14 For the one I really want to talk about is one that's very close to my heart. 22:18 As an open source maintainer, I maintain about seven 22:22 open source repositories, and I. 22:27 I really care for the open source maintainers in the world. 22:30 They're under huge amount of pressure at the moment. 22:34 You know, if these if these repositories have, say, 200 or 400 open issues 22:39 and each of those are going to take a day, a night of 22:42 of kind of spare time work to kind of work through. 22:45 That's a lot of time you're asking of open source maintainers. 22:48 And what happens is these repositories end up dormant. 22:50 They end up kind of not with no forward velocity at all. 22:54 I still want them maintained, but they but you know, they're kind of stuck there 22:58 logjam there. They're not progressing. 23:01 So let's take a look at our repository maintenance 23:05 I will talk about repo assist. 23:09 Now repo is one particular agent workflow. 23:13 And I just want to dig in here to what it does okay. 23:18 It's pretty simple. 23:19 It reads it's memory. 23:21 And then it chooses a couple of a smorgasbord of tasks. 23:24 And of course this is under your control as a repository, as a maintainer 23:29 you can shape these tasks. 23:30 You can delete them off, you can add new tasks. 23:32 And just once a day or some appropriate kind of cadence, it's going to wake up 23:37 and it's going to do these things in the repository. 23:41 And there was talk about like repository maintainer holidays 23:45 yesterday in Jack Jack talk from Google. 23:50 You can actually enable this kind of thing while you're away on your holiday 23:55 limiting the task. 23:56 Maybe it will reply hey, I'm away on holiday, but the AI says such 23:59 and such about this kind of about this kind of issue 24:02 that you're kind of talking about, or you can just use it as a general 24:06 kind of background assistant to help you work in the repository. 24:10 The triage, propose improvements, update, manage labels, you know, 24:16 whatever you choose as a set of tasks. 24:18 And that's what I was using in this 24:20 in this work here to start your day with code. 24:22 That's better. 24:24 So repo assist try and guess where I started to use 24:27 repo assist in this repository. 24:29 This is the number of open issues. 24:31 And this was back in March. 24:33 And this is a repository that I maintain one called 24:37 maintained one called FSharp.Data. 24:39 And it was basically a dormant repository. 24:40 You can see that there was there was nothing happening, 24:42 but there was a big fat issue backlog that nobody was ever going to look at. 24:46 Turn on repo assist. 24:47 And I actually started to be joy being a maintainer again. 24:51 We ended up doing three major releases that went over the entire issue backlog. 24:55 Some of them were problems, some of them were feature requests. 24:58 And bang! 24:59 It was so much fun to suddenly work on these things. 25:02 The AI would be commenting on the issue with a very good and accurate 25:06 assessment of an issue from even back into the 2018, 25:10 or there were still issues around which they were valuable, 25:14 and it's a form of data mining. 25:15 We're turning we're turning backlog into forward progress. 25:18 We're turning dormancy into forward velocity as another one. 25:25 Deedle, another library that was pretty much dormant. 25:29 Here's a whole set of these. 25:31 Not all of these are maintained by me. 25:33 So there are other maintainers picking up the particular repo assist 25:37 workflow, customizing it for their own needs, and you kind of see 25:41 the range of different outcomes of kind of this is on issues in the repository. 25:45 Now some of these repositories also had incoming. 25:47 Some of them kind of had had were more dormant. 25:52 And so you see a range of different outcomes. 25:55 And we've written a report which you're very welcome to, to read is called 26:01 the Impact of Automated Repository Maintenance Assistance. 26:04 Big thank you to the maintainers who worked with me on this and that. 26:08 Other people get up next. 26:09 And you can kind of see the changes in velocity in those repositories. 26:14 Not all of them, but most and most of them achieve forward velocity. 26:19 You can see the graphs on that. 26:21 And all of this is leading to a different kind of thinking, where 26:24 suddenly you can begin to use factory thinking. 26:28 You can start to use process flow models. 26:31 You can start to think about this, about what is actually going on 26:35 in these repositories as we start to automate what is happening. 26:40 So the repository as an automated software factory, 26:43 we have of course, already been automated factories 26:47 through continuous integration and deployment, but we're adding 26:51 a whole new range of kind of machines that can work on the production 26:55 line of issues and pull requests and other kind of activity 26:58 that's happening in the repository. 27:00 You could create sub factories. 27:02 You don't have to turn the whole whole repository. 27:04 You can kind of carve out parts of work through labeling or issue titles 27:09 and other ways of, of working. 27:10 And we've written that some of this up 27:12 as a blog: repository as a human-agent knowledge factory. 27:16 And when I think of a repository now, this is what I think of. 27:21 It's a site where humans and agents come together to work collaboratively 27:25 to get forward velocity through our through the through for the team 27:30 and for the for the for the production process that's happening. 27:34 Okay. 27:35 So some kind of factory flow, once you start having 27:38 a flow based thinking, everything becomes about flow. 27:42 You kind of look at these different repositories. 27:44 You can say some of them are blocked and they blocked 27:47 well, some of them are flowing and some of them are kind of idle. 27:51 There's actually no more input coming into those systems. 27:54 And they're actually when we say blocked, they're actually kind 27:58 of gated on human requirements. 28:01 And that's okay. 28:03 It's always okay to slow down the factory. 28:06 You know, if you've got a little factory 28:08 running at home, you don't want it running all night. 28:10 Right? Maybe waking up in the middle of your sleep or something like that. 28:12 You might you can gate the factory on human and organizational needs. 28:17 And it's so, so. 28:18 And that is totally okay. 28:20 Humans are absolutely part of this process. 28:23 And the human needs are paramount throughout what we're building. 28:27 But you as a repository owner are probably now 28:32 going to be a factory or a flow designer. 28:37 And if you if your aim is productivity 28:40 through the taking into account the human concerns, 28:43 if your aim is productivity, then you have to get production 28:47 flowing at high quality and the right cost. 28:50 And so we're going to see a lot more process engineering kind of thinking, 28:54 you know, go read books and the kind of chemical industry 28:57 or the or the mechanical engineering kind of industry or the or all the other 29:02 kind of engineering disciplines, which are all about this kind of thinking. 29:07 And we now have to take that kind of thinking and bring it 29:10 into the software development process. 29:14 So things jam up. 29:16 Of course they do. 29:17 And I think what a lot of people are experiencing at the moment is 29:22 they're working in the middle of a big logjam, 29:23 and they unclear part of it and say, oh my God, look at these agents. 29:26 I've got to set up this thing. 29:27 And and then it jams on another part of the flow, you know, 29:32 because somebody else, it hands off to somebody else 29:34 who doesn't actually do anything with that kind of work. 29:38 So getting ourselves from the kind of logjam state that a lot of enterprises 29:43 are in into a kind of flowing state, there's a lot of work 29:47 that needs to be do to to 29:50 modern enterprise software development. 29:53 So our I just wanted to call out 29:59 one other big application of this kind of thinking. And 30:06 I'm in. 30:06 May's work with HUD is just amazing because she's 30:10 she's using GitHub Agentic Workflows, and she's using it to do a weekly report. 30:14 Now, people usually look at that weekly report sample and say, 30:17 do I really want a report every week on my repository? 30:21 Maybe not just a generic research report, but what about if you're getting a 30:26 report that from a set of probes into your production system, 30:32 which are analyzing all your faults and problems, 30:37 all your request failures in 30:41 and bringing that up each week 30:44 into your surfacing that information into your team. 30:48 So it's part of it is about the quality of the data, 30:53 the quality of the probes, the quality of the kind of observation 30:57 you have of the factory and the quality that's being being produced. 31:03 And then surfacing that up into 31:07 in to you, into your team. 31:09 And as, as May says, the performance sprint, you run normally, 31:14 you run it every few months and suddenly you can run it every week. 31:19 Okay. 31:19 So the repository is an automated software factory. 31:24 I'm doing this like this morning I was working on two sub 31:27 factories to do with, with with parts of GitHub. 31:31 One of them is a factory to deal with. One problem. 31:34 So we have some some algorithmic things that look over our database 31:37 requests from production and from CI. 31:40 And we find the one problems, we catalog them all 31:44 and then we start to try and get a factory flowing. 31:47 Now my factory is not flowing at the moment. 31:49 It's like we haven't got a sufficient quality gate. 31:52 We're not checking, you know, and we know that. 31:54 And instead of going and fixing up the issues and saying, okay, 31:57 we can fix this one up manually, the key thing, step step is to step back and say, 32:02 let's add a quality gate to the factory so we can get the whole factory flowing. 32:06 Because we've got hundreds of these N plus ones we have to work through. 32:09 CI improvements is another factor I'm working on to reduce CI times. 32:14 And again, part of the factory is the quality gates that I need to add 32:18 to the to the to the factory. 32:22 So just to wrap up are 32:24 part of this is about what is work going to be like in the future. 32:28 And to me it's crucial to remember that 32:31 it's not about it's not about like 32:35 work is not a fixed there's not a fixed amount of work to be done. 32:38 There's a huge amount of work that needed to be done 32:40 that was that was simply not being done because it was labor constrained 32:44 and too expensive. 32:45 So the maze example is a good one. 32:48 How often do we do those performance or quality sprints? 32:52 Well, not often enough. 32:54 Right now. We can do them every week, right? 32:56 We can automate that whole process. 32:57 So the A and so there's work that was being done can now be done. 33:02 The car the automobile led to travel that wasn't being done before. 33:07 The factory led to millions of quality products that weren't being done before. 33:11 Medicine led to diseases being treated that weren't being treated before. 33:17 So more overall work is getting getting done, more output, 33:21 more productivity at high, I believe we can AI can now be a new 33:26 a totally see change in quality in the software industry. 33:30 If we think about it the right way and we we, 33:34 we think about what process is aiming towards quality 33:37 and not just towards slop and other outcomes. 33:41 Okay, so that's all new work, new futures and GitHub workflows. 33:46 Use it today and we'd love to have your feedback. 33:49 And it is in technical preview and we'll be going to public preview soon. 33:53 So thank you very much. Massive round of applause. 33:55 Don't sign. Thank you so much. 34:00 Stay right where you are. 34:02 Next speaker is coming up