GitHub Universe 2026 舊金山現場回顧：兩場主題演講聚焦智能體工作流與開源社羣

I'll write another post in the coming days covering the announcements. This one focuses on GitHub Universe as an event and on the two keynotes.

Table of contents

• My updates from San Francisco
• The numbers behind the changes
• The Copilot app
• Projects across repositories
• Session continuity between tools
• Copilot Automations
• Review and merge
• Smaller platform updates
• Security
• Enterprise access and budgets
• Rebuilding Git
• Octoverse: how developers use the tools
• Closing keynote: developer joy and hardware
• Protecting open-source maintainers
• DevOps as a prerequisite for agents
• Human judgment and speed
• Chopin and collaborative planning
• Science and the next generation
• The closing message
• What I’m taking back

I attended GitHub Universe 2026 in person in San Francisco. Between the opening keynote that laid out the architectural overhaul of GitHub and the closing keynote dedicated to the open-source community, maintainers, and developer joy, there was far too much substance to absorb from memory alone. I watched both the Day 1 opening keynote and the Day 2 closing keynote again to take detailed notes.

The second watch helped me connect the announcements across both days. In the Copilot app, Projects coordinates work across repositories while Fusion handles model selection. Automations respond to production signals, code review checks the result, and GitHub is rebuilding the Git infrastructure underneath all of it. But the closing keynote provided the essential counterweight: how open-source maintainers protect their repositories from AI pull-request spam, why DevOps maturity is the real prerequisite for coding agents, and how collaborative multiplayer planning can replace isolated single-player prompts.

My takeaway is that GitHub wants to connect the whole delivery workflow, including the parts that happen before an agent writes code and long after it opens a pull request. That is the angle I care about as a technical lead: how a feature reaches production, who decides whether it is ready, how we protect maintainers, and what the platform needs to support that work.

Two updates I shared from San Francisco

The trip also gave me a chance to share two things I had been working on myself. Alongside the keynote announcements, these were my own small Copilot updates from San Francisco.

The first was Copilot Insights 5.5.0, my VS Code extension. I added a Model Costs explorer and a token-cost estimator so developers can compare model rates and explore how different choices affect estimated AI credit usage. The estimates stay separate from actual account consumption. Hearing so much about model choice at Universe made that question feel especially relevant: what does a particular choice mean for the work in front of me and the credits it uses?

Read my original Copilot Insights update on LinkedIn.

I also shared that I had earned the Microsoft Pro Badge: GitHub Copilot - Proficient. I am not usually a big badge-sharing person, but I was happy about this one. What I like is its focus on deliberate, practical Copilot use: refactoring that preserves behavior, tests that check something useful, and less time spent on repetitive logic. That connects with what I took from both keynotes: the result still needs our attention and judgment.

Read my original badge update on LinkedIn.

The numbers explain why GitHub is changing the stack

Jay Parikh opened with the scale of activity on GitHub. The platform now has more than 225 million developers, and a new developer joined every second over the past year, for the second consecutive year.

The 2026 Octoverse report puts the rest of that activity into perspective:

The reporting window matters: the Octoverse year runs from October 1, 2025, through September 30, 2026. These are not totals for the full 2026 calendar year, and Actions jobs are different from Actions minutes.

Activity climbed from January and accelerated sharply around June. GitHub connects that timing with better models, stronger agent harnesses, persistent sessions that can continue across days, and more work running in cloud environments.

One comparison deserves attention: among repositories created this year, those with an agent configuration file averaged eight times as many commits as those without one. That measures activity, with some limits: commit counts do not measure useful software, and a repository without an agent file may still use AI.

Jay also called out three projects that give those numbers some purpose: Ersilia's open-source AI tools for drug discovery, OpenQuake's earthquake hazard and risk assessment software, and Matt Pocock's AI Skills for sharing instructions across coding agents. Those examples range from scientific work to improving the tools developers use every day.

From an issue to working software in the Copilot app

Jay described a delivery process where a colleague's request, a code change, or a production signal can start work at any point. Developers set direction and make decisions while agents take on implementation and verification. He organized that vision around velocity, intelligence, and quality: completing work efficiently, carrying context and learning forward, and catching defects before shipping.

Cassidy Williams made it concrete with the GitHub Copilot app and a coffee-shop application.

Her task was a Coffee Passport feature: customers visit different locations, collect stamps, and receive a reward when they complete the passport. Before implementing it, the team needed answers about what counted as a visit and what happened on repeat visits.

That is a useful place to start a demo. An agent cannot implement the right behavior if the team has not agreed on the rules.

The app brings agent sessions, issues, external tools, and project work into one desktop surface. Its canvases include a browser, a terminal, and custom views. Cassidy showed the agent interacting with the running application in a browser canvas to test the passport feature, then opened the changes in VS Code to inspect the code.

The useful part for me is that implementation and inspection remain connected. A working preview helps answer whether the feature behaves correctly; the diff still needs attention.

Connectors bring the missing context into the session

The answers to Cassidy's requirements questions came through connected services. Copilot Connectors use GitHub-managed, verified MCP connections so you can authenticate to a supported service once and use its tools across supported Copilot surfaces.

The keynote and announcement materials included services such as Slack, Work IQ, Sentry, Vercel, Netlify, and Cloudflare. GitHub also emphasized the wider ecosystem, including Datadog and Figma. The point is access to requirements, discussions, deployment information, and production signals where the agent is doing the work.

Connectors are currently in public preview. They work across supported app, CLI, VS Code, mobile, and cloud surfaces, but are not yet supported in sessions running on GitHub Actions, such as assigning an issue to Copilot. That distinction matters when adding them to an existing workflow.

Copilot Fusion chooses how to use the models

Cassidy's next question was which model to use. Copilot Fusion moves that decision into a router and orchestrator that evaluates the task and chooses an execution pattern.

The three patterns explained in the keynote were:

• Single: one model handles the task.
• Cascade: a model drafts an answer, a judge evaluates it, and the system can escalate to a stronger model.
• Critique: other models review a draft, and their feedback informs a revision.

You choose an effort level: Standard, High, or Max. Standard targets everyday work, High adds orchestration for more substantial tasks, and Max prioritizes deeper reasoning. That is more useful to me than manually switching models for every step of a feature.

GitHub reported that Fusion Max scored 60 on the Artificial Analysis Coding Agent Index, within two points of Opus 5.5 Max, at half the cost and 40% less time per task. Those are benchmark results, so I would evaluate the same trade-off on my own repositories before assuming equivalent savings.

The Fusion documentation also clarifies that it respects plan and administrator model policies, bills for the models it uses, and does not itself launch subagents. Projects orchestration and model orchestration are separate capabilities. Users on paid Copilot plans receive a 30% discount on Fusion model costs through November 30, 2026.

Copilot Dreaming addresses instructions that have gone stale

One detail I wanted to keep from the second watch was Copilot Dreaming.

Cassidy explained that the coffee application had moved from Java to SvelteKit, while some instructions still described the old implementation. Dreaming proposed a pull request to update that guidance. She reviewed the diff as she would any other change, and also showed the memories Copilot had learned about her preferences and the team's practices. The Dreaming demo starts around 12:40.

I like this example because custom instructions require maintenance. An instruction file that describes last month's architecture can make an agent consistently do the wrong thing. Proposing an update through a reviewable change is a practical way to handle that maintenance.

Dreaming is in public preview, with plan and model restrictions: it requires GPT-6.1 Sol access, excludes Copilot Pro and data-residency environments, and consumes AI credits when it runs. Instruction-file changes arrive as pull requests; learned memories can update automatically.

Projects coordinates a feature across repositories

Burke Holland continued with Copilot Projects, using the Fourth Coffee repositories to build a feature that lets a customer reorder their usual drink with one tap.

He added the repositories as context, then supplied design mockups, a Slack discussion, and a Teams conversation with legal and compliance. The latter mattered because this was a personalization feature. He could keep adding context while work was underway, without waiting for an individual agent loop to finish.

Projects provides an orchestrator that coordinates agents across one or more repositories while keeping the goal and context together. Sessions can run locally or in the cloud, and resulting pull requests appear in the project overview. The developer can follow progress and redirect the work.

The demo also went beyond code. Burke showed short marketing videos generated with a skill, stored in the library, and described an automation to create them as new features ship. That connects implementation with another piece of delivery work that someone normally has to organize separately.

Projects was announced as available that day, in public preview. For a team with several repositories, the shared view of context, sessions, and resulting pull requests gives the feature a home beyond any individual agent's work.

The same session can follow you between tools

Damian Brady started his demo on a phone. The order-ahead feature stopped accepting orders before a cafe closed, as intended, but failed to explain that to customers.

He started a Copilot session to fix it in a cloud sandbox, then picked up the same session in VS Code. Session continuity also spans the Copilot app, CLI, and web, so changing surfaces does not require restarting the task.

Jay explained that this uses the same Copilot harness, now rolled out across Microsoft, and announced that developers could use the harness to build agents through Microsoft Foundry as well.

Damian's observation about being short on attention and time captured the practical constraint. Once the agent has a clear direction, the developer should be able to focus elsewhere and return when a decision is needed.

Automations connect production signals to repeatable work

The next demo began with a production error. The coffee site's information button returned a 500, and Damian opened the Sentry details in a custom canvas.

He could create an issue or ask Copilot to investigate. Copilot Automations turns that response into reusable work that can run manually, through an API, on a schedule, or in response to an event. Cloud execution means the workflow can continue after the laptop closes.

The controls were a substantial part of the demonstration: choose the available tools, allow an automation to create pull requests without allowing it to merge them, and set an AI credit limit. Shared automations let the team reuse that setup.

Damian also showed a group of specialist automations in a subscriptions repository. One watched for signals and created issues; others triaged them, reproduced the problem with screenshots, implemented a fix, and verified it against the original request.

That separation gives each automation a specific job and an output the next one can use. The announcements also described automations learning from outcomes and proposing improvements for review. The automation documentation confirms support for self-improving groups and configurable tools and spending limits. Changes to those workflows deserve the same review as changes to the application.

For a pilot, I would also account for the current cloud-automation requirements: an eligible paid plan, a private or internal repository, and both AI credit and GitHub Actions usage.

Review and merge have to keep up

GitHub reported that Copilot Code Review has surfaced 200 million findings since its launch. At Universe, it introduced Code Review Max, alongside Lite and Balanced, for changes that need deeper inspection.

According to GitHub, Max achieved the highest F1 score on ReviewBench for high-severity issues. My interest is in the defects a quick review can miss, such as interactions across changed files or a subtle security problem. Testing Max against a team's own review history would help establish where that deeper inspection pays off.

Damian showed Copilot reviewing a coffee-service pull request before the human review. Code Review is also available to organization members without a Copilot subscription when the organization enables paid usage; that route is currently on GitHub.com. Reviews can consume AI credits and GitHub Actions minutes. GitHub's documentation covers the review levels and access requirements.

Stacked pull requests make related changes easier to inspect

The Coffee Passport work was split into a stack: data changes, a service endpoint, and the UI that depended on them. Each part could be reviewed separately, and the stack could be merged together or in contiguous groups, starting from the bottom.

This gives reviewers smaller diffs while keeping the dependency between changes visible. Native support matters when agents can produce a large feature faster than a person can comfortably review it. The stacked pull request docs cover the workflow and the gh stack extension. Octoverse reports that the preview launched on July 30 and had been used by more than 264,000 developers by September. Stacked PRs reached general availability on October 6, before Universe.

Agent Merge helps a pull request reach completion

Damian returned to the fix he had started on his phone and enabled Agent Merge. In the demo, it handled follow-up work such as review feedback, CI failures, and conflicts in the background, with merging enabled once the requirements were met. The Agent Merge demo starts around 28:40.

That closes a gap I see in agent workflows: opening a pull request is only one stage of completing the task. Branches keep changing, checks fail, and reviewers ask for adjustments. Agent Merge takes on those follow-up changes, with repository checks and merge permissions defining when the work can land.

The current GitHub.com watch-and-fix workflow documents failed Actions checks and merge conflicts, excludes fork and stacked pull requests, and treats auto-merge as a separate setting. I would check those boundaries before expecting the whole stack to run unattended.

The smaller platform updates belong in this recap too

The Universe announcement page includes several changes that fit into the same workflow:

• GitHub CLI attachments: repeatable --attach flags add local images and videos inline to issues, pull requests, and comments. A reproduction video or architecture diagram can travel with work created from the terminal.
• Issue Artifacts: plans, research, links, and other artifacts stay attached to the issue, making the reasoning behind the implementation easier to find.
• Repository pull request views: the updated view helps you scan open work, understand its status, and find what needs attention next.

For example, the CLI attachment workflow supports attaching more than one file:

gh pr create \
  --title "Explain when order-ahead is unavailable" \
  --body "Adds a customer-facing explanation before the cafe closes." \
  --attach ./order-ahead-demo.mp4 \
  --attach ./order-flow.png

With the files saved locally, an agent-generated screenshot or recording can become part of the review evidence, especially when it shows whether a fix satisfies the original request.

Security needs to be part of the agent workflow

Damian demonstrated code scanning findings with the location, vulnerability type, and remediation context available to Agentic Autofix. Assigning a finding produced a pull request with a proposed fix.

The broader security announcements cover different stages of the workflow, from local changes to dependency installation and pushing code.

A Security canvas for investigating findings

The Copilot app's security extension brings code scanning alerts into a Security canvas, where you can ask for an explanation, request a fix, and inspect the resulting changes. It can also review local changes before a pull request is opened.

The extension documentation makes two useful distinctions: it is in public preview, and it displays code scanning alerts rather than Dependabot or secret scanning alerts. A requested fix changes the local working copy; the usual review and scanning process still determines whether the alert is resolved.

AI Scan extends coverage beyond CodeQL

GitHub presented whole-repository scanning and assigning a backlog of findings to Copilot, as well as AI Scan coverage for pull requests in languages and frameworks CodeQL does not cover.

For the pull request feature, the docs list examples including PHP, Shell/Bash, Terraform, Dockerfiles, JSP, and Blazor. The findings are advisory and currently cannot enforce a merge requirement through a ruleset. That is a material detail for a team planning its security gates.

Push protection catches unstructured secrets

Damian pushed a local commit containing a secret and showed AI detection blocking it before it reached the repository. This extends protection to unstructured secrets such as passwords that do not match a known provider pattern.

AI-detected secret push protection is in public preview. Both push protection and AI secret detection must be enabled. GitHub documents the security licensing requirements and additional AI credit consumption, which belong in the rollout plan.

Package firewall and reachability analysis address dependency risk

Package firewall blocks malicious or risky npm packages before agents, developer tools, or CI runners install them. The public preview evaluates downloads against policies such as package age and malware advisories.

Reachability analysis helps prioritize existing Dependabot alerts by looking for call paths from application code to vulnerable dependency functions. It currently supports JavaScript and TypeScript repositories and is also in public preview.

The static analysis gives teams a call path to investigate and helps order the remediation queue. Reachability alone establishes neither runtime execution nor exploitability, so severity and other evidence still inform the priority.

Enterprise access changes, but usage still needs a budget

GitHub Enterprise customers can now access Copilot features without purchasing a separate Copilot subscription and pay for the AI credits they use. The announcement includes the app, code review, automations, and the wider Copilot feature set.

The rollout details in the announcement matter: the new route is available through GitHub Sales, self-service is coming later, and existing Copilot Business and Copilot Enterprise customers can keep their plans or move when ready.

Simpler access should make adoption easier, while tool permissions and AI credit budgets give enterprise teams a way to control how that usage grows.

Rebuilding Git was one of the most substantial announcements

Jay acknowledged that GitHub had struggled with performance and reliability at points during the year. Growth explained some of the pressure; he explicitly said it was not an excuse.

GitHub reported adding four million CPU cores, 160 PB of high-speed storage, and 50 Tb/s of network capacity so far this year. It also expects to complete the broader migration to a multi-region Azure deployment in early 2027.

April Leonard then explained why adding capacity alone would not solve the Git bottlenecks. Every agent session can create branches, read history, and push changes. In September alone, developers and agents produced more than seven billion commits.

Nearly every repository had already moved to Azure, but for roughly 100 of the busiest repositories, even 25 milliseconds between data centers mattered. An initial improvement changed write coordination from locking a whole repository to locking the branch being updated. That delivered three to four times more write throughput for agents working on different branches.

The next architecture follows three principles: simplify the primitives, separate storage from compute, and minimize coordination. Azure Blob Storage holds the durable source of truth. Ephemeral serving nodes cache data and can scale with demand. A specialized replicated log service handles the small reference transaction that remains on the critical path.

The test results were substantial:

• With 5,000 agents targeting one repository, the system sustained 7,200 writes per second, which GitHub described as 180 times current throughput.
• GitHub replayed 24 hours of traffic from its busiest open-source repository in one minute against the new architecture.
• The read load-testing harness reached its own limit before the new architecture did.

Those are reported test results, rather than a throughput guarantee for every repository. The keynote included an early-user segment with Peter Steinberger of OpenClaw, and GitHub expects everyone to move to the new architecture by early 2027.

The infrastructure work also includes an AI gateway processing trillions of tokens, prompt caching and harness improvements, more Actions capacity and control-plane hardening, additional network edge sites, four times the backhaul between legacy data centers and Azure, and TLS optimizations. The keynote recording covers the infrastructure section, alongside GitHub's written announcement.

This is the dependency behind the earlier demos. Coordinating agents becomes much less useful if they spend their time waiting on Git, CI, or platform availability.

Octoverse shows how developers are using the tools

The rest of the Octoverse report adds context that I did not want to lose in a keynote-only recap.

Agents are increasingly producing the first draft

By September, more than 40% of pull requests started with a detectable agent's first draft, up from 17% in March. That amounted to around 110 million in September alone.

About 87% of agent-started pull requests changed multiple files, compared with 79% of those without detected agent involvement. The share of agent-involved PRs merged within two weeks rose from 83% in February to 90% in September; the comparison group remained around 86%.

Among Copilot's monthly active users, 55% used agentic features, up from 35% a year earlier. Cloud agent usage grew 230% year over year, compared with 85% for agent chat. These figures describe observed workflows, and undetected agent use can still exist in the comparison group.

Review and security activity grew alongside implementation: AI-assisted review and GitHub Advanced Security usage each increased by more than 90%, while push protection ran 5.8 billion scans, nearly four times the previous year's pace.

Model choice is already plural

In September, 61% of Copilot users who explicitly selected models used more than one, up from 50% four months earlier. Developers on paid plans used 47 distinct models, compared with 29 in May, and no model accounted for more than 25% of qualifying requests.

The report groups examples by their intended role:

Of every 100 developer-selected requests, 38 went to general-purpose models, 37 to reasoning and planning models, and 25 to lightweight models. This analysis excludes automatic selection and several other kinds of traffic; it describes usage rather than model quality.

Separately, 63% of paying Copilot developers used automatic model selection at least once in September. Project HydraFusion, the research preview behind Fusion, routed almost 60,000 sessions. That helps explain why GitHub is investing in choosing models on the developer's behalf while preserving explicit selection.

Growth reaches more countries and industries

The ten largest developer populations in September were:

The United States and India each added more than ten million developers, and Brazil added 3.28 million. Every country included in last year's projections had already closed at least 20% of the distance to its 2030 projection; the US had closed 38.6%, and India 28.3%.

For pushes to public repositories, the top ten were the United States, India, China, Brazil, Germany, the United Kingdom, South Korea, France, Japan, and Canada. That is a different ranking from total developer population.

The new industry analysis uses NAICS classifications of public repositories. Mining, construction, healthcare, and agriculture have grown substantially since 2022. More than 40% of repositories in administrative services, mining, healthcare, and agriculture mentioned AI, but detectable agent-opened pull requests were below 3%. Construction had about 25% mentioning AI and around 9% with agent-opened PRs.

The distinction between AI mentions and agent-opened PRs keeps two different kinds of adoption visible. The report's wider examples include disaster alerts in Nepal, spacecraft software, research tools, and industrial energy analysis. There is useful software here well beyond developer tooling.

Language choices may also reflect agent defaults

TypeScript remained first by contributors, followed by Python and JavaScript. Between September 2025 and September 2026, they added 3.62 million, 3.23 million, and 1.82 million monthly contributors respectively. Rust doubled its contributor base, the fastest percentage growth among the leading languages.

GitHub's forecast puts TypeScript and Python near 13 million monthly contributors each by September 2027.

The report also raises the possibility that agent defaults influence language choice. Among new repositories, TypeScript was the primary language in 35% of those with an observed agent signal, compared with 24% without one. For me, that reinforces the value of specifying language and architectural constraints when starting a project with agents.

Open source supplies both the foundations and the tools

Octoverse separates community and independent projects from single-vendor or product-led repositories. The distinction is strategic control, not whether the project receives community contributions.

These are the complete fastest-growing lists by increase in contributing accounts:

The most-engaged ranking combines stars, forks, and distinct pull request and issue creators:

Inference engines, runtimes, and community platforms sit alongside the agents and editors developers use directly. Both depend on people maintaining code that other projects build on.

The closing keynote: Developer joy, hackable hardware, and the human side of AI

While Day 1 focused on platform architecture, enterprise governance, and Git throughput, the final keynote of Universe 2026 brought the conversation back to where GitHub began: open source, community maintainers, and the joy of building software.

Martin Woodward opened the final session by acknowledging the emotional reality of 2026: with new frontier models shipping every few weeks and telemetry breaking records everywhere, developers are feeling the pace. His answer to feeling constantly out of date is simple: learn by doing.

The hackable badge and culture when no one is looking

The centerpiece of that hands-on ethos was the physical conference badge every attendee wore in San Francisco. Built in partnership with Arm, the 2026 badge is an astonishing piece of hardware: a dual-core Raspberry Pi RP2350 Cortex processor packed with an accelerometer, environmental sensors, Bluetooth radio, and a color screen running MicroPython.

Martin shared an unscripted story behind the badge that stuck with me. During the 2025 conference, a typhoon struck a component supplier and global supply shortages delayed screen deliveries until the night before the event. Rather than canceling the badge giveaway, GitHub engineers, managers, and community members spent the entire night in the San Francisco office hand-assembling boards and soldering screens so attendees could pick them up at 8:00 AM.

As Martin put it: "Culture is what happens when no one is looking." For all the enterprise features and cloud scale discussed this week, that community-first startup spirit is what still makes GitHub distinctive.

From web simulation to MicroPython in the Copilot app

To make sure attendees without hardware or developers watching the livestream could participate, GitHub published a complete web simulator for the badge. It was built by a summer intern, Charlie Nicholson, who used the simulator framework and around $95 in Copilot credits to create an emulator capable of running games like Flappy Mona directly in the browser.

Martin then took the badge project into the GitHub Copilot app. In a live canvas connected to the badge repository, he showed a Breakout game that he said he had created with a single prompt.

The technical detail that matters here is not the prompt; it is the harness. Martin explained that the Copilot app canvas could access the MicroPython debugging environment, letting the agent inspect execution and debug the game. That gave it a verification loop beyond simply generating code.

As Martin noted, that tight verification loop is the difference between an agent producing broken syntax and an agent delivering working software.

Edge ML on stage: Training a decision tree in the browser

Martin followed the Breakout demo with an edge machine learning application: building a pedometer for the badge without prior ML expertise.

He streamed raw accelerometer telemetry from the badge over Bluetooth into a browser canvas. On stage, he gathered live training samples across distinct motion states: standing still, walking normally, and swinging his arms with "big keynote energy" (or as he joked, "the walk of someone who just merged to main on a Friday").

Using a browser-based training loop, he trained a decision-tree classifier on the accelerometer dataset and deployed the resulting model directly back to the badge firmware over Bluetooth. The badge successfully distinguished actual walking from arbitrary gestures in real time.

It was a playful demo, but it demonstrated a practical point: agent tooling can give a developer a way into unfamiliar domains—like embedded edge ML—through experimentation. The learning still comes from collecting data, testing the result, and understanding where it fails.

Open source under AI pressure: Maintainer fatigue, pull request slop, and new defensive controls

The keynote then transitioned into the hardest conversation happening across the industry: what happens to open-source maintainers when coding agents make creating pull requests essentially free?

Octoverse reported that over 40% of all pull requests on GitHub now begin with an agent's first draft, up from 17% in March. While that speed accelerates prototyping, Martin acknowledged the painful downside: "Not all those PRs are diamonds. Just because it's easier to create than ever doesn't mean what you have is ready to commit. Some are just bad ideas. Some are barely ideas at all. You know, slop."

Traditionally, open source functioned because coding had inherent friction. Contributors had to spend time understanding the codebase, learning the project's culture, reading documentation, and following contribution guidelines before submitting code. That friction acted as an organic quality filter.

Coding agents have largely eliminated that barrier. Well-meaning contributors now use agents to generate pull requests and shallow security reports across dozens of repositories without reading the project guidelines or verifying the fix. For open-source maintainers—most of whom volunteer their free time after work—wading through low-effort AI contributions has become an exhausting, unpaid burden.

Maintainer guardrails: WIP limits, contributor exemptions, and PR access

To protect maintainers, Martin highlighted repository controls designed to restore balance. Some predate Universe; the latest update adds more flexibility over who is subject to limits:

1. Work-in-progress (WIP) limits per repository: Maintainers can cap open pull requests from users without write access, encouraging contributors to finish an existing change before opening another.
2. Exemptions for established contributors: The October 28 update allows exemptions based on account age or prior merged pull requests. Meeting either configured condition can exempt a contributor. This is separate from temporary interaction limits.
3. Control over pull request access: Since February, maintainers can restrict PRs to collaborators or disable them. Disabling PRs hides the PR tab, including existing pull requests; re-enabling restores access. It is more than a pause on new submissions.

Martin framed this policy change around a clear boundary:

"Open source is the freedom to inspect, to remix, and to share without asking for permission. But it's not the freedom to impose your will on others."

As a technical lead who manages both internal shared code and public open-source libraries, I see these controls as long overdue. If platforms do not give maintainers tools to protect their time, maintainers will simply walk away.

Why DevOps is the real prerequisite for AI agents

While unguided AI generation strains maintainers, the keynote showed that maintainers with mature operational pipelines are using agents effectively.

Martin recognized Franck Nijhof from Home Assistant in the audience and reported that the project had merged more than 5,000 pull requests. He also described GitHub's support for Copilot agents across the Cloud Native Computing Foundation (CNCF) ecosystem.

Martin recounted a telling example from Jorge Castro around OpenPrinting. The OpenPrinting maintainers possess deep, specialized knowledge of printer drivers and protocols, but their primary pain point was infrastructure: managing container refreshes, keeping dependencies current, and maintaining CI/CD pipelines across multiple architectures. He described the Hive automation framework taking on operational maintenance across four OpenPrinting repositories, freeing the domain experts to focus on the driver code they enjoy.

That example reinforces a foundational truth: teams that do DevOps well are the best equipped to take advantage of AI.

The automated checks, strict linting, integration suites, and branch protections you build to let human developers ship quickly are the exact same safeguards an autonomous agent needs. An agent running in a repository without automated testing or clean CI is just an engine for accumulating unverified changes.

Actions continues to be the backbone of that verification. According to the published Octoverse report, Actions executed 1,440 jobs per second (about 124 million daily) over the reporting year—more than three times the previous year's volume.

The limit of pure speed: "Why they call it work"

Martin addressed the temptation to treat raw coding speed as the sole metric of success:

His point was that shipping faster only helps if we are building the right things. Humans still need to understand the problem, direct the work, and reflect on whether the result makes things better or worse. Defining what good looks like remains part of the job; the agent cannot take that responsibility away.

That judgment also reflects how developers interact with models. The telemetry shows that developers are not relying on a single frontier model. Of every 100 developer-selected requests, 25 went to fast, lightweight models (such as Gemini 3.8 Flash, Claude Haiku 5.5, or GPT-6 Luna), while 37 went to reasoning models and 38 to general-purpose models. These figures exclude automatic selection; they are request shares, not a breakdown of all developer tasks.

Choice also extends to editor surfaces. Copilot usage spans the terminal, CLI, Copilot app, web, mobile, VS Code, Visual Studio, Eclipse, and IntelliJ. Native Copilot integration has also expanded to Apple's Xcode following announcements at WWDC.

GitHub Next and Chopin: Rethinking collaborative planning with agents

One of the most compelling segments of the closing keynote came from Maggie Appleton, designer and engineer at GitHub Next (GitHub's advanced research and prototyping lab).

Maggie tackled a problem every engineer using coding agents has experienced: agent planning today is broken.

Her critique targeted four specific failure modes:

1. The multiple-choice interrogation: Planning typically happens in a tiny terminal CLI or desktop chat box, subjecting the developer to an endless sequence of multiple-choice questions. By question nine, cognitive fatigue sets in and the developer defaults to clicking "Option A (Recommended)"—what Maggie called vibes-based decision making.
2. Text walls: Once the questionnaire concludes, the agent spits out pages of dense markdown. Reading walls of technical text is tiring, and subtle architectural errors get buried.
3. Single-player isolation: Today's agent sessions are private 1-on-1 conversations between an individual engineer and an LLM. Teammates cannot see the plans being generated or the architectural trade-offs being accepted.
4. The PR is too late for feedback: Because engineers lack collaborative planning tools, they default to letting the agent implement the entire feature and opening a pull request to get feedback from teammates. But a pull request is way too late in the lifecycle to ask: "Should we even build this?" or "Is this the right backend architecture?" Rewriting or discarding code after tokens have already been spent is pure waste.

The Chopin prototype: Multiplayer canvases, proactive research, and decision audit logs

To solve this, GitHub Next built Chopin, an experimental prototype named after the composer Frédéric Chopin.

Chopin re-imagines agent planning as a real-time collaborative workspace where multiple human developers and an intelligent agent work together inside the same document:

• Shared context: The planning canvas is connected directly to the repository and open to the entire team. Multiple engineers can chat, write requirements, and refine specifications simultaneously.
• Proactive agent research: Rather than waiting passively for instructions, the Chopin agent reads the team's discussion and anticipates needs. When Martin and Maggie discussed using Bluetooth versus Wi-Fi for their multiplayer badge game, Chopin proactively researched Bluetooth LE range limitations, synthesized the technical trade-offs, and generated inline dataflow diagrams explaining how synchronization would work.
• Visual prototypes over text walls: When debating user interfaces, Chopin generated interactive, clickable mockups showing different states (such as an animated landscape game view versus a large accessible counter). Engineers can click through states before any production code is written.
• Decision cards with attribution: The demo captured choices as decision cards. When Maggie or Martin selected an option, the document recorded who made the decision and when. If a developer asks two months later why a specific approach was chosen, the record gives them someone to ask and the surrounding planning context.
• Direct conversion to tasks: Once the team agrees on the plan, Chopin breaks the work into modular implementation tasks and opens corresponding pull requests.

Maggie and Martin then tried the collaborative 10,000-step game on their badges. After moving closer together, the demo reached its shared goal—a suitably hands-on ending to a discussion about planning.

For engineering teams, this approach feels far healthier than isolated agent prompting. It brings software planning back to what it should be: a collaborative team activity where agents assist research and visual prototyping, while humans make and own the decisions.

Software beyond tech: Science, low-level systems, and the next generation

The keynote also explored how open-source practices are transforming disciplines outside traditional commercial software.

Professional, scientific, and technical services have grown fivefold on GitHub, becoming the leading open-source growth sector outside of core tech. Research repositories have quietly become the verifiable paper trail behind published academic literature.

To support researchers, GitHub highlighted native Citation support (enabling standard academic citations directly from repositories) and ORCID ID integration to link software artifacts to verified researcher identities.

The GitHub Campus Program now spans nearly 2,500 academic institutions across 60 countries, supported by more than 100 active Campus Experts and 500 alumni helping students navigate git, AI tools, and open source.

Martin invited Jocelyn Velarde, a visiting undergraduate researcher at the UC Davis Neuroprosthetics Lab and an MLH coach, to share her path through open source.

While still in high school in Monterrey, Mexico, Jocelyn cold-emailed Dr. Miriam Alanis at Tec de Monterrey and built an EEG-controlled brain-computer interface (BCI) robotic hand prosthetic using Linear Discriminant Analysis (LDA) machine learning.

Today at UC Davis, she works on the "Brain to Voice" project, decoding neural signals to restore real-time speech for ALS patients. Her specific technical focus is low-level systems engineering across heterogeneous compute platforms to minimize audio streaming latency—work that requires deep hardware and systems understanding.

Her advice to aspiring engineers was simple and practical: set clear goals, find supportive communities (such as Campus Experts and MLH), and do not hesitate to reach out to mentors directly.

The closing message: You write the story

The final keynote ended with characteristic hacker playfulness. Martin placed his badge inside a plushie "Ship It" squirrel, trained gesture-recognition models on stage to detect throws and drops, and invited the audience into a live airtime contest, tossing Mona, Copilot, and Octocat plushies across the hall while the badges tracked airtime.

Underneath the fun was a serious message for developers:

Martin said AI makes it easier to create applications we previously lacked the time or skills to build. He asked us to broaden the circle of people we learn from, push the boundaries of what we know, and learn by doing. Creativity, judgment, and taste remain ours to bring.

"In this new era, AI doesn't write the story. You write the story."

What I am taking back from Universe

Jay Parikh opened Universe with the claim that all the software written so far might amount to just 1% of what humans and agents build over the next five years. Martin Woodward closed it by reminding us that without human judgment and heart, building faster just means accumulating unverified slop.

Across both keynotes, the real narrative of Universe 2026 was not that agents are replacing developers. It was that GitHub is evolving every layer of the delivery pipeline to make agent-assisted engineering manageable, accountable, and sustainable.

Day 1 provided the technical machinery:

• Copilot Projects to coordinate features across repositories.
• Copilot Fusion to handle multi-model routing across reasoning, general, and fast tiers.
• Rebuilding Git from the ground up, with a reported test sustaining 7,200 writes per second from 5,000 agents targeting one repository.
• Automations and Code Review Max to catch regressions and security vulnerabilities before shipping.

Day 2 provided the operational principles:

• Protecting maintainers from automated spam with WIP limits and interaction gates.
• Recognizing that DevOps and CI/CD maturity are strict prerequisites before deploying agents at scale.
• Moving planning out of private terminal questionnaires into multiplayer collaborative canvases like Chopin.
• Anchoring delivery in tight verification loops and human accountability.

For my own teams and clients, I am taking back a clear implementation checklist:

1. Pilot a multi-repo feature with Copilot Projects: Choose a bounded feature spanning two or three services. Set explicit AI credit budgets and tool access, and follow the work from initial issue through review and merge.
2. Harden the verification gate before scaling agents: If a repository does not have automated linting, appropriate unit and integration tests, and clean CI checks, do not give an agent merge permissions. The OpenPrinting example reinforced why operational maintenance belongs alongside the agent rollout.
3. Turn on repository guardrails: Configure appropriate limits for outside contributors, with exemptions that fit the community, to encourage focused contributions and prevent maintainer fatigue.
4. Bring planning into the open: Stop letting engineers plan complex features in private 1-on-1 LLM prompts. Use shared specs, visual mockups, and explicit decision records so the whole team understands what is being built and why.

Tools like Fusion, Automations, and Chopin will continue to evolve. But the fundamental responsibility of an engineering lead remains unchanged: define what good looks like, establish the safety rails, and ensure that every decision that reaches production can be explained by a human.

Thanks for reading this post, I hope you found it interesting!

Feel free to follow me to get notified when new articles are out 🙂