From rules to reasoning: the next layer of repo automation

Continuous integration solved the automatable side of software engineering: tests, builds, formatting, static analysis. These are tasks with deterministic outcomes. A test passes or fails, a build completes or doesn't, a linter flags a rule violation. CI is built for binary results.

The harder part of engineering has always been the judgment-dependent work that surrounds code. Reviewing changes, keeping docs in sync with behavior, tracking dependency drift, synthesizing what happened in a given week, judging whether intent still holds after an edit. None of that reduces easily to a flow chart or a regex, and none of it was ever in CI's scope.

GitHub Next calls the new pattern that addresses this Continuous AI: background agents that run against a repository the way CI jobs do, but only for tasks that require reasoning rather than rule-following.

A different class of automation

Continuous AI is not a replacement for CI. Rule-based automation is still right for problems that have unambiguous definitions, and YAML and heuristics remain the appropriate tools for those cases.

Any time something can't be expressed as a rule or a flow chart is a place where AI becomes incredibly helpful.

Idan Gazit, head of GitHub Next

The pattern itself is straightforward:

Continuous AI = natural-language rules + agentic reasoning, executed continuously inside your repository.

A developer writes, in plain language, what should always be true about the codebase — especially expectations that cannot be expressed as a rule. An agent evaluates the repository against that expectation and produces reviewable artifacts: patches, issues, discussions, insights.

Not every judgment-heavy task is equally automatable. Plenty of chores are better left to deterministic methods.

  • A docstring says one thing; the implementation does another.
  • Text passes an accessibility linter but is still confusing for users.
  • A dependency introduces a new flag that changes behavior without a major version bump.
  • A regex compiles inside a loop, hurting performance in subtle ways.
  • A UI's behavior shifts but only reveals itself during interaction.

These failures are not rule violations. They are breaks between intent and behavior. When a rule can't cover a task, natural language can: a sentence expresses an expectation, and an agent reasons over it.

Safe by default

Agentic workflows in this pattern treat safety as a primary design constraint. By default, agents operate with read-only access to the repository. Creating issues, opening pull requests, and modifying content requires explicit permission.

Safe Outputs is the term GitHub Next uses for this deterministic contract. A workflow declares exactly which artifacts an agent may create (a PR, an issue, a comment) and under what constraints. Anything outside of that declaration is forbidden.

The assumption is that agents can fail or misbehave. Outputs are sanitized, permissions are granular, and all agent activity is logged and auditable, so the blast radius of an unpredictable run remains small. This is not autonomous software development; it's automation that lives inside guardrails a developer has defined.

Pull requests are the most common output type for a simple reason: they align with how developers already review change. Agents do not merge code. Developers hold final authority over everything an agent produces.

What works today

Several of these workflows have been exercised in real repositories.

Doc-behavior mismatch detection

A perennial maintenance problem: code drifts from its documentation, and neither a linter nor a type checker can catch it. An agentic workflow can read a docstring, compare it to the implementation, flag mismatches that require semantic understanding, suggest a fix in code or docs, and open a PR. Idan describes this category as one of the most valuable Continuous AI has addressed: "You don't want to worry every time you ship code if the documentation is still right. That wasn't possible to automate before AI."

Recurring project reports

Maintainers answer the same questions repeatedly: what changed, are bugs trending up, which directories are churning. An agentic workflow can pull from multiple sources (issues, commits, PRs, CI results), synthesize that data with reasoning, and produce a summary that highlights bug trends, correlates recent changes with failures, and surfaces risky areas. The synthesis itself is the deliverable.

Translation drift

In localized applications, content changes continuously while translations lag behind, often batching into a mad rush before release. An agent can detect when a source string changes, regenerate the translation set for every supported locale, and open a single PR with all updates. Machine translations aren't necessarily release-ready, but a draft in a PR makes review by human translators substantially easier and shifts the cycle from episodic to continuous.

Dependency drift without a version bump

Libraries change behavior in subtle ways: a new CLI flag, a shifted default. In one demonstration, an agent installed a dependency, inspected its help text, compared the output against the previous day's, identified a new undocumented flag, and filed an issue before maintainers had noticed. The detection requires interpreting semantics, not just diffing two files, so classic tooling would have missed it.

Test coverage burn-down

One long-running experiment shed useful data on cost and cadence. An agent wrote tests that moved a repository's coverage from roughly 5% to near 100% — over 1,400 tests in 45 days — for about $80 in tokens. The agent produced small PRs daily instead of one large batch, which kept the review burden incremental.

Background performance improvements

Linters don't always spot performance traps that depend on intent. A regex that compiles inside a hot function is a textbook case. An agent can recognize the inefficiency, rewrite the code to hoist compilation out of the loop, and open a PR with a clear explanation. Individually small; collectively significant in frequently called paths.

Agents as interaction testers

A demo from GitHub Universe used an agent to play a platformer thousands of times, hunting for UX regressions that unit tests never see. The pattern generalizes to onboarding flows, multi-step forms, retry loops, and input validation, where the agent may suggest a deeper integrity check of user flows.

Starting your first workflow

The gh aw prototype compiles an agentic workflow into a standard GitHub Actions workflow with no separate infrastructure.

1. Write a natural-language rule in a Markdown file. For example:

---
on: daily
permissions: read
safe-outputs:
  create-issue:
    title-prefix: "[news] "
---
Analyze the recent activity in the repository and:
- create an upbeat daily status report about the activity
- proviate an agentic task description to improve the project based on the activity.
Create an issue with the report.

2. Compile it into an Action:

gh aw compile daily-team-status

The result is a standard, visible GitHub Actions workflow YAML.

3. Review the generated YAML. Everything an agent may do is explicit and inspectable.

4. Push to the repository and the workflow runs on the same triggers as any other Action: pushes, pull requests, issues, comments, schedules.

5. Review what the agent creates, as a PR or an issue, on your terms.

For style violations and other rule-shaped problems, CI is and will remain the right tool. For the larger class of chores that requires semantic understanding, background agents add a new, guarded automate, keeping the developer as the final reviewer of generated work.

Emerging patterns in agentic development

A handful of workflow trends are taking shape even at this early stage:

Natural-language rules enter automation. Instead of translating every intent into code, developers write short English rules that express what should happen:

  • "Keep translations current"
  • "Flag performance regressions"
  • "Warn on auth patterns that look unsafe"

Repositories host small agent fleets. The direction is not one general-purpose agent but many narrow ones, each owning a single chore, check, or rule of thumb.

Chores go continuous. Tests, docs, localization, and cleanup shift from "when someone remembers" to "every day." This mirrors the original CI movement: developers are not replaced, but the timing of work changes.

Debuggability wins over complexity. Teams will gravitate toward agentic patterns that are transparent, auditable, and diff-based rather than opaque systems that act without visibility.

What this means for developers

As Idan puts it, "Custom agents for offline tasks, that's what Continuous AI is. Anything you couldn't outsource before, you now can." More precisely, many judgment-heavy chores that previously required manual attention can now run continuously.

The mental shift resembles moving from owning files to streaming music. "You already had all the music," Idan says, "but suddenly the player is helping you discover more."

Start small

Continuous AI is not all-or-nothing, and no pipeline overhaul is required. A sensible entry point is one small workflow: translating strings, adding missing tests, checking for docstring drift, detecting dependency changes, or flagging subtle performance issues. Each is something agents can meaningfully assist with today.

The practical move is to identify the recurring, judgment-heavy tasks that quietly drain attention and make those tasks continuous instead of episodic. If CI automated rule-based work over the past decade, Continuous AI may extend the same treatment to select categories of judgment-based work—when applied deliberately and safely.

Explore Continuous AI Actions and frameworks >