GitHub

88 posts

github.blog/engineering

Filter by tag

Github Copilot33 Github24 AI Agents21 GitHub Actions16 Github Copilot Cli15 CI/CD12 Model Context Protocol12 Large Language Models9 Pull Requests8 Code Review8 Open Source7 AI5+261

githubJul 22, 20262 min readCurated summary

Next chapter: Restructuring GitHub’s bug bounty program

GitHub is restructuring its bug bounty program to prioritize high-quality, high-impact security research over report volume. The changes introduce a permanent VIP program with higher rewards and faster support, reduce and simplify public-program payouts, and add submission limits for researchers without an established track record. Reports submitted before July 27, 2026 will remain under the previous terms. ## Permanent VIP program for top researchers GitHub is creating a private, invite-only program for researchers who consistently produce valuable findings. - VIP researchers receive: - Higher payouts - Faster response times - Closer collaboration with GitHub’s security engineering team - VIP bounty payouts are: - Low: $1,000 - Medium: $7,500 - High: $20,000 - Critical: $30,000+ - Researchers can qualify by achieving at least one of the following: - One critical finding - Two high-severity findings - Four medium-severity findings - Seven low-severity findings - The program emphasizes quality and impact rather than the number of submissions. ## Restructured public bounty payouts GitHub is replacing variable payout ranges with fixed amounts to make rewards more predictable and reduce administrative overhead. - New public-program payouts: - Low: $250 - Medium: $2,000 - High: $5,000 - Critical: $10,000 - GitHub may still provide discretionary bonuses for exceptional work. - The public program will remain an entry point for new researchers and a pathway into the VIP program. ## Higher submission standards To address increasing report volume, including low-effort and AI-generated submissions, GitHub is adding a HackerOne signal requirement. - Researchers below the required signal threshold will have a limited number of submissions. - New researchers can make up to four initial submissions while establishing credibility. - The goal is to reduce noise without excluding legitimate newcomers. ## Existing commitments and transition period GitHub says it will continue paying quickly, communicating clearly, and treating researchers as security partners. - Reports submitted before the changes take effect will follow the old bounty structure. - Reports submitted on or after July 27, 2026 will use the new rules. - GitHub also plans to improve response times, severity explanations, and community engagement through conferences and outreach. The restructuring is designed to make GitHub’s bug bounty program more sustainable while directing greater rewards and attention toward researchers who deliver deep, thoughtful security work.

Vulnerability Management Application Security Bug Bounty Hackerone+2

githubJul 21, 20262 min readCurated summary

How to build interactive experiences with canvases

Canvases extend GitHub Copilot beyond text-based conversations by providing shared, interactive workspaces where developers and agents can visualize information and take action together. They are useful for tasks such as triaging issues, exploring code architecture, managing worktrees, and searching organizational knowledge. The article concludes that canvases make AI workflows more engaging, practical, and easier to iterate on. ## How canvases work - Canvas extensions are interactive surfaces within the GitHub Copilot app. - Agents can update the canvas while users interact through clicks, edits, swipes, and other controls. - User actions may be sent back to the agent or handled locally. - Developers create one by running `/create-canvas` in a Copilot agent session and describing the desired interface and capabilities. - Canvases can evolve through follow-up prompts that add features or refine existing behavior. ## Visual issue triage - A card-based interface displays GitHub Issues one at a time. - Users swipe right to ship an issue or left to reject it. - The canvas updates immediately, organizing issues into decision-based categories. - This replaces a slower, text-heavy review process with direct visual interaction. ## Interactive codebase diagrams - A generated diagram represents components of a project as connected nodes. - Users can hover over, drag, and filter elements to explore relationships and architectural layers. - The interface turns static codebase documentation into an explorable model. ## Managing sessions and worktrees - A canvas can display active GitHub Copilot sessions and their associated Git worktrees. - It distinguishes active, stale, and orphaned worktrees. - Cleanup actions are available directly from the interface, reducing manual maintenance. ## Improving agent prompts - The prompt coach reviews previous agent interactions. - It identifies issues such as unclear context, spelling mistakes, and syntax problems. - It suggests ways to make prompts more precise and improve future agent results. ## Finding organizational knowledge - A knowledge finder can search sources such as Slack, Teams, email, and documentation. - It identifies people connected to a file or topic. - Results explain both who has relevant context and where that connection was found, making it easier to locate the right expert. ## Getting started Canvases are best suited to workflows where visual understanding and direct manipulation are more effective than sequential prompts. Developers can try them in the GitHub Copilot app by using `/create-canvas`, then iterating with the agent to build a workspace tailored to their task.

AI Agents Slack Github Copilot Github Issues+3

githubJul 17, 20261 min readCurated summary

The cost of saying yes has changed

Dalia is a software engineer on GitHub’s Copilot Agent Control Plane team. Her work focuses on building the subagent governance layer for Copilot customers. ### Role and Focus - Works on GitHub Copilot’s Agent Control Plane. - Builds governance capabilities for subagents. - Supports Copilot customers through controls and management features. The provided content contains only a brief professional description, not a full blog post, so there are no additional technical sections or conclusions to summarize.

Github Copilot Software Engineering Subagents Control Plane+1

githubJul 15, 20263 min readCurated summary

GitHub for Beginners: Your roadmap to mastering the GitHub essentials

GitHub for Beginners presents a step-by-step roadmap from understanding version control to collaborating on projects through GitHub. It explains the essential Git concepts, account setup, repository creation, Markdown, and the GitHub flow. The central message is that beginners can master GitHub by learning a small set of practical tools and following a repeatable workflow. ## Understanding Version Control and Git - Version control tracks file changes over time, allowing developers to see what changed, when, and why. - Git replaces confusing file copies such as `final_v2` or `FINAL_actually` with a complete change history. - Git uses three main areas: - **Working directory:** where files are edited - **Staging area:** where changes are prepared for saving - **Local repository:** where committed history is stored - Core commands include: - `git status` to inspect changes - `git add` to stage changes - `git commit` to save a snapshot - “Pushing” code means uploading local commits to GitHub. ## Securing and Personalizing a GitHub Account - A GitHub account acts as a developer identity and should be protected with two-factor authentication. - 2FA can be enabled under **Settings → Password and authentication**. - Recovery codes should be downloaded and stored securely, such as in a password manager. - A profile README can serve as a public portfolio describing skills, projects, and interests. - The README appears on the profile when stored in a public repository named after the user’s GitHub username. ## Essential Git Commands - Beginners do not need to memorize all of Git; a small group of commands supports most daily workflows. - Important commands include: - `git config --global user.name "..."` to identify commits - `git init` to create a repository - `git clone <url>` to copy a remote repository locally - `git add .` to stage changes - `git commit -m "message"` to save changes - `git switch -c <branch>` to create and enter a branch - `git push` to upload commits - `git pull` to retrieve and merge remote changes - `git merge <branch>` to integrate another branch ## Creating a First Repository - A repository is a project’s home base: it stores files, tracks history, and supports collaboration. - To create one: - Select **New** from the GitHub dashboard - Choose a name - Set it as public or private - Optionally initialize it with a README - A `.gitignore` file excludes generated files, dependencies, system files, and temporary build output from version control. - A license communicates how others may use or share the project. ## Writing with Markdown - Markdown is a lightweight text-formatting language used throughout GitHub. - It powers READMEs, issues, pull requests, and comments. - Simple symbols and optional HTML tags can create readable documentation without complex tools. ## Following the GitHub Flow - GitHub flow provides a repeatable process for contributing safely: 1. Clone the repository 2. Create a branch 3. Make changes 4. Commit the work 5. Push the branch to GitHub 6. Open a pull request - Pull requests let colleagues review changes before they are merged. - The workflow applies to many shared projects, including repositories containing reusable AI prompts or other collaborative resources. Start with the basic Git commands, protect and document your GitHub profile, then practice the branch-and-pull-request workflow on a small repository. These fundamentals provide a practical foundation for contributing to larger team projects and open source.

Open Source Github Git Markdown+3

githubJul 10, 20263 min readCurated summary

Better tools made Copilot code review worse. Here’s how we actually improved it.

Copilot code review became more expensive and less effective after GitHub replaced its specialized exploration tools with shared `grep`, `glob`, and `view` tools. The tools themselves worked correctly, but their general-purpose instructions encouraged broad repository browsing rather than focused pull request investigation. After rewriting the instructions around diff-first review workflows, GitHub achieved roughly 20% lower average review cost without reducing review quality. ## Why the Tool Migration Regressed - Copilot code review previously used specialized tools for: - Listing directories - Searching files and directories - Reading code - These tools often returned matching lines along with surrounding context, which suited earlier models that made fewer tool calls and needed more context per request. - GitHub migrated to the shared Unix-inspired tools used by Copilot CLI and other products: - `glob` replaced `list_dir` - `grep` replaced `search_file` and `search_dir` - `view` replaced `read_code` - The migration aimed to reduce duplicated implementations and let improvements benefit multiple Copilot products. - Offline benchmarks showed higher review costs and fewer useful comments after the migration. ## Repository Browsing Instead of Pull Request Review - Execution traces showed the agent: - Searching broadly - Guessing file paths - Reading large sections of code - Finding more things to search - Carrying unnecessary context into later reasoning - This workflow is reasonable for a coding assistant asked to understand an unfamiliar repository. - It is inefficient for code review, where the agent should begin with the pull request diff and investigate a specific potential problem. - Excessive tool output increases token usage because returned file contents remain in the agent’s context window. - Broad exploration can also make the review less focused by mixing relevant evidence with unrelated code. ## The Difference Between Coding and Reviewing - A coding assistant may need to map a large area of a repository before editing code safely. - A reviewer typically asks targeted questions based on the diff, such as: - Where is the changed function called? - Is a modified configuration key used elsewhere? - Does a similar test or helper already exist? - What is the smallest code range needed to understand the behavior? - Copilot code review has a narrower objective: - Start from the pull request diff - Determine whether the change introduced a real issue - Gather only the evidence needed to confirm or dismiss that issue - The shared tools were designed for broader interactive workflows, so their instructions unintentionally encouraged the wrong behavior in the review agent. ## Instructions Were the Real Fix - GitHub concluded that changing tools was not enough; the agent’s workflow instructions also had to change. - The revised instructions emphasized: - Diff-first investigation - Targeted searches - Minimal surrounding context - Narrow evidence gathering - Avoiding unnecessary repository-wide exploration - With these workflow changes, the shared tools became more effective for review rather than merely reproducing their coding-assistant behavior. - The result was approximately 20% lower average review cost while preserving review quality. The practical lesson is that tool quality cannot be evaluated separately from the instructions and workflow guiding an agent. Shared tools can work well across products, but each use case needs instructions that match its task—in this case, focused, evidence-driven pull request review rather than broad repository exploration.

AI Agents Github Copilot Code Review Pull Requests+2

githubJul 9, 20261 min readCurated summary

How GitHub gave every repository a durable owner

Michael Recachinas is a Staff Security Engineer at GitHub who leads large-scale security initiatives. His work focuses on vulnerability management, secure development lifecycle tooling, and developer-first security automation. Throughout his career, he has built scalable systems designed to make secure choices easier for development teams. ## Professional Focus - Leads security programs at GitHub. - Specializes in: - Vulnerability management - Secure development lifecycle tooling - Security automation designed for developers ## Engineering Approach - Builds systems that operate at large scale. - Focuses on integrating security into developers’ workflows. - Aims to make secure practices the easiest and most natural choice. Overall, the passage presents Recachinas as a security engineering leader focused on scalable, practical, and developer-friendly solutions.

Github Vulnerability Management Security Automation Secure Development Lifecycle+1

githubJul 8, 20263 min readCurated summary

Automating cross-repo documentation with GitHub Agentic Workflows

The Aspire team used GitHub Agentic Workflows to automate documentation across its product and documentation repositories. For versions 13.3 and 13.4, the system produced 82 documentation pull requests, typically within 44.8 hours of the corresponding product change, with review from the engineer who shipped the feature. The approach combines AI-generated drafts with deterministic branch selection and tightly controlled write permissions. ## The Cross-Repository Documentation Problem - Product code lives in `microsoft/aspire`, while documentation lives in `microsoft/aspire.dev`. - The old process depended on writers discovering changes weeks later and reconstructing intent from closed pull requests. - Engineers often had limited context by the time clarification was requested. - Broad repository tokens were unacceptable, making secure cross-repository automation difficult. ## How GitHub Agentic Workflows Work - Workflows are authored as Markdown files with YAML-style frontmatter and natural-language instructions. - A compiler generates a standard GitHub Actions `.lock.yml` workflow. - An agent analyzes repository data and produces proposed actions as JSON rather than writing directly to GitHub. - A separate “safe-outputs” handler executes only explicitly permitted actions through a narrowly scoped GitHub App. - This separation provides AI flexibility while preserving security controls and auditability. ## The Automated Documentation Pipeline - The `pr-docs-check.md` workflow runs when a pull request is merged into `main` or a `release/*` branch. - A deterministic Bash script resolves the documentation target branch before the agent runs: - Product pull request milestone, such as `13.4`, maps to `release/13.4`. - Linked issue milestones are checked next. - The pull request’s base branch is used if it matches a release pattern. - Otherwise, documentation targets `main`. - The agent: - Reviews the product diff and linked issues. - Determines whether documentation is necessary. - Checks out `microsoft/aspire.dev`. - Writes documentation using the project’s existing writing conventions and Starlight/MDX components. - The workflow creates a draft documentation pull request with: - A `[docs]` title prefix. - The `docs-from-code` label. - A restricted base branch. - The documentation repository as the target. - The subject-matter expert who reviewed the original product pull request as reviewer. - A comment containing the documentation pull request link is posted back to the source pull request, while older workflow comments are minimized on reruns. ## Security Through Safe Outputs - The agent receives constrained GitHub tools and read access. - Repository access is limited through allowed repositories and a dedicated GitHub App. - Actions must use pinned, integrity-checked components through `min-integrity: approved`. - Write operations are restricted to declared safe outputs, such as creating pull requests. - Documentation changes remain drafts and are never auto-merged. ## Results and Broader Fit - The process eliminated the need for additional staff or major process training. - Documentation drafts arrive shortly after the related code is merged, while the implementation context is still fresh. - The workflow preserves human review by routing drafts to the engineer or SME who approved the feature. - Both the automation documentation and `aspire.dev` use Astro and Starlight, making the tooling and publishing environment closely aligned. The practical recommendation is to use agentic automation for drafting and routing documentation, but keep branch resolution, permissions, and final review deterministic and human-controlled. This provides much of the speed of autonomous workflows without granting an AI agent unrestricted repository write access.

AI Agents GitHub Actions Astro Github Agentic Workflows+3

githubJul 8, 20262 min readCurated summary

How GitHub Copilot enables zero DNS configuration for GitHub Pages

GitHub Copilot CLI can automate the entire process of publishing a GitHub Pages site on a custom domain, including DNS configuration, without manually editing records. Using a community Namecheap skill and the registrar’s API, the author went from an empty repository to an HTTPS-enabled custom domain in roughly 14 minutes. The approach keeps users in control by requesting confirmation before making DNS changes. ## Publishing with GitHub Pages - Create a new public GitHub repository. - Ask Copilot CLI to: - Generate a landing page. - Commit the site. - Enable GitHub Pages. - The site initially becomes available through a standard `github.io` URL. ## Registering an Affordable Domain - Premium `.com` domains are not required for side projects. - The author registered `ghpagesblog.click`. - The domain cost approximately USD $2.00, or CAD $2.46. ## Connecting Namecheap to Copilot CLI ### Enabling Namecheap API access - Open **Profile → Tools → Business & Dev Tools → Namecheap API Access**. - Turn the API on. - Add the calling machine’s public IP to Namecheap’s **Whitelisted IPs**. - Copy and securely store the API key. ### Installing the Namecheap skill - Install the community skill with: ```bash gh skill install github/awesome-copilot namecheap --scope user ``` - The first request prompts for the Namecheap username and API key. - Copilot can then list the account’s domains, providing a basic connection test. ## Automating DNS Configuration - Ask Copilot to connect the GitHub Pages site to the registered domain. - The skill identifies existing Namecheap parking or redirect records. - Before changing anything, it asks the user for confirmation. - After approval, it: - Replaces the parking records with GitHub Pages A records. - Adds a CNAME record for the `www` subdomain. - Commits a `CNAME` file to the repository so GitHub Pages recognizes the custom domain. - This follows GitHub’s documented custom-domain configuration. ## Verifying the Deployment - Copilot CLI checks that the custom domain resolves instead of simply assuming the configuration worked. - The process is intended to verify the deployment end to end, including DNS and GitHub Pages publication. The main recommendation is to use Copilot CLI with a trusted registrar-specific skill to remove much of the manual DNS work while retaining approval over potentially disruptive record changes. Nevertheless, API keys and DNS modifications should be handled carefully, especially by restricting API access to an allowlisted IP.

Github Copilot Dns Github Pages Namecheap Api+2

githubJul 2, 20261 min readCurated summary

How GitHub used secret scanning to reach inbox zero

Michael Recachinas is a Staff Security Engineer at GitHub who leads large-scale security initiatives. His work centers on vulnerability management, secure development lifecycle tooling, and automation that helps developers make secure choices more easily. ### Professional Focus - Leads security programs at scale. - Focuses on: - Vulnerability management - Secure development lifecycle tools - Developer-first security automation ### Experience and Approach - Has built systems designed to operate reliably at large scale. - Emphasizes making secure behavior the easiest option for development teams. The provided text is a professional biography rather than a full technical blog post, so it does not include a specific argument, technical sections, or conclusion to summarize.

Github Vulnerability Management Application Security Security Automation+1

githubJul 1, 20261 min readCurated summary

6 security settings every GitHub maintainer should enable this week

Joseph is a cybersecurity and AI expert who creates software and educational content to help developers build more securely. His open-source game, videos, and international speaking engagements have reached a broad audience, combining practical security guidance with accessible explanations. ## Cybersecurity and AI Leadership - Develops software and content focused on secure development. - Helps shape how developers approach cybersecurity and AI. ## Open-Source Security Education - Created the open-source game [gh.io/scg]. - More than 10,000 developers have used it to build future-proof security skills. ## Educational Videos - His videos have received over 2.8 million views. - Simplifies complex security topics into actionable advice for a global audience. ## International Speaking - Delivered 79 talks across 25 countries in the past four years. - Known for combining technical insight with energetic stage presence. Overall, Joseph’s work spans hands-on tools, accessible education, and public speaking, making cybersecurity knowledge more practical and widely available to developers.

AI Open Source Cybersecurity Secure Software Development

githubJun 29, 20261 min readCurated summary

Inside the Advisory Database and what happens when vulnerability volume breaks records

Madison Ficorilli is a vulnerability transparency advocate and senior security manager at GitHub. She leads the advisory database curation team and contributes to vulnerability reporting, response, and disclosure through several industry organizations. Her perspective combines current leadership experience with prior roles in incident response and vulnerability coordination. ## Leadership at GitHub - Leads GitHub’s advisory database curation team. - Focuses on improving vulnerability transparency and the quality of security advisory information. ## Industry and Open Source Security Work - Co-chairs a relevant Open Source Security Foundation (OpenSSF) working group. - Serves on the CVE Program Board. - Advocates for effective vulnerability reporting, response, and disclosure practices. ## Professional Background - Previously worked as a product incident response analyst at GitHub. - Served as a vulnerability coordinator at the CERT Coordination Center at Carnegie Mellon University’s Software Engineering Institute. Her career reflects deep expertise across vulnerability coordination, incident response, database curation, and security disclosure policy.

Github Vulnerability Management Incident Response Cve+2

githubJun 26, 20262 min readCurated summary

Transitioning as a hubber

Arthur Searle describes transitioning at GitHub as a largely smooth experience, enabled by an inclusive, remote-first culture and strong workplace support. Using handles, written communication, flexible avatars, and gender-affirming benefits reduced many common sources of stress. His experience shows that transition can involve both bureaucratic challenges and profound joy when colleagues respond with acceptance and care. ## A Career Built at GitHub - Searle began in IT support and operations before teaching himself to code. - He joined GitHub’s IT Engineering team after a colleague’s referral and moved to Enterprise Security six months later. - His work has included: - Helping migrate GitHub’s main SaaS platform to infrastructure as code. - Speaking at Oxford University about version control. - Throughout his transition, his handle—“gleeblezoid”—remained constant, providing continuity at work. ## How GitHub’s Culture Supported Transition - GitHub’s remote-first structure reduced anxiety around appearance, commuting, and in-person interactions. - Much of Searle’s work happened through written communication in Slack and GitHub, limiting the pressure of speaking while undergoing voice training and hormone-related voice changes. - Employees commonly use handles and informal avatars, making gender assumptions based on appearance less central. - Searle was able to update his name and pronouns in internal systems, with colleagues consistently using them. ## Gender-Affirming Benefits - GitHub covered gender-affirming healthcare for employees. - Benefits included reimbursement for: - Voice training. - Hormone replacement therapy prescriptions. - Therapy. - The main remaining difficulty was ordinary administrative friction, such as changing his legal name in payroll systems. ## Acceptance, Joy, and Belonging - Searle contrasts his experience with people who remain closeted, repeatedly come out to new coworkers, or face extensive bureaucracy. - Colleagues treated his transition as a normal part of his life and expressed genuine happiness for him. - Small gestures had a major emotional impact, including hearing his name and pronouns used at work for the first time and receiving a shaving kit from a teammate. - He emphasizes that being trans is not defined only by hardship; there is also joy in living openly and being supported by others. GitHub’s example suggests that inclusive policies, flexible communication practices, and everyday respect can make workplace transition significantly safer and more affirming. For organizations, support should extend beyond formal benefits to the culture and systems employees use every day.

Github Slack Version Control Infrastructure As Code+3

githubJun 25, 20263 min readCurated summary

Evaluating performance and efficiency of the GitHub Copilot agentic harness across models and tasks

GitHub argues that an agentic harness—the system coordinating tools, context, and workflow—strongly influences how effectively an AI model solves software tasks. Its shared Copilot harness aims to match model-vendor harnesses in task completion while using fewer tokens. Benchmark results across four models suggest near-parity overall, with performance varying by model and task. ## Benchmarking Approach - GitHub evaluates the harness using public and internal benchmarks, plus real-world metrics and online experiments. - Comparisons hold the following constant: - The same underlying model - The same task - Context-window size - Reasoning effort - Tool selection - MCP servers - Copilot CLI is compared with: - Claude Code for Claude Sonnet 4.6 and Claude Opus 4.7 - Codex CLI for GPT-5.4 and GPT-5.5 - Benchmarks include: - **SWE-bench Verified:** 500 human-validated Python bug fixes - **SWE-bench Pro:** More complex, multi-step engineering tasks - **SkillsBench:** Skill usage and triggering - **TerminalBench:** Command-line workflows - **Win-Hill:** Software tasks in Windows containers ## Token Efficiency - Copilot’s harness generally completes tasks at rates comparable to model-vendor harnesses while consuming fewer tokens. - It performed better across the reported tests for Sonnet 4.6 and Opus 4.7. - For GPT-5.4 and GPT-5.5, Copilot performed better on nearly every benchmark. - The main exception was SWE-bench Verified, where Copilot was 7% worse with GPT-5.4 and 4% worse with GPT-5.5. ## Task Resolution - GitHub emphasizes that lower token use matters only when the agent successfully completes the work. - Overall task-resolution rates were considered on par with vendor harnesses. - Results varied by benchmark: - Copilot generally did better on SWE-bench Pro, especially with GPT models. - It outperformed vendor harnesses on Win-Hill or matched them for every model. - It performed better on TerminalBench with Sonnet and Opus, matched GPT-5.5, and trailed GPT-5.4. - SkillsBench results favored GPT models on Copilot but favored vendor harnesses for Claude models. - Differences are described as statistically comparable because model behavior is stochastic and run-to-run variation can explain many gaps. ## TerminalBench Variance Analysis - GitHub uses TerminalBench 2.0 to study both cost and completion rate over repeated runs. - The preferred outcome is higher resolution with lower cost. - The analysis illustrates that benchmark results should account for variance rather than relying on a single run. - GitHub presents Copilot as equal to or better than the vendor harnesses on this cost-versus-success comparison. The practical conclusion is that harness design is a reusable performance multiplier across Copilot products. GitHub’s results support using its shared harness when developers need broad model choice, efficient token usage, and comparable task-completion performance, while recognizing that the best harness can still vary by model and workload.

Large Language Models AI Agents Model Context Protocol Github Copilot+3

githubJun 23, 20261 min readCurated summary

I automated my job (and it made me a better leader)

Ashley Willis is GitHub’s Senior Director of Developer Relations, where she focuses on open source, community, and developer advocacy. Her work combines leadership, accessibility, and inclusion, with an emphasis on making technology more human and building resilient teams. ### Leadership and Advocacy - Leads developer relations at GitHub. - Advocates for developers and open-source contributors. - Amplifies underrepresented voices in technology. ### Community and Accessibility - Builds supportive, inclusive spaces for contributors. - Focuses on creating tools that genuinely serve their users. - Works at the intersection of leadership, advocacy, and accessibility. Overall, Willis’s career centers on strengthening developer communities and making technology more inclusive, accessible, and human.

Open Source Accessibility Github Developer Relations

githubJun 19, 20263 min readCurated summary

How we built an internal data analytics agent

Qubot is GitHub’s internal, Copilot-powered analytics agent, designed to make warehouse data accessible without requiring an analyst. Employees ask natural-language questions through Slack, VS Code, or the Copilot CLI, while Qubot uses curated context and selects between Kusto and Trino to produce answers. GitHub’s experience shows that structured context is central to improving both accuracy and response speed. ## The Problem Qubot Addresses - Product teams often struggle to identify the right data model, grain, filters, and query. - Limited analyst availability leaves many teams to investigate telemetry independently. - Qubot targets exploratory questions rather than replacing dashboards or formal reporting. - It enables employees to investigate unfamiliar datasets with minimal setup and maintenance. ## Multiple Ways to Ask Questions - **Slack:** Users ask questions in a shared channel, receive answers in threads, and collaborate on follow-up questions. - Each result is saved as a Markdown report in a pull request, allowing users to refine queries or reuse them in dashboards. - **VS Code and Copilot CLI:** Qubot is installed as a plugin and operates alongside other agents, skills, and tools. - Offering both zero-configuration and developer-focused interfaces increased adoption among different user groups. ## A Federated Context Layer Qubot’s context is tailored to GitHub’s warehouse layers: - **Bronze:** Product teams provide telemetry schemas and metadata for raw events. - **Silver:** Data teams maintain query examples, usage guidance, and required filters for conformed data. - **Gold:** Dataset owners contribute business rules and metric definitions. - ETL pipelines add derived metadata and other signals automatically. - Context is fetched at runtime through the GitHub MCP Server. A dedicated context agent standardizes contributions from different teams. It ingests Markdown documentation and repository references, then organizes and normalizes them into a structure that Qubot can use effectively. ## Evaluation Before Deployment Every change to Qubot’s instructions or context layer is tested through an offline evaluation framework. - Test cases contain prompts, expected answers, ground-truth SQL, domains, and difficulty levels. - Automated orchestration launches multiple parallel agent trials using `gh agent-task create`. - Results are saved as JSON and aggregated by completion rate, accuracy, and duration. - Teams compare configurations and detect regressions before releasing changes. ## Choosing Between Kusto and Trino Qubot connects to both query engines through MCP servers: - **Kusto** is used for fast exploration of recent event data. - **Trino** handles complex joins and deeper historical analysis. - Qubot defaults to Kusto and switches to Trino when the question requires more advanced or historical querying. - This hides query-engine selection from users. ## Adoption and Lessons Learned - Hundreds of GitHub employees have run thousands of queries through Qubot. - Routine questions in analytics support channels declined as teams gained more autonomy. - The agent helped employees who previously avoided the warehouse access data for decision-making. - GitHub found that well-structured, carefully maintained context improved accuracy and made Qubot approximately three times faster at finding the right answer. The main recommendation is to treat analytics context as a maintained engineering asset. A capable agent depends not only on model intelligence, but also on accurate metadata, documented business rules, evaluation-driven iteration, and interfaces that fit users’ existing workflows.

AI Agents Model Context Protocol Slack Github Copilot+4