Modern IT is about foresight. Learn how Dell AIOps empowers smarter decisions and future-ready infrastructure management. Modern IT is about foresight. Learn how Dell AIOps empowers smarter decisions and future-ready infrastructure management. Observability Blog | Dell
Racing takes flight! Discover how Dell powers Airspeeder’s electric flying race cars and the future of mobility. Racing takes flight! Discover how Dell powers Airspeeder’s electric flying race cars and the future of mobility. Innovation Blog | Dell
Discover how Dell’s mobile, secure, and rugged 5G PCs are transforming the future of policing. Discover how Dell’s mobile, secure, and rugged 5G PCs are transforming the future of policing. Dell Pro Rugged Blog | Dell
Driving scalable and efficient IT for modern finance with secure thin client solutions. Driving scalable and efficient IT for modern finance with secure thin client solutions. Customer Blog | Dell
Sovereign AI is powering up in Europe. Discover how infrastructure, partnerships, and innovation are driving AI leadership. Sovereign AI is powering up in Europe. Discover how infrastructure, partnerships, and innovation are driving AI leadership. Agentic AI Blog | Dell
Hear highlights from JJ Davis on the Merco podcast about Dell’s Texas roots, building trust and fueling global impact. Hear highlights from JJ Davis on the Merco podcast about Dell’s Texas roots, building trust and fueling global impact. Awards Blog | Dell
Discover how a smarter private cloud drives innovation, adapts to business needs, and delivers real business outcomes. Discover how a smarter private cloud drives innovation, adapts to business needs, and delivers real business outcomes. Thought Leadership Blog | Dell
Dell, CrowdStrike and Intel stop breaches. Learn how our joint solution enriches threat detection with hardware-level visibility. Dell, CrowdStrike and Intel stop breaches. Learn how our joint solution enriches threat detection with hardware-level visibility. Endpoint Security Blog | Dell
Dell infrastructure powers the Massachusetts AI Hub, accelerating AI research and driving economic impact. Dell infrastructure powers the Massachusetts AI Hub, accelerating AI research and driving economic impact. Government Blog | Dell
We’ve been hard at work over the past few months to build the most usable and enjoyable AI agents for developers. To strike the right balance between usability and security, we’ve put together a set of guidelines to make sure that there’s always a human-in-the-loop element to everything we design. The more “agentic” an AI product is, the more it can actually do, enabling much richer workflows, but at the cost of a greater risk. With added functionality, there’s a greater chance and a much greater impact of the AI going off its guardrails, losing alignment, or even getting manipulated by a bad actor. Any of these could cause security incidents for our customers. To make these agents as secure as possible, we’ve built all of our hosted agents to maximize interpretability, minimize autonomy, and reduce anomalous behavior. Let’s dive into our threat model for our hosted agentic products, specifically Copilot coding agent. We’ll also examine how we’ve built security controls to mitigate these threats, and perhaps you’ll be able to apply these principles to your own agents. Security concerns When developing agentic features, we are primarily concerned with three classes of risks: Data exfiltration When an agent has Internet access, it could leak data from the context to unintended destinations. The agent may be tricked into sending data from the current repository to an unintended website, either inadvertently or maliciously. Depending on the sensitivity of data, this could result in a severe security incident, such as if an agent leaks a write access GitHub token to a malicious endpoint. Impersonation and proper action attribution When an agent undertakes an action, it may not be clear what permissions it should have or under whose direction it should operate. When someone assigns the Copilot coding agent to an issue, who issued the directive—the person who filed the issue or the person who assigned it to Copilot? And if an incident does occur as a result of something an agent did, how can we ensure proper accountability and traceability for the actions taken by the agent? Prompt injection Agents operate on behalf of the initiating user, so it’s very important to ensure that the initiating user knows what the agent is going to do. Agents are prompted from GitHub Issues, files within a repository, and many other places, so it’s important to ensure that the initiator has a clear picture of all the information guiding it. If not, malicious users could hide directives and trick repository maintainers into running agents with bad directives. Rules for agentic products To help prevent the above risks, we have created a set of rules for all of our hosted agentic products to make them more consistent and secure for our users. Ensuring all context is visible Allowing invisible context can allow malicious users to hide directives that maintainers may not be able to see. For example, in the Copilot coding agent, a malicious user may create a GitHub Issue that contains invisible Unicode with prompt injection instructions. If a maintainer assigns Copilot to this issue, this could result in a security incident as the maintainer would not have been aware of these invisible directives. To prevent this, we display the files from which context is generated and attempt to remove any invisible or masked information via Unicode or HTML tags before passing it to the agent. This ensures that only information that is clearly visible to maintainers is passed to the agent. Firewalling the agent As mentioned previously, having unfettered access to external resources can allow the agent to exfiltrate sensitive information or be prompt-injected by the external resource and lose alignment. We apply a firewall to the Copilot coding agent to limit its ability to access potentially harmful external resources. This allows users to configure the agent’s network access and block any unwanted connections. To balance security and usability, we automatically allow MCP interactions to bypass the firewall.. In our other agentic experiences like Copilot Chat, we do not automatically execute code. For example, when generating HTML, the output is initially presented as code for preview. A user must manually enable the rich previewing interface, which executes the HTML. Limiting access to sensitive information The easiest way to prevent an agent from exfiltrating sensitive data is… to not give access to it in the first place! We only give Copilot information that is absolutely necessary for it to function. This means that things like CI secrets and files outside the current repository are not automatically passed to agents. Specific sensitive content, such as the GitHub token for the Copilot coding agent, is revoked once the agent has completed its session. Preventing irreversible state changes AI can and will make mistakes. To prevent these mistakes from having downstream effects that cannot be fixed, we make sure that our agents are not able to initiate any irreversible state changes without a human in the loop. For example, the Copilot coding agent is only able to create pull requests; it is not able to commit directly to a default branch. Pull requests created by Copilot do not run CI automatically; a human user must validate the code and manually run GitHub Actions. In our Copilot Chat feature, MCP interactions ask for approval before undertaking any tool calls. Consistently attributing actions to both initiator and agent Any agentic interaction initiated by a user is clearly attributed to that user, and any action taken by the agent is clearly attributed to the agent. This ensures a clear chain of responsibility for any actions. For example, pull requests created by the Copilot coding agent are co-committed by the user who initiated the action. Pull requests are generated using the Copilot identity to make it clear that they were AI-generated. Only gathering context from authorized users We ensure that agents gather context only from authorized users. This means that agents must always operate under the permissions and context granted by the user who initiated the interaction. The Copilot coding agent can
When we shared this year’s Octoverse data with Guido van Rossum, the creator of Python, his first reaction was genuine surprise. While TypeScript overtook Python to become the most used language on GitHub as of August 2025 (marking the biggest language shift in more than a decade), Python still grew 49% year over year in 2025, and remains the default language of AI, science, and education for developers across the world. “I was very surprised by that number,” Guido told us, noting how this result is different from other popularity trackers like the TIOBE Index. To learn more, we sat down with Guido for a candid conversation about Python’s roots, its ever-expanding reach, and the choices—both big and small—that have helped turn a one-time “hobby project” into the foundation for the next generation of developers and technologies. Watch the full interview above. 👆 📦 What is Python? Python is a high-level, general-purpose programming language created by Guido van Rossum in 1991. It’s designed to be readable, intuitive, and easy to learn—using clean indentation instead of braces, friendly error messages, and a massive standard library. Developers use Python for everything from data science and AI to web apps, automation, scripting, scientific computing, and education. Its ecosystem includes widely used tools like NumPy, pandas, Django, FastAPI, PyTorch, and Jupyter. Because it’s open source, cross-platform, and backed by a huge global community, Python remains one of the most accessible and versatile languages in the world. The origins of Python For Guido, Python began as a tool to solve the very real (and very painful) gap between C’s complexity and the limitations of shell scripting. I wanted something that was much safer than C, and that took care of memory allocation, and of all the out of bounds indexing stuff, but was still an actual programming language. That was my starting point. Guido van Rossum, creator of Python He was working on a novel operating system, and the only available language was C. “In C, even the simplest utility that reads two lines from input becomes an exercise in managing buffer overflows and memory allocation,” he says. Shell scripts weren’t expressive enough, and C was too brittle. Building utilities for a new operating system showed just how much friction existed in the developer workflow at the time. Guido wanted to create language that served as a practical tool between the pain of C and the limits of shell scripting. And that led to Python, which he designed to take care of the tough parts, and let programmers focus on what matters. Python’s core DNA—clarity, friendliness, and minimal friction—was baked in from the beginning, too. It’s strangely fitting that a language that started as such a practical project now sits at the center of open source, AI, data science, and enterprise AI. Why TypeScript pulled ahead in 2025: Guido’s view Python held the top spot on GitHub for most of 2024 and half of 2025. But by August, TypeScript took the lead—and that surprised Guido. He offered several possible explanations: Modern static websites are checked into GitHub Modern JavaScript frameworks scaffold with TypeScript GitHub’s data reflects public and open source activity vs. global usage “If you’re writing JavaScript today, the logical conclusion is to use TypeScript,” Guido says. But he doesn’t view this competitively. He treats data like a puzzle, not a threat. Monty Python and the language’s personality Unlike other programming languages named for ancient philosophers or stitched-together acronyms, Python’s namesake comes from Monty Python’s Flying Circus. “I wanted to express a little irreverence,” Guido says. “A slight note of discord in the staid world of computer languages.” The name “Python” wasn’t a joke—it was a design choice, and a hint that programming doesn’t have to feel solemn or elitist. That sense of fun and accessibility has become as valuable to Python’s brand as its syntax. Ask practically anyone who’s learned to code with Python, and they’ll talk about its readability, its welcoming error messages, and the breadth of community resources that flatten that first steep climb. If you wrote something in Python last week and, six months from now, you’re reading that code, it’s still clear. Python’s clarity and user friendliness compared to Perl was definitely one of the reasons why Python took over Perl in the early aughts. Python and AI: ecosystem gravity and the NumPy to ML to LLM pipeline Python’s influence in AI isn’t accidental. It’s a signal of the broader ecosystem compounding on itself. Today, some of the world’s fastest-growing AI infrastructure is built in Python, such as PyTorch and Hugging Face Transformers. So, why Python? Guido credits the ecosystem around Python as the primary cause: after all, once a particular language has some use and seems to be a good solution, it sparks an avalanche of new software in that language, so it can take advantage of what already exists. Moreover, he points to key Python projects: NumPy: foundational numerical arrays pandas: making data manipulation easier PyTorch: Machine learning at scale Local model runners and LLM agents: Today’s frontier with projects like ollama leading the charge. The people now writing things for AI are familiar with Python because they started out in machine learning. Python isn’t just the language of AI. It enabled AI to become what it is today. That’s due, in part, to the language’s ability to evolve without sacrificing approachability. From optional static typing to a treasure trove of open source packages, Python adapts to the needs of cutting-edge fields without leaving beginners behind. Does Python need stronger typing in the LLM era? Guido says no. With AI generating more Python than ever, the natural question is: does Python need stricter typing? Guido’s answer was immediate: “I don’t think we need to panic and start doing a bunch of things that might make things easier for AI.” He believes Python’s optional typing system—while imperfect—is “plenty.” AI should adapt to us, not the other way around. He also offered a key insight: The biggest issue
Finding the right gift for the developers on your list shouldn’t feel like chasing an intermittent bug. We’re here to give you our top tips for finding the perfect gift for them. (Or just for you, you know you deserve it.) From vibe code to holiday mode Move straight from shipping code to holiday mode with the ugly holiday socks and beanie. Made with 49% merino wool, the socks keep your feet warm, while the 100% wool beanie handles the rest. Pair them with the ugly sweater to finish the look. 🎁 And they’re all included in our Black Friday sale—so grab them before they’re gone. The answer to life’s biggest questions “Should I push to prod on New Year’s Eve?” “Should I eat more of my favorite holiday dish?” “Should I create another side project in 2026?” The GitHub Copilot Amazeball will have the answer for these questions, and many, many more. It’ll get you on your path. Is it the right path? We don’t have the answer for that. Stay hydrated (and caffeinated) A good day starts with a coffee, right? We’ve got the solution to all your hot beverage needs, whether you’re on the go with our Invertocat orb bottle, at your desk with our “Ship It” diner mug (on sale now) or deep in the forest with our Invertocat MiiR camp mug (also works on the school run). And, of course, staying hydrated is important too, and nothing will help you more than our Stanley cup or Invertocat Asobu Marina tumbler (which also has a coffee cup built in, just saying). Get them both in our Black Friday sale. Level up your workspace Have you seen our latest key caps? They may not help you ship code faster, but they do look great. They’re an easy office gift or the perfect extra touch for a holiday present. The recycled desk mat helps your mouse glide smoothly across your workspace. Sophisticated and sleek… well, not exactly. This desk mat is loud, proud, and unmistakably GitHub—with Octocats from edge to edge. A fan favorite on social media, our MiiR backpack is here to get you to the office, to the plane and everywhere in between. A holiday must-have. For future builders Encourage curiosity early. For the little builders in your life, we have our very cosy youth ASCII Invertocat pullover, along with our ASCII Invertocat tee. Want to do some holiday matching? We have the ASCII Cube tee in both youth and adult sizes. Take advantage of our Black Friday sale Giving the perfect gift feels great. Getting it at a solid discount feels even better. From November 26 to December 7, our Black Friday sale offers markdowns on some of these picks and plenty more across the shop. See everything on sale, and check our holiday order deadlines to ensure your gifts arrive on time. From all of us at the GitHub Shop: here’s to a December packed with good gifts, good energy, and the occasional sprint to finish that last bit of code. Have a joyful holiday season. The post The ultimate gift guide for the developer in your life appeared first on The GitHub Blog. Company news, News & insights, GitHub Shop 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
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. 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
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:
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
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. 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
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
Revolutionize your business with Dell NativeEdge and Private Cloud—powering automation, AI, and unstoppable innovation. Revolutionize your business with Dell NativeEdge and Private Cloud—powering automation, AI, and unstoppable innovation. Edge Blog | Dell
Opposite of GST Office, Chandar, Raiganj, Uttar Dinajpur, West Bengal - 733134
support@itmaity.com
infoitmaity@gmail.com
+91-9907-227112
+91-8759-027112
©2025. ITMAITY and Team. All Rights Reserved.
