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

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 clickTurn 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 requestAs 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 barRulesets 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 debtThe 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 actionThink 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

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