GitHub/github-copilot

33 posts

github

Write your first prompt with the GitHub Copilot app (opens in new tab)

Starting with GitHub Copilot does not require a perfect prompt or specialized syntax. The article recommends connecting Copilot to a repository or local folder, describing a task in plain English, and refining the request interactively. Users can gradually adjust the AI model, input method, and session settings as their needs become more complex. ## Start with Project Context - Connect an agent session to: - An existing GitHub repository - A local folder on your computer - Selecting a project gives Copilot access to the code and files needed for the task. - Once the project is connected, you can submit a prompt. ## Describe Tasks in Plain English - Prompts only need to explain the desired outcome. - Example: `Add a most-funded sort option to the games list.` - Copilot can inspect the codebase and identify relevant files. - If the result is incomplete or incorrect, provide more details and ask for revisions. - Prompting is iterative, so the initial request does not need to include every requirement. ## Select an Appropriate AI Model - The app supports multiple AI models with different strengths. - More capable reasoning models may help with complex tasks, while simpler models can be faster for straightforward changes. - Beginners can use the default model without understanding every model difference. - Models can be switched later if the task becomes more demanding or the initial result is unsatisfactory. ## Use Voice Input - Built-in voice input lets users describe tasks verbally. - Speech is converted into editable text before submission. - This can be useful for explaining lengthy or complicated ideas more naturally. ## Customize Agents and Sessions - Session settings allow users to select different agents for different types of work. - Remote control enables access to a session through the web. - Users can start work locally, leave their computer, and resume the same session from another device. - These options are available when needed but are not required for a first task. ## Start Small and Iterate - Begin with a modest change in a familiar project. - Review Copilot’s work and refine the prompt as necessary. - Experiment with different models or session configurations only when the task requires them. The practical recommendation is to choose a project, describe one small task in ordinary language, and begin. Experience with iterative prompting will make model selection and other Copilot settings easier to use over time.

github

From coder to orchestrator: How agents shift the role of a developer (opens in new tab)

AI agents can generate impressive one-prompt demos, but reliable software delivery requires more than isolated outputs. Developers increasingly need to design workflows that define how code is proposed, tested, reviewed, and shipped. The article argues that this shifts developers from primarily writing code to orchestrating agents within controlled, repeatable systems. ## From One-Off Prompts to Reliable Workflows - A single prompt can quickly produce a demo, such as a simple game. - Production development requires repeatable delivery with: - Appropriate context - Validation and testing - Security controls - Review processes - Clear permissions and handoffs - GitHub Copilot is presented as a control plane for connecting these parts. ## An Agentic Development Flow - Familiar repository events can trigger agent work, including: - Adding a label to an issue - Running a scheduled workflow - Starting a GitHub Actions process - The agent’s changes are captured in a pull request. - Deterministic checks then validate the work through: - Linting - Tests - Security scans - Build verification - CODEOWNERS, required reviews, and branch protection rules control what can be merged. - Agents handle ambiguous, context-heavy tasks, while predictable automation provides the safety boundary. - Developers decide: - What agents can access - How tasks are scoped - Where workflows hand off - When human judgment is required ## GitHub’s Implementation Options - Copilot cloud agent workflows support event-driven automations. - Copilot CLI can run AI-powered steps inside GitHub Actions. - Model Context Protocol (MCP) can extend agents with additional tools and external context. - These options represent different stages of building an agent-enabled development workflow. ## Starting Small - Teams should begin with one bounded, low-risk workflow. - Suitable examples include: - Issue triage - Synchronizing documentation and tests - Routine maintenance updates - The recommended approach is to integrate Copilot into existing development infrastructure rather than redesigning everything at once. Developers should treat AI agents as components within an engineered delivery system, not as replacements for that system. Start with a limited workflow, surround agent output with automated checks and review controls, and gradually expand as the process proves reliable.

github

A guide to slash commands in the GitHub Copilot app (opens in new tab)

Slash commands in the GitHub Copilot app provide quick, context-aware shortcuts for planning work, challenging decisions, automating implementation, and reviewing ideas. Unlike CLI commands, which manage terminal-oriented concerns such as directories and working paths, app commands focus on multi-session workflows and agent behavior. The post presents slash commands as a way to work faster while staying focused in the Copilot app. ## What Slash Commands Are - Type `/` in the chat composer to open an autocomplete menu of commands available in the current context. - The app manages project context visually, so commands such as `/add-dir` and `/cwd`—common in the CLI—are unnecessary. - Some commands, including `/clear` and `/model`, work in both the CLI and the app. - App-specific commands emphasize session navigation, project management, and controlling Copilot’s working mode. ## Planning Work with `/plan` `/plan` helps users think through a task before implementation and switches the session into Plan mode. - Break down new features by identifying files, components, dependencies, and implementation steps. - Prepare large refactors with an incremental migration strategy and risk assessment. - Investigate bugs by exploring possible causes and creating a diagnostic and repair plan. - Example: `/plan I need to add two-factor authentication to our application. Help me break down the work involved, identify what files need to change, and outline an implementation approach.` ## Challenging Ideas with `/spar` `/spar` acts as a critical reviewer, questioning assumptions and highlighting risks, tradeoffs, and edge cases. - Pressure-test architecture decisions such as using Redis for caching. - Compare alternatives like REST versus GraphQL or synchronous versus asynchronous processing. - Review database and infrastructure migration plans for rollout risks. - Evaluate proposed performance optimizations for hidden costs or unintended effects. ## Implementing with `/autopilot` `/autopilot` turns a high-level goal into an implementation workflow and switches the session into Autopilot mode. - Ask Copilot to implement features, update files, and modify tests. - Use it for multi-step maintenance work, including dependency upgrades, refactoring, and documentation updates. - Example tasks include adding CSV report exports or upgrading a React project while addressing breaking changes and running the test suite. ## Reviewing Ideas with `/rubber-duck` `/rubber-duck` provides an independent perspective for thinking through problems and debugging. The article introduces it as a more useful alternative to explaining an issue to a pet, but the supplied text ends before describing its full capabilities or examples. Use `/plan` to clarify the work, `/spar` to test the approach, and `/autopilot` to carry out the implementation. These commands complement the app’s visual workflow by making common Copilot interactions immediately accessible from the chat composer.

github

Stacked sessions and pull requests in the GitHub Copilot app (opens in new tab)

GitHub Copilot’s stacked sessions let developers split large, dependent changes into smaller pull requests while preserving their order. Cassidy Williams demonstrates this by modernizing a decade-old React application, recovering from an incorrect branch choice, and then starting a separate `react-bootstrap` replacement on top of the styling work. The approach made a difficult modernization more manageable and reduced the temptation to create an unwieldy “everything” pull request. ## Modernizing a Legacy Application - Williams’ personal dashboard had accumulated outdated dependencies and patterns: - React 15 - Less - An old version of `react-bootstrap` - Updating the application manually had previously seemed too time-consuming. - She used the GitHub Copilot app to plan a frontend modernization focused on: - Replacing Less with Tailwind or vanilla CSS - Improving accessibility and responsiveness - Modernizing dependencies - Cleaning up links, inputs, labels, wrapping, and container widths - Claude Opus 4.8 helped formulate the plan, while GPT-5.5 provided a review. - The initial attempt failed because the work began from the wrong branch. ## Recovering from the Wrong Branch - Williams discovered that an old `dev` branch already contained partial modernization work and was the version she actively used. - The new session had incorrectly branched from `main`, creating compatibility problems. - Rather than discard the work, she asked Copilot to: - Close the incorrect pull request - Start a fresh session from `dev` - Port the styling and accessibility changes onto that branch - Copilot handled the branch and pull request transition, preserving useful decisions from the failed attempt. ## Investigating Legacy Warnings - Testing exposed warnings involving: - `findDOMNode` - `componentWillReceiveProps` - The outdated code was largely coming from `react-bootstrap`, not Williams’ own application code. - She used Plan mode to compare upgrading or migrating existing components with removing the library. - Copilot recommended replacing `react-bootstrap` entirely. ## Stacking Dependent Sessions - Replacing `react-bootstrap` represented substantial scope beyond the current styling work. - Williams chose to submit the existing work first, then create a second session branched from it. - The new session would: - Build on the completed styling changes - Replace `react-bootstrap` - Produce a separate pull request - Eventually merge into `dev` after the first pull request - This structure keeps each change easier to review and test while maintaining the dependency between them. The practical recommendation is to use stacked sessions for large, related modernization efforts: isolate coherent tasks into separate pull requests, branch later work from earlier changes, and avoid allowing AI-assisted development to turn every improvement into one oversized change.

github

The harness is all you need (mostly) (opens in new tab)

The post argues that effective AI-assisted development depends less on discovering elaborate prompts, tools, or configurations and more on learning the underlying agent harness. A simple workflow—choose a consistent tool, grant agents autonomy in a safe environment, and prototype before implementing—can produce major productivity gains. The author concludes that the harness is “all you need,” with only a few practical habits required. ## Choose a Tool and Learn the Harness - GitHub Copilot is available through the CLI, Copilot app, VS Code, Visual Studio, JetBrains, and other environments. - Although interfaces differ, these tools increasingly share the same underlying harness and workflow. - Beginners may benefit from starting with the CLI because its text-based interface exposes the agent’s behavior directly. - Learning the harness once makes it easier to work across different Copilot environments. ## Enable Autonomous Agent Operation Safely - “YOLO mode,” also called `/allow-all` or “Allow All,” lets the agent execute commands without requesting approval each time. - Repeated approval prompts slow development and encourage users to approve actions without reading them. - Agents should be given autonomy, but unrestricted execution is risky on local or production systems. - Use isolated environments such as GitHub Codespaces or development containers, especially when working with private organizational data. ## Prototype Before Implementing - AI makes it inexpensive to explore multiple designs before committing to an implementation. - For a date picker, the author recommends generating many HTML mockups at once—for example, 20 variations—to compare layouts and interaction models. - Reviewing prototypes can reveal ideas that are difficult to anticipate from text alone, such as navigating from year to month to day. - Visual and tangible representations help people understand complex concepts faster than dense descriptions. ## Use Visual Models for Non-Visual Work - Prototyping is also useful for backend tasks and API design. - For an analytics-download endpoint, the author suggests asking the agent to create several visual implementation options. - Mermaid diagrams can map out alternatives directly in Markdown. - Exploring these options early exposes requirements and trade-offs, reducing rework and wasted tokens. ## Keep the Model and Reasoning Settings Consistent - The author recommends using a medium-sized model with medium reasoning for most tasks. - Keep the same model and reasoning level throughout a feature, bug fix, or enhancement. - Consistency allows previous conversations to remain cached, reducing token costs on later requests. The practical recommendation is to focus less on collecting AI tools and clever prompts and more on mastering the agent workflow: give it controlled autonomy, prototype alternatives early, and maintain a consistent working context.

github

GitHub Copilot app for Beginners: Getting started (opens in new tab)

The GitHub Copilot app is designed as a development workspace rather than a single AI chat window. It connects agent sessions to projects, supports parallel tasks, provides an interactive browser canvas for UI work, and helps manage pull requests through Agent Merge. Together, these features aim to support the full workflow from exploration to shipping. ## Project-Based Agent Sessions - Each session is connected to a specific project and its repository context. - Projects can be selected from GitHub or added from a local machine. - Copilot can inspect the codebase, identify relevant files, implement changes, and run tests. - This reduces the setup required before beginning a development task. ## Managing Multiple Work Threads - Users can create separate sessions for different tasks without interrupting ongoing work. - **Quick Chat** provides a lightweight way to: - Ask questions about Copilot or the codebase - Explore implementation options - Investigate unfamiliar parts of an application - Gather context before making changes - Returning to an existing session preserves its history and allows work to continue from where it stopped. ## Interactive UI Work with Canvas - The app includes a browser canvas for previewing applications alongside the AI conversation. - Canvas can be created with the `/create-canvas` slash command. - **Enable Canvas Dev Mode** and **Pick & Polish** allow users to select page elements directly and use them as context for refinement requests. - This supports an iterative workflow in which developers can inspect the visual result, identify problems, and ask Copilot to adjust specific UI elements. ## Pull Request Assistance with Agent Merge - **Agent Merge** extends Copilot’s role beyond implementation into code review and delivery. - It can be enabled from a pull request’s options in the Copilot app. - Developers choose which actions it may perform, including: - Addressing review feedback - Helping resolve CI failures - Handling merge conflicts - Agent Merge monitors the pull request while checks and reviews are in progress, preparing it for merge once requirements are satisfied. The Copilot app is intended to centralize development activities in one workspace: start with a project, separate work into focused sessions, visually refine applications through canvas, and use Agent Merge to help complete the pull request process. Developers can learn the workflow by applying it to an existing backlog task.

github

Copilot vs. raw API access: What are you actually paying for? (opens in new tab)

GitHub Copilot and direct model APIs serve different purposes rather than competing at the same layer. Copilot bundles model access with development workflows—repositories, editors, terminals, issues, pull requests, and organizational controls—while APIs give teams the primitives to build their own systems. The best choice depends on whether you want to own the surrounding infrastructure or use GitHub’s integrated tooling. ## Copilot as Development Tooling - Copilot supports workflows from GitHub Issues through code changes, testing, pull requests, and review. - Its value includes integration with: - Editors and repositories - Terminals and permitted commands - Repository instructions - Pull requests and organizational policies - Paid plans include code completions and Next Edit Suggestions, while more intensive chat and agentic tasks consume AI Credits. - Actual cost depends on context selection, input/output/cached tokens, tool calls, retries, and task complexity. - Organization plans pool credits and provide budgets and usage tracking through the billing dashboard. ## Raw APIs for Systems You Control - Direct API access is suited to product features, internal agent platforms, evaluation systems, and automation pipelines. - Teams control prompts, retrieval, model routing, retries, logging, security, credentials, and billing. - Production agents still require substantial engineering, including: - Selecting relevant repository or document context - Preserving instructions - Handling failed tool calls - Storing traces and audit records - Defining data boundaries and approval points - Agent SDKs can provide orchestration, tools, sessions, and streaming. GitHub’s Copilot SDK exposes the runtime used by Copilot CLI and can run with either a Copilot subscription or a provider key. ## BYOK: Keeping Copilot’s Workflow - Copilot’s public-preview Bring Your Own Key feature lets teams use supported external models in Copilot Chat, CLI, and VS Code. - Supported providers include Anthropic, AWS Bedrock, Google AI Studio, Microsoft Foundry, OpenAI, OpenAI-compatible services, and xAI. - GitHub continues to provide the Copilot harness and integrations, while the customer pays the model provider directly. - BYOK can preserve existing cloud contracts or provider commitments while maintaining a familiar Copilot workflow. - Administrators can control which GitHub-hosted or BYOK models teams may use. - Because BYOK is still in public preview, teams should consult the current documentation before making purchasing or architecture decisions. ## Choosing the Right Layer - Choose raw API access when you need custom integrations, behavior, security controls, auditing, or billing. - Choose Copilot when developers primarily need to work faster within existing repositories, editors, terminals, issues, pull requests, reviews, and security processes. - BYOK is a middle option for teams that want GitHub’s development workflow but prefer to pay for models through an existing provider relationship. The practical decision is not simply about token price. It is about whether your team needs to build and operate the surrounding AI system or wants an integrated development workflow managed through Copilot.

github

How to build interactive experiences with canvases (opens in new tab)

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.

github

The cost of saying yes has changed (opens in new tab)

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

Better tools made Copilot code review worse. Here’s how we actually improved it. (opens in new tab)

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.

github

How GitHub Copilot enables zero DNS configuration for GitHub Pages (opens in new tab)

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

Evaluating performance and efficiency of the GitHub Copilot agentic harness across models and tasks (opens in new tab)

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.

github

How we built an internal data analytics agent (opens in new tab)

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.

github

Getting more from each token: How Copilot improves context handling and model routing (opens in new tab)

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.

github

What are git worktrees, and why should I use them? (opens in new tab)

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.