GitHub Uses Copilot to Build GitHub: What We Learned

TL;DR

• GitHub assigns Copilot actual issues in their core repo — it opens PRs, fixes bugs, and ships features
• Copilot handles tedious work: removing 161 typos across 100 files, cleaning up feature flags, and fixing a 15-minute git push bottleneck
• It's building new API endpoints, performing security audits, and doing codebase-wide architectural analysis
• The real value isn't auto-merging — it's getting a concrete first-pass implementation instead of starting from zero

The Big Picture

Dogfooding is one thing. What GitHub is doing with Copilot is something else entirely.

Inside their core repository — the one that builds github.com — @Copilot isn't just autocompleting code in an editor. It gets assigned issues by human engineers. It opens pull requests. It does the work.

GitHub analyzed a month of PRs created by Copilot in their main repo. The results show a shift in how AI fits into real development workflows. This isn't about replacing engineers. It's about offloading the tedious 80% so humans can focus on the critical 20% that actually requires judgment, architecture, and domain expertise.

The pattern is simple: assign Copilot an issue, review its PR like any other contributor, then decide whether to merge, iterate, or take a different approach. The value is in not starting from zero.

How It Works

GitHub treats Copilot as a contributor. Engineers assign it issues directly using @Copilot. It analyzes the task, generates a solution, and opens a pull request. From there, it follows the same review process as any human engineer.

The work Copilot handles falls into several categories, ranging from trivial to surprisingly complex.

Simple Work That Adds Up

UI tweaks. Copy changes. Realigning misaligned icons. Updating placeholder text in filter bars. These are the quick fixes that cause constant context-switching for human engineers.

One standout example: Copilot was assigned to fix 161 typos in comments and documentation strings across 100 different files. Simple work. But no human wants to spend an afternoon on it.

Critical Cleanup and Maintenance

This is where Copilot shines. A significant portion of its PRs focus on code maintenance and large-scale refactors.

Removing feature flags is a huge one. Copilot constantly cleans up deprecated flags, removing conditional logic, stale code, and old tests across the entire codebase. It's tedious work that requires precision but not creativity.

Large-scale refactoring is another area. When GitHub needs to rename a class used across the application, Copilot takes it on. It's authored massive, repository-wide PRs to rename core internal classes — the kind of task that would take a human developer days of tedious find-and-replace work.

Performance optimization is also in scope. Copilot finds and fixes common anti-patterns, replacing inefficient code with optimized alternatives in high-traffic areas.

Fixing Bugs and Flaky Tests

Copilot patches production issues and improves CI/CD stability. It's resolved tricky NoMethodError issues in core logic and fixed complex error masking problems in caching infrastructure.

One of its most impactful contributions: fixing a severe performance issue where git push was taking 15 minutes for engineers in Codespaces. That's not a trivial bug fix. That's a real productivity bottleneck.

Flaky tests are another pain point. Copilot gets regularly assigned to investigate and fix them. Anyone who's dealt with a test breaking a build knows how much time this saves.

Building New Features

This is where it gets interesting. Copilot isn't just maintaining old code. It's actively building new functionality.

One PR added a new REST API endpoint to list repository security advisory comments. Human engineers spec out the work in an issue, assign it to Copilot, and it gets to work.

It's also building internal tools. GitHub's internal intranet, training sites, and onboarding systems have all been maintained significantly by Copilot. These aren't customer-facing features, but they're critical for internal productivity.

Migrations and Security

GitHub is assigning Copilot high-stakes, complex projects. Security gating is one example. Copilot has been tasked with adding security gates to prevent internal integrations from performing sensitive actions like modifying releases or release assets.

Database migrations are another. Copilot handles schema migrations, including critical, high-precision tasks like migrating column types to support new standards.

Documentation creation is also in scope. Copilot keeps documentation in sync with fast-moving code. It's authored numerous PRs to add comments to rate-limiting code, ensuring developers remember to keep it synchronized with another service.

Codebase-Wide Audits and Analysis

In its most advanced tasks, Copilot acts as a researcher. GitHub assigns it an ambiguous task, and it analyzes the codebase and reports back with findings in a PR.

In one case, it was tasked with auditing all Codespaces feature flags. It returned a comprehensive report categorizing all the flags and their references throughout the code.

In another, it performed a comprehensive analysis of authorization queries to identify opportunities for performance and safety improvements. This moves Copilot's role from code generation to systems-level architectural analysis. Developers can jump straight to solving a complex problem rather than spending days just identifying it.

What This Changes For Developers

The pattern GitHub discovered is more important than any individual PR Copilot created.

Copilot's merged PR rate is lower than human contributors. That's expected. And useful.

Here's how it works: You assign Copilot an issue. It opens a PR with a first-pass solution. You review it like any other PR. Then you choose to merge it, iterate on the branch, or close it and take a different approach.

The value isn't in blindly merging. It's in not starting from zero. You get a concrete implementation to critique right away. All the boilerplate and basic scaffolding is already handled.

This shifts focus away from writing all the code. Instead, you jump straight to the most critical parts of engineering: solving the core problem, refining Copilot's suggestions, working in areas of the codebase not fit for AI, and owning the architecture, security, and user experience.

It's not about automating jobs. It's about letting Copilot handle the tedious 80% so you can dedicate expertise to the critical 20% that truly matters.

This approach complements other workflow improvements GitHub has been shipping. If you're already using Copilot for code review, treating it as a contributor for entire issues is the logical next step.

Try It Yourself

GitHub's approach is replicable. You don't need special access or custom tooling. The core workflow is available in GitHub Copilot today.

Start small. Assign Copilot a well-defined issue: removing a deprecated feature flag, fixing a flaky test, or updating documentation. Tag it with @Copilot in the issue description and let it open a PR.

Review the PR critically. Don't expect perfection. Expect a starting point that's 70-80% there. Iterate on the branch if needed. Merge if it's solid. Close it if it's off-base.

The key is treating Copilot like a junior contributor who needs clear specs and thorough review. The clearer your issue description, the better the first-pass solution.

Over time, you'll develop a sense for which tasks are Copilot-appropriate. Tedious refactors, large-scale renames, documentation updates, and simple bug fixes are all good candidates. Complex architectural decisions, security-critical logic, and user-facing design choices still need human judgment.

The Bottom Line

Use this if you're drowning in maintenance work, feature flag cleanup, or flaky tests. Skip it if your bottleneck is architectural decisions or unclear requirements — Copilot won't solve those.

The real opportunity here isn't speed. It's focus. GitHub's engineers aren't writing less code because Copilot is faster. They're writing less tedious code because Copilot handles the grunt work. That frees them to spend more time on the problems that actually require human expertise.

The real risk is treating Copilot PRs as auto-merge candidates. They're not. They're first drafts. Good ones, often. But still drafts. The review process is non-negotiable.

If you're already using Copilot in your editor, this is the next evolution. Stop thinking of it as autocomplete. Start thinking of it as a contributor you can assign issues to. The workflow shift is bigger than the technology.

Source: GitHub Blog