GitHub

88 posts

github.blog/engineering

Filter by tag

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

Using the GitHub Copilot SDK for Java (opens in new tab)

Ed Burns is a Principal Software Engineer focused on bringing idiomatic Java experiences to Microsoft and GitHub technologies. He has worked with Java since 1997 across client, server, cloud, and artificial intelligence applications. ## Professional Focus - Works at Microsoft and GitHub. - Concentrates on making Java development feel natural and idiomatic within their technologies. ## Experience - Has used Java since 1997. - His experience spans: - Client-side development - Server-side systems - Cloud technologies - Artificial intelligence No specific blog topic or technical argument is included in the provided content.

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

How we took malware advisories beyond npm (opens in new tab)

Ankit is a Senior Engineering Manager at GitHub and leads the Dependabot team within the Supply Chain Security organization. His work involves protecting more than 30 million repositories across over 34 package ecosystems, giving him extensive exposure to software supply-chain risks and attacks. ## Role and Responsibilities - Leads the Dependabot team at GitHub. - Works within GitHub’s Supply Chain Security organization. - Oversees systems monitoring 30M+ repositories. - Supports more than 34 package ecosystems. ## Security Perspective - The scale of Dependabot’s coverage exposes Ankit to a wide range of supply-chain threats. - This responsibility has made him particularly vigilant about software supply-chain attacks.

github

How the GitHub legal team used Copilot CLI to streamline their workflows (opens in new tab)

GitHub’s legal team used Copilot CLI to turn repetitive legal work into customizable internal tools without relying on traditional software engineering. By expressing workflows, standards, and policies in plain language and Markdown, lawyers built systems that improved consistency, reduced drafting time, and preserved human oversight. The post argues that domain expertise can be operationalized into useful AI tools by anyone who can clearly define a process. ## Building a Contract Drafting Style Guide - Principal Product Counsel Ngandu Kasuku created **terms-ai** to manage varied commercial agreements involving data, infrastructure, and product integrations. - The tool stores instructions, drafting resources, workflows, and reference documents in a version-controlled repository. - An internal style guide enforces plain-language drafting and replaces repetitive prompt copying with consistent guidance. - A library of approved agreements lets the tool draw on prior work for addenda and new contracts. - Sensitive agreements remain in a controlled internal environment rather than the open-source repository. - Kasuku reports cutting drafting and review time roughly in half while producing more consistent provisions. - The main insight was that AI could support a lawyer’s own judgment and working style, not merely perform isolated tasks. ## Turning Legal Workflows into Plain-Language Instructions - Online Safety Counsel Jesse Geraci began with a workflow for analyzing source code in **DMCA** notices. - Copilot instructions covered triage, code comparison, license checks, circumvention review, policy references, and report templates. - Instead of traditional programming, the workflow encoded legal reasoning through structured instruction files. - Different modes were created for clients and lawyers, including faster client analysis, escalation recommendations, deeper legal review, and arguments for both sides. - The system later grew into a desktop application supporting contract review, NDA triage, risk assessment, compliance checks, and response drafting. - Reusable skills and agents handle tasks such as intake, playbook alignment, risk scoring, evidence verification, escalation, and report assembly. - Legal teams can still customize the system through readable Markdown, while human review remains essential. ## Broader Lessons for Nontechnical Teams - Repetitive work in almost any profession can be a starting point for automation. - Clear definitions of methodology, standards, and desired outputs can substitute for extensive programming knowledge. - Teams should begin with one bottleneck, use Copilot CLI to prototype a solution, and expand based on real usage. - These tools are decision-support systems—not replacements for professional judgment. Teams can use Copilot CLI to turn their existing expertise into repeatable, transparent workflows while retaining control over sensitive data and final decisions.

github

Turn one giant AI-generated pull request to a reviewable stack (opens in new tab)

Coding agents can rapidly produce complete features, but they often deliver them as enormous, shallow pull requests that are difficult to review and slow to merge. GitHub’s stacked pull requests address this by decomposing a feature into small, dependency-ordered layers. The result is a reviewable chain of changes that preserves context while reducing maintenance and merge conflicts. ## The Problem with Giant AI-Generated Pull Requests - A seemingly simple product-search feature may include: - A data model and seed data - An API route and validation - Client integration and UI states - Coding agents commonly generate all of this in a single 1,000-plus-line pull request. - Large pull requests: - Become difficult to review thoroughly - Cause reviewers to lose context - Receive lower-quality feedback - Take longer to merge - Are more likely to land under-reviewed Traditional alternatives are also imperfect: one large pull request harms reviewability, while a manually maintained chain of smaller pull requests creates synchronization work and conflict-management overhead. ## Stacked Pull Requests - Stacked pull requests break a feature into logical, dependent layers. - Each pull request focuses on one concern and remains small enough for reviewers to understand. - Later layers build naturally on earlier, already-reviewed work. - Different layers can be assigned to specialized reviewers, such as data or UI owners. For the product-search example, the proposed stack is: - **L1 – `feat/catalog-data`**: Typed catalog, seed data, validation, and data access; based on `main` - **L2 – `feat/search-api`**: Validated `/api/products/search` endpoint; based on L1 - **L3 – `feat/chat-grounding`**: Connects chat to the API and real product data; based on L2 - **L4 – `feat/grounded-ui`**: Adds product citation cards and UI states; based on L3 ## Setting Up the Stack - Choose the stack base first, because CI checks and merge rules are evaluated against it. - Place foundational work closest to the base and dependent work above it. - Install GitHub’s CLI extension: ```bash gh extension install github/gh-stack ``` - Teach coding agents how to create and manage stacks: ```bash gh skill install github/gh-stack ``` Alternatively: ```bash npx skills add github/gh-stack ``` - Ensure CI is configured, since every pull request layer is checked against the stack base. ## Assigning Agents to Layers The example uses separate agents with strict scope boundaries: - **L1:** Data modeler agent - **L2:** Backend agent - **L3:** Frontend agent - **L4:** Frontend agent This division encourages each agent to produce a focused pull request rather than reconstructing the entire feature in one pass. ## Recommended Workflow The development process starts with the foundational catalog layer and proceeds upward through the dependency chain. Agents work autonomously within their assigned scope, while each completed layer can be reviewed independently before subsequent layers are evaluated. Stacked pull requests are a practical way to preserve the productivity benefits of coding agents without sacrificing review quality. Teams should define clear layer boundaries, establish the stack base, assign appropriate reviewers or agents, and run CI for every layer.

github

Don’t stop early: Case-folding source code at memory speed (opens in new tab)

Case folding converts text into a canonical, case-insensitive form for comparisons, making it essential to GitHub’s large-scale code search. GitHub optimized this operation by removing an apparent optimization: instead of stopping at the first non-ASCII byte, it scans the entire buffer branchlessly, enabling SIMD vectorization. The resulting Rust `casefold` crate processes ASCII at over 45 GiB/s—close to memory-bandwidth limits. ## Case Folding Is Not Lowercasing - Lowercasing is intended for display and can depend on locale or context. - Greek sigma may become `ς` or `σ`. - Turkish `I` has locale-specific behavior. - Case folding is intended for comparison and must be locale-independent and symmetric. - Unicode provides explicit rules in `CaseFolding.txt`. - The crate supports simple one-to-one folds (statuses C and S), but not: - Full folds such as `ß → ss` - Turkic-specific folds such as dotted `İ` - This restriction matches tools such as ripgrep and helps maintain consistent matching behavior. ## Why Case-Folding Performance Matters - GitHub’s Blackbird search engine indexes more than: - 180 million repositories - 480 TB of source code - Source bytes are case-folded before n-gram extraction and indexing. - Folding is also needed when evaluating potential query matches. - Since most source code is ASCII, optimizing the ASCII path provides the largest benefit. ## Removing the Early Exit - A conventional implementation scans until it finds a non-ASCII byte, then switches to Unicode processing. - On an Apple M4, this branch-heavy approach reached only about 3.1 GiB/s. - The optimized loop: - ORs every byte into an accumulator to detect non-ASCII data once. - Uses `b.wrapping_sub(b'A') < 26` as a branchless uppercase test. - Sets bit 5 with `| (is_upper << 5)` to lowercase uppercase ASCII letters. - The loop always processes and writes the entire buffer, then checks whether Unicode processing is necessary. ## Vectorization Beats Early Termination - Removing the data-dependent `break` allows LLVM to vectorize the loop with 16-byte NEON instructions. - Performance progression on a 5.7 KB ASCII buffer: - Naive branchy loop: 3.1 GiB/s - Branchless body with early exit: 2.6 GiB/s - Early exit removed: 7.6 GiB/s - Fully branchless loop: over 45 GiB/s - The early exit prevents vectorization even when the loop body is otherwise branch-free. - Branchless arithmetic then eliminates compare-and-blend overhead and enables full memory-speed performance. ## Why Branchless Code Can Be Slower - In scalar code, the branchless version writes every byte, even when no change is needed. - The branchy version skips stores for the majority of lowercase letters, digits, spaces, and other unchanged bytes. - Its conditional branch is highly predictable, so it is inexpensive. - Branchless writes become beneficial only after vectorization, where the processor handles a whole vector at once. The practical lesson is to avoid data-dependent loop exits when they block vectorization. For predominantly ASCII workloads, a complete branchless scan can outperform “stop as soon as possible” logic by a wide margin, while an accumulated high-bit check efficiently identifies inputs requiring Unicode handling.

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

Tame Dependabot: Group your updates, slow the cadence, keep security fast (opens in new tab)

Dependabot can generate unnecessary noise when it opens a separate pull request for every dependency update, especially on active repositories. Using dependency groups, a slower schedule, and coverage for all relevant ecosystems turns that stream into predictable maintenance batches. The recommended approach preserves the speed of security updates while reducing routine review and CI overhead. ## The Problem: Frequent, Un grouped Updates - Microsoft’s GCToolkit had 92 Dependabot commits out of 578—about one in six—with 61 arriving in the previous year. - Its original configuration: - Checked GitHub Actions dependencies daily. - Opened a separate pull request for every dependency. - Limited open Dependabot pull requests to 10. - The pull-request limit capped the visible backlog but did not reduce the underlying noise. ## Grouping Dependencies into Batches - Dependabot’s `groups` configuration combines multiple updates into one pull request. - A wildcard pattern such as `"*"` includes all dependencies in that ecosystem. - Instead of 10 pull requests and 10 CI runs, maintainers receive one reviewable batch. - Larger projects can define separate groups for categories such as testing and production dependencies. - In monorepos, Dependabot can group the same dependency across multiple directories using `directories` and `group-by: dependency-name`. ## Moving from Daily to Monthly Updates - Changing `schedule.interval` from `daily` to `monthly` creates a predictable maintenance cycle. - Combined with grouping, this produces one batch per ecosystem each month rather than a continuous stream. - `weekly` is an alternative for projects needing a faster cadence. - Specific days and times can be configured with `schedule.day` and `schedule.time`. ## Covering All Dependency Ecosystems - The original configuration monitored only GitHub Actions. - The revised configuration also monitors Maven, which is essential for a Java project like GCToolkit. - Each ecosystem receives its own schedule and grouped pull request, keeping Actions and Maven updates separate and manageable. ## Keeping Security Updates Fast - The grouping and scheduling changes primarily affect routine version updates, not Dependabot security fixes. - Maintainers can therefore slow ordinary dependency maintenance without delaying urgent vulnerability patches. A practical configuration is to group all routine updates by ecosystem, run them monthly—or weekly when appropriate—and explicitly configure every package ecosystem used by the repository. This reduces maintenance noise while keeping security response timely.

github

Disrupting supply chain attacks on npm and GitHub Actions (opens in new tab)

GitHub describes a layered approach to disrupting npm and GitHub Actions supply-chain attacks, which typically compromise one project, steal credentials, and spread malware across many others. Rather than relying on one defensive feature, GitHub is targeting several links in the attack chain—from initial compromise through credential theft and malicious publishing. Recent protections add account recovery delays, safer workflow defaults, credentialless publishing, network monitoring, and stronger publishing approvals. ## Anatomy of Supply-Chain Attacks - Attacks commonly: - Compromise a maintainer account or CI/CD workflow. - Escalate access by stealing credentials. - Use those credentials to infect additional packages and projects. - GitHub says effective defense requires multiple mitigations that disrupt the most damaging steps in the chain. ## Preventing Initial Compromise - **High-impact npm account protection** - Accounts enter read-only mode for 72 hours after an email change or use of a 2FA recovery code. - The delay gives maintainers time to detect phishing-related account takeover and recover access. - **Safer `pull_request_target` checkout defaults** - `actions/checkout` now prevents commonly exploited workflows from checking out untrusted code from forks by default. - This reduces exposure to “pwn requests,” where fork-provided code executes with workflow privileges. - **Workflow execution policies** - Enterprise, organization, and repository administrators can control who may trigger workflows and which trigger types are permitted. - These policies provide configurable least-privilege controls for Actions. - **Read-only Actions cache for untrusted triggers** - Less-trusted workflows can no longer modify caches shared with more privileged workflows. - This blocks cache poisoning attacks intended to escalate access to release and publishing credentials. ## Limiting Credential Exfiltration - **npm trusted publishing for CircleCI** - CircleCI can now use trusted publishing, allowing packages to be published without long-lived credentials stored in CI/CD. - Removing persistent tokens reduces the value of compromised workflows. - **Actions network firewall** - The technical preview logs outbound network traffic from workflow runs. - This can expose suspicious downloads or credential exfiltration to unfamiliar domains. - Planned restrictions will allow organizations to block unauthorized network destinations. ## Slowing Attack Propagation - **Staged npm publishing** - Publishing credentials alone are insufficient to immediately release a new package version. - Packages remain staged until an additional approval and 2FA authentication occur through npm’s CLI or website. - This opt-in control separates automated publishing credentials from final authorization, giving maintainers a chance to detect malicious releases. Together, these measures reduce the opportunities for attackers to enter projects, obtain powerful credentials, and rapidly publish malware. GitHub’s recommendation is effectively to combine safer workflow configuration, short-lived or trusted authentication, network visibility, and additional publishing approval rather than depending on any single control.

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

The case for a cooldown: Why Dependabot now waits before issuing version updates (opens in new tab)

Carlin is a GitHub Product Manager focused on GitHub Advanced Security and Dependabot. Her experience in software engineering and data science supports a data-driven approach to product management. ### Professional Background - Works on GitHub Advanced Security. - Focuses specifically on Dependabot. - Brings experience in software engineering and data science. ### Personal Interests - Lives in Washington with her partner and dog, Cookie. - Enjoys cycling and competitive board games. No technical blog post content was provided beyond this author biography.

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.