![\"Pillippa](\"https://github.blog/wp-content/uploads/2026/04/Image-1.jpeg?resize=1024%2C683\")
Learn about the productivity tool one GitHub engineer built, and how AI supported the development process.
\nThe post Build a personal organization command center with GitHub Copilot CLI appeared first on The GitHub Blog.
\n","content":"\nWhat if you could remove the struggle of context switching across several apps, bringing them together into one place?
\n\n\n\nMeet Brittany Ellich, Staff Software Engineer, and the productivity tool she built to streamline her work. We sat down with Brittany to learn about this project\u2013what she built, how she did it, and how AI supported the development process from ideation to implementation. Brittany created a visual home that fits how she learns and thinks, all inspired by the GitHub Copilot CLI.
\n\n\n\nVisual learner? Watch the video above!
\n\n\n\nWhat is your role at GitHub?
\n\n\n\nI\u2019m a staff software engineer on the billing team at GitHub. My day-to-day work mostly consists of working on metered billing, so things like keeping records of Actions minutes, storage amounts, and copilot usage. I passionately dogfood everything that comes out of the Copilot org. I\u2019m also an open source contributor to ATProto projects and built Open Social for applications built on the AT Protocol.
\n\n\n\nWhat did you build?
\n\n\n\nI built a personal organization command center to solve a simple problem: digital fragmentation. My goal was to take everything scattered across a dozen different apps and unify them into one calm, central space.
\n\n\n\nHow long did v1 take to make?
\n\n\n\nI use a plan-then-implement workflow when building systems, leveraging AI for planning and Copilot for implementation. For v1, this approach let me move from idea to a working tool in a single day alongside my other regular work.
\n\n\n\nWhile planning, I have Copilot interview me with questions about how something should work until we have a plan that I think is adequate. That way, there\u2019s less guesswork about what I want done and implementation goes more smoothly. Copilot will implement the work based on the plan that we put together.
\n\n\n\nWhat\u2019s your favorite tool stack to build with?
\n\n\n\nI like working in agent mode in VS Code for synchronous development, typically with up to 2 non-competing agent workflows going at a time, and Copilot Cloud Agent for asynchronous development. I typically try to keep a few asynchronous tasks flowing with Copilot Cloud Agent, like bug fixes or tech debt changes that have been well-scoped, while I\u2019m focusing on the work that needs more oversight in VS Code.
\n\n\n\nFollow-up loaded question: Do you care what tech stack your apps use now?
\n\n\n\nNot really. I\u2019ve always wanted to build an Electron app and this is technically my first one, but I can\u2019t say I learned a ton about Electron during this process since it was almost completely built by Agent Mode. That said, I went in and simplified the repo significantly to make it publicly accessible which required a lot more hands-on work (agents seem to like adding code but are much less enthusiastic about removing code) and felt pretty comfortable reading through the repo and making changes despite not having a ton of familiarity with Electron apps.
\n\n\n\n\n\n\n\nWhat\u2019s your one-line takeaway for other builders?
\n\n\n\nGo build something! Building solutions from scratch has never been easier, and it\u2019s helpful for learning how to work with new AI tools.
\n\n\n\nHow do you keep up with news and changes in the industry?
\n\n\n\nI stay on top of industry news through articles, podcasts, and social media. I read articles that are shared internally on GitHub\u2019s Slack, and I read the GitHub blog. We have a ton of great engineers who are great at curating useful resources and sharing them with the team. There are a few podcasts that I like for keeping up with things, like How I AI and Last Week in AI. On social media, I\u2019m active on Bluesky and have had a ton of great conversations with other engineers there.
\n\n\n\nBrittany\u2019s project is a good reminder that the most useful projects often start as small fixes for everyday problems.
\n\n\n\nWhile you can use your own stack for this, if you\u2019d like to try something similar, here are the tools Brittany used:
\n\n\n\nAll of these are open source, and GitHub Copilot can help you get started with them quickly!
\n\n\n\nIf you\u2019d like her exact solution, you can clone Brittany\u2019s repository to get up and running right away. You\u2019ll need the following on your machine:
\n\n\n\nThere are more detailed instructions in her repository README file!
\n\n\n\n\n\nThe post Build a personal organization command center with GitHub Copilot CLI appeared first on The GitHub Blog.
\n","enclosure":{},"categories":["AI & ML","GitHub Copilot","GitHub Copilot CLI"]},{"title":"Developer policy update: Intermediary liability, copyright, and transparency","pubDate":"2026-04-15 15:00:00","link":"https://github.blog/news-insights/policy-news-and-insights/developer-policy-update-intermediary-liability-copyright-and-transparency/","guid":"https://github.blog/?p=95283","author":"Margaret Tucker","thumbnail":"","description":"\nWe\u2019re sharing recent policy updates that developers should know about, updating our Transparency Center with the full year of 2025 data, and looking to what\u2019s ahead.
\nThe post Developer policy update: Intermediary liability, copyright, and transparency appeared first on The GitHub Blog.
\n","content":"\nWe\u2019re sharing a few timely updates on developer policy that reflect GitHub\u2019s ongoing work on transparency, developer protections, and copyright policy engagement\u2014issues that directly affect how developers build, share, and maintain software.
\n\n\n\nThis March, the U.S. Supreme Court issued its decision in Cox v. Sony, a case addressing the limits of secondary copyright liability for online services. GitHub and developer platforms served as key examples in an industry amicus brief to explain why clear and balanced liability standards are essential for developer platforms and other intermediaries that host or enable user\u2011generated content.
\n\n\n\nThe Court\u2019s opinion reinforced that service providers are not automatically liable for copyright infringement by users without evidence of intent to encourage or materially contribute to infringement. By clarifying this standard, the decision helps avoid overly expansive liability theories that would make it difficult for intermediaries to exist or operate at scale. For developers, this legal certainty supports innovation, collaboration, and the continued availability of neutral infrastructure that enables lawful activity like GitHub.
\n\n\n\nAnother important copyright process is approaching: the next triennial review of exemptions under Section 1201 of the DMCA. DMCA Section 1201 is the part of U.S. copyright law that restricts bypassing digital access controls. It matters for developers because it can affect activities like security research, interoperability, repair, accessibility, and other lawful work unless temporary exemptions are in place. The most recent triennial cycle concluded in 2024, setting exemptions that remain in effect for the current three-year period.
\n\n\n\nGitHub has a long history of engaging in the Section 1201 process and publishing resources to explain why these exemptions matter to developers. In 2021, we filed comments in support of a broad safe harbor for good-faith security research. The 2024 cycle included several submissions of interest to developers such as the Authors Alliance exemption expansion petition, which addressed access and preservation concerns, as well as a security research petition focused on AI safety\u2011related research and analysis which drew thoughtful comments in support from HackerOne, the Hacking Policy Council, and academic researchers.
\n\n\n\nAlthough the generative AI security research petition was not ultimately adopted in the 2024 cycle, it raised important questions about how existing DMCA frameworks apply to emerging AI\u2011related research and development practices. As the software ecosystem continues to evolve, new Section 1201 challenges are emerging\u2014particularly around AI systems, model inspection, safety research, and interoperability.
\n\n\n\nLooking ahead to the 2027 triennial review, we\u2019re interested in hearing from developers about the issues they\u2019re encountering, which use cases matter most, and how these questions should be explored in future DMCA triennial reviews.
\n\n\n\nWe\u2019ve also updated GitHub\u2019s Transparency Center with the full year of 2025 data. For this update, we made improvements to the site, including clearer charts and updated visualizations for our abuse-related restrictions, appeals, and reinstatements designed to make the information easier to understand. 2025 had the highest count of DMCA circumvention claims since we started our transparency reporting. While this can be attributed to a few very large takedowns, it also underscores how important a balanced approach to the DMCA is for software developers, code collaboration platforms, and the open source ecosystem.
\n\n\n\nWe\u2019re hearing growing concern from the developer community about age assurance laws emerging in U.S. states, Brazil, and Europe, particularly where requirements aimed at commercial, consumer\u2011facing products could unintentionally sweep in open source operating systems, package managers, and other critical digital infrastructure. These issues reinforce the value of ongoing collaboration with policymakers to promote informed, balanced policies that support open source developers. We\u2019ll continue to advocate for policies that reflect technical realities and support open development, including through an upcoming educational developer policy blog post and a May Maintainer Month session focused on these topics.
\n\nThe post Developer policy update: Intermediary liability, copyright, and transparency appeared first on The GitHub Blog.
\n","enclosure":{},"categories":["News & insights","Policy","GitHub Policy","GitHub Transparency Report"]},{"title":"Hack the AI agent: Build agentic AI security skills with the GitHub Secure Code Game","pubDate":"2026-04-14 18:17:59","link":"https://github.blog/security/hack-the-ai-agent-build-agentic-ai-security-skills-with-the-github-secure-code-game/","guid":"https://github.blog/?p=95266","author":"Joseph Katsioloudes","thumbnail":"","description":"\nLearn to find and exploit real-world agentic AI vulnerabilities through five progressive challenges in this free, open source game that over 10,000 developers have already used to sharpen their security skills.
\nThe post Hack the AI agent: Build agentic AI security skills with the GitHub Secure Code Game appeared first on The GitHub Blog.
\n","content":"\nI was scrolling through my feed one evening when I came across OpenClaw, an open source personal AI assistant that people were calling everything from \u201cJarvis\u201d to \u201ca portal to a new reality.\u201d The idea is beautiful: an AI that lives on your machine or in the cloud, talks to you over WhatsApp or Telegram, clears your inbox, manages your calendar, browses the web, runs shell commands, and even writes its own plugins. Users were having it check them in for flights, build entire websites from their phones, and automate things they never thought possible.
\n\n\n\nMy first reaction was the same as everyone else\u2019s: this is incredible.
\n\n\n\nMy second reaction was\u2026different. I started thinking about what happens when that kind of power meets a malicious prompt. What if someone tricks the agent into reading files it should not access? What if a poisoned web page rewrites the agent\u2019s instructions? What if one agent in a multi-agent chain passes bad data to another that blindly trusts it?
\n\n\n\nThose questions became Season 4 of the Secure Code Game.
\n\n\n\nThe Secure Code Game is a free, open source in-editor course where players exploit and fix intentionally vulnerable code. When I created the first season in March 2023, the goal was straightforward: make security training that developers would enjoy. Fix the vulnerable code, keep it functional, level up. That core philosophy has not changed across any season.
\n\n\n\nSeason 2 expanded into multi-stack challenges with community contributions across JavaScript, Python, Go, and GitHub Actions. Season 3 took players into LLM security, where they learned to hack and then harden large language models. Along the way, over 10,000 developers across the industry, open source, and academia have played to sharpen their skills.
\n\n\n\nWhat has changed with each season is the landscape. When we launched Season 1, AI coding assistants were just starting to become mainstream. By Season 3, we were teaching players to craft malicious prompts and then defend against them. Now, with Season 4, we are tackling the security challenges of AI systems that can act autonomously. They can browse the web, call APIs, coordinate with other agents, and act on your behalf.
\n\n\n\nThe timing is not a coincidence. AI agents have moved from research prototypes to production tools at remarkable speed, and the security community is racing to keep up.
\n\n\n\nThe OWASP Top 10 for Agentic Applications 2026, developed with input from over 100 security researchers, now catalogues risks like agent goal hijacking, tool misuse, identity abuse, and memory poisoning as critical threats. A Dark Reading poll found that 48% of cybersecurity professionals believe agentic AI will be the top attack vector by the end of 2026. And Cisco\u2019s State of AI Security 2026 report highlighted that while 83% of organizations planned to deploy agentic AI capabilities, only 29% felt ready to do so securely.
\n\n\n\nThe gap between adoption and readiness is exactly where vulnerabilities thrive. And the best way to close that gap is by learning to think like an attacker.
\n\n\n\nSeason 4 puts you inside ProdBot, your productivity bot, a deliberately vulnerable agentic coding assistant for your terminal. Inspired by tools like OpenClaw and GitHub Copilot CLI, ProdBot turns natural language into bash commands, browses a simulated web, connects to MCP (Model Context Protocol) servers, runs org-approved skills, stores persistent memory, and orchestrates multi-agent workflows.
\n\n\n\nYour mission across five progressive levels is simple: use natural language to get ProdBot to reveal a secret it should never expose. If you can read the contents of password.txt, you have found a security vulnerability.
\n\n\n\nNo AI or coding experience is needed\u2026just curiosity and willingness to experiment. Everything happens through natural language in the CLI.
\n\n\n\nEach level of the game mirrors a stage in how real AI-powered tools evolve. As ProdBot gains new capabilities, the upgrade opens a new attack surface for you to discover. Here is what ProdBot looks like as it grows:
\n\n\n\nEach level builds on the previous one, and that progression is the point.
\n\n\n\nWe aren\u2019t going to tell you exactly which vulnerabilities you will find at each level as that would ruin the fun. But we will say this: the attack patterns you will discover in Season 4 are not theoretical. They reflect the kinds of risks that security teams are grappling with right now as organizations deploy autonomous AI systems into production.
\n\n\n\nThink about CVE-2026-25253 (CVSS 8.8 \u2013 High): Known as \u201cClawBleed\u201d or the one-click Remote Code Execution (RCE) vulnerability. It allowed attackers to steal authentication tokens via a malicious link and gain full control of the OpenClaw instance.
\n\n\n\nThe goal is not just to learn a specific exploit. It is to build the instinct that helps you spot these patterns in the wild, whether you are reviewing an agent\u2019s architecture, auditing a tool integration, or simply deciding how much autonomy to give the AI assistant that just landed on your team.
\n\n\n\nThis entire experience runs in GitHub Codespaces, so there is nothing to install, nothing to configure, and it doesn\u2019t cost you a penny (Codespaces offers up to 60 hours of free usage per month). You can be inside ProdBot\u2019s terminal in under two minutes, and each season is self-contained, so you can jump straight into Season 4 without covering the earlier ones.
\n\n\n\nYou may find Season 3 to be a helpful foundation since it builds the basics of AI security. But it is not required. Just bring your hacker mindset.
\n\n\n\nReady? Start Season 4 now >
\nSpecial thanks to Rahul Zhade, Staff Product Security Engineer at GitHub, and Bartosz Ga\u0142ek, creator of Season 3, for testing and improving Season 4.
\n\n\n\nDo I need AI or coding experience to play Season 4?
\n\nNo. Everything happens through natural language in the CLI. You type plain English, or any language, prompts and ProdBot responds. Curiosity and a willingness to experiment are all you need.
\n\u00a0\nDo I need to complete previous seasons first?
\n\nNo. Each season is self-contained. You can jump directly into Season 4 by running ProdBot and typing level <N>. That said, Season 3 builds a helpful foundation in AI security and takes about 1.5 hours.
How long does Season 4 take?
\n\nApproximately two hours, though it varies depending on how deeply you explore each level. Some players like to try multiple approaches per level.
\n\u00a0\nIs this free?
\n\nYes. The Secure Code Game is open source and free to play. It runs in GitHub Codespaces, which provides up to 60 hours of free usage per month.
\n\u00a0\nWhat are the rate limits?
\n\nSeason 4 uses GitHub Models, which have rate limits. If you hit a limit, wait for it to reset and resume. Learn more about responsible use of GitHub Models.
\n\nThe post Hack the AI agent: Build agentic AI security skills with the GitHub Secure Code Game appeared first on The GitHub Blog.
\n","enclosure":{},"categories":["AI & ML","Security","agentic AI security","AI security","coding training","cybersecurity","GitHub Security Lab","secure coding"]},{"title":"How exposed is your code? Find out in minutes\u2014for free","pubDate":"2026-04-14 15:00:00","link":"https://github.blog/security/application-security/how-exposed-is-your-code-find-out-in-minutes-for-free/","guid":"https://github.blog/?p=95258","author":"Dorothy Pearce","thumbnail":"","description":"\nThe new Code Security Risk Assessment gives you a one-click view of vulnerabilities across your organization, at no cost.
\nThe post How exposed is your code? Find out in minutes\u2014for free appeared first on The GitHub Blog.
\n","content":"\nMost security leaders share the same suspicion: there are vulnerabilities in our codebase that we don\u2019t know about.
\n\n\n\nThe uncomfortable truth is that most code never gets a thorough security review. Vulnerabilities accumulate quietly in active repositories, across languages and teams, often undetected until something goes wrong. And if you\u2019re relying on manual reviews or narrowly scoped tools, the gaps may be wider than you think.
\n\n\n\nToday, we\u2019re introducing the Code Security Risk Assessment: a free, one-click scan that reveals vulnerabilities hiding in your organization\u2019s code. No license required. No configuration. No commitment. Just clarity.
\n\n\n\nThe Code Security Risk Assessment is available to GitHub organization admins and security managers. If that\u2019s not you, this post is still worth reading and sharing: it explains what the assessment reveals and why it\u2019s worth running.
\n\n\n\n\n\n\n\nThe Code Security Risk Assessment scans up to 20 of your most active repositories using CodeQL, GitHub\u2019s industry-leading static analysis engine, and delivers a dashboard summarizing what it finds:
\n\n\n\nThe assessment is available to organization admins and security managers on GitHub Enterprise Cloud and GitHub Team plans. It\u2019s completely free \u2014 you won\u2019t be charged for any licenses, and the GitHub Actions minutes used for scanning don\u2019t count against your quota.
\n\n\n\nSee how it works. \ud83d\udc47
\n\n\n\nIf you\u2019ve already run a Secret Risk Assessment, you know the value of visibility. Since launching last year, the Secret Risk Assessment has helped thousands of organizations understand their exposure to leaked credentials. In 2025 alone, customers using Secret Protection scanned nearly 2 billion pushes and blocked 19 million secret exposures.
\n\n\n\nThe Code Security Risk Assessment brings that same philosophy to vulnerabilities in your source code. Both assessments now run together from a single entry point, with a tabbed interface that lets you switch between your secret exposure and your code vulnerability findings. Together, they give you a unified view of your organization\u2019s security posture\u2014secrets and code\u2014in minutes.
\n\n\n\nEven if you\u2019re not responsible for running security scans yourself, the results of these assessments can help your team align on where risk exists and what to fix first.
\n\n\n\nAnd when you\u2019re ready to act on what you find, each assessment has a corresponding GitHub product designed to help. Secret Protection stops credentials from leaking. Code Security finds and fixes vulnerabilities. The assessments show you why you need them.
\n\n\n\nKnowing where your vulnerabilities are is the first step. Fixing them is what actually reduces risk.
\n\n\n\nThat\u2019s where GitHub Code Security and Copilot Autofix change the equation. Across GitHub in 2025:
\n\n\n\nYour Code Security Risk Assessment results will show you how many of your detected vulnerabilities are eligible for Copilot Autofix \u2014 giving you a concrete picture of how quickly you could start reducing risk. When you\u2019re ready, you can enable Code Security directly from the results page with a single click.
\n\n\n\nWhether you have no security scanning in place, you\u2019re evaluating your current tools, or you want a broader view of risk across your organization \u2014 the Code Security Risk Assessment meets you where you are.
\n\n\n\nIt\u2019s free. It takes minutes. And what you learn might change how you think about your security posture.
\n\n\n\nRun your free Code Security Risk Assessment, or to learn more, read the docs.
\nThe post How exposed is your code? Find out in minutes\u2014for free appeared first on The GitHub Blog.
\n","enclosure":{},"categories":["Application security","Security","Web application security","code scanning","Code security","risk assessment","Secret Protection"]},{"title":"GitHub for Beginners: Getting started with GitHub Pages","pubDate":"2026-04-13 15:00:00","link":"https://github.blog/developer-skills/github/github-for-beginners-getting-started-with-github-pages/","guid":"https://github.blog/?p=95207","author":"Kedasha Kerr","thumbnail":"","description":"\nLearn how to create a free website for any repository on GitHub Pages.
\nThe post GitHub for Beginners: Getting started with GitHub Pages appeared first on The GitHub Blog.
\n","content":"\nWelcome back to GitHub for Beginners. So far, we\u2019ve discussed GitHub Issues and Projects, GitHub Actions, and covered a bit about security. This time, we\u2019re going to talk about GitHub Pages.
\n\n\n\nDid you know that you have access to a free and secure hosting service on GitHub, readily available for any project? That\u2019s what GitHub Pages is\u2014a way to turn any GitHub repository with a static website into a live site for free. You just need three things:
\n\n\n\nFollow the steps in this blog and your project will be live, searchable, and ready to share. Let\u2019s get started!
\n\n\n\nAs always, if you prefer to watch the video or want to reference it, we have all of our GitHub for Beginners episodes available on YouTube.
\n\n\n\nTo get started, navigate to the sample repository, and create a fork of the repository that you can use for your own walkthrough. This repository has a static website generated with Next.js. Since it\u2019s already been pushed up to GitHub, it\u2019s ready to deploy.
\n\n\n\nThere are two different ways that you can deploy your project to GitHub Pages: deploying from a branch or using GitHub Actions. First, let\u2019s look at deploying from a branch.
\n\n\n\nmain as the branch to deploy from.This publishes the website from the main branch and makes it publicly available.
\n\n\n\nNow let\u2019s look at publishing using the GitHub Actions workflow. Since we\u2019re already on the appropriate Settings page, we\u2019ll pick up from here.
\n\n\n\nmain branch is selected, then click Commit changes at the bottom of the window.Congratulations! You have successfully deployed a website to GitHub Pages. Keep in mind that even if your repository is private, the published website will still be public. If you ever want to see who most recently deployed your website, you can do so by navigating back to Settings -> Pages.
\n\n\n\nBy default, all websites on GitHub Pages will have the following URL: USERNAME.github.io/REPOSITORY-NAME.
However, you can update this to use your custom domain if you want. To do this, you\u2019ll first need to configure DNS records with your domain provider. You can read more about how to do this by checking out our docs on managing a custom domain. You\u2019ll also need to verify your domain at the org or profile level.
\n\n\n\nOnce you\u2019ve configured the DNS records and verified the domain, you can set the custom domain by following these steps:
\n\n\n\nNow you know how to select a project to deploy and create a website for the repository either from a branch or by using GitHub Actions. Not only that, but you can customize the domain, and it\u2019s all available for free! Use this to promote your projects, share what you\u2019re working on, or expand your portfolio, even if the projects themselves are private.
\n\n\n\nIf you want to learn more about GitHub Pages, here are some good places to get started:
\n\n\n\nHappy coding!
\n\nThe post GitHub for Beginners: Getting started with GitHub Pages appeared first on The GitHub Blog.
\n","enclosure":{},"categories":["Developer skills","GitHub","GitHub for beginners","GitHub Skills"]},{"title":"GitHub Copilot CLI for Beginners: Getting started with GitHub Copilot CLI","pubDate":"2026-04-10 16:00:00","link":"https://github.blog/ai-and-ml/github-copilot/github-copilot-cli-for-beginners-getting-started-with-github-copilot-cli/","guid":"https://github.blog/?p=95185","author":"Christopher Harrison","thumbnail":"","description":"\nGitHub for Beginners: Getting started with the GitHub Copilot CLI, a step-by-step tutorial.
\nThe post GitHub Copilot CLI for Beginners: Getting started with GitHub Copilot CLI appeared first on The GitHub Blog.
\n","content":"\nWelcome to GitHub Copilot CLI for Beginners! In this series (available in video format and on the GitHub Blog), we\u2019ll explore how to use your AI coding assistant directly in your terminal, along with tips and tricks on how to navigate the command line like a pro!
\n\n\n\nIn this blog, we\u2019ll walk through what GitHub Copilot CLI is, how it works, and how to get started. You\u2019ll learn how to install it using npm, authenticate with your GitHub account, grant folder permissions, and run your first prompts to generate code directly from the terminal.
\n\n\n\nLet\u2019s get started!
\n\n\n\nThe GitHub Copilot CLI brings Copilot\u2019s agentic AI capabilities right into the command-line interface (CLI), becoming like any terminal or console based tool you use (with the full context of your repos)!
\n\n\n\nWhat makes agents so special is their ability to perform tasks like building code and running tests autonomously, so you can build iteratively. They can even self-correct and fix errors without needing a human to prompt them.
\n\n\n\nThis means you can assign tasks to Copilot, focus on other to-do list items, and then review the results and request additional changes from the terminal\u2014all without having to interrupt your workflow or switch tools. (You can even delegate tasks to Copilot Cloud agent from inside the CLI, more on this later.)
\n\n\n\nNot surprisingly, the first step to using Copilot CLI is installation. The core cross-platform way\u2014if you already have node\u2014to do this is via npm, using:
\n\n\nnpm install -g @github/copilot If you\u2019re using a package manager like WinGet or Homebrew, you can install Copilot CLI through those tools as well. (You\u2019ll want to consult those tools\u2019 documentation for the exact specifics on how to do this.)
\n\n\n\nOnce you install the product, you can launch it by typing \u201cCopilot\u201d in your command line. There are numerous switches you can use, which we\u2019ll cover later in the series.
\n\n\n\nIf it\u2019s your first time in the terminal, you\u2019ll need to log in with your GitHub credentials.
\n\n\n/loginThis will:
\n\n\n\nWhen using Copilot, you need to grant access to the folder for Copilot to be able to explore and potentially modify files. You can do this for only this session or save this setting to apply to later sessions, too. This will allow you to launch Copilot again in the future, without having to keep approving it for the same project.
\n\n\n\nOnce you\u2019ve done that, you can start talking to Copilot, asking it questions, and request code or other tasks.
\n\n\n\nHere are just a few GitHub Copilot CLI use cases. (There are many more covered in the GitHub Copilot CLI 101 blog!)
\n\n\n\nAsk for an overview of the project: Copilot will explore, open important files, and report back with its findings.
\n\n\nGive me an overview of this project Ask for code, such as a new endpoint: Copilot will look at the project, find existing documentation and examples, and try to follow the practices it sees. Again, it will ask for permission to create the file.
\n\n\nLet\u2019s add a new endpoint to return all categoriesDelegate tasks to Copilot cloud agent: For well-defined tasks, you can delegate to Copilot cloud agent right from the CLI. Copilot will preserve the context from your current session, create a new branch, open a draft pull request, and make the requested changes in the background before requesting your review.
\n\n\n/delegate Let\u2019s deal with issue #14 to add the rest of the CRUD endpoints to gamesOf course, one of the best ways to explore what you can do with Copilot CLI is to simply ask Copilot. It can look through its own documentation and provide guidance on the best ways to interact with it and explore.
\n\n\n\nTune in for the next lesson in the series which covers using two different modes: interactive mode to have GitHub Copilot run your project locally or non-interactive mode with the -p flag for quick summaries without leaving your shell context.
Bringing agentic AI right to your terminal opens a whole new way to learn, experiment, and get things done without ever breaking your flow. Keep an eye out for more videos in the GitHub Copilot CLI for Beginners series, where we\u2019ll learn about:
\n\n\n\nHappy coding!
\n\n\n\nLooking to try GitHub Copilot CLI? Read the Docs and get started today.
\nMore resources to explore:
\n\n\n\nThe post GitHub Copilot CLI for Beginners: Getting started with GitHub Copilot CLI appeared first on The GitHub Blog.
\n","enclosure":{},"categories":["AI & ML","Generative AI","GitHub Copilot","GitHub Education","GitHub Copilot CLI","GitHub Copilot CLI for Beginners"]},{"title":"GitHub availability report: March 2026","pubDate":"2026-04-09 02:21:17","link":"https://github.blog/news-insights/company-news/github-availability-report-march-2026/","guid":"https://github.blog/?p=95150","author":"Jakub Oleksy","thumbnail":"","description":"\nIn March, we experienced four incidents that resulted in degraded performance across GitHub services.
\nThe post GitHub availability report: March 2026 appeared first on The GitHub Blog.
\n","content":"\nIn March, we experienced four incidents that resulted in degraded performance across GitHub services.
\n\n\n\nMarch 03 18:59 UTC (lasting 1 hour and 10 minutes)
\n\n\n\nOn March 3, 2026, between 18:46 and 20:09 UTC, GitHub experienced a period of degraded availability impacting github.com, the GitHub API, GitHub Actions, Git operations, GitHub Copilot, and other dependent services. At the peak of the incident, github.com request failures reached approximately 40%. During the same period, approximately 43% of GitHub API requests failed. Git operations over HTTP had an error rate of approximately 6%, while SSH was not impacted. GitHub Copilot requests had an error rate of approximately 21%. GitHub Actions experienced less than 1% impact.
\n\n\n\nThis incident shared the same underlying cause as an incident in early February, where we saw a large volume of writes to the user settings caching mechanism. While deploying a change to reduce the burden of these writes, a bug caused every user\u2019s cache to expire, get recalculated, and get rewritten. The increased load caused replication delays that cascaded down to all affected services. We mitigated this issue by immediately rolling back the faulty deployment.
\n\n\n\nWe understand these incidents disrupted the workflows of developers. While we have made (and are making) substantial, long-term investments in how GitHub is built and operated to improve resilience, we acknowledge we have more work to do. Getting there requires deep architectural work that is already underway, as well as urgent, targeted improvements. We are taking the following immediate steps:
\n\n\n\nMarch 05 16:35 UTC (lasting 2 hours and 55 minutes)
\n\n\n\nOn March 5, 2026, between 16:24 and 19:30 UTC, GitHub Actions was degraded. During this time, 95% of workflow runs failed to start within 5 minutes with an average delay of 30 minutes, and 10% of workflow runs failed with an infrastructure error. This was due to Redis infrastructure updates that were being rolled out to production to improve our resiliency. These updates introduced a set of incorrect configuration changes into our Redis load balancer, causing internal traffic to be routed to an incorrect host leading to two incidents.
\n\n\n\nWe mitigated this incident by correcting the misconfigured load balancer. Actions jobs were running successfully starting at 17:24 UTC. The remaining time until we closed the incident was spent burning through the queue of jobs.
\n\n\n\nWe immediately rolled back the updates that were a contributing factor and have frozen all changes in this area until we complete follow-up work. We are working to improve our automation to ensure incorrect configuration changes cannot propagate through our infrastructure. We are also working on improved alerting to catch misconfigured load balancers before it becomes an incident. Additionally, we are updating the Redis client configuration in Actions to improve resiliency to brief cache interruptions.
\n\n\n\nMarch 19 13:44 UTC (lasting 48 minutes)
\n\n\n\nOn March 19, 2026, between 01:05 and 02:52 UTC, and again on March 20, 2026, between 00:42 and 01:58 UTC, the Copilot Coding Agent service was degraded and users were unable to start new Copilot Agent sessions or view existing ones. During the first incident, the average error rate was ~53% and peaked at ~93% of requests to the service. During the second incident, the average error rate was ~99% and peaked at ~100% of requests with significant retry amplification. Both incidents were caused by the same underlying system authentication issue that prevented the service from connecting to its backing datastore.
\n\n\n\nWe mitigated each incident by rotating the affected credentials, which restored connectivity and returned error rates to normal. The mitigation time was 01:24. The second occurrence was due to an incomplete remediation of the first.
\n\n\n\nWe have implemented automated monitoring for credential lifecycle events and are improving operational processes to reduce our time to detection and mitigation of issues like this one in the future.
\n\n\n\nMarch 24 16:59 UTC (lasting 2 hours and 52 minutes)
\n\n\n\nOn March 24, 2026, between 15:57 and 19:51 UTC, the Microsoft Teams Integration and Teams Copilot Integration services were degraded and unable to deliver GitHub event notifications to Microsoft Teams. On average, the error rate was 37.4% and peaked at 90.1% of requests to the service\u2014approximately 19% of all integration installs failed to receive GitHub-to-Teams notifications in this time period.
\n\n\n\nThis was due to an outage at one of our upstream dependencies, which caused HTTP 500 errors and connection resets for our Teams integration.
\n\n\n\nWe coordinated with the relevant service teams, and the issue was resolved at 19:51 UTC when the upstream incident was mitigated.
\n\n\n\nWe are working to update observability and runbooks to reduce time to mitigation for issues like this in the future.
\n\n\n\nFollow our status page for real-time updates on status changes and post-incident recaps. To learn more about what we\u2019re working on, check out the engineering section on the GitHub Blog.
\nThe post GitHub availability report: March 2026 appeared first on The GitHub Blog.
\n","enclosure":{},"categories":["Company news","News & insights","GitHub Availability Report"]},{"title":"GitHub Universe is back: We want you to take the stage","pubDate":"2026-04-08 16:35:46","link":"https://github.blog/news-insights/company-news/github-universe-is-back-we-want-you-to-take-the-stage/","guid":"https://github.blog/?p=95093","author":"Rachel Cohen","thumbnail":"https://github.blog/wp-content/uploads/2026/04/Image-1.jpeg?resize=1024%2C683","description":"\nGet inspired by five of the most memorable, magical, and quirky Universe sessions to date.
\nThe post GitHub Universe is back: We want you to take the stage appeared first on The GitHub Blog.
\n","content":"\nEveryone\u2019s favorite global developer event is back for another year of learning, connection, building, and donuts. We hope you\u2019re excited to join us at Fort Mason Center in San Francisco on October 28\u201329. Of course, you don\u2019t just have to be in attendance this year: Our Call for Sessions is open now through Friday, May 1 at 11:59 p.m. PT. If you\u2019ve been thinking about taking the stage, this is your moment. Submit a proposal that shares what you\u2019ve been building over the past year, what you\u2019ve learned, and what other builders can take away from it. And if you know someone who deserves a mic, you can also nominate a speaker.
\n\n\n\nNeed some inspiration? Below, we have five past Universe sessions that have captured our imaginations (so much so that we\u2019re still talking about them). These sessions perfectly encapsulate what Universe is all about: learning, fun, and just a little magic. We can\u2019t wait to see what they spark for you.
\n\n\n\nPillippa P\u00e9rez Pons took a problem every frontend team recognized: messy rebases, ever-growing monorepos, mysteriously vanishing commits, and general Git chaos, and made it delightfully weird by framing the whole thing as a cat\u2019s nine lives. Each \u201clife\u201d unlocked a lesser-known Git feature or optimization\u2014sparse checkouts, partial clones, reflog rescues, and performance boosts\u2014delivered with storytelling, visuals, and just enough humor to make the tricky parts stick.
\n\n\n\n![\"Matteo](\"https://github.blog/wp-content/uploads/2026/04/Image-2.jpeg?resize=1024%2C683\")
This full-on fantasy adventure, presented by Matteo Bianchi (GitHub) and Alexandra Aldershaab (Eficode), cast CI/CD as a castle, reframed ancient scripts as lurking monsters, and sent the audience on a quest to modernize automation without inviting supply chain dragons into the build. Under the playful storytelling, the session delivered a genuinely practical payoff: secure GitHub Actions patterns (with Copilot as a trusty sidekick) that helped teams speed up workflows while keeping security front and center.
\n\n\n\nIn Martin Woodward\u2019s (GitHub) hands, \u201cspeed\u201d became less of a productivity metric and more of a creative superpower (and yes, occasionally a little Furby-powered). The session zoomed out to the big shift underway in software: ideas moving from sketch to prototype to shipped experience faster than ever, and the new questions that came with that acceleration. Instead of obsessing over velocity, Martin challenged the audience with the idea that the best developers never stop experimenting. They stay curious. \u201cIf you can dream it,\u201d he said. \u201cYou can build it.\u201d
\n\n\n\nIf you\u2019ve ever wished Kubernetes security training came with a party of adventurers and a ridiculous quest narrative, this one absolutely delivered. Noah Abrahams, Ian Coldwater, Kat Cosgrove, Seth McCombs, and Natali Vlatko walked the audience through a serious cluster of security concepts while roleplaying their way through a chaotic fantasy world, complete with memorable villains and dramatic stakes.
\n\n\n\nWith true cinematic excitement, Nick Liffen (GitHub) and Niroshan Rajadurai turned application security into a near-future mission briefing. During their session, they pulled back the curtain on how GitHub applies AI to streamline remediation and make alerts easier to interpret\u2014then pushed the story forward into what comes next: AI that can fortify defenses and even spot emerging threats before they turn into incidents. They even saved a special surprise for the finale, giving the whole session that \u201cstay until the credits\u201d energy. This blog post will self-destruct in 3\u20262\u20261\u2026just kidding.
\n\n\n\nIf you need help polishing your proposal or making your idea stand out, check out our submission guide, which covers this year\u2019s content tracks, provides an in-depth look at session types, and outlines the anatomy of a great submission.
\n\n\n\nThis year\u2019s sessions fall into three categories:
\n\n\n\n\ud83d\udca1 Pro tip: Ship & Tell is a new format this year that\u2019s ideal for startup founders and builders to tell their story. What did you ship? How did you scale it? What broke? What worked? Your takeaways will provide inspiration for the next generation of builders.
\n\n\n\nReady to pitch your own Universe-worthy idea? If these sessions have one thing in common, it\u2019s this: they\u2019re grounded in real engineering lessons, then delivered with personality, creativity, and a clear point of view. That\u2019s exactly the kind of proposal we\u2019re excited to see for Universe.
\n\n\n\nBefore you submit, review the submission guide for what makes a strong proposal, plus tips to match your idea to the right format.
\n\n\n\nAnd don\u2019t wait: the deadline to submit a session proposal or nominate a speaker is Friday, May 1 at 11:59 pm PT.
\n\n\n\n\n\nThe post GitHub Universe is back: We want you to take the stage appeared first on The GitHub Blog.
\n","enclosure":{},"categories":["Company news","News & insights","GitHub Universe"]},{"title":"GitHub Copilot CLI combines model families for a second opinion","pubDate":"2026-04-06 21:53:49","link":"https://github.blog/ai-and-ml/github-copilot/github-copilot-cli-combines-model-families-for-a-second-opinion/","guid":"https://github.blog/?p=95067","author":"Nick McKenna","thumbnail":"","description":"\nDiscover how Rubber Duck provides a different perspective to GitHub Copilot CLI.
\nThe post GitHub Copilot CLI combines model families for a second opinion appeared first on The GitHub Blog.
\n","content":"\nWhen you ask a coding agent to build a data pipeline, it may not use the best structure. But what if the agent got a second opinion before it executed the plan?
\n\n\n\nToday, in GitHub Copilot CLI, we\u2019re introducing Rubber Duck in experimental mode. Rubber Duck leverages a second model from a different AI family to act as an independent reviewer, assessing the agent\u2019s plans and work at the moments where feedback matters most.
\n\n\n\nTo catch different kinds of errors, a different perspective matters. Our evaluations show that Claude Sonnet + Rubber Duck makes up 74.7% of the performance gap between Sonnet and Opus alone, achieving better results for tackling difficult multi-file and long-running tasks. Use /experimental in Copilot CLI to access Rubber Duck alongside our other experimental features.
Today\u2019s coding agents follow a clear loop. First, the agent assesses the task, then drafts a plan, implements, tests, and iterates if necessary. It\u2019s a powerful flow that works well, but it has blind spots. Any decision an agent makes early on, especially in the planning stage, is the foundation you\u2019re building upon. Assumptions and inefficiencies become dependencies, and by the time you notice, you may have to fix more than just the small mistake at the start.
\n\n\n\nUsing self-reflection and having the agent review its own output before moving forward is a proven technique. However, a model reviewing its own work is still bounded by its own training biases: the same training data and techniques, the same blind spots.
\n\n\n\nRubber Duck is a focused review agent, powered by a model from a complementary family to your primary Copilot session. When you\u2019ve selected a Claude model from the model picker to use as your orchestrator, Rubber Duck will be GPT-5.4. As we experiment with Rubber Duck, we are exploring other model families for the orchestrator and for the Rubber Duck. The job of Rubber Duck is to check the agent\u2019s work and surface a short, focused list of high-value concerns: details that the primary agent may have missed, assumptions worth questioning, and edge cases to consider.
\n\n\n\nWe evaluated Rubber Duck on SWE-Bench Pro, a benchmark of large, difficult, real-world coding problems drawn from open-source repositories. Here\u2019s what we found:
\n\n\n\nClaude Sonnet 4.6 paired with Rubber Duck running GPT-5.4 achieved a resolution rate approaching Claude Opus 4.6 running alone, closing 74.7% of the performance gap between Sonnet and Opus.
\n\n\n\nWe noticed that Rubber Duck tends to help more with difficult problems, ones that span 3+ files and would normally take 70+ steps. On these problems, Sonnet + Rubber Duck scores 3.8% higher than the Sonnet baseline, and 4.8% higher on the hardest problems identified across three trials. Here are a few examples of what Rubber Duck finds:
\n\n\n\ndict key on every iteration. Three of four Solr facet categories were being dropped from every search query, with no error thrown.GitHub Copilot can call Rubber Duck automatically, both proactively and reactively, and it can be triggered by a user at any time to critique and revise its work.
\n\n\n\nFor complex work, GitHub Copilot may seek a critique automatically at the checkpoints where feedback has the highest return:
\n\n\n\nThe agent can also seek a critique reactively if it gets stuck in a loop or can\u2019t make progress. Consulting Rubber Duck can break the logjam.
\n\n\n\nAs a user, you can request a critique at any point. Copilot will query Rubber Duck, reason over the feedback, and show you what changed and why.
\n\n\n\nWe made a key design choice: the agent invokes Rubber Duck sparingly, targeting the moments where the signal is highest, without getting in the way. For the technically curious: Rubber Duck is invoked through Copilot\u2019s existing task tool\u2014the same infrastructure used for other subagents.
\n\n\n\nFor now, we are enabling Rubber Duck for all Claude family models (Opus, Sonnet, and Haiku) used as orchestrators in the model picker. We are already exploring other model families for the Rubber Duck to pair with GPT-5.4 as the orchestrator.
\n\n\n\nRubber Duck is available today in experimental mode.
\n\n\n\nTo start using it, install GitHub Copilot CLI, and run the /experimental slash command. Rubber Duck will be available when you select any Claude model from the model picker and have access enabled to GPT-5.4. You\u2019ll see critiques surface in two ways:
Where Rubber Duck helps most:
\n\n\n\nRubber Duck in GitHub Copilot CLI is now available in experimental mode. Share your feedback with us in the discussion.
\nThe post GitHub Copilot CLI combines model families for a second opinion appeared first on The GitHub Blog.
\n","enclosure":{},"categories":["AI & ML","GitHub Copilot","AI agents","GitHub Copilot CLI"]},{"title":"The uphill climb of making diff lines performant","pubDate":"2026-04-03 16:00:00","link":"https://github.blog/engineering/architecture-optimization/the-uphill-climb-of-making-diff-lines-performant/","guid":"https://github.blog/?p=94994","author":"Luke Ghenco","thumbnail":"https://github.blog/wp-content/uploads/2026/04/3.png?resize=960%2C1340","description":"\nThe path to better performance is often found in simplicity.
\nThe post The uphill climb of making diff lines performant appeared first on The GitHub Blog.
\n","content":"\nPull requests are the beating heart of GitHub. As engineers, this is where we spend a good portion of our time. And at GitHub\u2019s scale\u2014where pull requests can range from tiny one-line fixes to changes spanning thousands of files and millions of lines\u2014the pull request review experience has to stay fast and responsive.
\n\n\n\nWe recently shipped the new React-based experience for the Files changed tab (now the default experience for all users). One of our main goals was to ensure a more performant experience across the board, especially for large pull requests. That meant investing in, and consistently prioritizing, the hard problems like optimized rendering, interaction latency, and memory consumption.
\n\n\n\nFor most users before optimization, the experience was fast and responsive. But when viewing large pull requests, performance would noticeably decline. For example, we observed that in extreme cases, the JavaScript heap could exceed 1 GB, DOM node counts surpassed 400,000, and page interactions became extremely sluggish or even unusable. Interaction to Next Paint (INP) scores (a key metric in determining responsiveness) were above acceptable levels, resulting in an experience where users could quantifiably feel the input lag.
\n\n\n\nOur recent improvements to the Files changed tab have meaningfully improved some of these core performance metrics. While we covered several of these changes briefly in a recent changelog, we\u2019re going to cover them in more detail here. Read on for why they mattered, what we measured, and how those updates improved responsiveness and memory pressure across the board and especially in large pull requests.
\n\n\n\nAs we started to investigate and plan our next steps for improving these performance issues, it became clear early on that there wouldn\u2019t be one silver bullet. Techniques that preserve every feature and browser-native behavior can still hit a ceiling at the extreme end. Meanwhile, mitigations designed to keep the worst-case from tipping over can be the wrong tradeoff for everyday reviews.
\n\n\n\nInstead of looking for a single solution, we began developing a set of strategies. We selected multiple targeted approaches, each designed to address a specific pull request size and complexity.
\n\n\n\nThose strategies focused on the following themes:
\n\n\n\nWith these strategies in mind, let\u2019s explore the specific steps we took to address these challenges and how our initial iterations set the stage for the improvements that followed.
\n\n\n\nWith our team\u2019s goal of improving pull request performance, we had three main objectives:
\n\n\n\nTo hit these goals, we focused on simplification: less state, fewer elements, less JavaScript, and fewer React components. Before we look at the results and new architecture, let\u2019s take a step back and look at where we started.
\n\n\n\nIn v1, each diff line was expensive to render. In unified view, a single line required roughly 10 DOM elements; in split view, closer to 15. That\u2019s before syntax highlighting, which adds many more <span> tags and drives the DOM count even higher.
The following is a simplified visual of the React Component structure mixed with the DOM tree elements for v1 diffs.
\n\n\n\n![\"V1](\"https://github.blog/wp-content/uploads/2026/04/3.png?resize=960%2C1340\")
At the React layer, unified diffs typically contain at least eight components per line, while the split view contain a minimum of 13. And these numbers represent baseline counts; extra UI states like comments, hover, and focus could add more components on top.
\n\n\n\nThis approach made sense to us in v1, when we first ported the diff lines to React from our classic Rails view. Our original plan centered around lots of small reusable React components and maintaining DOM tree structure.
\n\n\n\nBut we also ended up attaching a lot of React event handlers in our small components, often five to six per component. On a small scale, that was fine, but on a large scale that compounded quickly. A single diff line could carry 20+ event handlers multiplied across thousands of lines.
\n\n\n\nBeyond performance impact, it also increased complexity for developers. This is a familiar scenario where you implement an initial design, only to discover later its limitations when faced with the demands of unbounded data.
\n\n\n\nTo summarize, for every v1 diff line there would be:
\n\n\n\nThis v1 strategy proved unsustainable for our largest pull requests, as we consistently observed that larger pull request sizes directly led to slower INP and increased JavaScript heap usage. We needed to determine the best path for improving this setup.
\n\n\n\nNo change is too small when it comes to performance, especially at scale. For example, we removed unnecessary <code> tags from our line number cells. While dropping two DOM nodes per diff line might appear minor, across 10,000 lines, that\u2019s 20,000 fewer nodes in the DOM. These kinds of targeted, incremental optimizations, no matter how small, compound to create a much faster and more efficient experience. By not overlooking these details, we ensured that every opportunity for improvement was captured, amplifying the overall impact on our largest pull requests.
Refer to the images below to see how v1 looks compared to v2.
\n\n\n\n![\"V1](\"https://github.blog/wp-content/uploads/2026/04/Screenshot-2026-04-02-at-4.12.35-PM.png?resize=720%2C899\")
![\"V2](\"https://github.blog/wp-content/uploads/2026/04/Screenshot-2026-04-02-at-4.12.47-PM.png?resize=704%2C874\")
This becomes clearer if we look at the component structure behind this HTML:
\n\n\n\n![\"V1](\"https://github.blog/wp-content/uploads/2026/04/Screenshot-2026-04-02-at-4.13.00-PM.png?resize=681%2C1024\")
![\"V2](\"https://github.blog/wp-content/uploads/2026/04/Screenshot-2026-04-02-at-4.13.11-PM.png?resize=667%2C1024\")
We went from eight components per diff line to two. Most of the v1 components were thin wrappers that let us share code between Split and Unified views. But that abstraction had a cost: each wrapper carried logic for both views, even though only one rendered at a time. In v2, we gave each view its own dedicated component. Some code is duplicated, but the result is simpler and faster.
\n\n\n\nFor v2, we removed deeply nested component trees, opting for dedicated components for each split and unified diff line. While this led to some code duplication, it simplified data access and reduced complexity.
\n\n\n\nEvent handling is now managed by a single top-level handler using data-attribute values. So, for instance, when you click and drag to select multiple diff lines, the handler checks each event\u2019s data-attribute to determine which lines to highlight, instead of each line having its own mouse enter function. This approach streamlines both code and improves performance.
The most impactful change from v1 to v2 was moving app state for commenting and context menus into their respective components. Given GitHub\u2019s scale, where some pull requests exceed thousands of lines of code, it isn\u2019t practical for every line to carry complex commenting state when only a small subset of lines will ever have comments or menus open. By moving the commenting state into the nested components for each diff line, we ensured that the diff-line component\u2019s main responsibility is just rendering code\u2014aligning more closely with the Single Responsibility Principle.
\n\n\n\nIn v1, we gradually accumulated a lot of O(n) lookups across shared data stores and component state. We also introduced extra re-rendering through useEffect hooks scattered throughout the diff-line component tree.
To address this in v2, we adopted a two-part strategy. First, we restricted useEffect usage strictly to the top level of diff files. We also established linting rules to prevent the introduction of useEffect hooks in line-wrapping React components. This approach enables accurate memoization of diff line components and ensures reliable, predictable behavior.
Next, we redesigned our global and diff state machines to utilize O(1) constant time lookups by employing JavaScript Map. This let us build fast, consistent selectors for common operations throughout our codebase, such as line selection and comment management. These changes have enhanced code quality, improved performance, and reduced complexity by maintaining flattened, mapped data structures.
\n\n\n\nNow, any given diff line simply checks a map by passing the file path and the line number to determine whether or not there are comments on that line. An access might look like: commentsMap[\u2018path/to/file.tsx\u2019][\u2018L8\u2019]
Definitely. The page runs faster than it ever did, and JavaScript heap and INP numbers are massively reduced. For a numeric look, check out the results below. These metrics were evaluated on a pull request using a split diff setting with 10,000 line changes in the diff comparison.
\n\n\n\n| Metric | \nv1 | \nv2 | \n\nImprovement\u00a0 | \n
|---|---|---|---|
| Total\u00a0lines of\u00a0code\u00a0 | \n2,800 | \n2,000\u00a0 | \n27% less\u00a0 | \n
| Total\u00a0unique\u00a0component\u00a0types\u00a0 | \n19 | \n10\u00a0 | \n47% fewer\u00a0 | \n
| Total\u00a0components\u00a0rendered\u00a0 | \n~183,504 | \n~50,004\u00a0 | \n74% fewer\u00a0 | \n
| Total\u00a0DOM\u00a0nodes\u00a0 | \n~200,000 | \n~180,000\u00a0 | \n10% fewer\u00a0 | \n
| Total\u00a0memory\u00a0usage\u00a0 | \n~150-250 MB | \n~80-120 MB\u00a0 | \n~50% less\u00a0 | \n
| INP on\u00a0a\u00a0large\u00a0pull request\u00a0using\u00a0m1\u00a0MacBook pro with 4x slowdown:\u00a0 | \n~450 ms | \n~100 ms\u00a0 | \n~78%\u00a0faster\u00a0 | \n
As you can see, this effort had a massive impact, but the improvements didn\u2019t end there.
\n\n\n\nWhen you\u2019re working with massive pull requests\u2014p95+ (those with over 10,000 diff lines and surrounding context lines)\u2014the usual performance tricks just don\u2019t cut it. Even the most efficient components will struggle if we try to render tens of thousands of them at once. That\u2019s where window virtualization steps in.
\n\n\n\nIn front-end development, window virtualization is a technique that keeps only the visible portion of a large list or dataset in the DOM at any given time. Instead of loading everything (which would crush memory and slow things to a crawl), it dynamically renders just what you see on screen, and swaps in new elements as you scroll. This approach is like having a moving \u201cwindow\u201d over your data, so your browser isn\u2019t bogged down by off-screen content.
\n\n\n\nTo make this happen, we integrated TanStack Virtual into our diff view, ensuring that only the visible portion of the diff list is present in the DOM at any time. The impact was huge: we saw a 10X reduction in JavaScript heap usage and DOM nodes for p95+ pull requests. INP fell from 275\u2013700+ milliseconds (ms) to just 40\u201380 ms for those big pull requests. By only showing what\u2019s needed, the experience is much faster.
\n\n\n\nTo push performance even further, we tackled several major areas across our stack, each delivering meaningful wins for speed and responsiveness. By focusing on trimming unnecessary React re-renders and honing our state management, we cut down wasted computation, making UI updates noticeably faster and interactions smoother.
\n\n\n\nOn the styling front, we swapped out heavy CSS selectors (e.g. :has(...)) and re-engineered drag and resize handling with GPU transforms, eliminating forced layouts and sluggishness and giving users a crisp, efficient interface for complex actions.
We also stepped up our monitoring game with interaction-level INP tracking, diff-size segmentation, and memory tagging, all surfaced in a Datadog dashboard. This continues to give our developers real-time, actionable metrics to spot and squash bottlenecks before they become issues.
\n\n\n\nOn the server side, we optimized rendering to hydrate only visible diff lines. This slashed our time-to-interactive and keeps memory usage in check, ensuring that even huge pull requests feel fast and responsive on load.
\n\n\n\nFinally, with progressive diff loading and smart background fetches, users are now able to see and interact with content sooner. No more waiting for a massive number of diffs to finish loading.
\n\n\n\nAll together, these targeted optimizations made our UI feel lighter, faster, and ready for anything our users throw at it.
\n\n\n\nThis exciting journey to streamline the diff line architecture yielded substantial improvements in performance, efficiency and maintainability. By reducing unnecessary DOM nodes, simplifying our React component tree, and relocating complex state to conditionally rendered child components, we achieved faster rendering times and lower memory consumption. The adoption of more O(1) data access patterns and stricter rules for state management further optimized performance. This made our UI more responsive (faster INP!) and easier to reason with.
\n\n\n\nThese measurable gains demonstrate that targeted refactoring, even within our large and mature codebase, can deliver meaningful benefits to all users\u2014and that sometimes focusing on small, simple improvements can have the largest impact. To see the performance gains in action, go check out your open pull requests.
\n\nThe post The uphill climb of making diff lines performant appeared first on The GitHub Blog.
\n","enclosure":{},"categories":["Architecture & optimization","Engineering","diffs","performance engineering","pull requests"]}]}