Bret: Say something's gone wrong in your repository, you don't wanna have
to get up in the morning, and say, oh my God, something's gone wrong.
Should I have coffee or should I investigate it?
You shouldn't have to make that trade-off because the agent should
have already investigated it for you.
So you should be able to just go to your breakfast, have your coffee, read
the report, read the analysis, and it says, here's a possible fix for it.
Here's actually meta pool request for it.
And you go, oh yeah man, uh, we, we gotta fix that.
Let's get that in.
it should be there, ready for you.
the agent should be proactive and should be immersed in a
world of cooperative agents.
Bret (2): Welcome to the Agentic DevOps podcast, and I am your host, Bret Fisher,
back with another episode about one of my most exciting things that I'm working on
this year, the project that I am adopting on GitHub, and I am trying to dig into
the weeds as much as possible because I think that GitHub is onto something.
Specifically GitHub Next and Microsoft Research, which are both the research arms
of both those organizations, and they're working together to evolve GitHub Actions
to what it would be if it was AI native.
What would it be if AI was there in a safe and reproducible way that we could
sandbox and protect in a, in a very detailed and heavily scrutinized way?
And it's not what you think.
It is not simply just adding LLM prompts into GitHub Actions,
which you could do today, and you've been able to do for years.
It's not simply just adding Claude Code as a step in your GitHub Action.
Those are things that already existed.
But out of GitHub Next last year, we heard about the early alpha beta
release of something called Agentic Workflows, which is technically what I
would call a feature of GitHub Actions, but it's a whole website now with tons
of examples, a team working on it.
And when you really dig into the details of what this is, I think this is the
only way we should be doing anything with an AI inside of GitHub Actions.
If we are prompting in GitHub Actions, they should be using
this tool, in my opinion.
As I dig more into this, and then the recent Claude Code security
concern that we had, and then all of the security concerns we've had
around GitHub Actions lately related specifically not to the supply chain
per se, but specifically to workflows that are getting basically prompt
injected through untrusted prompt input.
That is one of the biggest risks anywhere we put a model, whether it's in a
chatbot or it's in our automation or it's in front of some of our systems.
If someone can put untrusted text in a place that somehow doesn't get verified
by a trusted member of our team before it goes to a model, that's a risky
place to be, and that's part of our job.
Platform engineers, DevOps, security engineers, like we're all
very concerned about that, right?
We're maybe a little bit trepidatious on what we should be doing with these
things today, which is automating more of our systems because we don't wanna be
that person on the team that gets caught putting risky AI stuff into automation.
'Cause as we know, automation can make good things really easy.
It can reduce toil, but it can also automate the bad things if we're not
careful, and you can sometimes automate yourself all the way into an outage.
So we have on the show this time Don from GitHub Next.
That's their research arm full of PhDs and experts that are trying to figure
out tooling for the future of GitHub.
Personally, I just love GitHub Next.
I'm always on their website, githubnext.com, and looking at what
they're working on because to me it's like reading the tea leaves of where the
big money is researching for the future of software development life cycle.
And we also have Pele from Microsoft Research, who's also on the team building
this product And using it daily, which we get into exactly how they use it.
And I'm really excited because I feel like this system has a lot of rigor
to it, which is what I'm looking for.
And when I'm thinking about implementing AI anywhere in my
automation, especially when it comes to CI/CD automation, possibly anything
around my code repos, I'm wanting that to be as secure as possible.
So I look to make my steps deterministic with traditional programming, and then
only as a last resort when I need a judgment or a, maybe a consolidation
of text or a summary of text, that's when I consider putting in models.
And I used to just attach Claude Code, maybe build it a workflow around that,
or attach Codex or Copilot as a step, but this is something totally different.
You use command line tools to generate something that is a very long workflow.
You use CLI tools to create a lock file to make sure that that doesn't change.
You establish rigor around making sure that the prompts and the
things that you're trying to create with AI are trustworthy and can be
sandboxed and protected properly.
And I feel like the depths that I've gone into after this show that we're
gonna get into in a second, I feel like I now can say this is how I'm only
gonna be doing the AI in GitHub Actions.
So welcome to the show Don and Pele, and let's get into
it.
Bret: Don tell us who you are and how you got here.
Don: Bret, thank you so much.
the introduction is through our mutual friend, Ben, who works as a
product director at GitHub Actions, and yeah, we are having a blast.
I work at GitHub Next, and I am now working on, I guess, what we'd call
ai, agentic DevOps so continuous ai, agentic software, automated
agentic, software engineering, and lots of associated topics.
And yeah, I got a long background in kind of programming language design
and runtime design and done a lot of product delivery over the years
i- in Microsoft and other places.
A lot of DevOps along the way, and yeah, I've been at GitHub Next a few
years now, and I absolutely love it.
Yeah, we got a charter to investigate the frontier of software development,
and there's never been a more exciting time to Mm-hmm … be doing that.
A time where things are so nascent and things are in formation and in
change and, turning upside down, And you're really able to kind of
radically rethink a lot of things.
I mean, a lot of it's, turns your head upside down, just
how much things are changing.
But, you know, I, I'm enjoying that very much.
It's
Bret: a good moment to be here, I think.
I keep reminding myself, I don't know, a couple times a week, it feels like that
just reflect on the fact that you're in the middle of this and that, like, when
you look back on it, these are the stories we will tell and like, be present because.
When I look back at the cloud and the pc, the mainframe, to PC migration, and
like all the sort of large infrastructure evolutions that I've been a part of,
you know, when you're in the middle of it, it's, I was too young to
realize that it was of significance.
and as I've grown older, I've started to see the patterns and so I can
sort of feel like I, this is it.
This is a thing.
It's, this is exciting.
this will not happen, this will not be like this forever.
and we will look back on this as, wow, that was crazy.
so Yeah.
yeah.
Yeah.
Welcome.
I'm glad to have you here.
Peli: my name is Philippe Duhaleu.
I'm a engineer in Microsoft Research in a group called
Research in Software Engineering.
We're also very interested in things like verification testing, uh, all
this kind of stuff over the years.
And I had been looking at, LLM Automation back in the days before agents, and
got in contact with Don in GitHub Next.
And, we decided to kind of work together on this idea of continuous ai.
This kind of started this project, and that was a year ago, roughly.
Uh, but we had been working with Don from a distance from Microsoft
on various projects It's-- we've been around for a while.
Yeah.
yeah, so that's the intro.
I've been working on developer tools for professionals, but
also for kids for a while.
I've built, K12 coding platforms.
Bret: Nice.
Yeah.
Is there an analogy between a K12, learning platform and agent harnesses?
It is, it
is
Peli: There's a lot of things that people don't realize in the way it's designed.
It is designed as a sandbox, just like I build the coding
infrastructure for Minecraft.
Mm. So when kids learn to code in Minecraft, we, so there are some design
patterns that, that are applicable.
Uh, you know, these agents are finicky little monsters.
so we gotta talk a lot about kind of sandbox design and API design and
things we do under the hood to make it more reliable when people say,
"I know, agents aren't reliable.
or- Right.
So we do a lot of work under the hood to remove that.
But also we talk a lot about safety.
' cause when we have a real sandbox, you can't just experiment You can build
castles, without destroying the world.
So there's a lot of that is baked in.
but it's made for professional, it's made for DevOps, it's made for people
who are actions users and stuff.
Yeah.
But yeah, it's uh, actually, it happened, I didn't realize I, I was designing a
system like that and then after the fact it's like, whoa, this kind of feels like
I've rebuilt a system that I've built for so many times for that environment.
yeah.
Bret: Okay.
So it like it became apparent after it was happening, yes.
and I, I should back up because I think, uh, we got connected because I heard
about Agentic workflows last year, when it was before, GitHub Universe.
And it was like early beta or maybe even before that.
And I think I was like requesting early access to get in because it was right up
my alley and I had no idea what it was and just knew that, uh, at the time I was
building a GitHub Actions course, still am recording videos, uh, week by week.
And I've been a big GitHub Actions fan for, gosh, at least five or six years,
since before we had reusable workflows and a lot of the niceties we have
nowadays ' cause I really kind of saw that as the evolution of the everyone's
CI almost kind of what Jenkins represented in the industry for so long, where it
was sort of the default and I was so anxious for the, another winner to,
to replace Jenkins 'cause I was tired of maintaining the infrastructure.
And then, you know, got onto GitHub Actions, saw the advantages of having it
built right into where our code storage was and where everything else was.
And that just really fit, I think with a lot of my clients
and a lot of my community.
And so over the years, uh, GitHub Next, which we should
probably talk about what that is.
I've always looked at GitHub Next, you know, a couple times a year to try to see,
try to re- see the tea leaves that you all are reading and figure out where, what's
next for GitHub, what's the exciting thing that might come to fruition?
Whether it's a font, uh, font package, which is my favorite fonts
that I use everywhere today or, some feature in the UI of GitHub that
was considered a new experiment in how we represent the information.
And it's been fun to watch that.
'cause y- you feel like you're kind of seeing the skunk works
or the, like the, the deep think of an organization, in public.
And that's been a really cool thing that I don't think a lot of people know about.
Obviously Microsoft research is the same thing that's been around for
decades, but, um, uh, it was cool to see that so close to the coding
platforms that we're all using every day.
So last year, if I'm setting this up correctly, there was an
announcement around GitHub Agentic workflows as an idea, and then
you announced it at Universe,
And then since then, it, I feel like it's been like off to the races, incredible
documentation, slide decks that are available that you all are putting out.
and there's a lot of information that I think has to come along with this
because it's not an obvious evolution necessarily of how it's not just like
one little feature added to a workflow.
So who wants to take up the mantle of describing, elevator pitch,
the agentic workflow concept?
Don: I mean, I'll just run through the kind of three principles, right?
One is the idea of agentic repository automation.
You know, uh, we, the… when people talk about agents, I think there's been
something missing in the conversation.
Okay.
Which is about, you want agents that are proactive.
That's what I think of when I think of an agent.
I don't know where the idea came in around the world.
That agent was something you invoked from your chat session, right?
I don't know who invented that.
because when I think of the word agent, I think of something
that kind of is there around me.
It does stuff.
It knows the, it knows of What's happening in the world around me.
And in the context of a repository, that means it kind of knows what's
happening in the repository.
And, when I think about things like, I want to, refactor my code so that all
the files are under a certain size, I wanna check, uh, my error messages to
check the language is age-appropriate for a particular target audience,
or hundreds and hundreds of other things I wanna do in my repository.
I, those are things I wanna do continuously.
They're not something I wanna just do once, okay.
I don't wanna have to stand up every day and kind of say, oh
my, we had some error messages.
Gotta re reestablish that kind of principle.
that the error messages are all in, in good shape or whatever.
You know, A GitHub repository fundamentally is a continuous growing,
evolving, collaborative kind of space.
And it, it's got a history that's very interesting and long from wherever
it came from, and it's got future.
and the agents, uh, the, anything that happens in the repository
has to be established to happen on a continuous basis.
It's gotta be able to be adaptive to what- to the change that's happening in
the, in, in the, re- in the repository.
If you're gonna have AI working in a pull request is also a
continuous kind of object.
You know, it's gotta kind of go with you.
the journey all the way through the repository's a journey.
And we've been digging, to me that's the heart of what GitHub is.
it's like that's just central.
That's why it's the place where everybody comes to work together.
It's why continuous integration and continuous, uh, deployment,
make sense there and.
So if you're gonna do agentic working, you wanna establish it on a continuous basis.
we all know the examples.
here, continuous documentation, continuous code improvement,
continuous fault analysis, proactive, kind of fault analysis.
You don't wanna have to,
Bret: say something's gone wrong in your repository, you don't wanna have
to wait, you don't wanna have to kind of get up in the morning, and say,
oh my God, something's gone wrong.
Should I have coffee or should I investigate it?
Don: Right.
Bret: You shouldn't have to make that trade-off because the agent should
have already investigated it for you.
'cause you, the flow is to investigate a fault in CI or a
fault in your website or whatever.
there's where the signal, the fault signals are coming
from the flows are encodable.
you know, all the steps you wanna do.
You've probably written them out in your Mm …kind of documentation and so on.
So
you should be able to just go to your breakfast, have your coffee,
read the report, read the analysis,
Don: uh,
Bret: and you know, it says, here's a possible fix for it.
Here's actually meta pool request for it.
And you go, oh yeah man, uh, we, we gotta fix that.
Let's get that in.
Right?
So it should be there, ready for you.
the agent should be proactive and should be immersed in a
world of cooperative agents.
Don: And when you think about that kind of vision, there's,
that's quite close to the idea of.
uh, Assistance in your repository, sort of a virtual team in a way.
They're not humans.
Okay.
We, I don't like the anthropomorphization, but they,
Peli: yeah, it's hard
not
Don: to though.
they're gonna
Bret: be
Don: It's hard.
Bret: to, yeah.
Don: Yeah.
And, and there's so many times in my working life I've wanted
assistance in various repositories.
I think, there's so much, you know, I, I, there's, I don't know how to
do really good engineering uh, in, in various dimensions, in every
repository I have to kind of touch.
Uh, so bringing in this proactive assistance.
I know.
And so, when you think about it, where are we?
Let's make that real.
We're in, sitting in 2025, and let's make that real.
What's the ideal experience?
What's the most, let's platform fit that onto GitHub as a concept.
And you go Actions actually, yeah.
Actions has got a lot of trouble.
Yeah.
We, we, you know, you start thinking, well, we automatically generate
some big complex YAML, which kind of is like compilation of some
intent or something like that.
And then you go, then you realize actually, no, I just wanna run
those amazing coding agents, which will also appear around that time.
I just wanna run them in actions on a kind of continuous basis.
Okay.
And what would be the ideal simple, let's make that simple.
Let's make that as simple as possible.
That would be Check in a markdown file, which describes your prompts.
and It runs and you have, check and it and give some triggers like in actions.
Everything just works.
That's the kind of core idea of GitHub agentic workflows is to make
it, to capture the simplicity, the beautiful simplicity of GitHub Actions.
YAML, you know, people have got all sorts of complaints about GitHub
Actions, and YAML and so on, but it's got a massive advantage, which
is, it is damn really simple to use.
You just check in a file and you have magic, right?
Peli: Yeah.
Don: And that's uh, existing's ya YAML A- and one way that people put
it, I think Ben puts it this way, is that actions is a way for a- average
developers repository maintainers to get access to some cloud resources.
They get access to cloud compute networking and some storage
in the context of a repo.
And they don't have to go ask the security team a permission grant
has been given by the company that decides to let you use Git, GitHub,
or your open source repositories.
You get this amazing playground and it's not just a… It's a, it's
actually like a factory space, right?
It's actually like, it's got storage, it's got network, it's got so much compute, and
these days it's now we're bringing kind of coding agents into that kind of factory.
And, uh, so that's the simplicity of it.
You're running through the kind of, uh, add wizard kind of thing here,
which is kind of, uh, saying, you know, yeah, helping you, uh, set up your
tokens as well, uh, in, in the video.
And it's, it, it says, would you also like to trigger the workflow?
And then bang, you've got your first repository, automation running, and, uh,
that thing I think is set up to run daily.
Uh, you can kind of change it to run, weekly on different kind of schedules,
uh, different triggers and so on.
And bang, you've just got, you just made your, brought the most
powerful coding tools into your factory, onto your factory floor.
And the, the potential is limitless.
Now.
You have got all the power to automate everything, and creative things,
analytical things, uh, problem-solving things, code improvement things.
everything is set up, in, in, in the GitHub repository now.
Okay.
So that's the vision repository.
Automation with the coding agents you know and love.
You can use Claude.
You can use copilot, CLI, you can use Gemini, CLI.
And I think we're adding some more.
codecs as well.
And, uh, we, we will take, uh, proposals for new ones as well.
So that's it.
Repository automations with the coding agents, you know, and love
safely with strong guardrails.
We'll get onto that in GitHub Actions.
That's the formula.
Nice and simple.
Bret: Nice.
That's a good elevator pitch.
one of the challenges I think in all of, in all, like, like just if we think of
the entire software life cycle on GitHub, I've always experienced this with every
piece of software I've implemented as sort of a DevOps ops person, is anything that
I put in, even if its goal as a product or a tool to, to automate something.
Like even putting in GitHub Actions as a thing to help me automate
traditional, bef- before we had agents.
There always was an addition, the, a, a cost of toil that was added on
top of that, that I could not escape.
And when I teach GitHub Actions, a lot of, you know, it's obviously there's,
there's the day zero creation of these YAMLs, but the day two stuff is arguably
even more important because it rarely gets discussed, like in, in getting
started guides and stuff like that.
And so over the years, GitHub Actions has added functionality to, you know,
reusable workflows and templates and, the GitHub repo op opportunities there.
And there's, there's been a certain level of trying to manage this giant beast that
we've all created when you have hundreds of repos, and now that means possibly
thousands of YAML files to manage.
And, uh, you know, I hate to, I don't like using the word at scale, I think
like it's way overused and a lot of us aren't even dealing with scale.
We're just small teams.
but I always felt like there was this challenge of, oh yeah, we're gonna
implement this CI tool for you, but you probably need someone's, you know, half
a half a day, a week, maybe, or more to, you know, fix the broken workflows,
to update the GitHub, or approve the PRs for the action upgrades to make
sure that the Dependabot is configured correctly with all the latest stuff.
And so there's a lot of this sort of hidden toil.
And I was gonna throw the question to you of, do either one of you see this future
where it, it feels like there might be a possibility here where we can add.
We can add features or functionality or, or, or solve problems without
adding additional toil, but also maybe that toil might be managing
the agents, like up updating the agent skills or the configuration,
or like, that becomes the new human toil layer that we have to maintain.
Or do we think that this is the, the gain is far exceeding
possibly the, the toil involved?
Um, with that, what do you, what do you think about that?
You-
Peli: So essentially no, we compile down to action.
Yeah.
So our markdown becomes an action.
So we inherit all the toil today, Today we have all the toil that you have to do.
However, we're working closely with the GitHub action team,
and we're looking at that toil.
we're looking at the sources of that, and we're looking for solution to get
rid of these, you know, the requirement to, oh, there's no way to push an
action over an entire org, you know?
Mm-hmm.
You always have to push files, things like that.
It's like, can we do make this better?
Uh, so we're looking at these problems where you start to have
hundreds and thousands of repos and everything becomes a scale problem.
so there is definitely work being there for the action product itself to be able
to fix those oh, you mean But in general
sort of a
Bret: deterministic level, like something that's just a feature of GitHub is a
deterministic feature of action to be just
Peli: yeah …better at this.
But aside from that, we can go and.
Attack any toil and automate it, anything.
Because now we have, we have a, we have the ultimate reasoning hammer
that we can just point at a problem, just go systematically on every
repo, do some reasoning, right?
You can take, in fact, any deterministic tool and wrap it into, with an
agent and point it at any repo and, you know, hope for the best.
It might give you a result.
But, let's say your Dependabot thing, it's always slightly different, For every repo.
But now you have an agent that actually pretty good at dealing with that.
So you can go and, and run campaigns over your repos and, and fix complying
issues and things like that, that a deterministic tool would fail.
These agents are able to go and, and I think that's what you mentioned by toil.
Yeah.
Or I, yeah, but we also inherit Yeah …the, the limitation of actions today.
because, we're working on that, but, you know, that takes time.
but
Don: Yeah …it's on
Peli: our radar.
Don: I got a different thing for the toil.
Mm. It's kind of like, yeah.
it does take time, take costs something to kind of create automations that take kind
of cost something, costs you personal time and there's ongoing maintenance time for,
to create existing, uh, GitHub Actions.
YAML.
Couple of things kind of change a bit.
One is that because we're dealing with coding agents, it's
possible to create extremely um.
You might think of it as ambiguous, but it's actually kind of
general, kind of, um, workflows.
So you can kind of create, one of my favorite workflows is to
do with, repository maintenance and it's called Repo Assist.
and, um, and it's a multitask workflow and it kind of, each day
it's got like 11 tasks I think, and it kind of rolls the dice each day.
to say, Hey, what am I going to do today?
Okay.
So, because you don't want it to do all of them.
because it, you know, Yeah … only do the first three, so it just rolls the dice.
Just to kind of get things nice and balanced.
One of them is, for instance, to label issues, to just to make sure
all the issues are, can check most recent issues It can look at a backlog
and just make sure all the labels are kind, you don't have to write
that out algorithmically, right?
You just kind of tell it the end state that you want and maybe some hints about
how to get there, about what the journey is, it has to make and, uh, you know,
pretty much what I just said really.
And it'll work out all the rest of the details.
Uh, it, you know, in the sense that that's the prompting that will be
running each day or every third, fourth, fifth day or whatever it runs.
Uh, and, um, it sorts out the rest in any repository for any set of labels for any.
Language, you don't have to work in English, you could
be working something else.
So whereas in a traditional setting, you might have had to configure the exact
labels to use, configure the kind of, uh, the, the, the, the kind of heuristics
to use to label issues and so on.
In this setting, it can be made to work everything.
And that's really golden.
'cause that means you have these very generic workflows, which can
be used in many different settings.
I mean, other Yeah …tasks in that repo are things like take, uh, work through the
issues and just analyze them one by one.
not all in one run.
just do a bit of that frontier work, uh, uh, and, and do a depth investigation,
do a reproduction, and give some advice about what to do about this issue.
And it's sort of what you'd do with a coding agent today.
You might check it out locally and investigate the kind of thing, but
it's all done for you, proactively.
Um, and again, it's very general, right?
You don't have, it's the sort of thing we could never have programmed up
two or three years ago because it's amazing, you know, these things Yeah
these agents do.
But it's also very general and that means the burden I use repo assist
in, I think, um, 12 different repos.
They're all different and I haven't had to change it really between any of them.
So you can have these very generic, powerful, tools which help you
make progress, uh, expressed at the right level, low enough that it
actually kinda knows what it's doing.
It doesn't just do something canned.
but general enough, it's really applicable to everything.
Bret: I'm starting to see enough teams that are tiptoeing into agents
as, in their CI, essentially, right.
P- Somehow, somewhere sticking a model and writing a prompt in some fashion to
a model, whatever we wanna call that.
And they've, I think they, a lot of the teams that I'm working with,
see, the first experience is sort of, it's a checkbox feature in GitHub.
Like they might turn on the PR review agent for copilot and it's sort of an o
on/off thing, or you, you can opt in to each PR and it just becomes a feature.
So it doesn't really feel, I mean, even it's providing automation and obviously
it does, you know, it puts comments in the PR it does all these things,
but it, it's not something that they have to hobby kit implement, right?
They're not writing a YAML file necessarily on day one of that.
So I feel like that's the first phase.
And the second phase is where.
They wanna actually ha- you know, see everybody else putting Claude, code into a
CI run, or they, you know, they, I notice nowadays it's actually getting pretty
rare to look at the, uh, maintainers or, or the contributors to a repo.
And that Claude logo is always there, it seems like nowadays.
people are sort of figuring out how they can either write code or, or review code.
That feels almost like, for me, that wasn't the most interesting part to me.
So, someone who had to maintain the CI, I was always looking for things
that would, you know, automatically troubleshoot a failed check, right?
And try to provide an automated, uh, 'cause I, I'm that person who's usually
responsible when the, the checks fail because the dev team's gonna push back and
say, yeah, there's a configuration issue.
It's not our fault, blah, blah, blah.
And so we're gonna have that back and forth there.
And I, I've, I've started to describe this, because people aren't even really
sure where to start, and I love that the Agentic Workflows website, the
documentation really is starting to categorize these things into certain
areas where you're finding success and you're seeing the good metrics
coming out of tho- those results.
But I've often tried to describe it to them as just find a place where
there's huge human judgment involved.
that You've previously had to involve a human, but it wasn't a deliberate gate.
because a lot of people get nervous about, I think, the idea of AI in their
CI because the first thing they might even, l- or one of their first thoughts
might be, well, I don't want it to automatically deploy to production.
Mm. And to me that's like, of course.
Yeah.
That's probably the last thing I'm going to automate Mm. with any sort of, Mm.
uh, model it, you know, that is to me, sometimes a lot of teams, it's a manual
gate we intentionally put there, and so we're enforcing a human stop point.
But there's so much other, that's like you mentioned, labels, uh, automatically
labeling automatically, you know, maybe approving like low risk, patch releases
of Dependabot updates or something.
Like, there's probably some low hanging fruit there.
I certainly have been a part of teams where we've had to implement that
cross repo l- auto labeling, even just synchronizing back when we didn't have it.
Uh, synchronizing label names across repos, you know, just a lot of sort
of silly stuff that maybe just wasn't a feature in the product yet and we
were backfilling it with some sort of manual automation that feels
like the ripe, uh, opportunities for, uh, people getting started.
But do you, f- do you frame it that way of look for opportunities where there's, y-
human judgment that we have today, but it we, it wasn't because we enforced a human
to get involved, we just didn't have a way to automate that with a, for each loop.
Is that something that you, you frame it that way for.
Don: Yeah, I personally like to begin with uh, a chat about what are the
problems people are having in the repo?
Like what are the actual struggles that are happening?
Okay.
So, um, in the case of, repo assist, you know, having that chat with
myself, the problem is we've got an issue backlog of 200 issues that
go back years and years and years.
And every time I come to this repo as a maintainer, I don't
know what to do with them.
I don't wanna close them out.
I, 'cause there's value there.
I know there are bugs there, and I don't want to leave bugs that people
have found lying around this software.
so, my problem is one of kind of the burden of being a maintainer,
the guilt in a way, you kind of, you know, it's not, I, haven't got on top.
I love to get on top of the repo.
I'd love to get it meaning get that issue count down in the below
100, below 50, below 10, uh, and.
So the flow is designed to help me solve that problem and reach where I wanna be.
So I kind of like to have the discussions about like, what
are you trying to achieve here?
What are your goals?
What are your quality goals?
You're after, uh, you know, is performance the top thing?
That's your, your problem?
is sort of, is quality and crunching out the bugs, the problem is integration
and kind of cross-repo kind of working.
That's absolutely in a lot of settings, a ki- kind of problem.
Making things regular across multiple repos is a good example.
Uh, so once you start the conversation about, tell me
what, what's making life painful?
What's Yeah …causing you to lose sleep, then, what causes you to disengage from
the repo or, whatever I don't know, Peli, How, how do you begin conversations?
Peli: I'm doing extreme agentic development in the way that I'm
at, what, 400 plus PRs a week?
exclusively through, I mean, a- agentic workflows is written with
agents and the challenge is how do you create quality software doing that?
Yeah.
And this involves many, many agents, uh, looking at the generated code,
cleaning it, adding tests, extracting specs, generating tests from specs.
So there's an entire.
Intricate set of agents that are running and that are powered by agentic workflows
that are running in the repo and that are, look, you know, it's really exploring,
okay, what is, so we can, we can generate code at a incredible rate now, but we've
always known that creating a feature was a tiny piece of the equation.
You had to do test plans, you had to design features, research, you had
to write documentation, maintain it.
All that stuff is ripe for automation.
and where does the human fit in?
Where does the engineer come in and, you know, say no.
In my, stat, I think 20% of the PRs, I refuse them.
there's still quite a bit of engineering involvement I do maybe
three up, three intervention per PR.
so there's still quite a bit of steering from the, from me, but I have a lot
of tools that are agentic workflows that are optimizing very specific
angle of a code base, like reducing code duplicates, fixing linter issues.
And you know, I mean these are kind of sound practices that
software engineers have been doing.
Um, Yeah.
and then we go down the rabbit hole and we're like, oh, well.
We always fix something.
So now we extract linters.
So we infer linters from our, our own practices.
your devs are always fixing the same bugs.
Maybe it should be a linter.
then once you have a linter, you have something that is very scalable
in terms of compute and cost.
And then, but there's, there's something we discover with the
agent they're very meta agents can help, agents can generate agents.
And agentic workflows are an instance of that.
They, the workflows are really specialized tools in my mind.
You know, they use agents and everything's an agent, so we
have to put different names.
But I build tools, uh, and one of the unblocker of this experiment
is that I can go from an idea to a tool in five minutes that is running
in the CI and giving me a result.
The first version will be trash, you know, it will not work, it will crash.
And then there's a self-reporting loop and two or three iteration, you have something
that actually creating the value.
and then, you know, add more loops.
You get, you start optimizing and, and saving tokens.
But …that's essentially the key thing is zero friction from
your idea to an automation that's bringing value to your project.
That's paramount.
Yeah.
Don: Yeah, the repository as the kinda agent foundry, the agent host,
the place where you can just create and deploy your automation and, um,
get it to do everything over, you know, the fabric of the repository.
Create issues, It can add issue comments, It can read existing issues.
It can create pull requests, it can add to existing pull requests.
Those are the kind of, uh, discussions of the other elements
of the information fabric.
But that's, and it can read the security reports, it can look at the
actions, it can look at the CI runs.
And so that's the fabric information fabric you're working over.
And, um, it, it makes you look at a lot of the stuff that people are doing with
agent harnesses differently because you don't really need to think about
where you put your to-to-do list.
Let's just put it in an issue, right?
You don't need to think, where do you put the output, the analysis of, say
you've got an agent, which is kind of, uh, checking performance every, night,
different dimensions of performance, and running through them, uh, uh, or
checking your, get your, your, your getting started guide, reading your
docs, and kind of running through the kind of getting started material and
making sure it's simple and making sure everything kind of works right.
Those basic kind of walkthrough kind of things.
where does it put its output.
I don't.
wanna have to think about deploying this to some Agent Foundry and
some other platform, right?
I I, it's just gonna run in GitHub and it's gonna write its output to GitHub then
it's gonna create an issue or add, right?
A comment to an existing issue.
Uh, or it's just gonna create a pull request and fix the the thing directly.
Depends on the design that you want.
And, th- so it's that it's, you mentioned it earlier with GitHub Actions about
how having it right there next to your code is just a, a great thing.
And, uh, it's the same with this.
It's like right there on the information fabric we all know and use it knows how
to use the GitHub information fabric.
really well.
It's all about issues and how to query, them, how to search,
about pull requests and so on.
Uh, so, um, I love that.
I lo- I love that it's operating in my home, in my, my fact, my place
where we get work done together.
And Yeah …I love, love that I can dig back to the actions log
and see exactly what happened.
I love Right … when, when the agents of the actions log to
work out what went wrong, right?
Peli: Yeah.
The inherent every time you come back, yeah, every time you come
back to the graph, to GitHub, the engineer can intervene.
The human is back in the loop.
Right.
The agent does some computation, creates an issue.
Uh,
Don: th- That's right.
It gives that natural place for the human to be in the loop.
Yeah.
And, and that's, that can be so confusing when you kind of
disassociate from the factory.
you take it to the outside, from the repo.
Uh, and you wonder where's the, h- where's the human gonna be l- in the
loop in this kind of stuff, right.
I'm drawing out.
And the answer's really simple right?
it's in the pull request.
Right?
It's okay if the, uh, the, i- yeah.
Okay.
First of all, it's actions.
What it does to the issue set of issues has to be really tightly constrained.
And that's where we can start to talk about guardrails.
You know, it's not allowed to delete every issue.
It's not allowed to close every issue.
It's not allowed to comment on every issue or randomly kind of
write ha ha ha all over the place.
It's got really strong limits over what it's, what it can do.
It can add a comment to a single issue, for example.
That's a super strong limit.
Uh, okay.
But it can do that automatically.
it's not gonna boil the ocean or whatever its expression to
let it act on the issue section.
so it's kind of n- it's a big enormous scratch pad for these agents to work on,
right?
Uh, and, th- and that again, it makes it clarifying.
'cause you know, it's not writing to the repo.
It's not like writing a to do or goals.md or tasks.md into the repo, like a lot
of people are doing, it's very tempting to use the repo as the scratch pad.
Uh, But it's not gonna do that.
Uh, uh, So it's, it's, we've got our scratch pad that is issues and it's
got its way of proposing forward action in the world, which is pull requests.
And, uh, or you can also propose an issue or propose a pull
request, an actual concrete change.
It's very common.
We get the, uh, agentic workflows to create issues instead of
going straight to a pull request.
Because again, it, g- it's, it kind of divided into a world where there's,
it, is it, it's roughly a, like, is it gonna take one kind of check?
Yes.
Do it thing in the pull request, or does it kind of …offer choices?
If it's offers offering choices, then you'd better create an
issue first, because the human really needs some guidance.
The agent really needs some guidance about Right.
What's the next step?
But in that, the human in the loop is really simple.
It is just at digesting what the agent does in the issue space, the comments
it adds the options it gives and acting in the pull request space to make a
actual, big, uh, actual change progress forward in, in the code towards the goals
that, that everyone's pursuing together.
I love that.
I lo- I love that I know what human in the loop m- means.
I love that.
it just very clarifying in what is, and it's a- also something I can trust.
if all it's gonna do is create a pull request and just one of them
is that, it's almost certainly going to be useful what it creates.
So at first like, that's great, but it's certainly not, you know, I can
trust, I can sleep well at night that the thing is doing things in a
positive direction or certainly not in a significantly bad direction.
So guardrails and security, super, super important.
Do very worried about something you said earlier, Bret, just to be controversial.
you were saying, run Claude code or these, uh, coding agent
CLIs directly in GitHub Actions.
I understand the temptation of that and, uh, in fact, the origins of GitHub
agentic workflows are in that kind of space, but it's really dangerous, right?
The- We call that kind of running naked, We're kind of Mm-hmm …running
without a security architecture or rolling your own security architecture
or attempting to do the re-analysis of the security architecture.
At every time, every workflow you do, That's really easy to make mistakes.
And you're being exposed to inputs.
You you've got the world's most powerful coding tools.
And frankly, they can be used for good and they can be used for bad, right?
And they are running in GitHub Actions with potentially access to secrets under
the direction of your, of arbitrary people working up, walking up to the
repo of people feeding in information.
Okay?
So it's a little bit like you hire an amazing team of people.
They're sitting in an office and you're allowing people to walk in through the
front security gate and just feed them notes about what to do under the door.
And they read them.
They go, oh yeah, I'll do that.
You know- And they think those are
"I'll just do
Bret: it" … just as important as the boss's notes.
Yeah.
And they'll do
Don: any They'll just… You know, I mean, yeah, you can try and box it and
try and tell it's not so important.
And of course you do all those things, but it's still, you kind of want the
security guard at the desk, and you want the security guard you particularly
want, I mean, you want any outward action, any write action from that
team, any act external action in the world, any information sent outside.
if you're, if you're worried about private information leaking.
you want, it's gotta have a security architecture, you've gotta, you, you,
must, if you're gonna run automated coding agents in the context of anything
sensitive whatsoever, you must have a security architecture full stop.
That's Do not leave home without that.
in any serious way.
And- And that's what GitHub- the security landscape
Peli: is different than what people think is secure.
Mm-hmm.
It is not just running in a container.
Right.
There's a lot more threat.
These things are intelligent.
Don: Yeah.
So for instance, running in a container, but in our model, we
have some very strong guarantees.
Uh, And, we really care about security.
not just because we're trying to stop people getting work done or anything, but
because we think the better the guardrails you have, the faster you can run.
Okay?
The faster the automation can go, the better the train tracks are.
The faster a train can go, the more you can ramp it up, ramp
up the TGV up to high speed.
because you trust the rails you're on and nothing's gonna go wrong along the way.
And that's what, that's how it actually works with GitHub agentic workflows.
Now, let's just run through some of those guardrailing kind of things.
Perhaps one of the really big ones is that the agentic step, the actual coding agent,
the reasoning the… runs read-only, okay.
With just one Mm …narrow safe output that it's allowed to make.
Okay.
And that is a really strong thing, All right?
That it, we are not giving these things, write Access to MCPs.
uh, In our MCP docs, we say, if you're gonna add in extra mcps, you should not.
Give them write Access to the external world.
You should design these safe outputs instead, which are very tightly
controll- controlled handover points.
And when you really digest that, it's running read-only
without access to any secrets.
'cause we go through our gateway to access, uh, inside the
container and got the ga- gateway.
Those two together, huge relief.
There's no chance it's gonna leak all your repository secrets.
Right, Uh- right.
'cause it never had access
to
Bret: begin with.
Yeah.
It
Don: never had access.
And it's got a firewall around it for network access as well.
Peli: Yeah.
There's
Don: still concerns about there, but they're known concerns.
you can calibrate what's going on in that landscape.
And, uh, and I, it's that allows me to sleep well at night when these things run.
When we first started running coding agents and actions, I was worried that we
were creating actions that were gonna be hackable, com, subvertible, compromisable,
and, and you do get those people.
Uh, and, but it's this very tight containerization, readonly, no access
to secrets and, um, and, and very narrow scope of action in the safe output.
And I, t- together these allow me, I, I'm a guy who worries, Worried about things.
as we should,
And I think that
Bret: will- as we should.
I think that's been a hot topic.
In fact, I'm doing, uh, some workshops and I'm actually speaking at a conference this
summer around GitHub Actions security.
And I've also got a, a little plug for a open source tool I'm
about to release called, uh, GASA, GitHub Action security assessment.
That really just kind of takes the top 10 things that I see, or the top
dozen that teams I work with or, uh, you know, and I've been studying a
lot of these GitHub action, uh, supply chain attacks and trying to understand
where the core misconfigurations are.
'cause that's really what we're talking about Mm.
-a lot in almost all these cases Yeah.
It's really
Don: just where's the problem in this seven-step attack.
Bret: Yeah.
Don: where did that go wrong?
Yeah.
Right.
Bret: What, what step in there can we secure immediately and, and
without Mm. consequence or, you know, usually without breaking anything.
And so that's one of the, I, I, I mean- I'm trying to build a little
tool that helps people discover that.
'cause a lot of these things are just like Mm. features of the platform that
people don't thoroughly Mm. understand that event in a GitHub action workflow
or that particular Mm. checkbox in the security settings of Mm. GitHub
Actions in their repo settings, that they just, they left it by default
'cause they didn't understand it.
They don't know the caveats.
And, and so I've, go ahead.
I was gonna set you up real quick Yeah.
for this and just say, Okay.
Go, go ahead.
Yeah.
Like, what if people aren't fully aware of what's what we're talking about here?
If you just add like a step in a workflow and maybe your workflow
today, your workflow before didn't exist, and you add a new workflow to.
Take, to assess an issue, right?
Like you they- Issue triage.
you need, you need some automation around the title, and maybe for it to, you're
thinking, I wanna have a model intuitively s- select the label based on what it
sees in the description, and the title.
And so we've seen some m- disastrous often cases where people just, they add
a step to a workflow, they put a prompt in there that basically says, please read
through this, and then decide the label.
And here's my GitHub, uh, you know, workflow, my action token out of the
gate by default, which may or may not have full privileges to the entire repo.
and you think that "Well, I'm giving it a prompt to just change the issue
or just uh, to just change the, label of an issue or, maybe add a comment or
something at most, but they don't really understand the effect or the causality of
what they just did and prompt injection.
So can you maybe set that up, as like, the problem with that and how this helps
prevent that, obviously you said like removing secret access and all that.
but- I, I can take on
Peli: on that.
Yeah.
looking at the token you have with the agent, let's say
you have to write an issue.
So you're doing issue write Can create, delete, update any issues in
your repo at an insane rate, right?
And the title might be a prompt injection that changes the goal of the agent.
Suddenly the goal, the agent has been reprogrammed to close all your issues.
Or to implant malware to all your issues or, you know, but basically
there's nothing preventing the agent from saying, oh sure, let me go and,
you know, I'll curl 500 times and pass the token and do it, or so.
So that's the danger that these agents are extremely powerful.
Uh, and the security posture.
And the security construct we have, you know, when we say
read-only, it's at the token level.
It is a deterministic guarantee by the GitHub action platform.
It is not based on any kind of prompting.
This is a strong guarantee that you basically adhere to because you're
using the permission object in action.
The same thing where we say there's no co- there's no sequence in a container.
Then you kind of, some level of trust containers and so forth.
So our security story is based on DevOps primitives that are well-known
in industry containers, and permission scopes and things like that.
And that is the deterministic secure box we built.
Yeah.
So we don't rely on agentic.
we, we have some agentic protection, but as much as possible, we wanna
build a box that is deterministically, provably safe to some extent, right?
Some guarantees.
Don: Vibe security, Yeah.
Yeah …that's what we call it.
So when you, um, when you use GitHub agentic workflows, you write this
markdown and you write some front matter.
Okay.
It's, it's, it's lovely, right?
The front matter looks a lot like actions.
YAML.
It will be fa- familiar to people.
There's some differences, but, uh, it's pretty, pretty familiar territory.
Um, and you, you run this step called, uh, GHAW Compile, okay?
And it can produce the lock.yaml, which is a YAML that actually runs and that,
that compile actually, I, I, I wish we'd chosen a different word for that.
And we might make it a synonym, which would be something like Harden.
Okay?
Mm-hmm.
'cause what you're actually doing is taking that prompting
and you're kind of hardening it.
You're m- you're putting a security architecture around it.
You're saying, I'm gonna run that prompting, I'm gonna
run it in in a coding agent.
But that's gonna be, you know, we're gonna create the YAML, which puts it in
a nice box and gives it a nice, secure thing and puts in a threat detection
step to as a, as just a extra step.
And I think that's the right kind of model to use is what I want an
automated tool, which will just make me feel good, safe about running
that, uh, about r- uh, running that coding agent in GitHub Actions.
And where that, we run that YAML through several checkers as well.
Actionlint, and uh, zizamor and, uh, there's another one as well,
Probably- Poutine … Poutine.
and, um, Poutine, Runner
Peli: guard.
Don: Okay,
And
Bret: so we run- Ooh, uh, Spell that for me.
'cause I don't know about that one.
Peli: P-O, P-O-U, you know, like the food, like the Canadian
Bret: fries, like the gravy Cheese and the fries.
I love, yeah, the gravy.
Yep.
Yeah.
Okay.
I'm already in.
Sign me up.
Yeah.
Don: Yeah.
so we, run those tools, uh, they caught some things in the
YAML, uh, in our hardened, YAML.
And, um, so there's a lot of goodness there.
And there's something you can hand off to the, it means your security team,
if you're doing this in an enterprise, can actually check that YAML as well.
They get to see what's going on.
They get to see the full security architecture and check
it matches up with what we say.
They get to see the exact container settings and its firewall
settings and what's mounted and what, what's not, and so on.
Uh, and yeah, so yeah, the guardrails are good.
And I love the security architecture and the confidence is it gives me to
run fast, uh, with agentic automation.
Peli: Yeah.
So back to, building educational runtimes and, you know, you think about velocity,
what this sandbox gives you is in the strict mode, a guarantee, because
that you're not gonna leak secrets.
So you're gonna have a read-only token when you're a, you know, the
agent won't see your agents, and that you have a very specific, you know,
precisely where the agent's gonna be able to mutate the world, right?
Because all the writes are transactional and then we validated them.
there's a layered, a number of layer of guarantees, and you're in full
control saying, I will allow you to do one issue as Don said, or "I
will allow you to open an, a PR.
Right?
So from a practitioner's point of view.
These are guar- deterministic guarantees.
Then this allows you to go wild on the prompt side and do back star and
do YOLO because you're gonna YOLO inside of the container, not on your
dev box where all the secrets are.
Um, you're gonna YOLO in a container that has no secrets that, you
know, you can't escape unless you break out of the container.
But, that is insanely empowering.
because now you can try things without second-guessing everything.
You can try things faster, more tools, without taking down the whole house.
That will take you from trying things very carefully with AI to
actually go, go, go, go, go much faster because you have safety.
So people underestimate the fact that,
To,
Don: to give an example, uh, on, on, on it means you're gonna write
prompting of things like, okay, agent, work out the test coverage
in this repository and improve it.
Okay?
Find the big holes and assess the value, uh, and choose the highest value bits
and fill in improve the test coverage.
That means it's actually going to in- possibly install tools
to be taking test coverage.
It's gonna be working out the command line invocations to kind of do that.
you know, stuff, if this is a c thing, you know, the impossible
stuff of ever taking coverage of a c repo or something like that.
And, uh, and it's gonna be reading the files.
Uh, and it's gonna be, uh, it's just gonna be doing everything right.
Yeah.
And you can keep your, it means you can keep your prompt in general
and the agents will use the full power of the software engineering
toolkits that it's got, uh, available.
And one of the magical things as well, you're running in GitHub Actions and,
people take those VMs for granted, but, and the system side of what's
built there, 'cause that's a Sure.
I don't know how big are the images now?
Like hundreds of gigabytes or something?
Terabytes.
Oh, really?
there's a lot of secret ingredients There's- …that
Peli: make action an amazing platform.
Yeah.
Don: Yeah.
Mm. So that means every time the agent, every time your agentic workflows, or
in fact your YAML workflows are kind of waking up, uh, or, or running.
They're running with all the world software engineering tools, kind of very,
very efficiently available and well-known install locations and all sorts of things.
Yes.
And, uh, that gives them a super powerful, um, I mean, they're just,
they're just incredible what they can do.
Peli: So, for example, if you think about the actions and the features you
have, you know, every run is recorded.
Every run you can store artifacts.
You can, You have APIs to read them.
So we store the agent session, the sessions that are sitting on your dev
box individually, they're kind of lost.
We store them.
So we analyze them, we optimize them, then we debug that.
Uh, so the automated agentic workflows are primed to be optimizable,
debuggable because we have full history.
You run things five times, you realize you always do the same MCP calls.
What happens?
You tell the agent, move these MCP calls to steps.
And guess what?
Because we're action, we can do a mix of deterministic, just
good old steps and agentic.
So let's say your agent does, you know, give me the the 10 first pull
requests, and it does the GitHub MCP.
That is an agentic step.
It eats a bunch of token.
But now you move that into a GH PR call as a step, drop it into a JSON file
and let the agent do JQ bash on that.
Suddenly your agent is eating 10, 10 less turns, 20 less turns.
Mm. you've moved the dial.
That's one of the interesting, these are all interesting things we've discovered
in actions that being able to pull the dial between deterministic and agentic.
Because in your CI we're 100% deterministic historically, And
people have gone 100% agentic.
But the truth is Yeah …it's gonna be in the middle.
And the more you are.
Yeah.
The more you're deterministic, the cheaper it is.
The most, powerful- And the less…
Don: Yes.
they are, uh, that's right.
So, and that's why we love being in the actions ecosystem, because those steps
can also use the full existing, GitHub Actions, everything in that ecosystem.
Yeah.
And, uh, and that's, that's really powerful.
Peli: You can see this gradient coming right in your CI, you know, 100% CI, 100%
deterministic, but now you start squeezing in a bit of agentic as much as you want.
Maybe just a little reasoning at the end of your test run, you know?
Yeah,
Don: yeah.
I do like to point out to those, uh, people who are really big
on, like, CI, and CD need to be deterministic, and we absolutely
have to kind of nail that in order to 'cause it is That's absolutely true.
we don't challenge that.
Okay.
We say there's a, a third area, a new area, like a third leg of a
stool that we didn't know was there.
Right, Which is like continuous ai.
Right.
Which includes some of these subjective steps and it's got different properties,
but the continuity is a big part.
The automation is what is and the kind of always aligning with the state of the
repo as it is today, which is what we kind of mean by continuity, continuous.
Um- the claim
Peli: is bolder.
The claim, you need CI and deterministic and fast.
This is how you're gonna tame the agents.
The agents are, you know, little monsters.
Don: Absolutely.
It's the ultimate guide.
This is the
Peli: golden era of CI.
Don: Yeah.
Peli: Yeah.
The Teams
that don't have CI will not benefit from this.
The Boost.
Bret: Yeah.
I've often thought or described it to people that, uh, are asking me like,
you know, where I get started and I, I talked to them about that, you know,
you're probably not gonna rewrite your Docker build workflow to be agentic.
that's probably not the area of focus.
I would imagine that a lot of these, the majority of these are n- net new
workflows or expanding Absolutely.
An existing workflow to do things it couldn't previously do.
Not rewriting my reliable test runs.
I mean, maybe there's an AI that's gonna help me automate parallelism and all that,
but it's separate from maybe the run.
itself.
Yeah.
And It's
Don: really, really important.
We get that deeply because the way one of my friends put it is like the CI/CD.
And in fact, GitHub in many ways is where the grownups are in software.
Development process, right?
That that's, Yeah …you know, we're all going crazy about doing our coding agents
and YOLOing on our local machines and you know, whatever kind of cra But in the
end, the place where you build confidence in an organization where you feel you
can deploy, where they're in your CI/CD.
and we've got to keep that grown-up mentality about quality.
And we want, you know, when we talk about code improvement, we we're talking
about proposed code improvements, which have to get through the gates, right?
Yeah.
We're not talking about things that they should come with test improvements, right?
That kind of match that just like you'd expect from any pull request.
so we absolutely have to keep CID being the place where the grownups are and keep
the mentality that goes along with that.
Uh, as well as having a more flexible idea about automation.
And we wanna really empower the DevOps people.
This is like, what it's all about is like we feel there's just this missing piece
of the puzzle in the AI story, which is where we empower the people who run the
repositories to use AI to their benefit.
And we know some people are suffering in the open source world from
AI coming in from third parties.
Right.
We wanna empower people.
So the maintainers and the people who create the repos decide What
automation runs in their repositories for what goals, under what c- cost,
trade-offs, what, you know, what quality trade-offs and everything.
They're the ones who can balance those things in the context of the
business goals or the open source goals that they kind of have.
And, uh, yeah, empower them and, and not, not, don't just make them suffer
and kind of the recipients of Make them.
Yeah.
the- And they'll see so many new uses for it.
That's one of the things, this is job creation all over the place in the sense
there's so often, so many opportunities to do work we could never have done before.
Performance optimization.
is a good one There's, there's- this is literal job or at least
work creation because the people up close to the repos are the ones who
know what, where the suffering is.
where the, where the un, where the unenforced invariance, unenforced
quality, uh, the, the opportunities for improvement, which were never explored.
Uh, and the, the legacy code, which can actually be brought back alive and
actually serve a, a, a role going forward or transition to a new system or whatever.
Peli: Yeah.
Don: So many opportunities for work, once you get into the
right mindset and, uh, yeah.
It's, it's a golden age for DevOps people, uh, who, um, to create There's lots
to learn, but it's, it's a golden age.
Bret: Yeah.
D- I, I have often, The more I've understood the mindset behind your
creation of agentic workflows and how, you know, like my first realization
was if I start looking at this lock file, most of this is deterministic.
Yeah.
it's relatively long.
It's not, it doesn't look anything like something I would write in a GitHub
action workflow, but it is really just a, mostly a framework around, at
least when I first got started around controlling and protecting and guiding
it, it is to this very small part that's actually a model prompt, Yeah,
Don: yeah.
It's, it's, yes, it's, that's right.
There's somewhere in the middle there's a invocation of a coding agent, but
you put all this apparatus around it to say, we were gonna make that safe.
We're gonna make that guardrail.
And we, and yeah.
Go on, Pavel.
Peli: Yeah.
There is something new.
Actually, you know, if you look at agentic workflows, it's, it's a big YAML.
I mean, by this time, we support a lot of features, but you
don't even edit this yourself.
I mean, at least for on the, in the ideation phase.
And, you know, until you reach your 90% done, this is gone.
This is done through an agent.
You don't actually have, you have to come in with your intent,
what you're trying to achieve.
And we, we've done a lot of research and we've done this, we have this prompt
that is gonna try to generate the best agentic workflow for you as a starter,
but there's also a completely new experience where as an automator, you use
an agent to design that automation, and then you can fine-tune, you know, and,
and run the compiler deterministically.
But this will get you from 0 to 80%.
Without actually having to read the documentation.
'cause you come in and say, um, you know, you, you name your scenarios and
you, you know the keywords, you know, issues PRs, build workflow, run test.
The agent has access to your agent md the agent has access to all your actions.
So if you already have CI/CD, the agent can read your CI build,
figure out how you build your software, how you run your test.
And one thing that is great about action is that it is baked into the LLMs.
LLMs today know very well action.
They know how to write the YAML, they know the entire schema, they know how
to refactor it because people have been blogging about yeah actions forever.
Uh, so there's like this free, you know, we have this format is actually
designed to be close to what the agent would expect because then you
get this magic where it just knows it, there's no fine-tuning needed.
You can tell it to refactor the prompt into steps.
And it's like, sure.
I mean, yeah, I, and it knows the ecosystem.
It's gonna go and pull in the right custom actions to, you know, to
do actions GitHub scripts, or to do checkout and all this stuff.
So that is also part of the magic here, is that not only we're leveraging a platform,
but we're leveraging the fact that the platform is already trained in the model.
Yeah.
You don't need to load a skill to learn actions.
It is already in- This is some new product.
Bret: Yes.
Don: Bret- I- uh, ca- can I just share, uh, my screen briefly?
Oh yeah, sure.
Yeah, I, just wanna, just wanna show one, one thing to kind of get across why Yeah.
why I'm so excited by this.
uh- yeah,
let
Bret: me, um,
Don: All right hold
Bret: on a second.
let me pull that in.
I don't have that button on my stream deck.
One second.
You can see it.
I can see it, but I need to put it on the screen for, everyone else to see it.
I need to give it a guest place.
And then, let's
Don: see.
There we go.
All right, brilliant.
I, so I just wanna briefly mention this, this particular workflow.
This is a, uh, this is a workflow.
You just install one of these in your repo and it kind of
helps you maintain the repo.
Okay.
This is the thing I mentioned before, repo.
This is… and, uh, it, it's really simple getting started and.
it's super, and this is kind of how, how it works There's a diagram here
kind of selects a couple of tasks.
It reads the memory, and these are the different tasks It
might do issue labeling for you.
It might do an issue investigation and the other things.
And you can configure this and you can edit, you can say, add
a new task to do this or this.
And, you know, and it kind of just works on a daily rhythm or hourly
rhythm or whatever rhythm you want.
And I kind of wr- I've written up, uh, written that up in a kind of blog post
and you can kind of see how it works.
but I just wanted to sh- share this really, which is this
report we've written, uh, on the impact of using repo assist.
So if you kind of look at what's on the screen.
You can probably guess where we started to use repo assist in this particular
repository There's a number of issues that were open in the repository.
So this was a pretty much dormant repository, but with a backlog, right?
It's got a… you know, I, I as a maintainer sort of stopped engaging with
this because I didn't actually, each of these issues would've taken me sort of
a, a night, probably in the traditional way to kind of reengage with the issue.
And even if I was doing it manually with a coding agent, it would've
taken me significant, 20 minutes, 30 minutes, an hour for each issue.
Okay.
And instead you've got the automated AI effectively r- burning through
the backlog, commenting on it, making pull requests for it, and
like actively, proactively kind of.
make solving all the, all of that backlog.
And I mean, boy, it allowed me either to close out the backlog or actually fix
the backlog and make I think three major, some of this was feature requests as well.
So it actually kind of took the repository forward as well as implementing
features and got three major new versions of this, uh, of this component
out in, uh, as open source releases.
And, that repository is now in a good state.
Reposys continues to run.
So if there's any more, uh, it's now running sort of on a weekly
kind of basis to as a cost control.
And if any new input comes into the repo, uh, new issues, uh,
it will, it will start to do.
Its, its kind of magic.
It will look after that for me.
Uh, and of course I'm still in control.
The human's still in the loop, but you can just get the very dramatic
difference it makes between software with bugs to software that is actually
maintainable and fully usable.
And it's not just one repo.
Here's another repo.
The same workflow, uh, with, uh, here's another one.
This is a different maintainer.
So it's not just me, other, other maintainers picking it up,
a slightly different percent.
Uh, but you know, after, after a month of sort of this thing ticking away,
uh, it, the repo's in excellent shape.
Uh, Here's another one.
This is something I co-maintain with somebody else, uh, it's
a, slight different trajectory.
And, uh, and here's another one where there were good reasons to leave a lot
of, uh, feature suggestions, uh, lying around the repo at the end of the kind
of, uh, as it acquiesces at the end.
Yeah.
So, um, That's cool …super, super happy with how this is, uh,
this is going, uh, this one, the maintainer actually only comes back.
He said, So didn't wanna work on this full, time.
didn't wanna crunch a whole lot away.
was just kind of happy just to kind of come back to it every
few months and kind of this graph will keep going down step by step.
So the, the report we're looking at is, uh, just to bring it up to
the top, is the impact of automated repository maintenance assistance.
and you wrote a blog about this, right?
on our GitHub Next site.
And yes, there is a, uh, blog, the blog about Reposys in general, and on my,
uh, just grabbing this is a, is a link to our new report, from GitHub Next,
it's on our GitHub Next site as well.
Yeah, so check that out.
Uh, where was that report?
Um…
Bret: Yeah.
Uh, I think to me one of the most exciting things about all of this,
and, and we're, we've been hinting at this the whole time, is that the.
As a CI maintainer, uh, uh, a-as someone who's m- I call it the middle gray area
of the software development life cycle, where it's post-commit of the developer,
but it's, it's pre-production running.
And everything in that middle has been like, I, I, r- I can remember, we, if we
go back to even 2018, I can distinctly remember at DockerCon and at KubeCon,
we were talking about what was the next wave of innovation, because we felt like
the container ecosystem had matured, and we kind of knew what that looked like
and how to move things around as images.
And that was all well-defined.
And w- at the time, we were all talking about the CI platform
as the next piece of innovation.
And there was all this discussion around different startups that were getting
funding because that was gonna be the n-next opportunity for innovation.
And uh, we, there was experiments that, you know, GitHub Actions, uh,
workflows were probably part of that.
Like that was a part of that wave.
It didn't, it was awesome, but also didn't seem to always fulfill the
promise of what we were trying to innovate on and reinvent in the CI space.
But I feel like we're finally at this moment where.
I might just be able to do all the things I always wanted
to do to fixing the platform.
You know, the maintenance, the toil, the backlog, the endless
backlog of things that needed to be optimized or locked down or scanned
or improved, like documentation.
And that w-we… management always tended to, you know, focus on the feature set.
You know, th- those of us in DevOps are always trying to help, help
them understand and that there's more than just adding features.
We need to maintain the system.
SREs are a thing now, so we all get this, you know, we at least get
someone in production that's helping to optimize the production information.
But I feel like the CI platform is still this sort of, uh, if redheaded stepchild
is a thing we still say like, it feels like the thing that still doesn't get the
love and nurturing that it always needed.
and- Mm. I mean- …I've lost count of the number of places going
Don: Yeah …my view, it's the center of the factory.
It's the, it is the software factory where all the grown-up stuff happens.
So much of the forward progress happens beyond the- yeah.
Maybe feature development, which might be done by agentic, local,
or Pele actually does a whole lot in the CI It's just Everything.
He wants a feature implemented, he just writes an issue and, uh, or, or yeah,
everything comes through it's CI system.
Amazing.
It, You know, the, the software factory- So you're- …is real.
And
Bret: so you're not prompting you're issuing You're issue prompting?
Uh, no.
Peli: I skip the issue.
Uh, I set a prompt directly, but a lot of it.
Are agents that create issues.
So the issue is Oh, okay …a work queue.
Right.
Mostly.
So a part of the work, which is maintenance and code improvement,
uh, or documentation updates, would be produced daily by, by workers.
but you know, what you're saying is right.
It's, you know, up until now you could have a sloppy CI and for example, you
could rely on a good dev team to kind of trust your, you know, they would do
the right thing, you know, the quality.
This is not true anymore.
The only thing, the only way you're gonna leverage these agent is to have
a very, very tight CI with a very good test suite and not just one test suite.
You need test of the test integration test first test.
I mean, you bring it.
Yeah.
Because you need to triangulate them so that they cannot escape that box.
And then you, and then once you have that, you can get the boost.
The boost is the cloud, your dev box.
There's only so many eyes and so many terminals you guys can handle.
So I don't know if you're, if you're a spider, you get eight eyes and
you can maybe do 64 terminals in the cloud, I can easily run hundreds.
Okay.
So let, me- There's, there's like no compare.
Bret: Yeah.
Uh, let me ask real quick, 'cause I think one of the things I love
about this, or I, I try to optimize on this show is to change behavior.
Give people an insight that will actually cause them to do something different
rather than just executive over-overviews.
not that we've been doing that, we've been digging in the weeds, but I,
I'm, I'm actually very curious like.
if When you're on the forefront, can you talk through what it, what your
activity looks like when you want to create something new with the CI?
So you're, you're prompting the LLM on your local harness, right?
It sounds like it's creating the issue on your behalf.
You've got a bunch of automation running in the background.
Are you asking it to like develop the PR and then you're gonna wait for it
to tell you when the checks are ready?
Like are you even going to GitHub or are you like harness first?
Like t-talk to a little bit through that so that we can get an idea.
Okay.
I'm,
Peli: a bit extreme.
Sure.
Um- That's what I want, I want,
Bret: I want the red pill all the way.
Peli: down.
So first of all, it's fully async.
Okay.
there is no discussion on my part with the agent.
I fire and forget through, git, the GitHub cloud agent most of the time.
So, you know, you go either to github.com and you do new agentic session.
I mostly use my phone.
So I do that from the iOS app.
So I'm not waiting.
That means I can have five to 10 agents running at all times.
And it's just like playing chess on multiple boards.
Now they take time.
So if I forget what do you do between the agents, you think about your future.
you have more time to think or you talk to people In fact you have more
time to talk to people because the agents are doing the work when they,
s- how is this gonna change your work?
So.
That's a very big one.
people are into the token, you know, they look at the token
flowing down and it becomes a slot machine, and they get addicted.
They get headaches and stuff.
They're tired.
Yeah.
Don't have, you know, just schedule the work.
let it churn for a while, come back.
so that's One big thing.
Now when I determine that there's a pattern that I'm doing the same
stuff all the time, or there's like something I'm thinking in my head of an
automator, whoa, I could do that again.
You know, there's like, there's some value to that.
So the most obvious one, one of the first one we wrote, was like, this
agent creates a lot of duplicate code.
And it did it in kind of a, a very subtle way.
it would rewrite string functions, like string start, string, you know,
string split, but in different ways.
so I had this idea I was like, okay, maybe we look at the, we look at
the function titles and we ask the agent to bucketize them by intent, So
because the body of the function may be s- completely different, but the
intent of the function, is the same.
so you open your phone and you say, create me a daily agentic workflow that uses some
LSP to list all the functions or regex to list all the function in code base.
Bucketize them by intent, pick the biggest bucket and now generate
a prompt that says, remove all these duplicates." That's it.
That's all you have to do.
Wait five minutes, you get an agentic workflow.
As a PR, you review the PR, you look at the safe outputs,
which are saved by default.
This is your first version.
probably not efficient, but it's gonna run, it's gonna burn a lot of tokens.
It's not, it doesn't have the right MCP, you know, it's not
optimized, but it kind of works.
Yeah.
And you're like, concept this is real value.
Then, you know, we iterate and so forth.
And this concept of, I've got something that, that annoys me in my code base
and I can get goodness I can get slight improvement in a human consumable
way, which is basically the daily newspaper concept is insanely good.
First of all, it's super fun.
You feel good because like, "Whoo, you know, my code is better now.
it's a new way to also handle the agent, because upstream that means
you don't need the perfect PR.
You can work in a feature branch.
You can go faster by not doing the 17 nits.
Mm. because you have cleaners now.
You have tools that are looking for patterns that are
known to happen with agents.
You know, they're gonna happen.
by the way, humans were terrible at coding too.
We forgot that.
But, uh, so now you clean everything, human or non-human,
you clean all the patterns.
and we've been, I mean by now we have what?
27 or 50 running.
So we have also a summarizer that looks at them.
I don't have time to look at them.
I have something that mines them, We track them.
But it's always started from there is something I'm doing all the time and I
wonder if the agent could actually help.
And this is important, like, I don't know at the moment I'm writing the agentic
workflow whether it's gonna work or not, Mm. but my time, my experiment costs
me five minutes, 10 minutes, So I'm not investing three months to build a static
analysis tool like we used to, like, Hey, maybe this works and some of them
are just terrible or just too expensive.
You, know, or,
they're, but a lot of them are like, surprisingly good.
Then you put the right MCPS and so forth.
Uh, then we optimize.
By optimize.
I mean, think of an agentic workflow as a concretized plan.
You've done sash plan, you paid for opus, you burn a lot of tokens.
You've got a really good plan.
That one is now set in stone in your agentic workflow.
That means you can go for a lower model to implement.
Mm-hmm.
And then you can start splitting into submodels and everything.
Lower your tokens.
And all of these are hyper-specialized tools because they, the clearer the
goal, the better the agent gonna be.
So these are all kind of intuitions that we build, that we've kind of
measured, that we use, um, so it's like a plethora, like a, an insane amount of.
Very, very specific tools.
Yeah.
Linters are a good example you know, this kind of tools we've built over the years.
Yeah, I love- Linters have rules.
Bret: My my favorite thing, and I think I might even have it in my global agents
file on my machine is always, always lint.
Uh, at the end of every edit you make, uh, or at the end of every run of an edit
you make, because I, I don't even wanna s- I don't even wanna look at what your
output is unless it's passed linters and, uh, at, I think the minimum, like you
ment- you mentioned the actionlint and the zismore and, yeah, these are Yeah …like
table stakes for me, for GitHub workflows.
Uh, I was just curious real quick.
Yeah.
What is a, what does optimization look like?
Is that just improving prompt, it, uh, when you're So many
Peli: things?
Yeah.
So you wanna have the same performance, the same reasoning,
at a lower cost, right?
that's really the end game.
you don't wanna degrade your performance, but also you don't wanna pay, you
cannot just pay opus all the time, Uh, so there's a lot of tricks in the bag.
And we talked about moving, turns into the step side of
the action Pre-computing data.
Also, this grounds the agent.
You do the computation, you cook some python, you're given the pre-fed
computation with all the aggregates and say, now reason on this and don't do any
computation, don't make up numbers, right?
So that's also a trick too.
But then other things are using small models.
So splitting a monolithic prompt into a prompt plus small models, typically.
For example, if your task says, go and summarize files, the file summary can be
done by a small agent, a subagent, Yeah.
Then comes back with the summary.
Right now, you've actually went from a 6X model sonnet style, you know, 6X, to 0.3.
you've dropped by 20X your cost per token.
Um, and of course, you know, there's a prompting and we have
AB testing in the platform.
So when you run at scale over thousands of repos, you can start doing campaigns and
field test, prompt improvement and measure in a scientific way, in a reasoned way.
Just like, you know, think these are really websites, right?
at the scale you're going to run these agents.
My belief is that it's not really an eval thing, it's more like a website where you
do ab testing on features, you're going to do ab testing on prompts or model and so
forth, and measure as you're spending the money measure whether they work or not.
It's really hard to build evals when you have hundreds of agents and
everything's moving all the time.
Right.
Uh, but- That's
that's
Bret: a lot of eval runs in addition to the agent runs themselves.
Yeah.
But AB
Peli: testing is a proven way of fielding, uh, improvements and measuring.
Don: Yeah.
And in terms of, you know, the people on the call watching this, uh.
you know, One of the big behavior changes and mindset changes is
like, what's your future work gonna be in an enterprise, right?
It's not just running over one repo, but you're gonna be the agentic maestro or a
team of agentic maestros who are able to do things at scale across tens, hundreds
of repos in say, a major, uh, a major organization that might be about like,
uh, applying security patches, uh, or making judgment calls about how the impact
of what it means to roll things out.
It might be, uh, making things more regular across those repos.
It might be, um, improving the test, uh, assessing the
test coverage across the repo.
You know, if I was the CTO of a major, um, all companies, software companies
these days, I'd kind of want a report a summary report, up of like, what is
the, what are all the repos we have?
What are, what's the status of them all?
What, how do they Right …cluster together?
How do they, how, what technologies do we actually use?
And not just based on what we think we use, but actually assessing,
what we actually depend on.
And so there's so much that's even on information reporting, kind of working,
kind of going up even before you get to kind of taking, improving all of
those different, uh, repositories.
Yeah, I, I, I, I think there's a, you know, I've been worried for a long
time that some of these, you know, I'm in London and the there are a
whole lot of investment banks down the road, I've worked with some of
them over the years, and I actually am really worried about some of them.
You know, I'm worried about their software.
They, they tell me they've got 20,000 production systems or
something like that, right?
And It's just like, Yeah … uh, it's, it's insane.
It's, the, the, the, The software legacy debt that they have across
those systems is just huge.
Luckily for them, the tools have now come along, which can deal with that.
But they need agentic Maestros to come up with the workflows to get a grip
on that software complexity in uh, through summarization and action and
all sorts of other, yeah, along various dimensions are kind of kind of working.
So we're not just talking one repo, we're talking a whole, the agentic
organization and how that actually maps down to actually working
with real software artifacts.
It's not just something in theory or something kind of, Some of these
automation platforms like, uh, you know, Asana and NAD and the other
ones, they're much more on the kind of information working side,
like working with the HR systems or your, uh, ERP systems or whatever.
this makes it very concrete to me, like I now know what the agentic
enterprise means for the whole software side of the enterprise.
Yeah, it's very real.
It's like, it, it, there's a lot of work to be done to make.
To actually crank the handle on that and auth, a lot of this becomes
auth constrained, for example, who's allowed to do this stuff, right?
Yeah.
the ideal job in this world is where you have maximal auth and you are trusted.
And that is what the maestro really, the, uh, the grand wizard of the enterprise.
That's the ideal job to have in this kind of situation.
You've got lots of power, lots of tokens to spend you, or can find
out what the actual business value work, uh, to be done actually is.
And you can actually make it happen not just shout from the sidelines a-
across some organizational divide.
So yeah, you want to be part of the grow- If you're looking for a new job to, or
a new career direction you want to be, you want to be leading the conversation,
the agentic software, automated software conversation in your whole company.
However, that is
Bret: the continuous AI czar.
maybe we'll workshop the name.
Or the group of czars.
Don: title, I mean Yeah, The group.
I mean, it doesn't have to be a single czar, but yeah.
The, the maestros, the, uh, the thought leaders in the company, the people who
see this in multidimensional ways, uh, who aren't just, they're not just nutty and
evangelistic, they've grown up about it, but they can use re- repository automation
at scale for positive action across the
Peli: whole.
org.
it will be the catalyst for a reorganization of software production.
The way we build software will change because we will design new processes
between agents and humans where, you know, we've been doing the pull
request for a while, the agents are kind of, you know, kicked in the
door and starting to shake things up.
But there will be new ways to build software and they will.
And you know, and we are seeing, in a way we're experimenting with all
these new kind of flow, information flow and production flow that involve
agents, human agents But, we do it fast.
We have the means to do it safely.
Yeah.
Don: My, yeah, the one I'm currently, um, which is a kind
of a software factory, uh, image.
I've used that kind of terminology quite a lot.
And, uh, when you said like, what's the action?
How do I, how do I start my design process?
At the moment it's about saying, let's build a factory, uh, where there's
actually lots of inputs flowing in.
They might be issues of some kind, but they might not be just
issues in a maintenance sense.
It might be like in, in the case of GitHub, we have automated tools which
find problems in, in, in GitHub problems, in the logic of how we use our databases
N+1 problems and things similar.
So you're kind of going to get these to flow in and then you've got a
whole automation human, a mixture of human and the factory is a, is a place
where both agents and humans work.
Crucially.
Okay.
And When you think of it as a factory, then things can get
blocked at the human point.
Like the, uh, even when you get all the automation set up, which is really,
really great, you, it can still get blocked by overwhelming the human
with too much kind of generation.
And you can either scale that back or you can increase the quality.
There may be good reasons why they're doing that, or you can
actually turn off the whole factory because it's not actually
serving the humans' needs properly.
Okay.
So the, the aim of the agentic maestro is to design that human, i-e,
that, that, that agent-human factory and make it flow, make it work.
'cause when it does flow, you get those really dramatic results on quality.
Bret: Awesome.
I feel like it's been, this has been a good discussion around, uh, agentic
workflows because I think that's not, it's not a feature that we see in the UI
n- yet, so I feel like it's still really early days in terms of getting everyone
to be aware that this thing exists and how to go about implementing it.
So I'm excited about talking more about it, and especially now that I, I feel
like you're giving me more reasons to pay more attention to it because
I'm realizing that I've, even though I've, I've dove into some of it and
implemented some of it that I'm, I'm still, I feel s- I'm a babe in the woods.
I'm a babe in the woods right now, but, um, so, so
are
Don: we.
Yeah.
So are we, yeah.
I wanted to ask you.
It's an exciting
Bret: time the last question or the last topic before we wrap this up.
you're both, you're bo- o- one of you is GitHub Next one
of you is Microsoft Research.
You're basically both already thinking years out.
my assumption is that there's, there's things that are coming.
So like what, this is all brand new to us.
It's, I'm sure it's still very new to you.
Like what, what is the thing that's coming, not that this is ever replacing
this, but like what, what are you excited about for the rest of the year?
what else do you, is it more pl- finding more places that this can operate or like
sussing out the real value of where these workflows are running in sort of m- like
maybe, maybe maybe making t- the top five list or the top 10 implementation list?
Like where is it that you, you're looking to in the short term?
take this.
Anyone wanna I'll let
Don: you first?
I'll
Peli: let you we're still in techno preview.
Yeah.
So In a sense it's, we haven't, we're still in first gear.
so very excited to see where, where the product is gonna go and we're
gonna really be able to, to go out and try to, and we have intuitions about
what's gonna happen when life scales.
We haven't really done it.
Yeah.
And very excited to actually learn.
Everything's fine when you have one repo, 10 repo.
But we are very much looking forward to 1000, 10,000, 100,000 scenarios.
And now looking at large scale, agentics and all these scales, economies
are gonna happen, uh, through that.
personally I think it's a golden era of CI.
I mean, if there's one thing out of this discussion is yeah, stay in CI,
it's gonna get good because everybody's gonna turn to you and say, how do I
run my agents in your, in your CI?
how do I do more agent stuff and you know, and do all these, I heard
this and I wanna do it in your CI and they're gonna turn to you.
Don: Yeah.
Peli: And they, they're they're also, they're,
Don: al- they're also gonna turn up and say, Hey, can I use
OpenClaw inside the enterprise?
You know?
'cause I wanna automate my, like, uh, I wanna automate doing
my PRs inside the repository.
And it's just like, you know, maybe you could go learn ag- get agentic
workflows because that's, that's actually like a, you know, pre- it's
pretty safe way of doing automation.
Right.
And they're gonna turn up.
with… there's, lo- we're seeing lots of other, We already kind of
touched on the, like run the naked coding agents kind of approach.
And it's like, the answer to that is go use GitHub agentic workflows, right?
'cause that's got, that's got a security architecture.
You can also make, there'll be other options as well.
There'll be other security, architectures.
Yeah.
but there's an answer to a question that's there.
And, and we, we chose a continuous AI framing because it was.
It's An industry, we wanted to create an industry neutral term that a ju- uh, just
like you've created Agentic DevOps and, they, and they're more or less, two, two,
very closely affinitized, which is great, and, and they, they're questions with
an answer, with a natural answer, which is GitHub Actions and, G- and GitHub,
which from a product perspect- product development perspective is, I'm very
happy to have made those contributions and where we've landed with all of that.
Uh, in terms of looking forward, there's all the kind of rollout of
this kind of agentic workflows at scale or agentic working in the enterprise.
And that's gonna take years to roll.
the enterprise turns slowly, development teams turn slowly.
They've got their own opinions and their own skilling.
As I said, this isn't, this is about as much as I use the agentic maestro
thing, the Agentic maestro also listens to the dev- developers, listens very
closely to them because they're the ones up close to the coalface who
know how to maximize, they merge
the
Peli: PRs that are not,
Don: and they probably merge the PRs or not.
If you're really lucky as an agentic maestro, you get to merge PRs too.
It's like, it's, it's good to have that power.
uh, but there's the, I'll, I'll leave you with one thing.
that's a little bit further out, uh, which is the… when we put
these workflows together, Previously o often they're simulating what
we'd imagine a human to do, like test improvement or test coverage.
They're doing one thing and you can imagine getting someone in to do, improve
your tests and assigning them that job.
But nowadays we can actually get them to use multiple kind of tools and
methodologies all at the same time.
And so if we look at say, performance improvement, for example, uh, y- the-
this thing not only knows how to do the profiling runs and how to write the
benchmarking kind of, tools and how to do garbage collect and optimization.
It can also go read the assembly code, right?
You know, which no- which n- we none of us can do, Read right?
We can't interpret that and it makes good sense of that.
And so, um, you can set up, if it's, if you really needed to squeeze that last
2 or 3 or 5% out of, uh, a performance out of, some say Go-based system, and
this might apply to say, GitHub or something, then you could actually
set the agents also optimizing, adding new optimizations to the go compiler.
Okay?
Like it can take us a private copy of the Go compiler and make a, uh, a
kind of maker, si, you know, make its own bots, compiler patches to that to
actually improve the register allocation.
Uh, and that's a multi-skilling thing where you could never find a single.
Person who could-- had all those skills across the board.
Right.
Ta- uh, Performance optimization- The agent … it's full
of those kind of problems.
Right?
So, you know, the people who actually know how to make their .NET or Java garbage
collectors, the memory hierarchies and use them re- uh, so that everything flows
really, really nicely in those systems.
They're really rare.
The people who can do that, the agents kind of know how to do that kind of work
where you can ki- you can encode code it.
So these kind of multi-skilling flows, are super interesting.
Uh, I think, that, are beyond, they're, they're a bit beyond what we, the frontier
of what we imagine these AI systems doing.
'cause they're kind of like little teams of people or little teams of, of
cooperating kind of agents all taking.
a… It's not just critique or different roles.
It's actually entirely different compatible sort of skills, which kind
of compose together really nicely.
yeah.
So it's one idea.
Bret: All right.
I think the tagline for this, this is, uh, besides that,
is another potential tagline.
'cause it, it sounds like I've got five different options
for the title or the tagline.
It could be, uh, GitHub Actions is the OpenClaw for grownups.
Dude.
I gotta get, I gotta think of Yeah …all the buzzwords I gotta put in there.
Yeah.
Peli: I
gotta have the word agent somewhere.
in there.
That, that's your show.
Yeah.
your show.
Don: Absolutely.
it.
You know,
Bret: it's got cron, it's got A- absolutely, we can, we've got memory.
It's got, yeah.
We can, it can learn over time.
Yeah.
The addition
Don: of the addition of memory to these GitHub agentic workflows, Yeah
… makes huge, huge difference to that.
'cause now they can do research.
The first task they do when they haven't done it before is they can
go research your code base and, and actually work out how to do all that.
All those, uh, depth kind of engineering things, uh, that, and
kind of keep their own private notes on that, and update those notes.
Amazing.
Peli: We have action cache.
I mean we mount memory on action caches on repo on comments in the wiki.
Plenty of places to store.
Uh, and then, you know, you've got these long-running, We have a practical
Auto Loop, which is the auto loop.
Think of the auto researcher ref loop, not just days, weeks, month, because
it's mounted on top of an action run.
Saves its data into a branch, then action restarts on a
branch, and then it keeps going.
So if you think about all your inner loop that are doing route for, let's say a
day now you have the outer loop of that.
Yeah.
That's gonna run for a month.
So you can point it at uh, an entire code base and say, convert
this stuff into something else.
Don: Yeah.
But, uh, Wow OpenClaw for grownups.
Yeah.
No, automation is an incredible thing.
Very empowering.
And, uh, it's just, yeah, a lot you can do with it, but make it safe.
Make a guardrail- And, yeah, we're very happy to help provide
a basis for doing this, uh, at scale in the enterprise and with
Peli: Um, we are very, we are a weird open source project, but we've closed,
we take, uh, bugs as, uh, as specs.
but we've closed so far.
See the number today, 633 community bugs since we shipped.
so if you're using agentic Workflows and you find something, uh,
run our agents on your workflow and tell it to file an issue.
And, uh, yeah, we've been, uh, running as fast as we can to
answer the needs of practitioners.
Most of the bugs we get are from professional CI/CD engineers.
And this is, these are really deep GitHub action feature that we didn't know.
Bret: Yeah.
Right.
Okay.
Yeah, so- All right.
Right.
Like the, the esoteric edge cases of, uh, yes.
Of GitHub Actions when someone knows every little nook and cranny of the Yeah.
Peli: Arc Runner on GHS with something, something.
Uh, we've been looking at that and you know, there's this thing where
the sandbox is closed by design, but we also have the hooks for the
pros, for the people who know to go and plug in the stuff they need.
GitHub apps, custom jobs, custom steps uh, Uhashicorp step to get your secrets.
All this stuff is basically, you know, we, we wanna fully leverage
the platform and we want the problem.
When you do a box that doesn't have the escape hatch for the pros that then people
turn up that, you know, you need to get stuff done, you turn up the security.
So we designed it.
Yeah.
bad
Bret: habits.
Yeah.
Peli: designed it so that you don't have to turn up security to get into
these enterprise scenarios that are, very complex CI/CD with multiple apps,
multiple security, multiple tokens, and th- things become, you know, the sample
we see on the landing page becomes way more, you know, when you start factoring
in real life CI/CD constraints, Then it becomes, but that is because we build on
top of action and we're just an increment.
We inherit all that goodness.
We're in all the ecosystem.
So, I mean, the call for action is try it out.
There's something you don't like.
We've been running as fast and responding to, uh, we only have
a backlog of 30 issues and we've closed 630, so we're, we're on it.
Bret: That's awesome.
Peli: Yeah.
Bret: Well, yeah.
Your agents are on it.
You're on top of the
Peli: agents.
No, the, we don't take PRs.
People run the agent on their side.
There's a full, ana- uh, full investigation on their
run with their secrets.
Then it's anonymized and then the agent files a generic issue.
Nice.
And that's just built in also it's a crazy way to do all software.
Bret: You're right, It's built in, it's built in, a feedback loop.
all right, so this has been awesome.
I'm so glad to have both of you here.
I'm very excited about the future of this.
I've been a heads down GitHub Actions guy for a long time, and I feel
like This is my whole new thing.
And this episode has convince me that I should have spent a lot more time
the last three months on it than I did.
you've convinced me and I'm excited to get into the weeds of this.
Where can people find both of you,
Don: certainly if you, if you wanna contribute ideas, uh, to the design of
GitHub agentic workflows or even just feedback on using it or examples of using
it, there's the, the repo You can make your pitch give us good feedback and
find us, make a pitch for a new feature, a new coding agent or some new thing
you, you think sh- should be supported.
And it's all open source so you can kind of, uh, s- see it all and work it
all out even before it, it gets to us.
and ship on Mondays.
Peli: You ship on Mondays?
Yeah.
You, c- and,
and
Don: uh, for me, you can find me on LinkedIn.
I do a lot of posting on LinkedIn and my blog as well, which,
Peli: yeah, I'm mostly on GitHub and you can find me on LinkedIn, but Nice.
Please file an issue with your idea why you think we should have it.
With the agentic plan, you know, burn some opus tokens on making your claim.
a lot of them were one-shot in BB Kitcode.
Yeah.
Awesome.
And the turnaround, we've got some three-hour turnaround sometimes if you're
at the right moment in time between filing the issue and getting a release.
this is agentic speed.
Bret: Yeah.
Uh, I'm, I've been playing around with GitHub mobile more and more.
And so it, it, the fact that you, that's your workflow, that's your process
is convincing me that I need to lean into more of that because I, I, it's
a, it's a habit that I don't have yet.
Like, I don't have the muscle memory to go, I have an idea.
Let me jump into my GitHub app.
so I need to break that.
for everyone listening, it's github.com/github/gh-aw, Obviously
there's a bunch of websites.
You can go to githubnext.com to see all the exciting stuff
coming out of the research.
Uh, basically just a, a bunch of, it's a whole list of smart people that I
basically wanna invite on, all, of them on the show for some things.
I think I, I just saw the presentation Love it …from AI Engineer
Linden The, n- yeah, the the new, team-based agentic harness mindset.
I am like, that is my next, I am.
So I saw that demo and thought this is exactly what I've been missing
and what my teams probably want, and, a replacement for Slack,
and like all these other things.
So I'm very excited about that one.
and I was like, immediately went to sign up for the beta.
I don't know if she realized that there might be a whole lot of signups, but
when I shared it out, I got a bunch of responses from people going, oh, yes.
You know, not just yes, but hell yes on that.
So I'm excited to see how these two areas merge and I can have the prompt cr uh,
crowdsourced from my humans and like we perfect the ai- output of possibly
how these GitHub action workflows are gonna be created by an agent.
Don: Bret, Thank you for having us on.
It's been a lot of fun
Bret AI July 2025: Thanks for joining us, and I'll see you in the next episode.