Updates, ideas, and inspiration from GitHub to help developers build and design software.
The future of AI-powered software optimization (and how it can help your team)
We envision the future of AI-enabled tooling to look like near-effortless engineering for sustainability. We call it Continuous Efficiency. The post The future of AI-powered software optimization (and how it can help your team) appeared first on The GitHub Blog.
When was the last time you heard someone ask in a standup, “How could we do this more sustainably?” Topics like green software and carbon efficiency are unfortunately rarely at the top of busy development teams’ priority lists. What’s more, there are very few “green software practitioners” out there. But we believe we’re at a unique moment in time where this can all change. The next generation of AI-enabled developer tooling has the opportunity to create near-effortless, always-on engineering for sustainability. The GitHub Next and GitHub Sustainability teams have been collaborating to prove this concept and value through a series of internal and external pilot projects. We call it Continuous Efficiency. Making the case for Continuous Efficiency We believe that once it’s ready for broader adoption, Continuous Efficiency will have the potential to make a significant positive impact for developers, businesses, and sustainability. For developers Digital sustainability and green software are intrinsically aligned to “efficiency,” which is at the core of software engineering. Many developers would benefit from performant software, better standardization of code, change quality assurance, and more. For businesses Building for sustainability has measurable business value, including: Reducing power and resource consumption Increasing efficiency Better code quality Improved user experience Lower costs Despite this, sustainability rarely makes it onto the roadmap, priority list, or even the backlog. But imagine a world in which the codebase could continuously improve itself… <img data-recalc-dims="1" fetchpriority="high" decoding="async" height="320" width="1024" src="https://github.blog/wp-content/uploads/2025/12/image1_c8a727.png?resize=1024%2C320" alt="A graphic showing Continuous Efficiency = Green Software + Continuous AI" class="wp-image-92828" srcset="https://github.blog/wp-content/uploads/2025/12/image1_c8a727.png?w=1324 1324w, https://github.blog/wp-content/uploads/2025/12/image1_c8a727.png?w=300 300w, https://github.blog/wp-content/uploads/2025/12/image1_c8a727.png?w=768 768w, https://github.blog/wp-content/uploads/2025/12/image1_c8a727.png?w=1024 1024w" sizes="(max-width: 1000px) 100vw, 1000px" /> Continuous Efficiency means effortless, incremental, validated improvements to codebases for increased efficiency. It’s an emergent practice based on a set of tools and techniques that we are starting to develop and hope to see the developer community expand on. This emerges at the intersection of Continuous AI and Green Software. Continuous AI is AI-enriched automation to software collaboration. We are exploring LLM-powered automation in platform-based software development and CI/CD workflows. Green Software is designed and built to be more energy-efficient and have a lower environmental impact. This practice tends to result in software that is cheaper, more performant, and more resilient. Continuous Efficiency in (GitHub) Action(s) While Continuous Efficiency is a generally applicable concept, we have been building implementations on a specific GitHub platform and infrastructure called Agentic Workflows. It’s publicly available and open source, but currently in “research demonstrator” status (read: experimental prototype, pre-release, subject to change and errors!). Agentic Workflows is an experimental framework for exploring proactive, automated, event-driven agentic behaviors in GitHub repositories, running safely in GitHub Actions. Our work in this space has been focused on two areas: Implementing rules and standards With modern LLMs and agentic workflows, we can now express engineering standards and code-quality guidelines directly in natural language and apply them at a scale that was previously unattainable. This capability goes far beyond traditional linting and static analysis approaches in three important ways: Declarative, intent-based rule authoring: you describe the intent in natural language and the model interprets and implements it (no need for hard-coded patterns or logic). Semantic generalizability: a single high-level rule can be applied across diverse code patterns, programming languages and architectures, giving far broader coverage than conventional tools and approaches. Intelligent remediation: this approach comprehensively resolves issues and violations through agentic, platform-integrated actions, like writing a pull request or adding comments and suggested edits to a change. Examples of our work: Case study: Code base reviews Green software rules implementation We have implemented a wide range of standard and specific Green Software rules, tactics and patterns. These can be applied fully agentically to entire codebases and repos. Example: We teamed up with the resolve project to scan their codebase with a number of rules, and agentically delivered proposed improvements. The outputs weren’t all perfect—but one of the recently approved and merged pull requests makes a small performance improvement by “hoisting” RegExp literals from within hot functions. The project gets 500M+ downloads per month on npm. So this small impact will scale! Case study: Implementing standards Web sustainability guidelines (WSG) The W3C WSG is a great resource to help people make web products and services more sustainable. We implemented the Web Development section into a set of 20 agentic workflows, so now the guidelines can be used by AI too! Example: We have run the WSG workflows on a number of GitHub and Microsoft web properties and found opportunities and built resolutions to improve them—ranging from deferred loading to using native browser features and latest language standards. Heterogeneous performance improvement Performance engineering is notoriously difficult because real-world software is profoundly heterogeneous. Every repository brings a different mix of languages and architectures, and even within a single codebase, the sources of performance issues can span from algorithmic choices to cache behavior to network paths. Expert performance engineers excel at navigating this complexity, but the sheer variety and volume of work across the industry demands better tooling and scalable assistance. We’ve been thinking about the “grand challenge” of how to build a generic agent that can walk up to any piece of software and make demonstrable performance improvements. One that could navigate the vast ambiguity and heterogeneity of software in the wild—no small task! Semi-automatic performance engineering aims to meet that need with an automated, iterative workflow where an agent researches, plans, measures, and implements improvements under human guidance. The process begins with “fit-to-repo” discovery—figuring out how to build, benchmark, and measure a given project—before attempting any optimization. Modern LLM-based agents can explore repositories, identify relevant performance tools, run microbenchmarks, and propose targeted code changes. Early results vary quite dramatically, but some show promise that guided automation can meaningfully improve software performance at scale. Case study: Daily perf improver Daily Perf Improver is a three-phase workflow, intended to run in small daily sprints. It can do things like: (1) Research and plan improvements (2) Infer how to build and benchmark the repository (3) Iteratively propose measured optimizations Example:On a focused recent pilot on FSharp.Control.AsyncSeq it has already delivered real gains by producing multiple accepted pull requests, including a rediscovered performance bug fix and verified microbenchmark-driven optimizations. Daily Perf Improver Research Demonstrator How to build and run agentic workflows GitHub agentic workflows enable you to write automation in natural language (Markdown) instead of traditional YAML or scripts. You author a workflow in a .md file that begins with a YAML-like “front matter” (defining triggers, permissions, tools, safe-outputs, etc.), followed by plain-English instructions. At build time you run the gh aw compile command (part of the agentic workflows CLI) which compiles the Markdown into a standard GitHub Actions workflow (.yml) that can be executed by the normal GitHub Actions runtime. When the compiled workflow runs, it launches an AI agent (for example via GitHub Copilot CLI, or other supported engines like Claude Code or OpenAI Codex) inside a sandboxed environment. The agent reads the repository’s context, applies the human-written natural-language instructions (for example “look for missing documentation, update README files, then open a pull request”), and produces outputs such as comments, pull requests, or other repository modifications. Because it’s running in the GitHub Actions environment, permission boundaries, safe-output restrictions, logs, auditability, and other security controls remain. How we build our Continuous Efficiency Workflows (with agents, of course!) Our internal process for creating Continuous Efficiency workflows follows a simple, repeatable pattern: Define the intent: based on a public standard or a domain-specific engineering requirement. Author the workflow in Markdown: using structured natural language, guided interactively by the create-agentic-workflow agent. Compile to YAML: turning the Markdown into a standard GitHub Actions workflow. Run in GitHub Actions: executing the workflow on selected repositories Want to get involved in Continuous Efficiency? If you’re a developer who loves the experimentation phase, you can already get started with running agentic workflows in GitHub Actions now! There are a range of examples that you can immediately try out (including a “Daily performance improver”) or author your own using natural language. GitHub Sustainability will soon be publishing rulesets, workflows, and more—if you’re interested in being an early adopter or design partner, please get in touch with me. The post The future of AI-powered software optimization (and how it can help your team) appeared first on The GitHub Blog.
A look at how we rebuilt GitHub Actions’ core architecture and shipped long-requested upgrades to improve performance, workflow flexibility, reliability, and everyday developer experience. The post Let’s talk about GitHub Actions appeared first on The GitHub Blog.
GitHub Actions has grown massively since its release in 2018; in 2025 alone, developers used 11.5 billion GitHub Actions minutes in public and open source projects, up 35% year over year from 2024. At the same time, this has not been without its growing pains, and you’ve made clear to us what improvements matter most: faster builds, improved security, better caching, more workflow flexibility, and rock-solid reliability. Meeting that level of demand first required a deliberate investment in re-architecting the core backend services powering every GitHub Actions job and runner. This was a substantial effort that laid the foundation for the long-term performance, scalability, and feature delivery you’ve been asking for. That new architecture is rolled out, powering 71 million jobs per day and giving us deeper visibility into developer experience across the platform. With that work behind us, we shift our attention back to your top requests for much needed, long-standing quality-of-life improvements. Below, we’ll walk through what we’ve shipped this year, how you can get started with these upgrades today, and what’s coming in 2026. Let’s jump in. Rebuilding the core of GitHub Actions In early 2024, the GitHub Actions team faced a problem. The platform was running about 23 million jobs per day, but month-over-month growth made one thing clear: our existing architecture couldn’t reliably support our growth curve. In order to increase feature velocity, we first needed to improve reliability and modernize the legacy frameworks that supported GitHub Actions. The solution? Re-architect the core backend services powering GitHub Actions jobs and runners. Our goals were to improve uptime and resilience against infrastructure issues, improve performance and reduce internal throttles, and leverage GitHub’s broader platform investments and developer experience improvements. We aimed to scale 10x over existing usage. This effort was a big bet and consumed a significant part of our team’s focus. And the work is paying off by helping us handle our current scale, even as we work through the last pieces of stabilizing our new platform. Since August, all GitHub Actions jobs have run on our new architecture, which handles 71 million jobs per day (over 3x from where we started). Individual enterprises are able to start 7x more jobs per minute than our previous architecture could support. This was not without its share of pain; it slowed the pace of feature work and delayed progress on long-standing community requests. We knew this would be a tough call, but it was a critical decision to enable our future roadmap and sustainability as a product. Shifting our focus back to community-requested improvements We acknowledge we still have a ways to go, and this is just the beginning of this new chapter of the GitHub Actions story. As we shift our focus back to much-needed improvements, we want to call out some of the most recent ships on this front: YAML anchors reduce duplication in complex workflows First up, we shipped support for YAML anchors, one of the most requested features across both the runners and community repositories. YAML anchors reduce repetitive configuration in GitHub Actions workflows by letting you define settings once with an anchor (&) and reference them elsewhere with an alias (*). This allows you to maintain consistent environment variables, step configurations, or entire job setups across your workflows—all defined centrally rather than repeated across multiple jobs. 💡 Read our Docs to learn more about YAML anchors and aliases Non-public workflow templates for consistent CI across teams We released non-public workflow templates, a longstanding request from organizations that want consistent, private workflow scaffolding. Non-public workflow templates let organizations set up common templates for their teams directly in their .github repository, giving developers a reliable starting point when spinning up new workflows. Instead of manually copying CI patterns across repositories, teams can now work from a shared set of patterns. 💡 Read our Docs to learn more about workflow templates Deeper reusable workflows for modular, large-scale pipelines We shipped increases to reusable workflow depth (another key request from the community). Reusable workflows let you break your automation into modular, shareable pieces. With the updated limits now supporting 10 levels of nesting and 50 workflow calls per run, teams now have more flexibility to structure their CI/CD pipelines in a way that’s maintainable and scales with their architectural requirements. 💡 Read our Docs to learn more about reusable workflows Larger caches for bigger projects and dependency-heavy builds Repositories can now exceed the previous 10GB cache limit, removing a long-standing pain point for teams with large dependencies or multi-language monorepos. For teams with larger codebases or complex build pipelines, the old 10GB GitHub Actions cache limit often meant build dependencies were evicted before they could speed up your next workflow run, leading to repeated downloads and slower builds. This release was only possible due to our architecture rework and fulfills a request from the community, particularly among some of our largest users. 💡 Read our Docs to learn more about managing cache storage More workflow dispatch inputs for richer automation In early December, we shipped an increase to the number of workflow dispatch inputs from 10 to 25, which also came up in our community discussions. Now developers have more flexibility to build sophisticated self-service workflows, whether teams are parameterizing deployments, configuring test runs, or building reusable automation with richer input options. 💡 Read our docs to learn more about manually running a workflow with workflow_dispatch More performance and platform improvements shipped in 2025 We also made progress on the strong foundation laid earlier this year, including arm64-hosted runners for public repositories, macOS 15 and Windows 2025 images (now generally available), Actions Performance Metrics (also generally available), and Custom Image support in public preview. These releases are designed to improve day-to-day workflow quality and remove long-standing friction. What’s coming in early 2026 This is just the beginning as there is much we need to do to deliver an even better experience with GitHub Actions. Here’s what we’re planning for the first quarter of 2026, influenced by some of the top requests from our community: Support for timezones in scheduled jobs and updates to schedule reliability. Return the run ID from workflow dispatch. Adding a case function for expressions so they have a conditional operator or function. UX improvements, including faster page load times, better rendering for workflows with over 300 jobs, and a filter for the jobs list. Moreover, we’ll start work on parallel steps, one of the most requested features across GitHub Actions. Our goal is to ship it before mid-2026. Lastly, we are going to raise the bar and start to address some of the asks to lift quality in our open source repositories—we appreciate we need to drive up the quality of our experience here as well. Help us shape the 2026 roadmap for GitHub Actions GitHub Actions is one of the most important primitives on GitHub. It powers the builds, tests, deployments, automations, and release processes that define how software ships today. Our promise to you: 2026 will bring more consistent releases, more transparency, and continued focus on the fundamentals that matter most. We are also increasing funding towards this area to enable us to meet your expectations faster than before. And this is where we need your help to make sure we’re focusing on the quality-of-life improvements that matter the most. We need your feedback. To support our work: Keep voting for your most important items in the community discussions. Join us in our new community discussion post, where the GitHub Actions product and engineering leads will be actively discussing with you what comes next. Help us drive a plan for next year to make actions the best it can be. We know GitHub Actions powers how developers build software, and the best version is the one we’ll build together. And as always, you can keep up to date with the GitHub Actions releases through the GitHub Changelog. The post Let’s talk about GitHub Actions appeared first on The GitHub Blog.
GitHub Availability Report: November 2025
In November, we experienced three incidents that resulted in degraded performance across GitHub services. The post GitHub Availability Report: November 2025 appeared first on The GitHub Blog.
In November, we experienced three incidents that resulted in degraded performance across GitHub services. November 17 16:52 UTC (lasting 2 hours and 16 minutes) On November 17, 2025, from 16:52 to 19:08 UTC, Dependabot was hitting a rate limit in GitHub Container Registry (GHCR) and was unable to complete about 57% of jobs within SLO. To mitigate the issue, we lowered the rate at which Dependabot started jobs and increased the GHCR rate limit. This mitigated the circumstances and led to the resolution of the incident. Longer term, we’re adding new monitors and alerts to help prevent this in the future. November 18 20:30 UTC (lasting 1 hour and 4 minutes) On November 18, 2025, from 20:30 to 21:34 UTC, we experienced failures on all Git operations, including both SSH and HTTP Git client interactions, as well as raw file access. These failures also impacted products that rely on Git operations. The root cause was an expired TLS certificate used for internal service-to-service communication. We mitigated the incident by replacing the expired certificate and restarting impacted services. Once those services were restarted we saw a full recovery. We have updated our alerting to cover the expired certificate, and we are performing an audit of other certificates in this area to ensure they also have the proper alerting and automation before expiration. In parallel, we are accelerating efforts to eliminate our remaining manually managed certificates, ensuring all service-to-service communication is fully automated. November 28 05:59 UTC (lasting 2 hours and 24 minutes) On November 28, 2025, between approximately 05:59 and 08:24 UTC, Copilot experienced an outage affecting the Claude Sonnet 4.5 model. Users attempting to use this model received an HTTP 400 error indicating no model was available until an alternative model was selected. Other models were not impacted. The issue was caused by a misconfiguration deployed to an internal service, which made Claude Sonnet 4.5 erroneously listed as unavailable. The problem was identified and mitigated by reverting the configuration change. We are working to improve cross-service deploy safeguards to prevent similar incidents in the future. Follow our status page for real-time updates on status changes and post-incident recaps. To learn more about what we’re working on, check out the engineering section on the GitHub Blog. The post GitHub Availability Report: November 2025 appeared first on The GitHub Blog.
MCP joins the Linux Foundation: What this means for developers building the next era of AI tools and agents
MCP is moving to the Linux Foundation. Here's how that will affect developers. The post MCP joins the Linux Foundation: What this means for developers building the next era of AI tools and agents appeared first on The GitHub Blog.
Over the past year, AI development has exploded. More than 1.1 million public GitHub repositories now import an LLM SDK (+178% YoY), and developers created nearly 700,000 new AI repositories, according to this year’s Octoverse report. Agentic tools like vllm, ollama, continue, aider, ragflow, and cline are quickly becoming part of the modern developer stack. As this ecosystem expands, we’ve seen a growing need to connect models to external tools and systems—securely, consistently, and across platforms. That’s the gap the Model Context Protocol (MCP) has rapidly filled. Born as an open source idea inside Anthropic, MCP grew quickly because it was open from the very beginning and designed for the community to extend, adopt, and shape together. That openness is a core reason it became one of the fastest-growing standards in the industry. That also allowed companies like GitHub and Microsoft to join in and help build out the standard. Now, Anthropic is donating MCP to the Agentic AI Foundation, which will be managed by the Linux Foundation, and the protocol is entering a new phase of shared stewardship. This will provide developers with a foundation for long-term tooling, production agents, and enterprise systems. This is exciting for those of us who have been involved in the MCP community. And given our long-term support of the Linux Foundation, we are hugely supportive of this move. The past year has seen incredible growth and change for MCP. I thought it would be great to review how MCP got here, and what its transition to the Linux Foundation means for the next wave of AI development. Before MCP: Fragmented APIs and brittle integrations LLMs started as isolated systems. You sent them prompts and got responses back. We would use patterns like retrieval-augmented generation (RAG) to help us bring in data to give more context to the LLM, but that was limited. OpenAI’s introduction of function calling brought about a huge change as, for the first time, you could call any external function. This is what we initially built on top of as part of GitHub Copilot. By early 2023, developers were connecting LLMs to external systems through a patchwork of incompatible APIs: bespoke extensions, IDE plugins, and platform-specific agent frameworks, among other things. Every provider had its own integration story, and none of them worked in exactly the same way. Nick Cooper, an OpenAI engineer and MCP steering committee member, summarized it plainly: “All the platforms had their own attempts like function calling, plugin APIs, extensions, but they just didn’t get much traction.” This wasn’t a tooling problem. It was an architecture problem. Connecting a model to the realtime web, a database, ticketing system, search index, or CI pipeline required bespoke code that often broke with the next model update. Developers had to write deep integration glue one platform at a time. As David Soria Parra, a senior engineer at Anthropic and one of the original architects of MCP, put it, the industry was running headfirst into an n×m integration problem with too many clients, too many systems, and no shared protocol to connect them. In practical terms, the n×m integration problem describes a world where every model client (n) must integrate separately with every tool, service, or system developers rely on (m). This would mean five different AI clients talking to ten internal systems, resulting in fifty bespoke integrations—each with different semantics, authentication flows, and failure modes. MCP collapses this by defining a single, vendor-neutral protocol that both clients and tools can speak. With something like GitHub Copilot, where we are connecting to all of the frontier labs models and developers using Copilot, we also need to connect to hundreds of systems as part of their developer platform. This was not just an integration challenge, but an innovation challenge. And the absence of a standard wasn’t just inefficient; it slowed real-world adoption. In regulated industries like finance, healthcare, security, developers needed secure, auditable, cross-platform ways to let models communicate with systems. What they got instead were proprietary plugin ecosystems with unclear trust boundaries. MCP: A protocol built for how developers work Across the industry including at Anthropic, GitHub, Microsoft, and others, engineers kept running into the same wall: reliably connecting models to context and tools. Inside Anthropic, teams noticed that their internal prototypes kept converging on similar patterns for requesting data, invoking tools, and handling long-running tasks. Soria Parra described MCP’s origin simply: it was a way to standardize patterns Anthropic engineers were reinventing. MCP distilled those patterns into a protocol designed around communication, or how models and systems talk to each other, request context, and execute tools. Anthropic’s Jerome Swanwick recalled an early internal hackathon where “every entry was built on MCP … went viral internally.” That early developer traction became the seed. Once Anthropic released MCP publicly alongside high-quality reference servers, we saw the value immediately, and it was clear that the broader community understood the value immediately. MCP offered a shared way for models to communicate with external systems, regardless of client, runtime, or vendor. Why MCP clicked: Built for real developer workflows When MCP launched, adoption was immediate and unlike any standard I have seen before. Developers building AI-powered tools and agents had already experienced the pain MCP solved. As Microsoft’s Den Delimarsky, a principal engineer and core MCP steering committee member focused on security and OAuth, said: “It just clicked. I got the problem they were trying to solve; I got why this needs to exist.” Within weeks, contributors from Anthropic, Microsoft, GitHub, OpenAI, and independent developers began expanding and hardening the protocol. Over the next nine months, the community added: OAuth flows for secure, remote servers Sampling semantics (These help ensure consistent model behavior when tools are invoked or context is requested, giving developers more predictable execution across different MCP clients.) Refined tool schemas Consistent server discovery patterns Expanded reference implementations Improving long-running task support Long-running task APIs are a critical feature. They allow builds, indexing operations, deployments, and other multi-minute jobs to be tracked predictably, without polling hacks or custom callback channels. This was essential for the long-running AI agent workflows that we now see today. Delimarsky’s OAuth work also became an inflection point. Prior to it, most MCP servers ran locally, which limited usage in enterprise environments and caused installation friction. OAuth enabled remote MCP servers, unlocking secure, compliant integrations at scale. This shift is what made MCP viable for multi-machine orchestration, shared enterprise services, and non-local infrastructure. Just as importantly, OAuth gives MCP a familiar and proven security model with no proprietary token formats or ad-hoc trust flows. That makes it significantly easier to adopt inside existing enterprise authentication stacks. Similarly, the MCP Registry—developed in the open by the MCP community with contributions and tooling support from Anthropic, GitHub, and others—gave developers a discoverability layer and gave enterprises governance control. Toby Padilla, who leads MCP Server and Registry efforts at GitHub, described this as a way to ensure “developers can find high-quality servers, and enterprises can control what their users adopt.” But no single company drove MCP’s trajectory. What stands out across all my conversations with the community is the sense of shared stewardship. Cooper articulated it clearly: “I don’t meet with Anthropic, I meet with David. And I don’t meet with Google, I meet with Che.” The work was never about corporate boundaries. It was about the protocol. This collaborative culture, reminiscent of the early days of the web, is the absolute best of open source. It’s also why, in my opinion, MCP spread so quickly. Developer momentum: MCP enters the Octoverse The 2025 Octoverse report, our annual deep dive into open source and public activity on GitHub, highlights an unprecedented surge in AI development: 1.13M public repositories now import an LLM SDK (+178% YoY) 693k new AI repositories were created this year 6M+ monthly commits to AI repositories Tools like vllm, ollama, continue, aider, cline, and ragflow dominated fastest-growing repos Standards are emerging in real time with MCP alone, hitting 37k stars in under eight months These signals tell a clear story: developers aren’t just experimenting with LLMs, they’re operationalizing them. With hundreds of thousands of developers building AI agents, local runners, pipelines, and inference stacks, the ecosystem needs consistent ways to connect models to tools, services, and context. MCP isn’t riding the wave. The protocol aligns with where developers already are and where the ecosystem is heading. The Linux Foundation move: The protocol becomes infrastructure As MCP adoption accelerated, the need for neutral governance became unavoidable. Openness is what drove its initial adoption, but that also demands shared stewardship—especially once multiple LLM providers, tool builders, and enterprise teams began depending on the protocol. By transitioning governance to the Linux Foundation, Anthropic and the MCP steering committee are signaling that MCP has reached the maturity threshold of a true industry standard. Open, vendor-neutral governance offers everyone: 1. Long-term stability A protocol is only as strong as its longevity. Linux Foundation’s backing reduces risk for teams adopting MCP for deep integrations. 2. Equal participation Whether you’re a cloud provider, startup, or individual maintainer, Linux Foundation governance processes support equal contribution rights and transparent evolution. 3. Compatibility guarantees As more clients, servers, and agent frameworks rely on MCP, compatibility becomes as important as the protocol itself. 4. The safety of an open standard In an era where AI is increasingly part of regulated workloads, neutral governance makes MCP a safer bet for enterprises. MCP is now on the same path as technologies like Kubernetes, SPDX, GraphQL, and the CNCF stack—critical infrastructure maintained in the open. Taken together, this move aligns with the Agentic AI Foundation’s intention to bring together multiple model providers, platform teams, enterprise tool builders, and independent developers under a shared, neutral process. What MCP unlocks for developers today Developers often ask: “What do I actually get from adopting MCP?” Here’s the concrete value as I see it: 1. One server, many clients Expose a tool once. Use it across multiple AI clients, agents, shells, and IDEs. No more bespoke function-calling adapters per model provider. 2. Predictable, testable tool invocation MCP’s schemas make tool interaction debuggable and reliable, which is closer to API contracts than prompt engineering. 3. A protocol for agent-native workloads As Octoverse shows, agent workflows are moving into mainstream engineering: 1M+ agent-authored pull requests via GitHub Copilot coding agent alone in the five months since it was released Rapid growth of key AI projects like vllm and ragflow Local inference tools exploding in popularity Agents need structured ways to call tools and fetch context. MCP provides exactly that. 4. Secure, remote execution OAuth and remote-server support mean MCP works for: Enterprises Regulated workloads Multi-machine orchestration Shared internal tools 5. A growing ecosystem of servers With a growing set of community and vendor-maintained MCP servers (and more added weekly), developers can connect to: Issue trackers Code search and repositories Observability systems Internal APIs Cloud services Personal productivity tools Soria Parra emphasized that MCP isn’t just for LLMs calling tools. It can also invert the workflow by letting developers use a model to understand their own complex systems. 6. It matches how developers already build software MCP aligns with developer habits: Schema-driven interfaces (JSON Schema–based) Reproducible workflows Containerized infrastructure CI/CD environments Distributed systems Local-first testing Most developers don’t want magical behavior—they want predictable systems. MCP meets that expectation. MCP also intentionally mirrors patterns developers already know from API design, distributed systems, and standards evolution—favoring predictable, contract-based interactions over “magical” model behaviors. What happens next The Linux Foundation announcement is the beginning of MCP’s next phase, and the move signals: Broader contribution More formal governance Deeper integration into agent frameworks Cross-platform interoperability An expanding ecosystem of servers and clients Given the global developer growth highlighted in Octoverse—36M new developers on GitHub alone this year—the industry needs shared standards for AI tooling more urgently than ever. MCP is poised to be part of that future. It’s a stable, open protocol that lets developers build agents, tools, and workflows without vendor lock-in or proprietary extensions. The next era of software will be shaped not just by models, but by how models interact with systems. MCP is becoming the connective tissue for that interaction. And with its new home in the Linux Foundation, that future now belongs to the community. Explore the MCP specification and the GitHub MCP Registry to join the community working on the next phase of the protocol. The post MCP joins the Linux Foundation: What this means for developers building the next era of AI tools and agents appeared first on The GitHub Blog.
Speed is nothing without control: How to keep quality high in the AI era
AI can help you build faster than ever, but it can also produce bugs, issues, and problems. Use these strategies to keep your speed without losing control of your code. The post Speed is nothing without control: How to keep quality high in the AI era appeared first on The GitHub Blog.
What’s the point of moving faster if you can’t trust the code you’re shipping? We’ve all been using AI in our workflows for a while now, and there’s no denying how much faster everyday development has become. Tasks that once took hours now finish in minutes. Entire features come together before you’ve even finished your morning coffee. But we’ve also experienced the other side of that speed: when AI is used without clear direction or guardrails, it can generate what’s often called AI slop—semi-functional code stitched together without context, quietly piling up bugs, broken imports, and technical debt. In this new era, being fast isn’t enough. Precision and quality are what set teams apart. “The best drivers aren’t the ones who simply go the fastest, but the ones who stay smooth and in control at high speed,” said Marcelo Oliveira, GitHub VP of product at GitHub Universe 2025. “Speed and control aren’t trade-offs. They reinforce each other.” So how do you get the best of both? How do you move fast and keep your code clean, reliable, and firmly under your direction? Here are three essential strategies: Tip #1: Treat speed and quality as a package deal It’s very easy to accept AI-generated code that appears polished but hides underlying issues. However, speed without quality doesn’t help you ship faster, it just increases the risk of issues compounding down the road. That’s why the teams and organizations that succeed are the ones that pair AI-driven velocity with real guardrails. And that’s exactly what GitHub Code Quality (currently in public preview) helps you do. GitHub Code Quality is an AI- and CodeQL-powered analysis tool that surfaces maintainability issues, reliability risks, and technical debt across your codebase, right as you work. Here’s how to start using it: Enable with one click Turn it on at the repository level and GitHub will analyze your code using a combination of CodeQL and LLM-based detection. This will give you a clear view of the maintainability and reliability issues in your codebase. Get automatic fixes inside every pull request As soon as you open a pull request, GitHub Code Quality flags unused variables, duplicated logic, runtime errors, and more. Here’s an example of pull request code that “works,” but isn’t production-ready: // fuelCalculator.js export function calculateFuelUsage(laps, fuelPerLap) { const lastLap = laps[laps.length - 1]; // unused variable function totalFuel(laps, fuelPerLap) { return laps.length * fuelPerLap; } // duplicated function function totalFuel(laps, fuelPerLap) { return laps.length * fuelPerLap; } return totalFuel(laps, fuelPerLap); GitHub Code Quality responds with AI + CodeQL-powered suggestions, including a one-click fix: -export function calculateFuelUsage(laps, fuelPerLap) { - const lastLap = laps[laps.length - 1]; // unused variable - - function totalFuel(laps, fuelPerLap) { - return laps.length * fuelPerLap; - } - - // duplicated function - function totalFuel(laps, fuelPerLap) { - return laps.length * fuelPerLap; - } - - return totalFuel(laps, fuelPerLap); -} +export function calculateFuelUsage(laps, fuelPerLap) { + if (!Array.isArray(laps) || typeof fuelPerLap !== "number") { + throw new Error("Invalid input"); + } + return laps.length * fuelPerLap; +} No triage or slowdown, just clean, reliable code. Enforce your quality bar Rulesets let you block merges that don’t meet your team’s standards. This keeps quality consistent without relying on reviewer willpower and without killing your velocity. Reveal (and fix) legacy technical debt The AI Findings page highlights issues in files your team is already working in, helping you fix problems while they’re top of mind and reduce context switching. Bottom line: AI gives you speed. GitHub Code Quality gives you control. Together, they let you move faster and build better without ever trading one for the other. Learn more about GitHub Code Quality 👉 Tip #2: Be the driver, not the passenger AI can generate code quickly, but quality has never come from automation alone. GitHub has always believed in giving you the tools to write your best code—from Copilot in the IDE, to GitHub Copilot code review in pull requests, to GitHub Code Quality—providing visibility into long-standing issues and tech debt, along with actionable fixes to help you address them. These features give you the power to set direction, standards, and constraints. The clearer your intent, the better AI can support you. Here’s a simple prompting framework that helps you do just that: Set the goal, not just the action Think of your prompts like giving direction to another engineer: the more clarity you provide, the better the final output. Bad prompt: refactor this file Better prompt: refactor this file to improve readability and maintainability while preserving functionality, no breaking changes allowed Establish constraints Examples: “No third-party dependencies” “Must be backwards compatible with v1.7” “Follow existing naming patterns” Provide reference context Link to related files, docs, existing tests, or architectural decisions. Decide the format of the output Pull request, diff, patch, commentary, or code block. With GitHub Copilot coding agent, you can even assign multi-step tasks like: Create a new helper function for formatting currency across the app. - Must handle USD and EUR - Round up to two decimals - Add three unit tests - Do not modify existing price parser - Return as a pull request Notice how you remain accountable for the thinking and the agent becomes accountable for the doing. Bottom line: AI accelerates execution, but your clarity—and GitHub’s guardrails—are what turn that acceleration into high-quality software. Learn more about coding agent 👉 Tip #3: Build visible proof of your thinking, not just your output As AI takes on more execution work, what sets effective developers apart is how clearly they communicate decisions, trade-offs, and reasoning. It’s no longer enough to write code, you need to show how you think, evaluate, and approach problems across the lifecycle of a feature. Here’s a best practice to level up your documentation signal: Create an issue that captures the why Write a brief summary of the problem, what success looks like, constraints, and any risks. Name your branch clearly and commit thoughtfully Use meaningful names and commit messages that narrate your reasoning, not just your keystrokes. Use Copilot and coding agent to build, then document decisions Include short notes on why you chose one approach over another and what alternatives you considered. Open a pull request with signal-rich context Add a short “Why,” “What changed,” and “Trade-offs” section, plus screenshots or test notes. For example, instead of: Added dark mode toggle Try this: - Added dark mode toggle to improve accessibility and user preference support. - Chose localStorage for persistence to avoid server dependency. - Kept styling changes scoped to avoid side effects on existing themes. Bottom line: Your code shows what you did, but your documentation shows why it matters. In this new AI era, the latter is just as critical as the former. Learn more about effective documentation 👉 Moving forward together At the end of the day, quality is everything. While AI may accelerate the pace of work, it can also turn that speed on its head if the output isn’t guided with intent. But when you combine AI with clear direction, strong guardrails, and visible thinking, you help your team deliver cleaner, more reliable code at scale—and position your organization to move quickly without compromising on what matters most. Get started with GitHub Copilot > The post Speed is nothing without control: How to keep quality high in the AI era appeared first on The GitHub Blog.
The new identity of a developer: What changes and what doesn’t in the AI era
Discover how advanced AI users are redefining software development—shifting from code producers to strategic orchestrators—through delegation, verification, and a new era of AI-fluent engineering. The post The new identity of a developer: What changes and what doesn’t in the AI era appeared first on The GitHub Blog.
For the past four years, the conversation about AI and software development has moved faster than most people can track. Every week, there is a new tool, a new benchmark, a new paper, or a new claim about what AI will or won’t replace. There is certainly noise, but even if sometimes data seems inconclusive or contradictory, we still know more now than three years ago about AI adoption. With four years of AI adoption under our belt, we are also able to start seeing the shift in what it means to be a software developer. I lead key research initiatives at GitHub where I focus especially on understanding developers’ behavior, sentiment, and motivations. The time we are in with AI is pivotal, and I interview developers regularly to capture their current perspective. Most recently I conducted interviews to understand how developers see their identity, work, and preferences change as they work more closely than ever with AI. The TL;DR? The developers who have gone furthest with AI are working differently. They describe their role less as “code producer” and more as “creative director of code,” where the core skill is not implementation, but orchestration and verification. Let’s dive in for the more detailed findings, alongside key stats from the 2025 Octoverse report. What were the interviews about, and who did we recruit? As developers work more with AI and get familiar with its capabilities, their relationship with coding—an activity central to the developer identity—changes. How do developers feel about that? What is their new role as developers, and what skills are important? In our interviews, we heard from 22 advanced users of AI about their workflows, how they arrived at them, and their outlook on AI-assisted software development. We define “advanced AI users” as developers who use AI for the majority of their coding, draw on several AI tools in parallel, and apply AI across a wide range of development tasks. We provide a more detailed note on who we recruited at the end of this post. 2023: Curiosity, hesitation, and identity questions Two years ago, we interviewed developers to understand their openness to having AI more deeply integrated into their workflow. At the time, code completions had become mainstream and agents were only a whisper in the AI space. Back then, we found developers eager to get AI’s help with complex tasks, not just filling in boilerplate code. Developers were most interested in: Summaries and explanations to speed up how they make sense of code related to their task, and AI-suggested plans of action that reduce activation energy. In contrast, developers wanted AI to stay at arm’s length (at least) on decision-making and generating code that implements whole tasks. The explanation of that qualitative trend from 2023 is important. At the time, AI was seen as still unreliable for large implementations. But there was more to the rationale. Developers were reluctant to cede implementation because it was core to their identity. That was our baseline in 2023, which we documented in a research-focused blog. Since then, developers’ relationship with AI has changed (and continues to evolve), making each view a snapshot. That makes it critical to update our understanding as the tools have evolved and developer behavior has consequently changed. One of the interviewees in 2023 wrapped their hesitation in a question: “If I’m not writing the code, what am I doing?” That question has been important to answer since then, especially as we hear future-looking statements about AI writing 90% of code. If we don’t describe what developers do if/when AI does the bulk of implementation, why would they ever be interested in embracing AI meaningfully for their work? 2025: Fluency, delegation, and a new center of gravity Fast forward to this year: we interviewed developers again, and this time, we focused on advanced users of AI. This was, in part, because we found a growing number of influential developer blogs focused on agentic workflows. They described sophisticated setups over time, and signalled optimism around coding with and delegating to AI (see here, here, and here for just a few examples). It was important to capture that rationale, assess if/how it’s shared by more AI-experienced developers, and understand what fuels it. The developers we spoke with described their agentic workflows and how they reached AI fluency: relentless trial-and-error and pushing themselves to use AI tools every day for everything. That was their method for gaining confidence in their AI strategy, from identifying which tools would be helpful for which task to prompting and iterating effectively. The tools did not feel magical or intuitive all the time, but their determination eventually led them to make more informed decisions: for example, when to work synchronously with an agent, when to have multiple agents working in parallel, or when to prompt an AI tool to “interview” them for more information (and how to check what it understands). None of these AI strategists started out that way. Most of them started as AI skeptics or timid explorers. As we synthesized the interviewees’ reported experiences, we identified that they matured in their knowledge and use of AI moving from Skeptic, to Explorer, to Collaborator, to Strategist. <img data-recalc-dims="1" loading="lazy" decoding="async" height="576" width="1024" src="https://github.blog/wp-content/uploads/2025/12/ai-fluency-stages-1-2.png?resize=1024%2C576" alt="Side-by-side cards illustrating Stage 1 ‘AI Skeptic’ and Stage 2 ‘AI Explorer.’ The left card shows a skeptical face emoji and describes low tolerance for iteration and errors. The right card shows a compass emoji and describes developers who use AI for quick wins and gradually build trust. Decorative GitHub-style cube artwork appears on the right with colorful radiating lines." class="wp-image-92725" srcset="https://github.blog/wp-content/uploads/2025/12/ai-fluency-stages-1-2.png?w=3840 3840w, https://github.blog/wp-content/uploads/2025/12/ai-fluency-stages-1-2.png?w=300 300w, https://github.blog/wp-content/uploads/2025/12/ai-fluency-stages-1-2.png?w=768 768w, https://github.blog/wp-content/uploads/2025/12/ai-fluency-stages-1-2.png?w=1024 1024w, https://github.blog/wp-content/uploads/2025/12/ai-fluency-stages-1-2.png?w=1536 1536w, https://github.blog/wp-content/uploads/2025/12/ai-fluency-stages-1-2.png?w=2048 2048w, https://github.blog/wp-content/uploads/2025/12/ai-fluency-stages-1-2.png?w=3000 3000w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> <img data-recalc-dims="1" loading="lazy" decoding="async" height="576" width="1024" src="https://github.blog/wp-content/uploads/2025/12/ai-fluency-stages-3-4.png?resize=1024%2C576" alt="Side-by-side cards illustrating Stage 3 ‘AI Collaborator’ and Stage 4 ‘AI Strategist.’ The left card shows a handshake emoji and describes developers who co-create with AI and iterate frequently. The right card shows a target emoji and outlines developers who plan, orchestrate, and verify work with high iteration tolerance and multi-agent workflows. Decorative GitHub-style green cube artwork appears on the right side." class="wp-image-92726" srcset="https://github.blog/wp-content/uploads/2025/12/ai-fluency-stages-3-4.png?w=3840 3840w, https://github.blog/wp-content/uploads/2025/12/ai-fluency-stages-3-4.png?w=300 300w, https://github.blog/wp-content/uploads/2025/12/ai-fluency-stages-3-4.png?w=768 768w, https://github.blog/wp-content/uploads/2025/12/ai-fluency-stages-3-4.png?w=1024 1024w, https://github.blog/wp-content/uploads/2025/12/ai-fluency-stages-3-4.png?w=1536 1536w, https://github.blog/wp-content/uploads/2025/12/ai-fluency-stages-3-4.png?w=2048 2048w, https://github.blog/wp-content/uploads/2025/12/ai-fluency-stages-3-4.png?w=3000 3000w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> Each stage came with a better understanding of capabilities and limitations, and different expectations around speed, iteration, and accuracy. A developer that used AI to co-create solutions (a stage we call “AI Collaborator”) knew to expect back-and-forth iteration with an agent. But when they were using exclusively code completions or boilerplate snippets (probably an “AI Skeptic”), they expected low-latency, one-shot success—or they quickly reverted to doing things without AI. Interestingly, each stage in a developer’s comfort with AI had a matching evolution in the tools and workflows they felt ready to adopt: completions, then a chat and copy-paste workflow, then AI-enabled IDEs, and then multi-agent workflows. The advanced AI users we interviewed used several AI tools and agents in parallel, relying on a self-configured AI stack. What looks from the outside like “new features” was, from the inside, a gradual widening of what developers were willing to delegate. By the time they reached that latest stage, the nature of their work had changed in a noticeable way. At the Strategist stage, their development sessions looked very different from the days when they worked with AI as autocomplete. They focused less on writing code in the traditional sense, and more on defining intent, guiding agents, resolving ambiguity, and validating correctness. Delegation and verification became the primary activities as they felt the center of gravity shift in their work. This transition is the identity shift. Developers who once wondered, “If I’m not the one writing the code, what am I doing?” now answer that question in practice: they set direction, constraints, architecture, and standards. They shift—using a phrase we first heard in interviews—from code producers to creative directors of code. And, crucially, the developers who reach this level do not describe it as a loss of craft but as a reinvention of it. This shift is imperceivable unless experienced. The path to becoming AI-fluent is paved with trial and error, frustration, a gradual build up of trust, and ah-ha moments when steps start working as intended and become workflows. Most of the interviewees told us that their sentiment toward the future of software development changed only after they saw the shift in their own work. What once felt like an existential threat began to feel like a strategic advantage. Their outlook became more optimistic as they learned how to use AI tools with confidence and agency. Ecosystem signals that reinforce the shift These interviews are early signals about the impact of AI in developer workflows from the most advanced users. But we are already seeing their practices diffuse outward. Developers are beginning to make different choices because AI is present in the workflow and they assume it will increase. Choices about abstractions, code style, testing strategy, and even programming languages are shifting as developers adjust to a world where delegation is normal and verification is foundational. The 2025 Octoverse report captured one striking example of this shift: TypeScript became the #1 programming language by monthly contributors on GitHub in August 2025. Many factors influence language popularity, but this particular rise says something important about the developer–AI relationship. TypeScript brings clarity and structure to a codebase, expresses intent more explicitly, and provides a type system that helps both developers and AI reason about correctness. In interviews, developers mentioned needing to give AI more guardrails and more context to reduce ambiguity and make verification easier. When AI writes large proportions of code, languages that enforce structure and surface errors early become a strategic choice. The shift toward TypeScript is a way of choosing languages that make delegation safer. We also saw another telling signal in Octoverse: 80% of new developers on GitHub in 2025 used Copilot within their first week. This signals that developers are getting their first contact with AI at the beginning of their journey. If early contact brings early confidence, we may see developers reach more advanced stages of AI maturity sooner than previous cohorts did. Another compelling data point was shared at GitHub Universe this year: within the first five months of the release of Copilot coding agent, GitHub’s autonomous agent that can generate pull requests, issues, or tasks, developers used it to merge more than 1 million pull requests. Each one of those pull requests represents a small story of delegation and verification. A developer had to imagine the change, articulate intent, decompose the task, provide context, and set boundaries. They had to review, test, and validate the output before merging. Seen collectively, these pull requests are a measure of developers stepping into a new role. They show developers trying AI with increasingly meaningful units of work, and they show developers gradually building trust while taking responsibility for ensuring those units are correct. That brings us to the natural next question: what skills support this new identity and role? The skills that support developers’ new role As delegation and verification become the focus, the skills developers will need to rely on shift upward. The work moves from implementation to three layers where developers focus, described below: understanding the work, directing the work, and verifying the work. Across interviews, developers consistently described strengths in all three layers as essential to working confidently with AI. 1. Understanding the work These skills help developers determine what needs to be built, why, and how to shape the problem before any code comes into play. AI fluency Developers need an intuitive grasp of how different AI systems behave: what they are good at, where they fail, how much context they require, and how to adjust workflows as capabilities evolve. This fluency comes from repeated use, experimentation, and pattern recognition. With increased AI fluency developers are able to compose their AI stack: tools and features that they use for different projects and tasks, or in parallel configurations for end-to-end workflows. Fundamentals Even as AI takes on more implementation, deep technical understanding remains essential for developers. Knowledge of algorithms, data structures, and system behavior enables developers to evaluate complex output, diagnose hidden issues, and determine whether an AI-generated solution is sound. Product understanding Developers will need to increasingly think at the level of outcomes and systems, not snippets. This includes understanding user needs, defining requirements clearly, and reasoning about how a change affects the product as a whole. Framing work from an outcome perspective ensures what is delegated to AI aligns with the actual goals of the feature or system. 2. Directing the work These skills enable developers to guide AI systems, tools, and agents so that the work moves forward effectively and safely. Delegation and agent orchestration Effective delegation requires clear problem framing, breaking work into meaningful units, providing the right context, articulating constraints, and setting success criteria. Advanced developers also decide when to collaborate interactively with an agent, versus running tasks independently in the background. Strong communication—precise, thorough, and structured—turns delegation into a repeatable practice. Developer–AI collaboration Synchronous collaboration with agents depends on tight, iterative loops: setting stopping points, giving corrective feedback, asking agents to self critique, or prompting them to ask clarifying questions. Some developers described instructing agents to interview them first, as a way to build shared understanding before generating any code. Architecture and systems design As AI handles more low-level code generation, architecture becomes even more important. Developers design the scaffolding around the work: system boundaries, patterns, data flow, and component interactions. Clear architecture gives agents a safer, more structured environment and makes integration more reliable. 3. Verifying the work This skill category is becoming part of the defining center of the developer role: ensuring correct and high-quality outputs. Verification and quality control AI-generated output requires rigorous scrutiny. Developers validate behavior through reviews, tests, security checks, and assumption checking. Many reported spending more time verifying work than generating it, and feeling this was the right distribution of effort. Strong verification practices are what make larger-scale delegation possible, and allow developers to gradually trust agents with meaningful units of work. Verification always was a step of the process, usually at the end. In AI-supported workflows, it becomes a continuous practice. Annie Vella, a Distinguished Engineer at Westpac NZ, recently wrote an exceptional post about how the software engineer role changes with AI and the new competency map for engineers building systems with LLMs and agents. Annie’s experience (and research) share many similarities with the findings from our interviews with advanced AI users. A worthy read! This year’s snapshot What started as curiosity has now become preparedness. Developers see their profession changing in real time. They believe that AI will continue to evolve rapidly, and that the pace of change will not slow. Many are adapting to the change by building AI fluency, practicing confident orchestration of tools and agents, and treating delegation and verification as core parts of their craft. They see these skills as a competitive advantage, one that will define the next era of software development. The value of a developer is shifting toward judgment, architecture, reasoning, and responsibility for outcomes, moving their work up the ladder of abstraction. As we build tools to support developers and look to measure AI’s impact, it’s important that our perspective matches the evolution of their work and identity. How to track the evolving landscape There is no single source of truth for how AI is changing software development, but there are reliable signals: Large-scale data reports (such as GitHub’s Octoverse report) show macro-level adoption and behavior patterns. Longitudinal industry studies (e.g., DORA) reveal where productivity gains stall or compound. Field research and developer interviews help us interpret big data correctly and identify trends before we see them at scale. Open source activity is a leading indicator of what workflows developers adopt first, before enterprises (you can track open source activity on GitHub in the Innovation Graph, a public data resource we update quarterly). Who did we interview? In this round of interviews, we recruited 22 US-based participants working full time as software engineers. We used the Respondent.io platform for recruitment, and there was no requirement for interviewees to be GitHub users. Participants were selected based on a screener that assessed the depth and breadth of their AI use. We included only those who used AI for more than half of their coding work, used at least four AI tools from the thirteen we listed, and indicated experience with all of the advanced AI-assisted development activities included in the screener. Participants worked in organizations of various sizes (55% in large or extra-large enterprises, 41% in small- or medium-sized enterprises, and 4% in a startup). Finally, we recruited participants across the spectrum of years of professional experience (14% had 0-5 years of experience, 41% had 6-10 years, 27% had 11-15 years, and 18% had over 16 years of experience). We are grateful to all the developers who participated in the interviews for their invaluable input. The post The new identity of a developer: What changes and what doesn’t in the AI era appeared first on The GitHub Blog.
How to use GitHub Copilot Spaces to debug issues faster
Follow this step-by-step guide to learn how to debug your issues using GitHub Copilot Spaces and Copilot coding agent. The post How to use GitHub Copilot Spaces to debug issues faster appeared first on The GitHub Blog.
Every developer knows this pain: you open an issue, and before you can write a single line of code, you’re hunting. You’re digging through old pull requests, searching for that design doc from three months ago, trying to remember which file has the security guidelines. That hunting phase? It takes forever. And it’s not even the actual work. And even if you want to bring AI into the picture, GitHub Copilot still needs the same thing you do: context. Without it, you get generic answers that don’t understand your codebase. GitHub Copilot Spaces fixes that. Spaces gives GitHub Copilot the project knowledge it needs—files, pull requests, issues, repos—so its responses are grounded in your actual code, not guesses. Are you a visual learner? Watch the full demo below. 👇 What is a space, again? Think of a space as a project knowledge bundle. You curate the files, docs, and decisions that matter for your project, and Copilot uses all of that when generating plans, explanations, or pull requests. You can: Add entire repositories or specific files, pull requests and issues (just paste the URL) Include text content like notes, video transcripts, or Slack messages Add design docs and architecture decisions Trigger Copilot coding agent directly from the space Use the space in your IDE through the GitHub MCP server The best part? Link it once and forget about it. Spaces automatically stay synced with the linked content. When your codebase updates, your space updates too. How to debug issues with spaces: 1. Start with an issue A contributor opened an issue reporting an unsafe usage of check_call in your project. As a maintainer, you might not know the best way to fix it immediately. On your own, you’d start by searching the repo, checking past pull requests, and combing through security guidelines just to figure out where to begin. With Spaces, you don’t have to do that manually. Create a space, add the issue and the key files or docs, and let Copilot reason across everything at once. 2. Create a space for your project Inside the space, add: Design patterns (e.g., /docs/security/check-patterns.md, /docs/design/architecture-overview.md) Security guidelines Accessibility recommendations The entire repository (for broad coverage) or a curated set of the most relevant files for your specific use case. Spaces work best when you’re intentional about what you include. The URL to the issue itself 3. Add Instructions for Copilot Each space includes an Instructions panel. This is where you tell Copilot how you want it to work inside your project. Here are some example instructions that will help with our task at hand: You are an experienced engineer working on this codebase. Always ground your answers in the linked docs and sources in this space. Before writing code, produce a 3–5 step plan that includes: - The goal - The approach - The execution steps Cite the exact files that justify your recommendations. After I approve a plan, use the Copilot coding agent to propose a PR. These instructions keep Copilot consistent. It won’t hallucinate patterns that don’t exist in your repo because you’ve told it to cite its sources. 🌟 Related reading: How to write a great agents.md Learn best practices for building effective custom agents for Copilot, based on an analysis of over 2,500 repositories. Get the guide > 4. Ask Copilot to debug the issue With everything set up, ask Copilot: “Help me debug this issue.” Copilot already knows which issue you mean because it’s linked to the space. It parses through all the sources, then returns a clear plan: Goal: Fix unsafe usage of runBinaryCheck to ensure input paths are validated. Approach: Search the repo for usages of runBinaryCheck Compare each usage to the safe pattern in the security docs Identify the required refactor Prepare a diff for each file with unsafe usage This isn’t a generic LLM answer. It’s grounded in the actual project context. 5. Generate the pull request Once you approve the plan, tell Copilot: “Propose code changes using Copilot coding agent.” The agent generates a pull request with: The before version and the after version An explanation of what changed References to the exact files that informed the fix The instructions that guided its choices Every file in the pull request shows which source informed the suggestion. You can audit the reasoning before you merge. 6. Iterate if you need to Not happy with something? Mention @copilot in the pull request comments to iterate on the existing pull request, or go back to the space to generate a fresh one. Keep working with Copilot until you get exactly what you need. 7. Share your space with your team Spaces are private by default. But you can share them with specific individuals, your entire team, or your whole organization (if admins allow it). Enterprise admins control who can share what, so you stay aligned with your company’s security policies. Use GitHub Copilot Spaces from your IDE Spaces are now available in your IDE via the GitHub MCP Server. Install the MCP server, and you can call your spaces directly from your editor. Same curated context, same grounded answers, but right where you’re already working. Being able to call a space from the IDE has been a game changer for me. It lets me stay focused without switching between the browser and my editor, which cuts out a ton of friction in debugging. Coming soon Here’s what’s on the roadmap: Public API Image support Additional file types like doc/docx and PDFs Three ways teams are using spaces right now 1. Code generation and debugging. Use spaces with Copilot coding agent to generate pull requests aligned with your patterns, security rules, and architecture. 2. Planning features. Link issues, design docs, and repos to plan features and draft requirements. Ask Copilot for a technical plan and it generates a pull request. 3. Knowledge sharing and onboarding. Spaces become living knowledge bases. New engineers onboard faster. Existing engineers stop answering the same questions repeatedly. Try it on your next issue Here’s my challenge to you: Create a GitHub Copilot Space. Add one issue and three to four key files. Add simple instructions. Ask Copilot to analyze the issue and propose a debugging plan. Approve the plan. Trigger the coding agent to generate a pull request. You’ll see exactly how much time you save when Copilot actually knows your project. Your AI assistant should never lack the right context. That’s what spaces are for. Want to see the full demo? Watch the GitHub Checkout episode on Copilot Spaces and try GitHub Copilot Spaces. The post How to use GitHub Copilot Spaces to debug issues faster appeared first on The GitHub Blog.
Your stack, your rules: Introducing custom agents in GitHub Copilot for observability, IaC, and security
Use partner-built Copilot agents to debug, secure, and automate engineering workflows across your terminal, editor, and github.com. The post Your stack, your rules: Introducing custom agents in GitHub Copilot for observability, IaC, and security appeared first on The GitHub Blog.
Every engineering team has its unwritten rules. How you structure Terraform modules. Which dashboards you trust. How database migrations must be handled (never at midnight). And your work stretches across more than your editor into observability, security, CI/CD, and countless third-party tools. GitHub Copilot isn’t just here to help you write code. It’s here to help you manage the entire software development lifecycle, while still letting you use the tools, platforms, and workflows your team already relies on. Custom agents bring that full workflow into Copilot. We’re introducing a growing ecosystem of partner-built custom agents for the GitHub Copilot coding agent (plus the option to create your own). These agents understand your tools, workflows, and standards—and they work everywhere Copilot works: In your terminal through Copilot CLI for fast, end-to-end workflows In VS Code with Copilot Chat In github.com in the Copilot panel Let’s jump in. Run custom agents in the GitHub Copilot CLI Copilot CLI is the fastest way to run multi-step tasks, automate workflows, and integrate agents into scripts or CI. If you live in the terminal, custom agents feel like native extensions of your workflow. Get started with Copilot CLI > What custom agents actually are Custom agents are Markdown-defined domain experts that extend the Copilot coding agent across your tools and workflows. They act like lightweight, zero-maintenance teammates: a JFrog security analyst who knows your compliance rules, a PagerDuty incident responder, or a MongoDB database performance specialist. Defining one looks like this: --- name: readme-specialist description: Expert at creating and maintaining high-quality README documentation --- You are a documentation specialist focused on README files. Your expertise includes: - Creating clear, structured README files following best practices - Including all essential sections: installation, usage, contributing, license - Writing examples that are practical and easy to follow - Maintaining consistency with the project's tone and style Only work on README.md or documentation files—do not modify code files. Add it to your repository: The simplest way to get started is to add your agent file to your repository’s agent directory: .github/agents/readme-specialist.md Your agent appears instantly in: GitHub Copilot CLI github.com in the control plane VS Code in Copilot Chat You can also define agents at: Repository level: .github/agents/CUSTOM-AGENT-NAME.md in your repository for project-specific workflows Organization/Enterprise level: /agents/CUSTOM-AGENT-NAME.md in a .github or .github-private repository for broader availability across all repositories in your org Try a partner-built custom agent in under 60 seconds Custom agents are just Markdown files. Add it to your repository and run it from GitHub Copilot CLI, VS Code, or github.com. 1. Pick the agent you want to try. All partner-built agents are available today (and we have these in our repository, too), including: Observability: Dynatrace Expert, Elasticsearch agent Security: JFrog Security Agent, StackHawk Security Onboarding Databases: MongoDB Performance Advisor, Neon Migration Specialist, Neon Performance Analyzer, Neo4j Docker Client Generator DevOps & IaC: Terraform Agent, Arm Migration Agent, Octopus Release Notes Agent, DiffBlue Java Unit Test Custom Agent Incidents & project management: PagerDuty Incident Responder, Monday Bug Context Fixer Feature flags & experiments: LaunchDarkly Flag Cleanup, Amplitude Experiment Implementation Automation & APIs: Apify Integration Expert, Factory.ai Code Spec Custom Agent, Lingo.dev Internationalization Implementation Custom Agent 2. Add the agent to your repository. .github/agents/<agent-name>.agent.md 3. Use it. From the Copilot CLI: copilot --agent=<agent-name> --prompt "<task>" From your VS Code: Open Copilot Chat and select the agent Select the agent from the dropdown From github.com: Open the Copilot panel and select the Agents tab Choose the agent you added to your repository Describe your task Featured examples from our partners with real developer workflows Here are real engineering workflows, solved with a single command via custom agents. Trigger and resolve incidents faster (PagerDuty Incident Responder) copilot --agent=pagerduty-incident-responder \ --prompt "Summarize active incidents and propose the next investigation steps." Use this agent to: Pull context from PagerDuty alerts Generate a clear overview of incident state Recommend investigation paths Draft incident updates for your team Fix vulnerable dependencies and strengthen your supply chain (JFrog Security Agent) copilot --agent=jfrog-security \ --prompt "Scan for vulnerable dependencies and provide safe upgrade paths." Use this agent to: Identify vulnerable packages Provide recommended upgrade versions Patch dependency files directly Generate a clear, security-aware pull request summary Modernize database workflows and migrations (Neon) copilot --agent=neon-migration-specialist \ --prompt "Review this schema migration for safety and best practices." Use this agent to: Validate schema changes Avoid unsafe migrations Tune analytical workflows Optimize transformations and queries Speed up product experimentation and feature rollouts (Amplitude Experiment Implementation) copilot --agent=amplitude-experiment-implementation \ --prompt "Integrate an A/B test for this feature and generate tracking events." Use this agent to: Generate experiment scaffolding Insert clean, consistent event tracking Map variations to your product logic Ensure your data flows correctly into Amplitude Why this matters By encoding your team’s patterns, rules, and tool integrations into a reusable agent, Copilot actually understands how your team works—not just the code in front of it. Custom agents help: Keep patterns consistent (Terraform conventions, database rules, security standards, etc.) Stop repeating context by defining expectations once and reusing them everywhere Share expertise automatically so the entire team can follow best practices (even when your subject matter expert is on vacation or in a different timezone) Work directly with your tools using Model Context Protocol (MCP) servers to pull data from your DevOps, security, and observability systems The full catalog of custom agents from our partners We partnered across the ecosystem to create custom agents that solve real engineering problems. Observability and monitoring Dynatrace Observability and Security Expert: Configure and optimize Dynatrace monitoring for your applications Elasticsearch Remediation Agent: Handle Elasticsearch configuration, query optimization, and observability setup Security and compliance JFrog Security Agent: Identify and remediate security vulnerabilities in your dependencies StackHawk Security Onboarding: Set up dynamic application security testing Database and data management MongoDB Performance Advisor: Analyze and optimize MongoDB query performance Neon Migration Specialist: Migrate databases to Neon’s serverless Postgres Neon Performance Analyzer: Find bottlenecks and optimization opportunities Neo4j Docker Client Generator: Generate Docker-based client code for Neo4j graph databases DevOps and infrastructure Terraform Infrastructure Agent: Write, review, and optimize Terraform infrastructure as code Arm Migration Agent: Migrate applications to Arm-based architectures Octopus Release Notes Expert: Generate comprehensive release notes from deployment data DiffBlue Java Unit Test Custom Agent: Generate fast, reliable Java unit tests using DiffBlue’s AI-powered test generation engine to improve coverage and catch regressions automatically Incident response and project management PagerDuty Incident Responder: Triage and respond to production incidents Monday Bug Context Fixer: Pull context from monday.com to resolve bugs faster Feature management and experimentation LaunchDarkly Flag Cleanup: Identify and safely remove obsolete feature flags Amplitude Experiment Implementation: Implement A/B tests and experiments API integration and automation Apify Integration Expert: Integrate web scraping and automation workflows Lingo.dev Internationalization Implementation Custom Agent: Detect, extract, and implement internationalization patterns across your codebase for seamless localization Factory.ai Code Spec Custom Agent: Install, configure, and automate development workflows using Droid CLI for CI/CD pipelines Run any of them with the following command: copilot --agent=<agent-name> --prompt "<task>" Get started Custom agents shift Copilot from “help write this code” to “help build software the way our team builds software.” These agents are also available now for all GitHub Copilot users, and you should try one: copilot --agent=terraform-agent --prompt "Review my IaC for issues" Explore all the partner agents in the awesome-copilot repository (with plenty of real-world examples). Give us feedback to let us know what you think of custom agents in GitHub Copilot! Learn how to build your own custom agent with our documentation on creating custom agents (and how they work). The post Your stack, your rules: Introducing custom agents in GitHub Copilot for observability, IaC, and security appeared first on The GitHub Blog.
“The local-first rebellion”: How Home Assistant became the most important project in your house
Learn how one of GitHub’s fastest-growing open source projects is redefining smart homes without the cloud. The post “The local-first rebellion”: How Home Assistant became the most important project in your house appeared first on The GitHub Blog.
Franck Nijhof—better known as Frenck—is one of those maintainers who ended up at the center of a massive open source project not because he chased the spotlight, but because he helped hold together one of the most active, culturally important, and technically demanding open source ecosystems on the planet. As a lead of Home Assistant and a GitHub Star, Frenck guides the project that didn’t just grow. It exploded. This year’s Octoverse report confirms it: Home Assistant was one of the fastest-growing open source projects by contributors, ranking alongside AI infrastructure giants like vLLM, Ollama, and Transformers. It also appeared in the top projects attracting first-time contributors, sitting beside massive developer platforms such as VS Code. In a year dominated by AI tooling, agentic workflows, and typed language growth, Home Assistant stood out as something else entirely: an open source system for the physical world that grew at an AI-era pace. The scale is wild. Home Assistant is now running in more than 2 million households, orchestrating everything from thermostats and door locks to motion sensors and lighting. All on users’ own hardware, not the cloud. The contributor base behind that growth is just as remarkable: 21,000 contributors in a single year, feeding into one of GitHub’s most lively ecosystems at a time when a new developer joins GitHub every second. In our podcast interview, Frenck explains it almost casually. Home Assistant is a free and open source home automation platform. It allows you to connect all your devices together, regardless of the brands they’re from… And it runs locally. Franck Nijhof, lead of Home Assistant He smiles when he describes just how accessible it is. “Flash Home Assistant to an SD card, put it in, and it will start scanning your home,” he says. This is the paradox that makes Home Assistant compelling to developers: it’s simple to use, but technically enormous. A local-first, globally maintained automation engine for the home. And Frenck is one of the people keeping it all running. 📌 What is Home Assistant? Home Assistant is an open-source home automation platform designed for maximum local control, privacy, and interoperability. It enables you to connect, orchestrate, and automate thousands of devices from hundreds of vendors—all running on hardware in your home (e.g., a Raspberry Pi) and without sending data to the cloud. The core engine is written in Python and supported by front-end components in TypeScript and other languages. Developers build integrations in a community-wide effort that has grown to tens of thousands of contributors and millions of installations. The architecture built to tame thousands of device ecosystems At its core, Home Assistant’s problem is combinatorial explosion. The platform supports “hundreds, thousands of devices… over 3,000 brands,” as Frenck notes. Each one behaves differently, and the only way to normalize them is to build a general-purpose abstraction layer that can survive vendor churn, bad APIs, and inconsistent firmware. Instead of treating devices as isolated objects behind cloud accounts, everything is represented locally as entities with states and events. A garage door is not just a vendor-specific API; it’s a structured device that exposes capabilities to the automation engine. A thermostat is not a cloud endpoint; it’s a sensor/actuator pair with metadata that can be reasoned about. That consistency is why people can build wildly advanced automations. Frenck describes one particularly inventive example: “Some people install weight sensors into their couches so they actually know if you’re sitting down or standing up again. You’re watching a movie, you stand up, and it will pause and then turn on the lights a bit brighter so you can actually see when you get your drink. You get back, sit down, the lights dim, and the movie continues.” A system that can orchestrate these interactions is fundamentally a distributed event-driven runtime for physical spaces. Home Assistant may look like a dashboard, but under the hood it behaves more like a real-time OS for the home. Running everything locally is not a feature. It’s a hard constraint. Almost every mainstream device manufacturer has pivoted to cloud-centric models. Frenck points out the absurdity: It’s crazy that we need the internet nowadays to change your thermostat. The local-first architecture means Home Assistant can run on hardware as small as a Raspberry Pi but must handle workloads that commercial systems offload to the cloud: device discovery, event dispatch, state persistence, automation scheduling, voice pipeline inference (if local), real-time sensor reading, integration updates, and security constraints. This architecture forces optimizations few consumer systems attempt. If any of this were offloaded to a vendor cloud, the system would be easier to build. But Home Assistant’s philosophy reverses the paradigm: the home is the data center. Everything from SSD wear leveling on the Pi to MQTT throughput to Zigbee network topologies becomes a software challenge. And because the system must keep working offline, there’s no fallback. This is engineering with no safety net. The open home foundation: governance as a technical requirement When you build a system that runs in millions of homes, the biggest long-term risk isn’t bugs. It’s ownership. “It can never be bought, it can never be sold,” Frenck says of Home Assistant’s move to the Open Home Foundation. “We want to protect Home Assistant from the big guys in the end.” This governance model isn’t philosophical; it is an architectural necessity. If Home Assistant ever became a commercial acquisition, cloud lock-in would follow. APIs would break. Integrations would be deprecated. Automations built over years would collapse. <img data-recalc-dims="1" loading="lazy" decoding="async" height="576" width="1024" src="https://github.blog/wp-content/uploads/2025/10/octoverse-2025-fastest-growing-open-source-projects-by-contributors.png?resize=1024%2C576" alt="A list of the fastest-growing open source projects by contributors. home-assistant/core is number 10." class="wp-image-91494" srcset="https://github.blog/wp-content/uploads/2025/10/octoverse-2025-fastest-growing-open-source-projects-by-contributors.png?w=1440 1440w, https://github.blog/wp-content/uploads/2025/10/octoverse-2025-fastest-growing-open-source-projects-by-contributors.png?w=300 300w, https://github.blog/wp-content/uploads/2025/10/octoverse-2025-fastest-growing-open-source-projects-by-contributors.png?w=768 768w, https://github.blog/wp-content/uploads/2025/10/octoverse-2025-fastest-growing-open-source-projects-by-contributors.png?w=1024 1024w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> The Foundation encodes three engineering constraints that ripple through every design decision: Privacy: “Local control and privacy first.” All processing must occur on-device. Choice: “You should be able to choose your own devices” and expect them to interoperate. Sustainability: If a vendor kills its cloud service, the device must still work. Frenck calls out Nest as an example: “If some manufacturer turns off the cloud service… that turns into e-waste.” This is more than governance; it is technical infrastructure. It dictates API longevity, integration strategy, reverse engineering priorities, and local inference choices. It’s also a blueprint that forces the project to outlive any individual device manufacturer. The community model that accidentally solved software quality We don’t build Home Assistant, the community does. “We cannot build hundreds, thousands of device integrations. I don’t have tens of thousands of devices in my home,” Frenck says. This is where the project becomes truly unique. Developers write integrations for devices they personally own. Reviewers test contributions against devices in their own homes. Break something, and you break your own house. Improve something, and you improve your daily life. “That’s where the quality comes from,” Frenck says. “People run this in their own homes… and they take care that it needs to be good.” This is the unheard-of secret behind Home Assistant’s engineering velocity. Every contributor has access to production hardware. Every reviewer has a high-stakes environment to protect. No staging environment could replicate millions of real homes, each with its own weird edge cases. Assist: A local voice assistant built before the AI hype wave Assist is Home Assistant’s built-in voice assistant, a modular system that lets you control your home using speech without sending audio or transcripts to any cloud provider. As Frenck puts it: We were building a voice assistant before the AI hype… we want to build something privacy-aware and local. Rather than copying commercial assistants like Alexa or Google Assistant, Assist takes a two-layer approach that prioritizes determinism, speed, and user choice. Stage 1: Deterministic, no-AI commands Assist began with a structured intent engine powered by hand-authored phrases contributed by the community. Commands like “Turn on the kitchen light” or “Turn off the living room fan” are matched directly to known actions without using machine learning at all. This makes them extremely fast, reliable, and fully local. No network calls. No cloud. No model hallucinations. Just direct mapping from phrase to automation. Stage 2: Optional AI when you want natural language One of the more unusual parts of Assist is that AI is never mandatory. Frenck emphasizes that developers and users get to choose their inference path: “You can even say you want to connect your own OpenAI account. Or your own Google Gemini account. Or get a Llama running locally in your own home.” Assist evaluates each command and decides whether it needs AI. If a command is known, it bypasses the model entirely. “Home Assistant would be like, well, I don’t have to ask AI,” Frenck says. “I know what this is. Let me turn off the lights.” The system only uses AI when a command requires flexible interpretation, making AI a fallback instead of the foundation. Open hardware to support the system To bootstrap development and give contributors a reference device, the team built a fully open source smart speaker—the Voice Assistant Preview Edition. “We created a small speaker with a microphone array,” Frenck says. “It’s fully open source. The hardware is open source; the software running on it is ESPHome.” This gives developers a predictable hardware target for building and testing voice features, instead of guessing how different microphones, DSP pipelines, or wake word configurations behave across vendors. Hardware as a software accelerator Most open source projects avoid hardware. Home Assistant embraced it out of practical necessity. “In order to get the software people building the software for hardware, you need to build hardware,” Frenck says. Home Assistant Green, its prebuilt plug-and-play hub, exists because onboarding requires reliable hardware. The Voice Assistant Preview Edition exists because the voice pipeline needs a known microphone and speaker configuration. This is a rare pattern: hardware serves as scaffolding for software evolution. It’s akin to building a compiler and then designing a reference CPU so contributors can optimize code paths predictably. The result is a more stable, more testable, more developer-friendly software ecosystem. A glimpse into the future: local agents and programmable homes The trajectory is clear. With local AI models, deterministic automations, and a stateful view of the entire home, the next logical step is agentic behavior that runs entirely offline. If a couch can trigger a movie automation, and a brewery can run a fermentation pipeline, the home itself becomes programmable. Every sensor is an input. Every device is an actuator. Every automation is a function. The entire house becomes a runtime. And unlike cloud-bound competitors, Home Assistant’s runtime belongs to the homeowner, not the service provider. Frenck sums up the ethos: “We give that control to our community.” Looking to stay one step ahead? Read the latest Octoverse report and consider trying Copilot CLI. The post “The local-first rebellion”: How Home Assistant became the most important project in your house appeared first on The GitHub Blog.
How to orchestrate agents using mission control
Run multiple Copilot agents from one place. Learn prompt techniques, how to spot drift early, and how to review agent work efficiently. The post How to orchestrate agents using mission control appeared first on The GitHub Blog.
We recently shipped Agent HQ’s mission control, a unified interface for managing GitHub Copilot coding agent tasks. Now, you can now assign tasks to Copilot across repos, pick a custom agent, watch real‑time session logs, steer mid-run (pause, refine, or restart), and jump straight into the resulting pull requests—all in one place. Instead of bouncing between pages to see status, rationale, and changes, mission control centralizes assignment, oversight, and review. Having the tool is one thing. Knowing how to use it effectively is another. This guide shows you how to orchestrate multiple agents, when to intervene, and how to review their work efficiently. Being great at orchestrating agents means unblocking parallel work in the same timeframe you’d spend on one task, stepping in when logs show drift, tests fail, or scope creeps. The mental model shift From sequential to parallel If you’re already used to working with an agent one at a time, you know it’s inherently sequential. You submit a prompt, wait for a response, review it, make adjustments, and move to the next task. Mission control changes this. You can kick off multiple tasks in minutes—across one repo or many. Previously, you’d navigate to different repos, open issues in each one, and assign Copilot separately. Now you can enter prompts in one place, and Copilot coding agent goes to work across all of them. That being said, there is a trade-off to keep in mind: Instead of each task taking30 seconds to a few minutes to complete, your agents might spend a few minutes to an hour on a draft. But you’re no longer just waiting. You’re orchestrating. When to stay sequential Not everything belongs in parallel. Use sequential workflows when: Tasks have dependencies You’re exploring unfamiliar territory Complex problems require validating assumptions between steps When assigning multiple tasks from the same repo, consider overlap. Agents working in parallel can create merge conflicts if they touch the same files. Be thoughtful about partitioning work. Tasks that typically run well in parallel: Research work (finding feature flags, configuration options) Analysis (log analysis, performance profiling) Documentation generation Security reviews Work in different modules or components Tips for getting started The shift is simple: you move from waiting on a single run to overseeing multiple progressing in parallel, stepping in for failed tests, scope drift, or correcting unclear intent where guidance will save time. Write clear prompts with context Specificity matters. Describe the task precisely. Good context remains critical for good results. Helpful context includes: Screenshots showing the problem Code snippets illustrating the pattern you want Links to relevant documentation or examples Weak prompt: “Fix the authentication bug.” Strong prompt: “Users report ‘Invalid token’ errors after 30 minutes of activity. JWT tokens are configured with 1-hour expiration in auth.config.js. Investigate why tokens expire early and fix the validation logic. Create the pull request in the api-gateway repo.” Use custom agents for consistency Mission control lets you select custom agents that use agents.md files from your selected repo. These files give your agent a persona and pre-written context, removing the burden of constantly providing the same examples or instructions. If you manage repos where your team regularly uses agents, consider creating agents.md files tailored to your common workflows. This ensures consistency across tasks and reduces the cognitive load of crafting detailed prompts each time. Once you’ve written your prompt and selected your custom agent (if applicable), kick off the task. Your agent gets to work immediately. How to write a great agents.md Most agents.md files fail because they are too vague. I analyzed 2,500 agent instruction files to learn what the good ones were doing differently. Read the guide to see what makes those stand out, and which agents you should consider building today. Tips for active orchestration You’re now a conductor of agents. Each task might take a minute or an hour, depending on complexity. You have two choices: watch your agents work so you can intervene if needed, or step away and come back when they’re done. Reading the signals Below are some common indicators that your agent is not on the right track and needs additional guidance: Failing tests, integrations, or fetches: The agent can’t fetch dependencies, authentication fails, or unit tests break repeatedly. Unexpected files being created: Files outside the scope appear in the diff, or the agent modifies shared configuration. Scope creep beyond what you requested: The agent starts refactoring adjacent code or “improving” things you didn’t ask for. Misunderstanding your intent: The session log reveals the agent interpreted your prompt differently than you meant. Circular behavior: The agent tries the same failing approach multiple times without adjusting. When you spot issues, evaluate their severity. Is that failing test critical? Does that integration point matter for this task? The session log typically shows intent before action, giving you a chance to intervene if you’re monitoring. The art of steering When you need to redirect an agent, be specific. Explain why you’re redirecting and how you want it to proceed. Bad steering: “This doesn’t look right.” Good steering: “Don’t modify database.js—that file is shared across services. Instead, add the connection pool configuration in api/config/db-pool.js. This keeps the change isolated to the API layer.” Timing matters. Catch a problem five minutes in, and you might save an hour of ineffective work. Don’t wait until the agent finishes to provide feedback. You can also stop an agent mid-task and give it refined instructions. Restarting with better direction is simple and often faster than letting a misaligned agent continue. Why session logs matter Session logs show reasoning, not just actions. They reveal misunderstandings before they become pull requests, and they improve your future prompts and orchestration practices. When Copilot says “I’m going to refactor the entire authentication system,” that’s your cue to steer. Tips for the review phase When your agents finish, you’ll have pull requests to review. Here’s how to do it efficiently. Ensure you review: Session logs: Understand what the agent did and why. Look for reasoning errors before they become merged code. Did the agent misinterpret your intent? Did it assume something incorrectly? Files changed: Review the actual code changes. Focus on: Files you didn’t expect to see modified Changes that touch shared, risky, or critical code paths Patterns that don’t match your team’s standards/practices Missing edge case handling Checks: Verify that tests pass (your unit tests, Playwright, CI/CD, etc.). When checks fail, don’t just restart the agent. Investigate why. A failing test might reveal the agent misunderstood requirements, not just wrote buggy code. This pattern gives you the full picture: intent, implementation, and validation. Ask Copilot to review its own work After an agent completes a task, ask it: “What edge cases am I missing?” “What test coverage is incomplete?” “How should I fix this failing test?” Copilot can often identify gaps in its own work, saving you time and improving the final result. Treat it like a junior developer who’s willing to explain their reasoning. Batch similar reviews Generating code with agents is straightforward. Reviewing that code—ensuring it meets your standards, does what you want, and that it can be maintained by your team—still requires human judgment. Improve your review process by grouping similar work together. Review all API changes in one session. Review all documentation changes in another. Your brain context-switches less, and you’ll spot patterns and inconsistencies more easily. What’s changed for the better Mission control moves you from babysitting single agent runs to orchestrating a small fleet. You define clear, scoped tasks. You supply just enough context. You launch several agents. The speed gain is not that each task finishes faster; it’s that you unblock more work in the same timeframe. What makes this possible is discipline: specific prompts, not vague requests. Custom agents in agents.md that carry your patterns so you don’t repeat yourself. Early steering when session logs show drift. Treating logs as reasoning artifacts you mine to write a sharper next prompt. And batching reviews so your brain stays in one mental model long enough to spot subtle inconsistencies. Lead your own team of agents to create something great! Ready to start? Visit mission control or learn more about GitHub Copilot for your organization. The post How to orchestrate agents using mission control appeared first on The GitHub Blog.