Repository Automation Needs Continuous AI

When I talk about agentic repository automation, I am talking about a shift from individual AI productivity to Continuous AI inside the software development lifecycle. Coding agents are not only tools a developer opens in a terminal. They can also become scheduled, auditable, collaborative processes that improve repositories while we sleep.

That was the frame for my talk, "The Agentic Repository Automation Revolution." I work at GitHub Next, where our mandate is broad: explore the future of software development. Over the last year, that future has become inseparable from AI, but I think the industry has focused heavily on one side of the change.

The familiar image is a Copilot: an individual developer with a powerful assistant. That matters. Individual productivity matters. But software development has always had another pole: the team process, the SDLC, the continuous automation around integration, deployment, quality, triage, and collaboration.

My argument is that we should add a third pillar to CI and CD: Continuous AI.

Use This Talk As Agent Context

Tessl has turned my AI Native DevCon talk into a skill your agent can use as context. You can also watch the full recording.

What Is Continuous AI?

Continuous AI is the use of automated or semi-automated AI workflows inside the ongoing software process. It is repetitive, integrated, collaborative, auditable, and triggered by repository events or schedules.

Once you start looking for it, the examples are everywhere. Continuous documentation. Continuous code improvement. Continuous triage. Continuous fault analysis. Continuous accessibility checks. Continuous performance investigation. These are activities we already want to do, but often do not do frequently because they require scarce human time.

The important shift is that AI can unjam some of those workflows. Instead of putting every quality, documentation, and triage concern back onto the individual developer, we can let repository automation handle some of the continuous work.

That changes the feeling of the day. I described waking up to code improvements: pull requests created overnight by safe repository automation. Starting the day with a repository that has already been analyzed, improved, or triaged is a very different experience from staring at a dormant issue backlog.

Why Does This Belong In GitHub Actions?

If CI/CD platforms are the answer to build and deployment automation, they should also become part of the answer to AI automation. Continuous AI needs a home, and making that home the same as your other continuous processes can make a lot of sense. GitHub Actions already gives developers an automation playground: compute, storage, network, events, and a familiar place to run workflows in the context of a repository.

GitHub Agentic Workflows is an implementation of Continuous AI that builds on that idea. It takes an agentic workflow specification and hardens it into a GitHub Action. The point is not simply to wrap a prompt in YAML. The point is to run coding agents people already know, such as Claude Code, Copilot CLI, Gemini CLI, or Codex-style agents, inside a platform with guardrails.

The repository becomes a software factory. A small checked-in file can define a workflow. The hardening step turns that into an action. The workflow can run on a schedule, on an issue event, on a pull request, or through another trigger.

That is powerful because the workflow sits where the work already happens. It can read repository data, inspect issues, produce pull requests, comment on issues, and connect to the existing GitHub data model.

Why Safety Determines Speed?

Automation only scales if it is safe. If someone talks about unattended coding-agent automation without a security architecture, that should immediately raise questions.

Individual productivity has a different safety dynamic. Developers often turn off friction because they want the agent to move faster in their local environment. Automation reverses that. The better the rails, the faster the train can go. Stronger boundaries create more confidence to let workflows run.

The safety model of GitHub Agentic Workflows is narrow by design. The agentic step runs read-only, without direct access to secrets, inside a container, and with a very limited output channel. It might be allowed to create one issue or one pull request, not to perform arbitrary writes everywhere.

Often there is a preload step. Traditional deterministic automation collects logs, CI data, repository state, or other input. The agent receives that package of information in a constrained environment. Then a separate apply stage handles the narrow output, with threat detection and human oversight between stages.

Pull requests remain a point of human control. These workflows do not merge their own PRs. The human review step is part of the architecture.

That is how agentic automation becomes bounded and auditable rather than just another unattended script with a model attached.

What Does Repository Assistance Change?

One workflow I focused on is repository assistance for maintainers. Open source maintainers are under enormous pressure. A repository can have hundreds of open issues, each requiring spare evening time to triage, analyze, or fix. The result is dormancy: valuable projects stay alive in name but do not move.

Repo Assist is an example GitHub Agentic Workflow that wakes up on a cadence, reads its memory, and chooses from a set of maintainer-shaped tasks. It can triage issues, propose improvements, manage labels, comment with analysis, or create pull requests, depending on how the repository owner configures it.

There are different ways to design that kind of automation. One style is an agent factory or agent zoo: many small workflows, each built for a specific kind of repository task. We wrote about examples such as continuous simplification, semantic function refactoring, styling, documentation, and other subjective improvements that are hard to express as ordinary deterministic scripts. Another style, which is closer to my own preference, is a single workflow that has a smorgasbord of maintainer tasks and chooses what to do on each run.

I used it on FSharp.Data, a repository I maintain. Before Repo Assist, the repository had a large issue backlog and very little movement. After turning it on, maintenance became enjoyable again. We worked through the backlog, shipped major releases, and converted years-old issues into forward progress.

The same pattern applied across other repositories, with different maintainers customizing the workflow for their needs. The outputs were not identical because the repositories were not identical. But the common pattern was that dormant work could start flowing again.

That is the deeper idea: repository automation turns backlog into a source of possible motion instead of a pile of guilt.

How Should We Think About The Repository?

I now think of the repository as a human-agent knowledge factory. It is the place where issues, pull requests, CI results, docs, code, humans, and agents come together.

CI/CD already made the repository an automated factory for builds and deployments. Agentic workflows add new machines to that factory line: triage, simplification, refactoring, documentation, accessibility, performance, issue analysis, and quality improvement.

Once you adopt that view, flow matters. Some repositories are blocked. Some are flowing. Some are idle because there is no useful input. Some are gated on human or organizational decisions, which is completely fine. The goal is not to let factories run uncontrolled through the night. The goal is to design the flow so the right work moves at the right quality and cost.

Repository owners therefore become factory or flow designers. They decide which inputs matter, which workflows run, which output channels are allowed, where human gates sit, and what quality checks are required before work progresses.

That includes deciding when a factory should be blocked or idle. If a workflow is waiting on a human decision, that is not a failure. It means the automation has reached a point where organizational judgement matters. The mistake is to clear one jam, celebrate the agent, and then ignore the next handoff where the work gets stuck. Once repositories become factories, flow has to be managed across the whole system.

That is process engineering applied to software development. Other engineering disciplines have spent decades thinking about flow, throughput, bottlenecks, quality gates, and production systems. We need more of that thinking in AI-native software work.

Where Do Quality Signals Come From?

Continuous AI becomes especially powerful when the inputs are high quality. May Walter's work with Hud was a good example I referenced in the talk: production signals can feed weekly agentic analysis, making performance work much more frequent than the occasional performance sprint.

If you have probes into production failures, request problems, CI timing, accessibility gaps, or code health, an agentic workflow can surface that information into the team regularly. The workflow is only as good as the observation system behind it. Better probes create better automation.

In my own work, I described sub-factories for problems such as N+1 database requests and CI improvements. The point is not to manually fix one issue and move on. The point is to step back and add a quality gate or workflow improvement so the whole factory flows better next time.

That is the difference between using an agent as a one-off assistant and using agents as part of repository automation.

What Happens To Work?

A common fear is that AI automation only replaces work already being done. I think that is the wrong model. There is a huge amount of work that is not done today because it is too labour-constrained or too expensive.

Performance sprints do not happen often enough. Accessibility checks are under-resourced. Old issues are not revisited. Documentation gets stale. Repositories become dormant. Quality improvements wait because no one has time.

Continuous AI makes some of that previously unaffordable work possible. That does not remove humans. It changes the role of humans toward designing flows, reviewing outputs, setting gates, and deciding what kinds of automation are worth running.

That was the argument I brought to AI Native DevCon London: the agentic repository automation revolution is not only about making one developer faster. It is about turning repositories into safer, more continuous human-agent software factories.