Attribution warning. This transcript has no per-speaker labels. The metadata identifies Simon Maple (Head of Developer Relations at Tessl) as the speaker, but the body of the talk is clearly delivered by someone from GitHub Next — they say "I work at a wonderful place called GitHub Next", reference "Pelle on my team", and describe GitHub Agentic Workflows as "our implementation". Simon Maple may have opened/MC'd the conference (the closing voice thanks "Simon" and announces the next speaker). When attributing, prefer "the speaker" or "the GitHub Next presenter" unless the user has clarified. Named individuals in the transcript: Pelle (speaker's GitHub Next teammate), May/Maze (from startup Hud). Audience reference: undergraduates at King's College London. Transcription artifacts have been left intact (e.g. "cholesterol.data" likely = "colorlogger" or similar; "rite of rings" likely = "Rings of Power"; "maze" likely = "May"; "Ali" near the end likely = "AI"; "Repolaris" appears to be the intended name).

1. Conference welcome & framing

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? These are all interesting. It's so much going on at the moment. And of course, imagine what's kind of going on in the industry. We all know it's a time of huge change and excitement, concerns, you know, a lot of ideas are kind of information.

And I work at a wonderful place called GitHub Next. We are a team. You kind of think of this one, I guess a key difference. We're not like a research team in the center through, like, publish kind of peer-reviewed papers. But we do get to decide what we work on. Management trusts 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, that mandate, you know, very broad, future software development. We all know that it's all about AI. Some of the people who started the original OG GitHub Copilot completions and kind of kicked everything off. Back in 2021, 22, they formed GitHub Next. So we inherit this, the spirit of those people who were working on, on Copilot completions.

2. Shovels and magic wands metaphor

Okay. Yes, a couple times images to use. I use the wizard image a lot. I. Used to work with programming languages. It 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 the arms. And the, the tail very gold flight. And he is obsessed with that shovels. And we're a bit like that. It's amazing. Those are incredibly powerful machines. Programming languages, but they're good construction material. You know, we want to see sharp, F sharp, strong typing, Java, all of it. We want really good construction materials.

But we have to be honest today people kind of moved on to the shovels. They were magic wands. And they've got magic ones. You've all got magic wands in your hands that make the shovels dance and make the machines down to make the tools of the construction materials. You know, you can boom. And this is incredible. It's disturbing. I mean, it's disturbing to sit in a meeting where you've got, like, I mean, it's like the council of wizards in northern rings. Right. Everybody's sitting around, 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. And, you know, I, we have to get across to the next generation. 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. They don't particularly rate rings of power. But here's the young Gandalf arriving in Middle Earth, blowing yourself up. There's lots of Harry Potter examples, too, with its kind of lines themselves up and useful to communicate the kind of risks and the dangers of kind of channeling the power. Incorrectly. And that, that image, I love images. You know, they're channeling. That'll come back in the rest of the talk.

3. Two polarities — individual productivity vs continuity

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 u, the individual. It's about individual from activity. 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, you know, everybody is kind of piling in to kind of make individuals more productive.

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, but that's 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. And I think the industry in their right, rightful pursuit of individual productivity has maybe not been focusing on automation and not being focusing on continuity. And at the heart of GitHub is, of course, continuity.

4. Introducing Continuous AI (CAI)

And we, so we went back a year ago and we kind of did a conceptual project. It's always like 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. There's a third pillar to that. There's actually three. It's not cicd. It's CI, CD and continuous AI, CAI.

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 do you start. Unpicking it? The examples are absolutely everywhere. 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, if you've all come out with flows, some of them are automated, some of them are semi-automated. About continuous documentation.

And then when you start to think about it, it begins to have a different field to individual productivity, a different emphasis. The problem with entirely everything in 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'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 when you start to think of things in continuous terms, you can start to unpick that dread and you can talk about things like actually, I would like to have continuous code improvement in my repository. And, 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 is on my blog. You know, 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 kind of log jam and say here, actually lying in bed, I can check the pull request and it'll be created for me. And, yeah, start my day with covert 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.

Okay. So continuous coding for dealing with the incoming continuous triage, continuous fault analysis. Now, that's a big, big one. And there's, if you saw maze talk from others in a startup called hud at these conferences, I'll be showing one slide from her talk later. She's using a workflows and continuous quality of continuous fault analysis in really incredible ways. And things like continuous accessibility 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, to be doing the walkthroughs or the running application 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.

So continuous AI. So these are automatable. They're repetitive, collaborative, integrated, audible. They're, and crucially, there are lots and lots of variants of these things. And then you think to yourself. What does this feel like? And it feels like cicd. 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 cicd, because in a way, it's a question where cicd is the answer to certain kinds of automation. Then those platforms should also be the answer to AI automation as well. They 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. And of course there are event triggered, they're proactive, and it's about collaboration, team productivity, not just individual productivity.

5. GitHub Agentic Workflows — the implementation

Okay, so continuous AI. But of course, if we're posing a question to the industry and to GitHub that we did 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 implementations will get up genetic workflows. Use it today. It's all open source. 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 compiler. I mean, it's got a prompt and it wraps that. So that's running in a, it's mainly about hardening it in security sense to make sure you can trust the flow that's being implemented by that agenda workflow.

So let's take a look at GitHub workflows. You can use it today. I will 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 your build and, and deployments so we can automate a huge range of subjective activities in the repository.

And how do we do it? Repository automation running the coding agents, you know, and love. So you're running Claude or you're running Copilot CLI called code or Copilot CLI or Gemini CLI or Codex are ultimately being hosted inside GitHub Actions. And the end result is that you're running the coding agents who know and love. We're strong guardrails in a platform your company or you are probably already using.

GitHub Actions has this amazing quality. 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 and use cloud resources, that is compute, network and storage. And AI and llms or coding agents in their context, in their working context and 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. And maybe there may be rules you have to follow in your organization, but generally you don't have to go and ask the kind of the cloud people for more cloud resources. You just claim them through GitHub Actions. So it's in a calorie platform and we're bringing a gentech automation right into that platform. Okay, so yeah, that's summarizing what I just said.

6. Anatomy of a workflow file

Right, let's take a look at the example, dead simple. Front matter plus markdown. You check it in, you harden it to a yaml, it runs. That's it. You have the factory. One file checked in, one file plus it's hardening. Checked in.

So it's got some triggers at the top. It's very familiar to people with directions. This is going to run every week. It's got, okay, it's got a safe output specification. So these coding agents, when they run every week, you can have actions, and you're going to be asleep, right? It's going to be the middle of the night and there's something running a coding engine in the middle of your repository. Like, what the heck, right? How is that safe?

And it's safe. They run read only with no access to secret, 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 gently. It's not done through MCPs. It's done as a secondary stage and actually threat detection in between those stages. So safe outputs with narrow channels, not just arbitrary permissions to write to your issues or write in contents of your repository.

It's got some tools of some kind and it's got some prompting or sort of natural language programming, usually very sort of deliberately ambiguous, generally useful ambiguity. And it's got actions familiar to those nearly everyone users could have actions in some way or another. And it assumes we're running on the GitHub what I call the GitHub information fabric or because I've data model. That means you can have safe outputs to create issues. You can have various tools to kind of read various fund inputs. You can do cross repository ones. You can throw out permissions. Set up. So you begin to have a generic workflows that run across a multiple repositories or indeed as your entire organization is the permissions. Are given.

Okay there can be data collection steps in the front matter. And then in some way they produce some sort of outward 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 if you triage. There's 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 thing.

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 visit on a typical agentic workflow. And bang, you're doing a gender automation. Getting pull requests or issue analysis and many, many other applications delivered. Into your repository.

7. Safety architecture (non-negotiable)

Okay. So safety. I've kind of touched on the main things about safety, but it's absolutely crucial if you're going to automate safety seriously. And if anybody is talking about automation and not talking about safety, like ask questions, right? Ask the right questions. We call us.

Unlike in individual productivity, there's a conflict between safety and productivity. Okay. And we all know this. The technicians who 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 apps and fees. You got to approve every single tool column. The individual just said, no, you got to yellow. 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 that. We just want the coding. We just want the productivity. Give you 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 operates 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 CICD thing. Without a security architecture of some kind. You must always have a security architecture as you should throw all your automation. But it's absolutely crucial in the context of a genetic working energetic automation.

So execution in sandbox permissions are minimized. The agenda accept runs read only, no secrets and very narrow save outputs. That means there's often a preload step where an algorithmic step gets lots of information, maybe CI logs or whatever the agentic stuff is going to work on. Get a 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. And we turn off things like shared package cases to make sure we don't get package case poisoning and other things going on. And all the outgoing network is firewalled. And controlled.

8. Two strategies — agent zoo (Pelle's agent factory) vs single multi-purpose workflow

Okay, so once you have continuous AI, once you have as a sort of philosophy and a gently quite flight as an implementation, there's several directions. And this is really where I think the whole industry is going in several directions. You can go in.

Now one of them is the agent zoo. And this is where you or the agent factory. We put together, this is the approach adopted by Pelly on my team, who is a wonderful collaborator. I don't think your mind won't call them kind of crazy because he has taken the philosophy of let's create a new agentic automated workflow just about everything. And it's created hundreds and hundreds of these things. For different kind of working. And we've, we were so taken by his work that we wrote it up in this kind of pilla's agent factory. 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 blog series called meet the workflow. So please check that out.

And it's really interesting themes come out. This idea of continuously simplifying your code and making your code better continuously free factoring your code, like things to take large files and split them apart into a really, and actually the code ends up really, really nice. To apply styling to your code is very subjective decisions at AI agents can make. 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 actually see very direct examples of how these things actually, you know, in this use of semantic function refactoring, the workflow had 112 merge VRs at 142. And we follow the causal chains of those. This is such and such an issue. Analyzed 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 that agent zoomed, that's actually not my style. I don't do that. I actually focus on a single workflow that does many things. And 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. But the one I really want to talk about is one very close to my heart as an open source maintainer.

9. Repolaris — open source maintenance case study

I maintain about seven open source repositories. And I really care for the open source maintenance in the world. They're under huge amount of pressure at the moment. You know, if these repositories have say 200 or 400 open issues and each of those are going to take a day, a night 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 to maintain stuck. They're long jammed. They're not progressing.

So let's take a look at repository maintenance. Let's talk about Repolaris. Now Repolaris is one particular agentic workflow. And I just want to dig in here to what it does. Okay, it's pretty simple. It reads its memory. And then chooses a couple of the smallest board of tasks. And of course, this is under your control of the repository as a maintain that you can shape these tasks. You can delete masks. 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 the repository.

And there was talk about like repository, maintain a holidays yesterday in talk from google. You can actually enable this kind of thing while you're away. On your holiday, limiting the task. Maybe it will apply, hey, I'm the way on holiday, but the AI says such and such 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 either repository to triage, compose improvements, update, manage labels, you know, whatever you choose as a set of tasks. And that's what I was using in this work here to cycle day with code. That's better.

So Repolaris. Try and guess where I started to use Repolaris in this repository. This is the number of open issues and this was back in March. And this is an impository that I maintained on called maintenance, cholesterol.data. and it was basically a dormant repository. You can see that. There was nothing happening, but there was a big fat issue back long that nobody was ever going to look at. Turn on Repolaris. And I actually started to enjoy being a maintainer again. We ended up doing three major releases that went over the entire issue backlog. Some of them were problems. Some in the feature requests. And bang, it was so much fun to suddenly work on these things. The AI would be commenting on the issues of 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 totally backlogged into forward progress. They're turning dormancy into forward velocity.

There's another one dl another library that has pretty much dormant. Here's a whole set of these, they know all of these are maintained by me. So there are other maintainers picking up the particular repository workflow, customizing it for their own needs. And you can't see the range of different outcomes of kind of this on issues in the repository. Now some of these fossils also have incoming and some of them kind of had more dormant. And so you see a range of different outcomes. And we've written a report which you're very welcome to read is called the impact of automated repository payments assistance. Big thank you to the maintainers who worked with me on this. And other people at GitHub Next. And you kind of see the changes in velocity in those repositories. Not all of them, but most of them achieved forward velocity. You can see the graphs on that.

10. Repository as automated software factory; factory flow thinking

And all of this is linked to a different kind of thinking where 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, already been automated factories through continuous integration and deployment, 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 subfactories. You don't have to turn the whole repository. You kind of carve out parts of work through labeling or issue titles and other ways of working. We've written some of this up as a plan article repositories accumulate and knowledge factories. And when I think of a repository now, this is what I think of it as a site where humans and agents come together to work collaboratively to get forward velocity through for the team and 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 kind of look at this different repositories. You say some of them are blocked. And they block. Ed, well some of them are flying and some of them are kind of idle. There's actually no more input coming into those systems. And they're actually, relatively blocked that 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? Maybe waking 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, and that is totally okay. Humans are absolutely part of this process and the human needs are paramount throughout what we're building.

But you as a repository owner are probably now going to be a factory or flow designer. And if you're aim is productivity through the taking into account 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. Go read books and the kind of chemical industry 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.

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 unclear part of it and say, oh my God, look at these agents and go set up this thing. 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 giving 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 do to unjam modern enterprise software development.

11. May / Hud — weekly performance report example

So I just wanted to call out one other big application of this kind of thinking. And in May's work, it was hard. It's just amazing because. She's, she's using GitHub agentic 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 just a generic research report, but what about if you're getting a report that from a set of probes into your production system, which are analyzing all your faults and problems, all your web request failures in and bringing that up each week into your surfacing that information into your teams. So 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 of this being produced and then surfacing that up. Into you, into your team. And as May says, the performance sprint you run, normally you run it every few months and suddenly you can run it every week.

12. Speaker's current sub-factories (n+1, CI)

Okay, so the repositories and automated software factory. I'm doing this like this morning. I was working on two sub factories to do with parts of GitHub. One of them is a factory to deal with n plus one problems. So we have some algorithmic things that we've got database requests from production and from CI. And we find n plus one problems. We catalog them all and then we start to try and get a factory flowing. Now my factory is not flowing at the moment. It's like we haven't got a sufficient quality gate. We're not checking, you know, and we know that. Instead of going and fixing up the issues and saying, oh, okay, we can fix this one up manually. The key thing step is to step back and take let out a quality date to the factory. So we can get the whole factory flowing because we've got hundreds of these mbus funds we have to work through. CI improvements are another factor I'm working on to reduce CI times. And again, you know, part of the factory is the quality gates that I need to add. To the factory.

13. Closing — work is not a fixed pie

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 like work is not a fixed amount of work to be done. There's a huge amount of work that needed to be done that was simply not being done because it was labor constraining too expensive. So the main example is a good one. How often do we do those performance or quality sprints? Well, not often enough. Right? Now we can do them every week. Right? We can automate that whole process. So the only, so there's work that wasn't being done that could now be done. 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 done more output, more for activity.

At heart, I believe we can. Ali can now be a new totally sea change in quality in the software industry. If we think about it the right way and we think about automated processes aiming towards quality and not just towards swap and other outcomes.

Okay, so that's all new work, new futures. GitHub workflows use it today and we'd love to have your feedback and it is a technical preview. I will be going public preview soon. So thank you very much.

14. Outro / handoff

Massive round of applause. Don't sign. Thank you so much. Stay right where you are. Next speaker is coming up. Right now. I'd say. I feel bad about having open source drinks that I don't maintain very well. And this is just going to change my life. If anyone has questions for Simon, if you can take. Them to the back of the room or out the room while we get the. Next tour. Set up. Thank you.