How we built a software factory to drive Astro’s GitHub issue count to zero

Astro maintainers cut their open GitHub issue count by 85% after replacing manual issue verification with isolated AI subagents that run in GitHub Actions. The work is described in the Cloudflare Blog post “How we built a software factory to drive Astro’s GitHub issue count to zero,” which frames the effort as a software factory aimed at driving the project’s open-issue backlog toward zero rather than treating triage as a one-off cleanup.

The system centers on automated bug reproduction, patch verification, and preview releases. Isolated AI subagents execute inside GitHub Actions so each run is separated from maintainer machines and from other jobs. That isolation is the operational core: reproduction, validation, and preview packaging move through the same CI surface maintainers already use for shipping code, instead of living in ad hoc scripts or private tooling.

For engineers and maintainers, the change attacks the costliest part of open-source support—confirming that a report is real, that a fix works, and that a release candidate is safe to share. Manual verification does not scale with issue volume; routing that work to subagents in Actions turns verification into a repeatable pipeline step. Builders on other projects can treat the same three stages—reproduce, verify patch, publish preview—as a concrete checklist rather than a vague “use AI for triage” slogan.

In the broader tooling market, this sits at the intersection of CI automation and AI agents applied to maintainer workflows. Many teams already run tests and previews in GitHub Actions; Astro’s approach extends that environment so agents own the verification loop that usually blocks issue closure. The 85% reduction is a project-specific outcome, not a universal benchmark, but it shows what is possible when issue handling is built as factory machinery instead of inbox labor.

What to watch next is whether the same factory model holds as issue mix shifts—new classes of bugs, flaky reproductions, or patches that need human judgment. The practical takeaway is narrow: if your backlog is dominated by verification work, invest first in isolated, CI-native reproduction and patch checks, then in preview releases that close the loop with reporters—before you expand agent scope into unrelated maintainer tasks.