GitHub

88 posts

github.blog/engineering

Filter by tag

github3 min readCurated summary

Getting more from each token: How Copilot improves context handling and model routing

GitHub is improving Copilot’s efficiency by optimizing both how context is handled and which model performs each task. Prompt caching and deferred tool loading reduce repeated overhead in long agentic sessions, while Auto selects models based on task complexity and real-time system conditions. The goal is to preserve quality while using tokens, compute, and cost more intelligently. ## Prompt Caching and Deferred Tools - Copilot sessions repeatedly include instructions, repository context, conversation history, tool definitions, and task state. - Prompt caching allows repeated prompt prefixes to reuse model state instead of being recomputed on every request. - Tool search loads tool definitions only when needed, rather than placing every full schema into context on every turn. - This is especially valuable for sessions involving MCP tools, terminal commands, file operations, workspace search, and other actions. - The approach reduces fixed per-turn overhead while preserving access to a broad toolset. ## Auto Model Selection - Copilot Auto chooses a model based on the task rather than requiring developers to select one manually. - Quick explanations, focused edits, and complex multi-file changes often benefit from different levels of reasoning. - Evaluations found that no single model consistently performs best across all tasks. - Auto uses more efficient models when they can achieve comparable results and selects stronger reasoning models when the task demands them. - The objective is not simply lower cost, but matching model capability to the work. ## How Auto Routes Tasks Auto combines two signals: - **Real-time model health** - Considers availability, utilization, response speed, error rates, and cost. - Avoids selecting a model that is technically capable but currently overloaded or unreliable. - **Task-aware routing with HyDRA** - Evaluates reasoning depth, code complexity, debugging difficulty, and tool-orchestration requirements. - Identifies models capable of meeting the task’s quality threshold, then chooses the best fit among them. - The system can be tuned toward maximum quality or greater cost savings. ## Cache-Aware Routing - Switching models during every turn can reduce efficiency by invalidating cached prompt prefixes. - Auto therefore keeps the same model during a conversation so the cache can continue building. - It changes models at natural cache boundaries: - The first turn, when no cache exists yet. - After context compaction, when older turns are summarized and the prompt prefix resets. ## Multilingual Routing - Copilot’s routing system was trained on conversations spanning 16 language families, including CJK and European languages. - Evaluations covered production VS Code chat data across 19 languages. - Routing accuracy remained within four points of the English baseline across language groups. - No statistically significant quality gap was observed between the language groups. Copilot’s efficiency strategy combines smarter context management with adaptive model selection. Caching and on-demand tools reduce repeated work, while cache-aware Auto routing chooses an appropriate model without unnecessarily sacrificing quality or session efficiency.

Read original(opens in new tab)
github2 min readCurated summary

What are git worktrees, and why should I use them?

Git worktrees let developers check out multiple branches simultaneously in separate directories, avoiding the stash-and-switch cycle. They preserve editor state, reduce context-switching friction, and make parallel work—especially AI-assisted development—much easier. Their main drawbacks are dependency duplication, folder cleanup, and restrictions on checking out the same branch twice. ## Switching Contexts with Branches and Stashing - Traditional urgent-work flow often requires: - Stashing unfinished changes. - Checking out and updating `main`. - Creating a hotfix branch. - Committing, pushing, and merging the fix. - Returning to the original branch and restoring the stash. - This process creates mental overhead and may involve reloading files, reinstalling dependencies, or resolving stash conflicts. - Some developers compensate with multiple repository clones or increasingly complex stash commands. ## Working in Parallel with Worktrees - A worktree creates another working directory connected to the same Git repository: ```bash git worktree add ../hotfix-workspace -b hotfix-bug main ``` - The original feature branch and editor remain untouched while the hotfix is developed in a separate folder. - After merging, the temporary worktree can be removed: ```bash git worktree remove ../hotfix-workspace ``` - Worktrees eliminate stash conflicts and support truly parallel development. - Tools such as VS Code provide built-in worktree support. ## Why Worktrees Are More Popular Now - Worktrees have existed since 2015 but were historically overlooked because Git GUIs offered limited support. - Developers increasingly run multiple tasks, coding sessions, reviews, and AI agents simultaneously. - Modern tools, including the GitHub Copilot app, use worktrees as a default way to isolate parallel sessions. ## Limitations to Consider - **Dependency bloat:** Each worktree may contain its own `node_modules`, Python packages, or other dependencies. - **Folder management:** Temporary worktrees must be deleted to prevent clutter. - **`.gitignore` concerns:** Worktrees created inside the repository may need to be ignored; placing them outside the repository avoids this issue. - **One-branch restriction:** Git prevents the same branch from being checked out in multiple worktrees simultaneously. ## Worktrees in the GitHub Copilot App - New Copilot sessions can be created in a new worktree by default. - The app displays the generated worktree name, location, associated project, and changes. - Worktree management is integrated into the session workflow. Worktrees are especially useful for parallel development and AI-assisted workflows, but they are not mandatory. Developers can use worktrees, traditional branching and stashing, or a combination depending on their workflow and resource constraints.

Read original(opens in new tab)
github2 min readCurated summary

GitHub Copilot CLI for Beginners: Overview of common slash commands

GitHub Copilot CLI’s slash commands provide a central way to control sessions directly from the terminal. They help users select models, manage context, inspect changes, switch projects, resume work, and control permissions. The article recommends typing `/` to explore the available commands and build a more deliberate CLI workflow. ## Slash Commands as Copilot CLI Controls - Slash commands are built-in terminal controls for: - Guiding Copilot’s behavior - Inspecting project changes - Managing conversation context - Moving between sessions and repositories - Resetting tool permissions - Typing `/` displays a scrollable list of supported commands. ## Selecting a Model - `/model` opens the list of available models. - Model information includes: - Capabilities for lightweight tasks or deeper reasoning - Availability based on the user’s plan or organization - Cost multipliers indicating relative usage cost - Choosing an appropriate model can balance speed, quality, and cost. ## Managing Context and Tokens - `/context` shows remaining tokens, system usage, and available buffer. - `/compact` summarizes the current conversation to free context space without starting over. - Copilot may compact automatically near the context limit, but users can trigger it manually when changing tasks. - `/clear` completely resets the current session. ## Resuming Previous Sessions - `/resume` lists earlier local and remote sessions. - Users can select a session to review its history and continue where they left off. ## Reviewing Changes - `/diff` displays recent modifications made during the session. - This helps users inspect and validate Copilot’s changes before proceeding. ## Switching Projects - `/cwd` changes Copilot’s current working directory. - It allows users to move between repositories or project directories without exiting the CLI. ## Resetting Permissions - `/reset-allowed-tools` removes previously granted permissions for actions such as editing files. - This is useful when switching to a repository that requires more cautious access controls. Users should start by typing `/` in Copilot CLI to discover available commands, then use commands such as `/model`, `/context`, `/compact`, `/diff`, and `/cwd` to maintain control over their coding sessions.

Read original(opens in new tab)
github3 min readCurated summary

Accelerating researchers and developers building multilingual AI with a new open dataset

GitHub has released the GitHub Multilingual Repositories Dataset, an open metadata resource for finding public repositories containing non-English developer content. Covering more than 40 million repositories, it classifies language use in READMEs, issues, and pull requests, helping researchers build multilingual AI tools and study representation in open source. GitHub emphasizes that the dataset is a discovery tool—not definitive language ground truth—and releases it under CC0-1.0. ## Dataset Scope and Contents - Contains over 80 million classification rows across more than 40 million public repositories. - Classifies: - READMEs - The most-commented issue - The most-commented pull request - Uses the first 150 characters of each text source, excluding samples shorter than 20 characters. - Includes classifications and confidence scores from: - fastText - Google’s CLD3 - lingua-py - Only classifications with confidence above 0.5 are included. - Repository metadata includes creation date, disk usage, stars, forks, primary language, SPDX license, issue and pull request counts, and snapshot date. ## Why Multiple Classifiers Are Exposed - GitHub does not combine the three classifiers into one definitive language label. - Classifiers differ in language coverage and confidence calibration, particularly for lower-resource languages. - Users can choose their own precision and recall strategy: - Require agreement among all classifiers for high-precision research. - Use a single classifier for broader exploratory studies. ## Language Patterns in Developer Content - Language distribution varies by repository content type. - Korean is the most common non-English language in issue text but ranks only fifth in README classifications. - Portuguese is the leading non-English README language, appearing in more than 3 million repositories. - These differences show that developer communities may use different languages for documentation, issue discussions, and code collaboration. ## Potential Applications - Find repositories with documentation or collaboration in particular languages. - Study how multilingual communities use READMEs, issues, and pull requests. - Create evaluation datasets for coding assistants, documentation generators, and code review tools. - Measure representation of European and other underrepresented languages in open source. - Provide evidence for expanding language support in developer tools and AI systems. ## Limitations and Responsible Use - Repository text is often short and may contain badges, commands, code, usernames, templates, or multiple languages. - A 150-character sample may not represent the language of an entire repository. - Classifier performance varies, especially for lower-resource languages. - The dataset should not be treated as a ground-truth language-identification benchmark. - It provides repository-level signals and should not be used to infer sensitive characteristics of repository owners, contributors, or communities. ## Importance for Multilingual AI - Many European languages are underrepresented in the data used to train and evaluate AI systems. - Developer content provides domain-specific examples of software collaboration, including installation guidance, bug reports, feature requests, and code reviews. - The dataset can help identify language gaps, improve evaluation, and support more inclusive AI tools for developers worldwide. GitHub recommends using the CC0-licensed dataset to conduct research, build evaluation sets, develop tools, and improve its classifications. Its transparency and multiple confidence signals allow users to tailor the data to their own research needs while accounting for its limitations.

Read original(opens in new tab)
github3 min readCurated summary

How we made GitHub Copilot CLI more selective about delegation

GitHub improved Copilot CLI by making subagent delegation more selective rather than treating delegation as inherently beneficial. The new orchestration policy keeps narrow tasks with the main agent, delegates broad or independent work, and encourages parallel execution instead of waiting. After full production rollout, it reduced tool failures by 23% and improved high-percentile wait times without reducing quality. ## The Cost of Unnecessary Delegation - Subagents help with complex investigations, large repositories, and parallel work, but every handoff adds tool calls, coordination, and latency. - Copilot sometimes delegated simple, well-scoped tasks that the main agent could complete directly. - Common problems included: - Repeated or overlapping repository searches. - Subagents re-discovering context already available to the main agent. - Sequential delegation that left the main agent idle. - Stale paths, incorrect relative paths, and workspace mismatches. - The result was slower execution and more tool failures for tasks that should have required only a few steps. ## How the Problem Was Identified - GitHub used LLMs to analyze complete agent trajectories rather than manually reviewing sessions. - The analysis found that delegation was frequently used for narrow, obvious, or fully described tasks. - This led to a clear target: - Keep focused discovery-and-edit work with the main agent. - Reserve subagents for broad exploration, cross-cutting tasks, or genuinely independent work. ## A More Selective Orchestration Policy - Copilot now starts with the narrowest effective workflow: - Find and read the relevant file. - Make the targeted change. - Verify the result. - Delegation becomes appropriate when additional context, uncertainty, or parallel execution creates real value. - Subagents are treated as a parallelism mechanism, not a reason for the main agent to pause. - Handoffs should clearly specify: - The user’s request. - What the main agent already knows. - Which work the subagent owns. - What result the subagent should return. ## Evaluation and Production Results - GitHub tested the change with generated regression cases and existing benchmarks before rollout. - Staff and public A/B tests measured reliability, responsiveness, subagent workload, and quality. - Production results showed: - 23% fewer tool failures per session. - 27% fewer search-tool failures. - 18% fewer edit-tool failures. - 5% lower P95 wait time. - 3% lower P75 wait time. - No quality regression. - The improvements came mainly from avoiding unnecessary subagent paths and reducing orchestration overhead, not from making individual model calls faster. Copilot CLI users can access the improvement by running `/update` and upgrading to version 1.0.42 or later. The broader recommendation is to delegate selectively: use the main agent for focused tasks and subagents only when independent context or parallel work provides meaningful leverage.

Read original(opens in new tab)
github1 min readCurated summary

Making secret scanning more trustworthy: Reducing false positives at scale

Mariko is a Principal Applied Scientist at Microsoft who leads the development of agentic AI workflows for cybersecurity operations. Her work centers on using large language models and agentic systems to bring frontier AI research into practical products and operational environments. ## Professional Role - Principal Applied Scientist at Microsoft. - Leads agentic AI workflow development for cybersecurity operations. ## Research and Technical Focus - LLM-powered systems. - Agentic workflows. - Applying frontier AI research to real-world products and operations. Overall, Mariko’s work connects advanced AI research with practical cybersecurity and enterprise applications.

Read original(opens in new tab)
github3 min readCurated summary

Give GitHub Copilot CLI real code intelligence with language servers

GitHub Copilot CLI can understand code far more accurately when connected to a Language Server Protocol (LSP) server. Without LSP, it relies on grep, package-directory browsing, and bytecode extraction, which can miss types, overloads, and dependencies. The LSP Setup skill automates server installation and configuration for 14 languages, giving the CLI capabilities such as type resolution, go-to-definition, and reference search. ## The Problem with Heuristic Code Understanding - Without an LSP server, Copilot CLI may: - Extract Java JAR files and grep through `.class` files. - Read installed Python packages directly. - Search through TypeScript’s `node_modules`. - These approaches use text and pattern matching rather than semantic analysis. - They often fail to correctly understand: - Generics and overloads. - Transitive types. - Compiled dependencies. - Exact method signatures and symbol relationships. - LSP requests such as `textDocument/definition` return precise source locations, resolved types, and signatures. ## How the LSP Setup Skill Works The skill automates a seven-step process: - **Language selection:** Uses `ask_user` to determine the required language. - **Operating system detection:** Identifies macOS, Linux, or Windows so it can choose the correct installation commands. - **Server lookup:** Reads curated data for 14 languages from `references/lsp-servers.md`. - **Configuration scope:** Supports: - User-wide configuration at `~/.copilot/lsp-config.json`. - Repository-specific configuration at `lsp.json` or `.github/lsp.json`. - Repository configuration takes precedence. - **Installation:** Runs the appropriate package-manager or platform-specific command, such as: - `npm install -g typescript typescript-language-server` - `brew install jdtls` - `rustup component add rust-analyzer` - **Configuration:** Adds a server under the `lspServers` object, mapping commands and file extensions to language identifiers. - **Verification:** Confirms the executable is on `PATH` and checks that the configuration is valid JSON. The skill merges new settings with existing configuration instead of overwriting other servers. It also accounts for transport differences, such as servers requiring `--stdio`. ## Supported Languages and Custom Setup - The skill provides predefined installation and configuration details for 14 languages. - If a language is not included, Copilot CLI can search for a suitable server and guide the user through manual configuration. - Each server configuration specifies: - The executable command. - Optional arguments. - File-extension mappings such as `.java` to `java`. ## Benefits After Configuration With LSP enabled, Copilot CLI can: - Resolve types across external dependencies. - Jump to definitions in third-party libraries. - Find every reference to a symbol. - Display hover documentation for functions, classes, and types. - Reduce unnecessary tool calls and avoid incorrect assumptions about APIs. - Handle larger and more complex coding tasks with IDE-like semantic understanding. ## Getting Started - Download the LSP Setup skill from the Awesome Copilot project. - Extract it into `~/.copilot/skills/`. - Restart Copilot CLI. - Ask the agent to set up LSP for a language, such as Java or Python. - Restart the CLI again, run `/lsp`, and test navigation on a dependency symbol. The practical recommendation is to configure an LSP server for each language used in a project. The setup gives Copilot CLI structured code intelligence instead of forcing it to reconstruct APIs through text searches and binary inspection.

Read original(opens in new tab)
github2 min readCurated summary

From one-off prompts to workflows: How to use custom agents in GitHub Copilot CLI

Custom agents in GitHub Copilot CLI turn repeated terminal tasks into reusable, consistent workflows. Defined as Markdown profiles in a repository, they encode team-specific expertise, tools, standards, and safety rules instead of relying on one-off prompts. This makes workflows easier to review, version, share, and reuse across the CLI, IDE, and GitHub. ## What Custom Agents Are - A custom agent is a specialized Copilot agent configured through a Markdown file. - Its profile specifies: - Role and area of expertise - Available tools - Required standards and procedures - Guardrails and expected output formats - Teams can tailor agents to requirements such as: - WCAG accessibility standards - Formatting and testing conventions - Security and privacy policies - Review and ownership requirements - Because profiles live in the repository, they can be versioned, reviewed, and shared like code. ## Creating and Using Agents in Copilot CLI - Invoke Copilot CLI from the terminal and use the `/agent` command to select an agent. - Store the profile in the repository’s `.github/agents` directory. - Agent files use YAML frontmatter and typically end in `.agent.md`, such as `accessibility.agent.md`. - The profile defines the agent’s name, description, model, tools, instructions, scope, and guardrails. - Copilot CLI is especially suitable for these agents because it can execute scripts, call APIs, inspect repositories, and work directly with command-line tooling. ## Automating Repeated Workflows Custom agents are most useful for recurring tasks that span the terminal, IDE, and pull requests. - A security audit agent can: - Run standard checks across repositories - Group findings by Critical, High, Medium, and Low severity - Produce a pull-request-ready checklist with owners and next steps - It can use tools such as `gitleaks`, `trivy`, `semgrep`, `gh`, `git`, and `jq`. - Agents should prefer existing repository configuration files, including `.semgrep.yml`, `.trivyignore`, and `.gitleaks.toml`. - Missing security tools should be reported as coverage gaps rather than replaced with invented results. - Instructions can require secrets to be redacted, inclusive terminology, and consistent date formats. - Ownership mappings can assign findings to teams based on affected paths, using `CODEOWNERS` when available or defined defaults otherwise. Custom agents provide a practical way to capture team expertise once and apply it consistently. Start by converting a repetitive, execution-heavy task into a narrowly scoped `.github/agents` profile with explicit tools, outputs, and safety rules.

Read original(opens in new tab)
github2 min readCurated summary

GitHub for Beginners: Answers to some common questions

The post is a beginner-friendly guide to common GitHub questions, focusing on SSH authentication and Personal Access Tokens (PATs). It explains how to securely connect a computer to GitHub, create credentials for command-line and API access, and limit those credentials appropriately. The provided excerpt ends just as it introduces merging versus rebasing. ## SSH Keys and GitHub Authentication - An SSH key consists of: - A private key that stays on the computer and must never be shared. - A public key uploaded to GitHub. - Git uses the matching key pair to verify identity when pushing and pulling code. - To create an Ed25519 key pair, run `ssh-keygen` with the email associated with the GitHub account. - Users can accept the default file location and protect the key with a passphrase. - `ssh-agent` securely stores the key so the passphrase does not need to be entered repeatedly. - The public key can be copied with `cat ~/.ssh/id_ed25519.pub` and added through **Settings → SSH and GPG keys → New SSH key**. - A descriptive title, such as “work-laptop,” helps identify the device later. ## Personal Access Tokens - A PAT is a GitHub-managed credential for authenticating command-line tools and API requests. - Tokens can be revoked and configured with limited permissions. - GitHub offers: - **Fine-grained tokens**, which can be restricted to specific repositories and individual read or write permissions. - **Classic tokens**, which use broader predefined scopes. - When creating a fine-grained token, users choose: - A name and description. - An expiration date. - Repository access. - Specific permissions and whether each is read-only or read/write. - Classic tokens are created through **Developer settings → Personal access tokens → Tokens (classic)** and use scopes to define access. - GitHub displays a token only once, so it should be copied immediately and stored securely, such as in a password manager. - A PAT can be supplied instead of a password when Git prompts for credentials in a terminal. ## Merging and Rebasing - The excerpt begins introducing the difference between merging and rebasing and how to resolve merge-related problems. - The supplied content ends before that explanation is provided. Use SSH keys for secure Git operations from a trusted device, and use narrowly scoped, expiring PATs when tools or APIs require token-based authentication. Never share private keys or tokens, and store credentials securely.

Read original(opens in new tab)
github3 min readCurated summary

GitHub for Beginners: Getting started with Git and GitHub in VS Code

VS Code provides an integrated way to manage Git and GitHub without leaving the editor, reducing context switching and simplifying common version-control tasks. The post walks beginners through initializing a repository, staging and committing files, creating branches, tracking edits, and reviewing diffs. It emphasizes that Git manages source code locally, while GitHub hosts repository copies remotely. ## Git, GitHub, and VS Code - **Git** is the program used to manage source code and version history. - **GitHub** hosts copies of Git repositories. - **VS Code** uses Git to provide a graphical workflow for managing code and synchronizing it with GitHub. - Following along requires installing both Git and VS Code. ## Initializing a Repository - Open a project folder in VS Code through the **Explorer** panel. - Select **Source Control** and click **Initialize Repository**. - VS Code creates a local Git repository, initially using the `main` branch. - The branch can be renamed through the Command Palette: - macOS: `Shift-Command-P` - Windows/Linux: `Ctrl-Shift-P` - Choose **Git: Rename Branch**. ## Staging and Committing Files - Newly detected files appear with a **U**, meaning “untracked.” - Click the plus sign beside a file—or beside **CHANGES** to stage everything. - Staged files receive an **A** indicator. - Enter a commit message in the Source Control panel and click **Commit**. - Git commits changes locally; they are not uploaded to GitHub until they are pushed. ## Creating and Switching Branches - Use the Command Palette and select **Git: Create Branch…**. - Enter a branch name such as `new-features`. - VS Code creates the branch and automatically switches to it. - The active branch is displayed in the bottom-left status bar. - Branches allow developers to work on features separately from `main`. ## Understanding Change Indicators VS Code displays edits directly in the editor gutter: - A green line marks newly added code. - A blue patterned line marks modified existing code. - A red arrow marks deleted code. - Modified files appear under **CHANGES** in the Source Control panel. - Hovering over a file provides controls to open it, discard changes, or stage it. - The **CHANGES** header also provides actions for reviewing, discarding, or staging changes across all files. ## Reviewing Diffs - Clicking a changed file opens a side-by-side comparison of the current and previous versions. - The diff menu’s **Inline View** option displays changes in a single editor pane. - Inline diffs can also be edited directly, allowing corrections before staging or committing. VS Code’s Source Control integration gives beginners a practical, visual workflow for Git. A typical process is to initialize a folder, create a working branch, inspect edits, stage selected files, commit them with a descriptive message, and then push the commits to GitHub.

Read original(opens in new tab)
github3 min readCurated summary

GitHub recognized as a Leader in the Gartner® Magic Quadrant™ for Enterprise AI Coding Agents for the third year in a row

GitHub argues that AI coding has made code generation easier, shifting the main bottleneck to reviewing, securing, governing, and deploying software. It presents GitHub Copilot as an agentic platform spanning the full software development lifecycle, enabling developers to assign issues to agents and focus on reviewing and approving results. Gartner named GitHub a Leader in the 2026 Magic Quadrant for Enterprise AI Coding Agents, placing it highest for ability to execute for the third consecutive year. ## The Shift from Code Generation to Software Delivery - AI coding agents are increasingly expected to handle more than writing functions. - The harder problems now involve: - Code review - Security - Governance - Testing - Deployment - GitHub describes the new workflow as “orchestrating outcomes”: developers assign work to agents, then return to steer, review, and approve it. - Gartner projects that asynchronous AI coding-agent workflows could improve engineering productivity by 30%–50% by 2028, compared with 0%–20% gains from code assistants in 2025. ## Enterprise Adoption of GitHub Copilot - Copilot is used by 140,000 organizations, nearly three times the number reported a year earlier. - Overall growth exceeded 100% year over year. - Most users work with multiple AI models. - GitHub Copilot CLI usage nearly doubled month over month. - GitHub says these figures indicate that enterprises are adopting increasingly sophisticated, agent-driven workflows. ## Gartner’s 2026 Evaluation - Gartner evaluated 12 enterprise AI coding-agent vendors according to: - Ability to execute - Completeness of vision - GitHub was positioned as a Leader and ranked highest in ability to execute. - Gartner describes Leaders as vendors combining strong execution, market-shaping vision, rapid innovation, broad software-engineering relevance, and enterprise-grade security and governance. - The report’s Leader quadrant also includes Anthropic, Cursor, and OpenAI. ## GitHub’s Claimed Differentiators - **Developer choice:** Copilot supports multiple models and providers. - **Broad availability:** It works across editors, IDEs, CLIs, and GitHub’s web, desktop, and mobile applications. - **Full-lifecycle integration:** Copilot operates across issues, pull requests, code reviews, and GitHub Actions—not only inside the editor. - **Enterprise governance:** Teams can observe, audit, and secure how AI is used in engineering workflows. ## What GitHub Plans to Build Next - GitHub says it will expand agentic workflows across more developer-facing surfaces. - Planned investments include: - Greater model choice and intelligent model routing - Deeper integrations throughout the software lifecycle - Performance improvements based on how software is actually built and maintained on GitHub GitHub’s central recommendation is to treat AI coding agents as part of an end-to-end engineering platform rather than isolated code-generation tools. The post also notes that Gartner’s recognition is not an endorsement and that its findings should be considered alongside the full research report.

Read original(opens in new tab)
github1 min readCurated summary

Investigating unauthorized access to GitHub-owned repositories

Alexis Wales is GitHub’s Chief Information Security Officer, responsible for protecting the platform, its products, and the open source community. With two decades of experience defending critical networks, she combines public- and private-sector expertise to address major cybersecurity challenges affecting modern technology. ## Leadership at GitHub - Leads a team of security professionals at GitHub. - Focuses on safeguarding GitHub’s platform and products. - Supports more than 150 million developers building and deploying software securely. - Helps protect the broader open source community. ## National Cybersecurity Experience - Has 20 years of experience defending critical national and private-sector networks. - Previously worked with the Department of Defense. - Served at the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA). ## Public-Private Collaboration - Her government experience shaped a strong interest in cooperation between public and private organizations. - Advocates collaboration to solve complex security threats affecting widely used technology. Overall, Wales’s work combines large-scale platform security with cross-sector cooperation to strengthen cybersecurity for developers and the broader technology ecosystem.

Read original(opens in new tab)
github3 min readCurated summary

Building a general-purpose accessibility agent—and what we learned in the process

GitHub is piloting a general-purpose accessibility agent that answers accessibility questions and automatically fixes straightforward issues in front-end code. The agent has reviewed 3,535 pull requests and resolved 68% of identified issues, especially problems involving structure, control names, status messages, text alternatives, and keyboard focus. GitHub’s experience shows that an accessibility agent is most effective as an augmentation of human expertise, supported by a strong foundation of manually documented accessibility work. ## Goals and Results - The agent serves two purposes: - Provide just-in-time accessibility guidance through GitHub Copilot CLI and VS Code. - Detect and automatically remediate simple, objective accessibility issues before production. - It evaluates pull requests that modify front-end code. - Its five most common issue categories are: - Making structure and relationships understandable to assistive technologies. - Giving interactive controls clear, concise names. - Ensuring users receive important status announcements. - Providing text alternatives for non-text content. - Maintaining a logical keyboard focus order. - Example fixes can identify mismatches between visual order and screen-reader reading order, then suggest code changes that developers can commit directly. ## An Augmenting, Not Universal, Tool - GitHub frames accessibility through the social model of disability: barriers are often created by how digital environments are designed and built. - The agent is intended to help engineers remove those barriers, not “solve” accessibility independently. - It is not a silver bullet capable of handling every accessibility scenario. - Clearly limiting its responsibility helped GitHub launch the experiment more quickly and gain broader internal support. ## Why Manual Accessibility Work Matters - New and upcoming regulations, including the European Accessibility Act and the Americans with Disabilities Act’s planned WCAG 2.1 AA requirements, increase the importance of accessibility investment. - Organizations without established processes for manually identifying and fixing accessibility problems will be at a disadvantage. - GitHub already had a mature issue-management process containing: - Structured problem reports. - Reproduction steps. - Severity, service-area, and WCAG metadata. - Links to fixing pull requests. - Acceptance criteria. - Centralizing these issues in one repository made the collection a valuable reference corpus for the agent. ## Using Historical Issues as Training Material - The agent examines past accessibility issues and related pull requests to find applicable code and language patterns. - LLMs’ fuzzy matching can be useful here because it helps connect new problems with similar historical examples. - Generic instructions such as “follow accessibility best practices” are insufficient. - LLMs often reproduce accessibility antipatterns because their training data contains decades of inaccessible code. - Manually cataloged issues and organization-specific fixes provide contextual examples that are more useful than short, generic accessibility checklists. GitHub’s experience suggests that teams should first build reliable human processes for reporting and remediating accessibility issues. Once that structured knowledge exists, an agent can help apply it consistently and efficiently—while remaining a complement to, rather than a replacement for, accessibility expertise.

Read original(opens in new tab)
github3 min readCurated summary

Raising the bar: Quality, shared responsibility, and the future of GitHub’s bug bounty program

GitHub is reaffirming its commitment to external security researchers while tightening bug bounty submission standards. Rising report volumes—partly driven by AI and other tools—have increased both valuable findings and unvalidated noise. GitHub’s central message is that tools are welcome, but researchers remain responsible for validating vulnerabilities, demonstrating impact, and understanding the platform’s shared security boundaries. ## Rising Submission Volume - New tools, including AI, have lowered the barrier to security research and expanded the number of people examining attack surfaces. - GitHub has also seen more reports that: - Lack a working proof of concept - Describe only theoretical attack scenarios - Concern categories already listed as ineligible - Because this challenge affects the wider industry, some bug bounty programs have shut down; GitHub instead plans to improve its program. ## Requirements for Strong Reports - Submissions must include a working proof of concept demonstrating concrete security impact. - Researchers should show what an attacker can actually accomplish, rather than merely describing a possible attack path. - Reports must respect GitHub’s published scope and ineligible findings list. Examples of generally ineligible issues include: - DMARC, SPF, or DKIM configuration problems - User enumeration - Missing security headers without a demonstrated attack path - Scanner, static-analysis, or AI-generated findings must be manually validated before submission. - Unverified false positives create unnecessary triage work and may affect a researcher’s HackerOne Signal and reputation. ## AI Is Welcome, but Validation Is Required - GitHub supports the use of AI in security research and uses AI internally. - AI-assisted reports are acceptable when findings are reproduced, verified, and supported by a working proof of concept. - Researchers remain accountable for the accuracy of their submissions, regardless of which tools produced them. - GitHub recommends a concise report structure: - A short issue summary - Clear reproduction steps and evidence, such as screenshots, HTTP requests, or terminal output - An impact statement explaining what an attacker can achieve - Lengthy theoretical explanations and AI-generated filler can obscure the actual vulnerability and slow triage. ## Shared Responsibility and GitHub’s Security Boundary - GitHub protects users through automated scanning, manual review, and other systems for detecting malicious content. - Users are still responsible for deciding what repositories, issues, code, and scripts to trust. - Users should review content before executing or interacting with it. - Cloning a repository is considered an act of trust because Git hooks, build scripts, and other automation may run locally. - Users must also secure their own environments, including tokens, credentials, and local security settings. - Scenarios generally do not bypass GitHub’s security controls when they require victims to deliberately engage with attacker-controlled content. ## Common Shared-Responsibility Scenarios - Prompt injection in content a user intentionally provides to an AI tool - Git hooks or filters executing code from a repository the user checked out - Malicious content in a repository the user chose to clone - Unexpected LLM output caused by untrusted input supplied by the user Research into these areas remains useful when it identifies a way to bypass an actual GitHub security control without requiring the user to actively trust malicious content.

Read original(opens in new tab)
github1 min readCurated summary

From latency to instant: Modernizing GitHub Issues navigation performance

Alexander is a senior software engineer on GitHub’s Issues team, where he focuses on making developer workflows feel fast and seamless. His background spans computer graphics, machine learning, and geospatial software, giving him a broad technical perspective. ### Professional Role - Works on the GitHub Issues team. - Focuses on improving everyday developer workflows. - Enjoys finding creative ways to make interactions feel instant. ### Technical Background - Computer graphics - Machine learning - Geospatial software The provided content is a short professional biography rather than a technical blog post, so it does not include a specific argument, technical explanation, or conclusion.

Read original(opens in new tab)