tech blog

Achieve Greater ROI with AI in Your Datacenter

As organizations look to scale AI, on-premises infrastructure holds the key to achieving better business value.   ​  ​As organizations look to scale AI, on-premises infrastructure holds the key to achieving better business value. AI Services Blog | Dell

tech blog

Welcome to Maintainer Month: Events, exclusive discounts, and a new security challenge

Open source software (OSS) is everywhere—it’s the lifeblood of the modern software ecosystem. Ninety percent of companies use open source1, 97% of codebases contain open source2, 70-90% of the code within commercial tools comes from open source3, and the value of OSS globally is estimated to be $8.8 trillion4. At GitHub, we love open source—and we’re so honored to host so much open source code that we famously preserved it in the Arctic. But in the same way that your office microwave doesn’t just magically get clean and your favorite park doesn’t have self-mowing grass, open source software doesn’t just happen.   We’re surrounded by human-maintained infrastructure and resources that, in our busy lives, can be easy to take for granted. This is why we started Maintainer Month—a time to thank the open source software maintainers that keep projects healthy. This May marks the fifth annual Maintainer Month, and there are lots of treats in store: new badges, special discounts, events with experts, and more. In addition to the fact that the device you’re reading this on functions–thanks, open source maintainers! Maintainer Month events and livestreams There are over 25 events and livestreams scheduled during Maintainer Month, so head on over to the schedule to see them all or add your own! Everyone is welcome at these events—whether or not you’re ready to call yourself a software maintainer. Here are a couple of our favorites, since they tackle thorny issues:  What maintainers need to know about open source licensing, SBOMs and security: May 6, 2025Join our colleague Jeff Luszcz from the GitHub Open Source Programs Office as he reviews what every maintainer should know about these topics in the ever-evolving landscape of 2025. We get so many questions about this, and Jeff is the expert! The CRA and Open Source: What Maintainers Really Need to Know: May 27, 2025Feeling stressed about the European Union’s new Cyber Resilience Act (CRA) regulations? We can help! Come to this stream with the Eclipse Foundation’s Cyber Resilience Working Group, where they’ll talk about resources and practical information for maintainers navigating these changes. 🎁 Meet the 2025 Partner Pack This year, we’re launching the new Maintainer Month Partner Pack—a bundle of perks, tools, and resources from organizations that truly believe in open source. Think of it as a care package for the folks behind our digital infrastructure. Here’s just a taste of what’s inside (and it’s available to all maintainers): Arachne Digital: Free tailored threat report with steps to defend your project Boot.dev: One month of free premium access to backend dev courses CNCF: Discounts on select cloud native training (Kubernetes included!) DevCycle: A full year of the Developer plan, free for maintainers JSConf North America: Special discounted tickets for Maintainer Month Linux Foundation Education: 25% off the full course catalog Mockoon: Free Mockoon Cloud account to build, test, and mock APIs faster Sentry: Access to their open source plan for monitoring and performance TODO Group: 20% off the CODE certification for enterprise open source Web Summit: Discounted tickets to Vancouver & Lisbon for OSS contributors …and we’ll be adding more throughout May.  👉 See all current offers and partners here. Some partners are offering extra perks for members of our private Maintainer Community—a vetted space to connect, share, and support each other. If you maintain an open source project, you can request to join our Maintainer Community. Security: a new challenge Security is kind of a big deal, which is why you hear about it all the time. This is why we’re excited to launch new security guidance on opensource.guide to help maintainers strengthen the trust and resilience of their open source projects. We’ve pulled together practical advice and tools you can start using right away to make your project safer for everyone who relies on it. Because building great open source software isn’t just about what your project does—it’s about how you protect the people who use it. The new Open Source Guide on Security Best Practices for Your Project will walk you through the basic considerations for software security, including how to: Secure your code as part of your development workflow Avoid unwanted changes with protected branches Set up an intake mechanism for vulnerability reporting Looking to improve security on your project with expertise and community? Apply to the GitHub Secure Open Source Fund.  You don’t have to secure your project alone—we’re here to support you. The GitHub Secure Open Source Fund provides a combination of funding, training sessions with experts, and access to researchers and community to get your project more secure. We’re completely serious, we will give you money ($10K) to improve your security practices!  Apply to the GitHub Secure Open Source Fund > 🔒 Security Challenge: Level up during Maintainer Month Ready to boost your project’s defenses—and your own skills? This May, take the Maintainer Month Security Challenge, which features three hands-on GitHub security skills while allowing you to snag a voucher for GitHub Advanced Security certification (hello, career boost!). In just a few hours, you’ll pick up real techniques to protect your project—and show the world you’re serious about security. Let’s build a safer open source together. Join the Security Challenge > 🔧 How to get involved throughout May and beyond Explore the Partner Pack: maintainermonth.github.com Join the Maintainer Community: maintainers.github.com Want to contribute an offer? Email us at maintainermonth@github.com Share your story: Tag #MaintainerMonth on social media to help us celebrate the humans behind the code! Read more about what’s happening with open source. 1 GitHub. 2022. “Octoverse 2022: The state of open source software.” https://octoverse.github.com/2022/. & OpenUK. 2021. “State of Open: The UK in 2021.” https://openuk.uk/wp-content/uploads/2021/10/openuk-state-of-open_final-version.pdf.  2 Blackduck. 2025. “Six takeaways from the 2025 “Open Source Security and Risk Analysis” report.” https://www.blackduck.com/blog/open-source-trends-ossra-report.html. 3 The Linux Foundation. 2022. “A Summary of Census II: Open Source Software Application Libraries the World Depends On.” https://www.linuxfoundation.org/blog/blog/a-summary-of-census-ii-open-source-software-application-libraries-the-world-depends-on. & Intel. 2025. “The Careful Consumption of Open Source Software.”  https://www.intel.com/content/www/us/en/developer/articles/guide/the-careful-consumption-of-open-source-software.htm.  4 Harvard Business School. 2024. “The Value of Open Source Software.” https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4693148.  The

tech blog

Building a more accessible GitHub CLI

At GitHub, we’re committed to making our tools truly accessible for every developer, regardless of ability or toolset. The command line interface (CLI) is a vital part of the developer experience, and the GitHub CLI is our product that brings the power of GitHub to your terminal. When it comes to accessibility, the terminal is fundamentally different from a web browser or a graphical user interface, with a lineage that predates the web itself. While standards like the Web Content Accessibility Guidelines (WCAG) provide a clear path for making web and graphical applications accessible, there is no equivalent, comprehensive standard for the terminal and CLIs. The W3C offers some high-level guidance for non-web software, but it stops short of prescribing concrete techniques, leaving much open to interpretation and innovation. This gap has challenged us to think creatively and purposefully about what accessibility should look like in the terminal. Our recent Public Preview is focused on addressing the needs of three key groups: users who rely on screen readers, users who need high contrast between background and text, and users who require customizable color options. Our work aims to make the GitHub CLI more inclusive for all, regardless of how you interact with your terminal. Run gh a11y in the latest version of the GitHub CLI to enable these features, or read on to learn about our path to designing and implementing them. Understanding the terminal landscape Text-based and command-line applications differ fundamentally from graphical or web applications. On a web page, assistive technologies like screen readers make use of the document object model (DOM) to infer structure and context of the page. Web pages can be designed such that the DOM’s structure is friendly to these technologies without impacting the visual design of the page.  By contrast, CLI’s primary output is plain text, without hidden markup. A terminal emulator acts as the “user agent” for text apps, rendering characters as directed by the server application. Assistive technologies access this matrix of characters, analyze its layout, and try to infer structure. As the WCAG2ICT guidance notes, accessibility in this space means ensuring that all text output is available to assistive technologies, and that structural information is conveyed in a way that’s programmatically determinable—even if no explicit markup is present. In our quest to improve the GitHub CLI’s usability for blind, low-vision, and colorblind users, we found ourselves navigating a landscape with lots of guidance, but few concrete techniques for implementing accessible experiences. We studied how assistive technology interacts with terminals: how screen readers review output, how color and contrast can be customized, and how structural cues can be inferred from plain text. Our recent Public Preview contains explorations into various use cases in these spaces.  Rethinking prompts and progress for screen readers One of the GitHub CLI’s strengths as a command-line application is its rich prompting experience, which gives our users an interactive interface to enter command options. However, this rich interactive experience poses a hurdle for speech synthesis screen readers: Non-alphanumeric visual cues and uses of constant screen redraws for visual or other effects can be tricky to correctly interpret as speech.
 A demo video with sound of screen reader reading legacy prompter. To reduce confusion and make it easier for blind and low vision users to confidently answer questions and navigate choices, we’re introducing a prompting experience that allows speech synthesis screen readers to accurately convey prompts to users. Our new prompter is built using Charm’s open source charmbracelet/huh prompting library. A demo of a screenreader correctly reading a prompt. Another use case where the terminal is redrawn for visual effect is when showing progress bars. Our existing implementation uses a “spinner” made by redrawing the screen to display different braille characters (yes, we appreciate the irony) to give the user the indication that their command is executing. Speech synthesis screen readers do not handle this well: A demo of a screenreader and an old spinner. This has been replaced with a static text progress indicator (with a relevant message to the action being taken where possible, falling back to a general “Working…” message). We’re working on identifying other areas we can further improve the contextual text. A demo video of the new progress indicator experience. Color, contrast, and customization Color is more than decoration in the terminal: It’s a vital tool for highlighting information, signaling errors, and guiding workflows. But color can also be a barrier—if contrast between the color of the terminal background and the text displayed on it is too low, some users will have difficulty discerning the displayed information. Unlike in a web browser, a terminal’s background color is not set by the application. That task is handled by the user’s terminal emulator. In order to maintain contrast, it is important that a command line application takes into account this variable. Our legacy color palette used for rendering Markdown did not take the terminal’s background color into account, leading to low contrast in some cases. The colors themselves also matter. Different terminal environments have varied color capabilities (some support 4-bit, some 8-bit, some 24-bit, etc). No matter the capability, terminals enable users to customize their color preferences, choosing how different hues are displayed. However, most terminals only support changing a limited subset of colors: namely, the sixteen colors in the ANSI 4-bit color table. The GitHub CLI has made extensive efforts to align our color palettes to 4-bit colors so our users can completely customize their experience using their terminal preferences. We built on top of the accessibility foundations pioneered by Primer when deciding which 4-bit colors to use. Building for the CLI community Our improvements aim to support a wide range of developer needs, from blind users who need screen readers, to low vision users who need high contrast, to colorblind users who require customizable color options. But this Public Preview does not mark the end of our team’s commitment to enabling all developers to use the GitHub CLI. We intend to make

tech blog

Copilot ask, edit, and agent modes: What they do and when to use them

If you have opened Copilot Chat in VS Code lately and didn’t notice the tiny dropdown hiding at the bottom, you’re not alone. It’s easy to miss, especially when you’re heads down trying to get something shipped. That little menu is where you can switch between ask, edit, and agent modes—three ways you can integrate Copilot into your workflow. But here’s the thing: Each of these modes does something pretty different. And depending on what kind of developer you are, how much context you have, or how much control you’re comfortable giving GitHub Copilot, you might have a very different experience with each one.  I’ve been using all three in different ways, from building apps and testing ideas to playing with frameworks I haven’t touched in a while. I’ve also spent time talking to other developers about what’s working for them.  Below is what I’ve learned so far. This isn’t the manual (for that, look at the VS Code documentation). It’s more of a guide for how to think about these tools, as you navigate where they fit into your own workflow. Ask mode: The quick gut check Ask mode is the simplest of the three—and if you are a long-time user of GitHub Copilot, it might be the only time you’ve thought about bringing up the Chat window.  Here’s how it works: You highlight some code, type a question into Copilot Chat, and it generates an answer. It might explain what the code does, suggest how to test it, give you a code snippet that implements what you are asking about, or remind you how to handle a particular edge case.  Ask mode is fast, helpful, and focused entirely on answering your programming question without touching your code. You can stay in your editor and ask questions that Copilot can answer using all the context of your current editor environment. Think of it like a quiet little whisper in your editor saying, “Hey, here’s what I think this means.” And it’s not just about your code. You can ask it anything related to programming—like how to use a certain library, how to structure a SQL query, and even which search algorithm is more efficient for a given dataset.  Need help styling something with Tailwind? Want a refresher on closures in JavaScript? Curious how to debounce an input in React? Copilot can help with that, too. There’s no project commitment, no architectural decisions, and no code changes. Just answers, right when you need them. It’s the lowest-friction way to get unstuck when a question is standing in the way of you and building what’s next. Edit mode: You’re still in charge, just moving faster Edit mode in VS Code is where things start to get more interesting. It lets you pick any number of files in your project you want to change and describe the update in natural language. Then, Copilot will immediately apply inline, review-ready code edits across those files.  Edit mode is perfect when you know what you want to do but don’t necessarily want to write it all out yourself. You highlight a block of code, type in an instruction—perhaps something like “add error handling” or “refactor this using async/await”—and Copilot rewrites the code for you. But (and this is important) it doesn’t save anything without showing you the diff first. That’s what makes edit mode so reliable. Copilot does the work, but you get the final say. You’re not handing over the reins. You’re speeding things up while staying fully in the loop. You can also bring custom instructions into edit mode if you want to level it up a bit. It’s a way to teach Copilot how you and your team like to write code, including your style preferences, how verbose or concise you want it to be, what your team’s standards are, how formal or casual you want it when it explains things, and even what language you want your comments written in. Setting up those preferences is like giving Copilot a playbook ahead of time—so when you say “clean this up,” it already knows what “clean” actually means to you. I’ve found myself reaching for edit mode when I’m deep in a brownfield app and don’t want to touch the rest of the system, or when I’m just trying to get through a handful of small but annoying improvements with surgical precision. It’s not trying to redesign your architecture. It’s not going to rename things you didn’t ask it to. It’s just here to make the thing you’re working on better and faster, with less mental overhead. Honestly, once you get used to it, it’s hard to go back. Agent mode: A lot of power, when you’re ready for it Now let’s talk about Agent mode. Agent mode lets you hand it a high-level prompt and then watch as Copilot autonomously plans the steps, selects the right files, runs tools or terminal commands, and iterates on code edits until the task is complete. It is by far the most powerful mode in Copilot Chat—and also the newest, which means for a lot of people, it’s still the least familiar. Agent mode can reason across your entire project, take multi-step actions, and hold onto a significant amount of context across a session. You can ask it to build features, fix bugs, create files, clean up routing logic, or even scaffold an entire section of an app based on a single prompt. At first glance, agent mode can look like an expanded version of edit mode—and in some respects, it is. But there’s a crucial distinction: Instead of only rewriting the lines you specify, agent mode analyzes related code, identifies additional changes that may be required, and applies them across the project to keep everything consistent. Another key distinction? Agent mode applies edits automatically rather than waiting for explicit approval, while still surfacing any potentially risky commands for review before they run. The workflow is closer to a continuous-edit “driver” model: The developer defines

tech blog

From MCP to multi-agents: The top 10 new open source AI projects on GitHub right now and why they matter

Every day, new public and open source repositories appear on GitHub, and navigating the sheer amount of activity can be a challenge for the best of us. Luckily, we’ve done the heavy lifting for you. Together with our panel of GitHub experts—who have experience across open source and developer relations—we analyzed every open source project created in the last 99 days (as of March 29, 2025), and ranked them in consideration of a number of factors including stars-per-day, forks, traffic spikes, and contributor velocity. Our GitHub panel includes: Abigail Cabunoc Mayes, aka @abbycabs, who works on open source maintainer programs and serves as a Director on the OpenJS foundation. Kara Sowles, aka @karasowles, who works with maintainers and the open source community. Kevin Crosby, aka @kevincrosby, who runs GitHub’s open source funding program. Jeff Luszcz, aka @jeffrey-luszcz, who helps manage GitHub’s open source program office (OSPO). Below, we’ll give you a rundown of these projects—and also discuss why we believe they’re the ones developers keep coming back to. Let’s dive in. Top trends, at a glance Agents are becoming key: A year ago the question was “What model can I fine tune?” Now it’s “What agent can I put to work?” Model Context Protocol (MCP) is helping integrate AI (and becoming the USB‑C of AI tooling): More projects are exposing their functions via MCP so any LLM can call them. Multi‑agent orchestration is no longer research only: Frameworks like OWL let several specialized agents cooperate on a task. Speech generation is leveling up: Projects push TTS/STT beyond “read this text aloud” into precise duration control and natural rhythm and sound. An increasing number of experiments with digital twins: There’s interest in personal AI that carries your context and voice across apps. Get the full analysis > 1. Open WebUI MCP: simplifying AI tool integrations 🔌 Website Source Python 📜 MIT license First up is a proxy server that turns MCP tools into OpenAPI-compatible HTTP servers. Developers building AI-powered apps are using the server to easily connect MCP-based tools with anything that uses standard RESTful OpenAPI interfaces. Why it matters “This new project from OpenWebUI (an alumni of 2024 GitHub Accelerator) is a great example of a growing trend in AI around integration—especially its use of MCP,” explains Abigail. “It’s highlighting that people in AI need more integration, and more standards like MCP will help.” 2. Unbody: the “Supabase of AI” 🧩 Website Source TypeScript 📜 Apache 2.0 license Think Supabase, but for AI: that’s Unbody in a nutshell. It’s a modular backend that lets you build AI-native software that actually understands and reasons about knowledge, instead of just shuffling data around. The project breaks things down into four layers that you can mix and match: Perception: Ingests, parses, enhances, and vectorizes raw data. Memory: Stores structured knowledge in vector databases and persistent storage. Reasoning: Generates content, calls functions, and plans actions. Action: Exposes knowledge via APIs, SDKs, and triggers. Why it matters “It’s an interesting question: How does agent coding become more abstracted from the backend?” asks Kevin. “With Unbody, you can write in any framework and get a backend that’s automatically managed. If you look at companies like E2E, you see work being done to create much more advanced agents that show how the backend stack is being abstracted.” 3. OWL: multi-agent collaboration in action 🦉 Source Python 📜 Apache 2.0 license When one AI agent isn’t enough, OWL enters the chat. Built on the CAMEL-AI framework—best known for popularizing multi-agent role-play and releasing a trove of synthetic “task + data” bundles—OWL lets several specialized agents cooperate through browsers, terminals, function calls, and MCP tools. It even tops the open-source leaderboard on the GAIA benchmark (58.18). Why it matters “It’s not just agentic, it’s also multi-model—and multi-agent architectures like OWL,” notes Abigail. “A year ago, it was all about people building models—now it’s all about agents and what they can do. OWL is doing multi-agent work which is quickly emerging.” 4. F/mcptools: Command-line power for MCP developers 💻 Source Go 📜 MIT license CLI fans: Here’s a command-line interface for working with MCP servers that’ll make you feel right at home. Built by GitHub Star Fatih Kadir Akin (who also shipped the GitHub Copilot prompts feature), it lets you discover and call tools, access resources, and manage prompts from any MCP-compatible server. MCP Tools supports input/output over stdin/stdout or HTTP, and spits out results in JSON or table views. It even lets you create mock servers for testing or proxy MCP requests to shell scripts. Why it matters This turns MCP into something you can “git clone && mcp call.” It offers a familiar CLI workflow plus a built-in guard mode that lets you prototype tools fast and lock them down for prod. 5. Nutlope/self.so: Build your personal site with AI in seconds ⚡ Website Source TypeScript 📜 MIT license If putting together a personal website isn’t your idea of fun, Nutlope/self.so can lend a hand. Upload your résumé or LinkedIn profile, and the tool will pull together a straightforward site for you, using AI to handle the layout so you can skip the CSS headaches. The tech stack includes Together.ai for language modeling, Vercel’s AI SDK, Clerk for auth, Next.js for the framework, Helicone for observability, S3 for storage, Upstash Redis for the database, and Vercel for hosting. Why it matters The project speaks to composable “AI Lego” stacks. That’s because it chains Vercel AI SDK, Clerk auth, Upstash Redis, S3, and Tailwind—with each service doing one job well—which illustrates how modern AI apps are often stitched together from small, specialized services instead of monoliths. 6. VoiceStar: precise control for text-to-speech applications 🎙️ Source Python 📜 MIT code license, CC-BY-4.0 model license If your project needs speech that lands within a specific time window, VoiceStar’s duration-controllable synthesis can help. It lets developers set target lengths so voice output fits time-sensitive use cases—like fixed-length prompts or narration—without extra audio editing. The project includes both CLI and Gradio interfaces

tech blog

The AI-powered DevOps revolution: Redefining developer collaboration

When it comes to mastering DevOps, it’s often not the technical skills that trip us up, but rather the more critical aspects of collaboration and communication. Communication challenges, vague requirements, and missing documentation can leave us guessing on stakeholder intent. Plus, siloed workflows can cause teams to face inconsistencies in their processes, tooling, and time to delivery, as there are so many moving parts. This all works against DevOps best practices. In this blog, we will look at ways that we can enhance team productivity, reduce cognitive load, and implement a more seamless collaboration across teams and tools to improve code quality and create faster delivery cycles. Adding a bit of AI into our workflows will get us on the right path. 💡 Tip: When using Copilot (or any generative AI), it’s always a good idea to review any suggestions before accepting them. There’s a reason we refer to GitHub Copilot as an assistant. It is meant to augment your abilities, not serve as a replacement for your skills. Filling in communication gaps and documentation When I get started on a new project, the first thing I do is seek out the README or documentation, if there is any. While we should be writing documentation for our code as we go, the reality is that we often do not. This gap, between intention and practice, creates consistent challenges for our teams as we try to onboard new members or revisit older projects. Nowadays, to get the documentation that I need, whether it’s working on a legacy code base or joining a new community project, I start by opening either GitHub Copilot Chat in VSCode or in the github.com immersive chat experience to ask Copilot to explain the codebase to me. And when the existing README is lacking, I can then ask Copilot to help me to write a better one. For example, here’s a typical placeholder README: Beyond a brief description, there’s not much information. I opened up VSCode and GitHub Copilot Chat, attaching the existing README file to give Copilot context, and asked it to simply make my README more detailed. After asking Copilot to help create a better README, here’s how it looked: GitHub Copilot provided a project overview, installation and configuration steps, and some usage instructions. This gives me, and anyone else who visits this project, a better understanding of what the project is doing and how to get started. You can use GitHub Copilot not only to generate a README once you’ve written your code, but also function and class descriptions. Copilot can improve readability of code by generating descriptions, adding context around what your code is doing, and writing documentation that can reduce the learning curve and onboarding time. For example, check out this bit of code where Copilot helped write inline comments: Oftentimes, the various technical teams (operations, security, and development) operate independently, not fully aware of other teams’ standards, dependencies, or changes. Using Copilot to create better documentation and code comments can help us to break down these silos. AI-powered code reviews and pull requests So, when we do make a code change that impacts other teams, how can we better review those changes to ensure a more seamless and secure delivery? Let’s take a look. You know when you submit your pull request and you’re in a rush because of task overload? In the example above, we used docstrings to explain our functions and that is extremely helpful when you’re working with complex functions. Copilot can help write your docstrings to provide clear parameter explanations, detailed method descriptions, and context about usage. This helps to reduce the ambiguity for your code reviewers and provides context to the changes that were made. When you get ready to submit your commit, instead of having to think of a funny and witty commit message yourself, select the AI-enhanced commit option and let Copilot generate a clear, concise summary of your changes for you: How often when we are reviewing a pull request there is little to no description? We can use Copilot to help with that, too! After I have committed my code, I can use the “summary” option to generate a summary of my pull request: Copilot reviews the commit and the files changed, and then outputs a thorough summary of the changes with links to the changed files. Oftentimes, we submit a pull request and expect the reviewer to figure out what changes were made, as if they had a crystal ball. In this example, I’ve used Copilot to generate a short summary of the changes in my commit, as well as a longer, more detailed summary of the pull request. This saved me time, but more importantly, it has provided a much higher quality output than I would have been able to do on my own. Copilot’s ability to summarize and document can be hugely beneficial in creating consistent terminology and communication across teams, eliminating collaboration breakdowns and enhancing code reviews. Along with using Copilot to summarize my pull request before I send up our commit, I can also set Copilot as one of my reviewers by clicking “Reviewers” in the top right hand corner of my screen. Once I do that, Copilot reviews my pull request before my other team members, allowing me to find typos and other errors, and iterate my code before asking others to review it. This enables me to iterate faster, getting direct feedback more quickly on my changes and lessening the time my teammates need to take to review my code. It also allows me to learn how to improve my code quality, too. Resolving merge conflicts with Copilot So far, I’ve used Copilot to better define the project README, add inline comments and documentation, and generate more relevant, thorough, and precise commit messages and precise pull request summaries. But most of these changes have been me acting alone—what about when I’m collaborating with my team and I run into a merge conflict? GitHub Copilot

tech blog

Partnering to Shape Telecom’s Future at MWC 2025

At MWC25, Dell unveiled innovative solutions with partners, empowering operators with scalability, innovation, and efficiency.   ​  ​At MWC25, Dell unveiled innovative solutions with partners, empowering operators with scalability, innovation, and efficiency. Telecommunications Blog | Dell

tech blog

GitHub for Beginners: Building a REST API with Copilot

Welcome to the next episode in our GitHub for Beginners series, where we’re diving into the world of GitHub Copilot. This is our fifth episode, and we’ve already talked about Copilot in general, some of its essential features, how to write good prompts, and a bit about security best practices. We have all the previous episodes on our blog and available as videos. Today we’re diving a little deeper—we’re using GitHub Copilot to help us build a backend REST API. We’ll walk through how to build the backend for Planventure, a travel itinerary builder that helps users plan their trips. You can find a full description of what we’ll be building in this repository. For the demos in this series, we’re using GitHub Copilot in Visual Studio Code Copilot is available in other IDEs, but the available functionality may vary depending on your environment. What you’ll need and what we’re building Before we get started, here’s what you’ll need to install: A code editor like VS Code Python SQLite Viewer to view database tables An API client like Bruno to test your routes Access to GitHub Copilot — sign up for free! What we’re building: We’re creating a minimum viable product (MVP) for Planventure’s backend API. In the next episode, we’ll build the frontend to connect to the API. Here’s what we’ll include: REST API built with Flask Database support using SQLAlchemy User authentication (with password hashing and JWTs) Full CRUD functionality for trips Each trip will include: Destination Start and end dates A basic itinerary with location coordinates (perfect for maps) At the end of this, we want to have a working API that handles user authentication and basic trip management. Step 1: Setting up the environment Fork and clone the planventure repository. Once you’ve done that, cd into the planventure-api directory in your code editor. git clone https://github.com/github-samples/planventure cd planventure-api Open up your terminal and run the following commands to create and activate a virtual environment. python3 -m venv venv source venv/bin/activate Assuming you’re using VS Code, you’ll see venv in the status bar at the bottom. If you’re using another editor, be sure to verify that you’re in your virtual environment. Staying in your terminal, run this command to install dependencies: pip install -r requirements.txt Run the following command in your terminal to start the server: flask run –debug You should see your server running on 127.0.0.1:5000. Use Bruno to make a GET request to that URL and you should see the following welcome message: Remember to add venv/ to your .gitignore! Step 2: Create the Database Now that you’ve got your environment created, it’s time to start using Copilot to generate some code. We’ll use Copilot Chat and Copilot Edits to generate our database setup. Open the app.py file and Copilot Chat, choose the Ask option, and enter the following prompt: @workspace Update the Flask app with SQLAlchemy and basic configurations At the bottom of the chat window, click the model selector and select the Claude 3.5 Sonnet model and send the prompt. Copilot will provide a plan, a code block, and a summary of suggested changes. Whenever you receive code suggestions from Copilot, it’s important to review them and understand the changes it’s suggesting. After reviewing the changes, hover over the code block and click the Apply in editor button—the first button in the top-right of the suggested code. Select the option to apply the changes into the active editor. Copilot will make these updates in the open file. Click Accept to add those changes. https://github.blog/wp-content/uploads/2025/04/apply_in_editor_vid.mp4#t=0.001 If Copilot provided suggestions that need to be in a new file, hover over the change and select the three dots, then select Insert into New File and save. https://github.blog/wp-content/uploads/2025/04/insert_new_file.mp4#t=0.001 Now we need to update our dependencies. Go back to Copilot Chat and enter the following prompt: @workspace update requirements.txt with the necessary packages for Flask API with SQLAlchemy and JWT Open the requirements.txt file. Hover over the suggested changes, click the Apply in editor button, and once again select the option to apply the changes into the active editor. Just like before, accept the changes and save the file. Step 3: Time to create some models Now it’s time to create our User and Trip models. This GitHub issue describes our requirements. According to the issue, the User model needs an email, a password, and must include password hashing and timestamps. The Trip model needs to have a destination, start and end dates, coordinates, and an itinerary with a user relationship. To do all of this, we’re going to use Copilot Edits. Click on the chat icon in your editor, and from the dropdown, select Edits. Open your app.py and requirements.txt file and drag them into the chat window. Then choose the Claude 3.5 Sonnet model from the model picker. Now send the following prompt to Copilot Edits: Create SQLAlchemy User model with email, password_hash, and timestamps. Add code in new files. Copilot Edits will then create a plan to do what you asked. It creates some new files and folders, as well as updates existing files. Accept the changes, review the code, and make any corrections necessary before saving the files. https://github.blog/wp-content/uploads/2025/04/edits_prompt_flow.mp4#t=0.001 Check the video for examples of things to look for, but remember that your changes might be different. Copilot can provide different suggestions for the same prompts. Now create a python script to create the database tables. Send Copilot Edits the following prompt: Update code to be able to create the db tables with a python shell script. As before, Copilot Edits will go to work and create or edit files as necessary. Accept the code and review the changes, making sure these changes address your needs. After saving the reviewed changes, go back to your terminal and initialize the database by running: python3 init_db.py If Copilot Edits created a different filename than init_db.py, use the filename in your project. After the script runs, you’ll see a new planventure.db file in your project. However,

tech blog

Cutting through the noise: How to prioritize Dependabot alerts

Let’s be honest: that flood of security alerts in your inbox can feel completely overwhelming. We’ve been there too. As a developer advocate and a product manager focused on security at GitHub, we’ve seen firsthand how overwhelming it can be to triage vulnerability alerts. Dependabot is fantastic at spotting vulnerabilities, but without a smart way to prioritize them, you might be burning time on minor issues or (worse) missing the critical ones buried in the pile. So, we’ve combined our perspectives—one from the security trenches and one from the developer workflow side—to share how we use Exploit Prediction Scoring System (EPSS) scores and repository properties to transform the chaos into clarity and make informed prioritization decisions. Understanding software supply chain security If you’re building software today, you’re not just writing code—you’re assembling it from countless open source packages. In fact, 96% of modern applications are powered by open source software. With such widespread adoption, open source software has become a prime target for malicious actors looking to exploit vulnerabilities at scale. Attackers continuously probe these projects for weaknesses, contributing to the thousands of Common Vulnerabilities and Exposures (CVEs) reported each year. But not all vulnerabilities carry the same level of risk. The key question becomes not just how to address vulnerabilities, but how to intelligently prioritize them based on your specific application architecture, deployment context, and business needs. Understanding EPSS: probability of exploitation with severity if it happens When it comes to prioritization, many teams still rely solely on severity scores like the Common Vulnerability Scoring System (CVSS). But not all “critical” vulnerabilities are equally likely to be exploited. That’s where EPSS comes in—it tells you the probability that a vulnerability will actually be exploited in the wild within the next 30 days. Think of it this way: CVSS tells you how bad the damage could be if someone broke into your house, while EPSS tells you how likely it is that someone is actually going to try. Both pieces of information are crucial! This approach allows you to focus resources effectively. As security pro Daniel Miessler points out in Efficient Security Principle, “The security baseline of an offering or system faces continuous downward pressure from customer excitement about, or reliance on, the offering in question.” Translation? We’re always balancing security with usability, and we need to be smart about where we focus our limited time and energy. EPSS helps us spot the vulnerabilities with a higher likelihood of exploitation, allowing us to fix the most pressing risks first. Smart prioritization steps 1. Combine EPSS with CVSS One approach is to look at both likelihood (EPSS) and potential impact (CVSS) together. It’s like comparing weather forecasts—you care about both the chance of rain and how severe the storm might be. For example, when prioritizing what to fix first, a vulnerability with: EPSS: 85% (highly likelihood of exploitation) CVSS: 9.8 (critical severity) …should almost always take priority over one with: EPSS: 0.5% (much less likely to be exploited) CVSS: 9.0 (critical severity) Despite both having red-alert CVSS ratings, the first vulnerability is the one keeping us up at night. 2. Leverage repository properties for context-aware prioritization Not all code is created equal when it comes to security risk. Ask yourself: Is this repo public or private? (Public repositories expose vulnerabilities to potential attackers) Does it handle sensitive data like customer info or payments? How often do you deploy? (Frequent deployments face tighter remediation times) One way to provide context-aware prioritization systematically is with custom repository properties, which allow you to add contextual information about your repositories with information such as compliance frameworks, data sensitivity, or project details. By applying these custom properties to your repositories, you create a structured classification system that helps you identify the “repos that matter,” so you can prioritize Dependabot alerts for your production code rather than getting distracted by your totally-not-a-priority test-vulnerabilities-local repo. 3. Establish clear response Service Level Agreements (SLAs) based on risk levels Once you’ve done your homework on both the vulnerability characteristics and your repository context in your organization, you can establish clear timelines for responses that make sense for your organization resources and risk tolerance. Let’s see how this works in real life: Here’s an example risk matrix that combines both EPSS (likelihood of exploitation) and CVSS (severity of impact). EPSS ↓ / CVSS → Low Medium High Low ✅ When convenient ⏳ Next sprint ⚠️ Fix Soon Medium ⏳ Next sprint ⚠️ Fix soon 🔥 Fix soon High ⚠️ Fix Soon 🔥 Fix soon 🚨 Fix first Say you get an alert about a vulnerability in your payment processing library that has both a high EPSS score and high CVSS rating. Red alert! Looking at our matrix, that’s a “Fix first” situation. You’ll probably drop what you’re doing, and put in some quick mitigations while the team works on a proper fix. But what about that low-risk vulnerability in some testing utility that nobody even uses in production? Low EPSS, low CVSS… that can probably wait until “when convenient” within the next few weeks. No need to sound the alarm or pull developers off important feature work. This kind of prioritization just makes sense. Applying the same urgency to every single vulnerability just leads to alert fatigue and wasted resources, and having clear guidelines helps your team know where to focus first. Integration with enterprise governance For enterprise organizations, GitHub’s auto-triage rules help provide consistent management of security alerts at scale across multiple teams and repositories. Auto-triage rules allow you to create custom criteria for automatically handling alerts based on factors like severity, EPSS, scope, package name, CVE, ecosystem, and manifest location. You can create your own custom rules to control how Dependabot auto-dismisses and reopens alerts, so you can focus on the alerts that matter. These rules are particularly powerful because they: Apply to both existing and future alerts. Allow for proactive filtering of false positives. Enable “snooze until patch” functionality for vulnerabilities without a fix available. Provide visibility

tech blog

How agentic AI is driving AI-first business transformation for customers to achieve more

The role of agentic AI has grown rapidly over the past several months as organizational leaders seek ways to accelerate AI Transformation. We firmly believe that Agents + Copilot + Human Ambition can deliver real AI differentiation for our customers. By putting the autonomous capabilities of an agent to work for their businesses, our customers are unlocking AI opportunity to realize greater value. The recent introduction of Microsoft 365 Copilot Chat is delivering on our promise of “Copilot for all” by providing frontline workers with a free, secure and enterprise-ready AI chat interface. Our customers are building their own custom agents with the no-code, low-code features of Microsoft Copilot Studio, allowing citizen and professional developers to extend the capabilities of Copilot and deliver on the unique needs of their industry. We also offer the best prebuilt agent framework right out-of-the-box, such as Sales Agent that works autonomously to help sellers build pipeline and close more deals with greater speed. Similarly, we recently announced general purpose reasoning agents — such as Researcher and Analyst — and invite all of our Microsoft 365 Copilot users to try these in their environments. It is exciting to see how agents are driving pragmatic AI innovation for our customers by increasing productivity, creating capacity across every role and function and improving business processes. Below are a few highlights from the past quarter that underscore the impact of an agentic AI approach — from improving employee experiences to streamlined workflows and significant cost savings. Agentic service management software provider Atomicwork leveraged Azure AI Foundry to create Atom — an AI agent that transforms the digital workplace experience for employees and automates service delivery. Adopters of this agentic management platform recognize significant benefits, such as reduced operational costs and increased employee satisfaction, with one customer achieving a 65% deflection rate within six months of implementation and projections of 80% by the end of the year. Integration within Microsoft Teams and other enterprise tools have further streamlined service delivery, allowing employees easier access to information and support. The company’s AI-driven approach has resulted in a 20% increase in accuracy and 75% reduction in response latency when compared to competing solutions. To support employees as they manage the high demand of internal requests and to create a more satisfying work environment, BDO Colombia used Copilot Studio and Power Platform to develop BeTic 2.0 — an agent that centralizes and automates key payroll and finance processes. The agent reduced operational workload by 50%, optimized 78% of internal processes and showed 99.9% accuracy in managed requests. It also helped reduce duplicative work, optimized workflows, improved the employee-client experience and continues to serve as a competitive differentiator for the company in the market. Dow is using agents to automate the shipping invoice analysis process and streamline its global supply chain to unlock new efficiencies and value. Receiving more than 100,000 shipping invoices via PDF each year, Dow built an autonomous agent in Copilot Studio to scan for billing inaccuracies and surface them in a dashboard for employee review. Using Freight Agent — a second agent built in Copilot Studio — employees can investigate further by “dialoguing with the data” in natural language. The agents are helping employees solve the challenge of hidden losses autonomously within minutes rather than weeks or months. Dow expects to save millions of dollars on shipping costs through increased accuracy in logistic rates and billing within the first year. As a leading provider of sustainable energy in Belgium, Eneco serves over 1.5 million customers. Facing performance issues with their existing chatbot, Eneco developed a new AI-driven agent using the no-code, graphical interface in Copilot Studio. This multilingual agent was deployed on the company website in just three months, integrating seamlessly with its live chat platform. The new agent manages 24,000 chats per month — an increase of 140% over the previous solution — and resolves 70% more customer conversations without a handoff to a live representative. For requests that do require escalation, the agent provides an AI-generated summary of the conversation for a more optimized call center experience. To reimagine trend forecasting and consumer marketing, The Estée Lauder Companies Inc. leveraged Copilot Studio to develop ConsumerIQ — an agent that centralizes and streamlines consumer data to enable instant access to actionable insights. Using natural language prompts, the agent reduced the time required for marketers to gather data from hours to seconds, while accelerating decision-making and helping prevent duplicated research. Together with Azure OpenAI Service and Azure AI Search, teams can gather data, identify trends, build marketing assets, inform research and move products to market faster. To create proposals and streamline knowledge retrieval and organization, Fujitsu leveraged Azure AI Agent Service within Azure AI Foundry to develop an intelligent, scalable AI agent for sales automation. The agent boosted productivity of sales teams by 67% while addressing knowledge gaps and allowing them to build stronger customer relationships. This transformation allowed teams to shift from time-intensive tasks to strategic planning and customer relationship building, while also supporting new hires with product information and strategic guidance. To reduce manual tasks and help employees deliver exceptional experiences, global baker Grupo Bimbo established its first ever technology Center of Excellence. Using Power Platform solutions and Copilot Studio, teams created 7,000 power apps, 18,000 processes and 650 agents to reduce busy work and enhance consumer service. By automating low-value tasks, the company saved tens of millions of dollars annually in development efforts and operational efficiencies. Grupo Bimbo also migrated to Azure for its AI capabilities, scalability, security and rapid time to market for apps. KPMG developed Comply AI — an agent that helps identify environment, social and governance compliance. Using Microsoft AI technologies, the agent helps identify relevant obligations, generate statements in natural language, assess control effectiveness and redraft control descriptions. This has already helped one of its customers achieve 70% improvement in Controls and Risks descriptions, an 18-month reduction in compliance program timelines and a 50% cut in ongoing compliance efforts. KPMG is also using

tech blog

A guide to deciding what AI model to use in GitHub Copilot

To ensure that you have access to the best technology available, we’re continuously adding support for new models to GitHub Copilot. That being said, we know it can be hard to keep up with so many new models being released all the time. All of this raises an obvious question: Which model should you use? You can read our recent blog post for an overview of the models currently available in Copilot and their strengths, or check out our documentation for a deep dive comparing different models and tasks. But the AI landscape moves quickly. In this article we’ll explore a framework—including a few strategies—for evaluating whether any given AI model is a good fit for your use, even as new models continue to appear at a rapid pace. It’s hard to go wrong with our base model, which has been fine-tuned specifically for programming-related tasks. But depending on what you’re working on, you likely have varying needs and preferences. There’s no single “best” model. Some may favor a more verbose model for chat, while others prefer a terse one, for example. We spoke with several developers about their model selection process. Keep reading to discover how to apply their strategies to your own needs. 💡 Watch the video below for tips on prompt engineering to get the best results. Why use multiple models? There’s no reason you have to pick one model and stick with it. Since you can easily switch between models for both chat and code completion with GitHub Copilot, you can use different models for different use cases. It’s kind of like dogfooding your own stack: You won’t know if it really fits your workflow until you’ve shipped some real code with it. – Anand Chowdhary, FirstQuadrant CTO and co-founder Chat vs. code completion Using one model for chat and another for autocomplete is one of the most common patterns we see among developers. Generally, developers prefer autocompletion models because they’re fast and responsive, which they need if they’re looking for suggestions as they think and type. Developers are more tolerant of latency in chat, when they’re in more of an exploratory state of mind (like considering a complex refactoring job, for instance). Reasoning models for certain programming tasks Reasoning models like OpenAI o1 often respond slower than traditional LLMs such as GPT-4o or Claude Sonnet 3.5. That’s in large part because these models break a prompt down into parts and consider multiple approaches to a problem. That introduces latency in their response times, but makes them more effective at completing complex tasks. Many developers prefer these more deliberative models for particular tasks. For instance, Fatih Kadir Akın, a developer relations manager, uses o1 when starting new projects from scratch. “Reasoning models better ‘understand’ my vision and create more structured projects than non-reasoning models,” he explains. FirstQuadrant CTO and co-founder Anand Chowdhary favors reasoning models for large-scale code refactoring jobs. “A model that rewrites complex backend code without careful reasoning is rarely accurate the first time,” he says. “Seeing the thought process also helps me understand the changes.” When creating technical interview questions for her newsletter, GitHub Senior Director of Developer Advocacy, Cassidy Williams mixes models for certain tasks. When she writes a question, she uses GPT-4o to refine the prose, and then Claude 3.7 Sonnet Thinking to verify code accuracy. “Reasoning models help ensure technical correctness because of their multi-step process,” she says. “If they initially get something wrong, they often correct themselves in later steps so the final answer is more accurate.” There’s some subjectivity, but I compare model output based on the code structure, patterns, comments, and adherence to best practices. – Portilla Edo, cloud infrastructure engineering lead What to look for in a new AI model Let’s say a new model just dropped and you’re ready to try it out. Here are a few things to consider before making it your new go-to. Recentness Different models use different training data. That means one model might have more recent data than another, and therefore might be trained on new versions of the programming languages, frameworks, and libraries you use. “When I’m trying out a new model, one of the first things I do is check how up to date it is,” says Xavier Portilla Edo, a cloud infrastructure engineering lead. He typically does this by creating a project manifest file for the project to see what version numbers Copilot autocomplete suggests. “If the versions are quite old, I’ll move on,” he says. Speed and responsiveness As mentioned, developers tend to tolerate more latency in a chat than in autocomplete. But responsiveness is still important in chat. “I enjoy bouncing ideas off a model and getting feedback,” says Rishab Kumar, a staff developer evangelist at Twilio. “For that type of interaction, I need fast responses so I can stay in the flow.” Accuracy Naturally, you need to evaluate which models produce the best code. “There’s some subjectivity, but I compare model output based on the code structure, patterns, comments, and adherence to best practices,” Portilla Edo says. “I also look at how readable and maintainable the code is—does it follow naming conventions? Is it modular? Are the comments helpful or just restating what the code does? These are all signals of quality that go beyond whether the code simply runs.” How to test an AI model in your workflow OK, so now you know what to look for in a model. But how do you actually evaluate it for responsiveness and correctness? You use it, of course. Start with a simple app Akın will generally start with a simple todo app written in vanilla JavaScript. “I just check the code, and how well it’s structured,” he says. Similarly, Kumar will start with a websocket server in Python. The idea is to start with something that you understand well enough to evaluate, and then layer on more complexity. “Eventually I’ll see if it can build something in 3D using 3js,” Akın says. Portilla Edo

triangular-image
tech blog

How the GitHub CLI can now enable triangular workflows

Most developers are familiar with the standard Git workflow. You create a branch, make changes, and push those changes back to the same branch on the main repository. Git calls this a centralized workflow. It’s straightforward and works well for many projects. However, sometimes you might want to pull changes from a different branch directly into your feature branch to help you keep your branch updated without constantly needing to merge or rebase. However, you’ll still want to push local changes to your own branch. This is where triangular workflows come in. It’s possible that some of you have already used triangular workflows, even without knowing it. When you fork a repo, contribute to your fork, then open a pull request back to the original repo, you’re working in a triangular workflow. While this can work seamlessly on github.com, the process hasn’t always been seamless with the GitHub CLI. The GitHub CLI team has recently made improvements (released in v2.71.2) to better support these triangular workflows, ensuring that the gh pr commands work smoothly with your Git configurations. So, whether you’re working on a centralized workflow or a more complex triangular one, the GitHub CLI will be better equipped to handle your needs. If you’re already familiar with how Git handles triangular workflows, feel free to skip ahead to learn about how to use gh pr commands with triangular workflows. Otherwise, let’s get into the details of how Git and the GitHub CLI have historically differed, and how four-and-a-half years after it was first requested, we have finally unlocked managing pull requests using triangular workflows in the GitHub CLI. First, a lesson in Git fundamentals To provide a framework for what we set out to do, it’s important to first understand some Git basics. Git, at its core, is a way to store and catalog changes on a repository and communicate those changes between copies of that repository. This workflow typically looks like the diagram below: Figure 1: A typical git branch setup The building blocks of this diagram illustrate two important Git concepts you likely use every day, a ref and push/pull. Refs A ref is a reference to a repository and branch. It has two parts: the remote, usually a name like origin or upstream, and the branch. If the remote is the local repository, it is blank. So, in the example above, origin/branch in the purple box is a remote ref, referring to a branch named branch on the repository name origin, while branch in the green box is a local ref, referring to a branch named branch on the local machine. While working with GitHub, the remote ref is usually the repository you are hosting on GitHub. In the diagram above, you can consider the purple box GitHub and the green box your local machine. Pushing and pulling A push and a pull refer to the same action, but from two different perspectives. Whether you are pushing or pulling is determined by whether you are sending or receiving the changes. I can push a commit to your repo, or you can pull that commit from my repo, and the references to that action would be the same. To disambiguate this, we will refer to different refs as the headRef or baseRef, where the headRef is sending the changes (pushing them) and the baseRef is receiving the changes (pulling them). Figure 2: Disambiguating headRef and baseRef for push/pull operations When dealing with a branch, we’ll often refer to the headRef of its pull operations as its pullRef and the baseRef of its push operations as its pushRef. That’s because, in these instances, the working branch is the pull’s baseRef and the push’s headRef, so they’re already disambiguated. The @{push} revision syntax Turns out, Git has a handy built-in tool for referring to the pushRef for a branch: the @{push} revision syntax. You can usually determine a branch’s pushRef by running the following command: git rev-parse –abbrev-ref @{push} This will result in a human-readable ref, like origin/branch, if one can be determined. Pull Requests On GitHub, a pull request is a proposal to integrate changes from one ref to another. In particular, they act as a simple “pause” before performing the actual integration operation, often called a merge, when changes are being pushed from ref to another. This pause allows for humans (code reviews) and robots (GitHub Copilot reviews and GitHub Actions workflows) to check the code before the changes are integrated. The name pull request came from this language specifically: You are requesting that a ref pulls your changes into itself. Figure 3: Demonstrating how GitHub Pull Requests correspond to pushing and pulling Common Git workflows Now that you understand the basics, let’s talk about the workflows we typically use with Git every day. A centralized workflow is how most folks interact with Git and GitHub. In this configuration, any given branch is pushing and pulling from a remote ref with the same branch name. For most of us, this type of configuration is set up by default when we clone a repo and push a branch. It is the situation shown in Figure 1. In contrast, a triangular workflow pushes to and pulls from different refs. A common use case for this configuration is to pull directly from a remote repository’s default branch into your local feature branch, eliminating the need to run commands like git rebase <default> or git merge <default> on your feature branch to ensure the branch you’re working on is always up to date with the default branch. However, when pushing changes, this configuration will typically push to a remote ref with the same branch name as the feature branch. Figure 4: juxtaposing centralized workflows from triangular workflows. We complete the triangle when considering pull requests: the headRef is the pushRef for the local ref and the baseRef is the pullRef for the local branch: Figure 5: a triangular workflow We can go one step further and set up triangular workflows

gettyimages
tech blog

Dell AI Factory and NVIDIA NeMo for Agentic AI

Organizations can now leverage new AI abilities with Dell AI Factory with NVIDIA and NeMo Microservices, to boost productivity.   ​  ​Organizations can now leverage new AI abilities with Dell AI Factory with NVIDIA and NeMo Microservices, to boost productivity. AI Solutions Blog | Dell

iStock
tech blog

The Essential AI PC App: Does It Even Exist?

What’s the one app that makes an AI PC invaluable? Learn how AI PCs quietly transform everyday tasks into powerful experiences.   ​  ​What’s the one app that makes an AI PC invaluable? Learn how AI PCs quietly transform everyday tasks into powerful experiences. AI Solutions Blog | Dell

tech blog

The 2025 Annual Work Trend Index: The Frontier Firm is born

We are entering a new reality — one in which AI can reason and solve problems in remarkable ways. This intelligence on tap will rewrite the rules of business and transform knowledge work as we know it. Like the Industrial Revolution and the internet era, this transformation will take decades to show its full promise — and will bring broad technological, societal and economic change. The 2025 Work Trend Index Annual Report is designed to prepare leaders and employees for this shift. As in previous years, it draws on a large global survey, Microsoft 365 telemetry and LinkedIn hiring and labor trends. New this year are insights from AI-native startups, economists, scientists and academics — all pointing to a seismic shift already underway. In fact, 82% of leaders say this is a pivotal year to rethink core aspects of strategy and operations. The data reveals the emergence of a new kind of organization: the Frontier Firm — built around intelligence on tap, human-agent teams and a new role for everyone: agent boss. While the shift ahead is profound, human ambition, creativity and ingenuity will continue to create new economic value and opportunity. In fact, 71% of workers at these firms say their company is thriving, compared to just 37% globally. You can buy intelligence on tap Imagine if you knew, before the internet took off, just how much it would reshape business. That’s where we are with AI. Intelligence is no longer bound by headcount or expertise. It’s an essential durable good: abundant, affordable and scalable on-demand. As economic and shareholder pressures grow, this on-demand intelligence offers a new lever for growth — one that can close the growing gap between business demands and human capacity. While 53% of leaders say productivity must increase, 80% of the global workforce reports lacking the time or energy to do their job. And on average, employees are interrupted by a meeting, email or ping every 2 minutes. To bridge this Capacity Gap, 82% of leaders expect to use digital labor to expand their workforce in the next 12 to 18 months. Digital labor will spur the reinvention of even the most established firms — and the birth of new companies we haven’t even thought of yet. On LinkedIn, top AI startups are hiring at 2X the rate of Big Tech. Much of that talent is flowing out of Big Tech and staying in the startup world, pointing to a deeper shift where innovation — and opportunity — are rising. As incumbents adapt and challengers scale, like we saw in the .com boom, the rules of talent and competition are being rewritten in real time. Human-agent teams will upend the org chart As AI continues to democratize expertise, we’re seeing a move from rigid org charts to more fluid, outcome-driven Work Charts. These structures flex with the needs of the business, drawing on the right mix of humans and agents to get the job done. While every function will evolve at a different pace and scale, 46% of leaders say their organization is using agents to fully automate workstreams or business processes — with customer service, marketing and product development as the top AI investment priorities. To maximize the impact of these human-agent teams, organizations need a new metric: the human-agent ratio. Leaders must ask two critical questions: How many agents are needed for which roles and tasks? And how many humans are needed to guide them? Getting that ratio right will be critical — and task-specific. Organizations will need to consider if there are times when human and digital labor outperform AI alone, when customers prefer a human touch or when society expects people to be responsible for the consequences — like a high-stakes product or finance decision. Whether it’s a customer conversation, a strategic decision or a product launch, knowing how to staff the right mix of humans and agents will define how work gets done — and how success is measured. Every employee becomes an agent boss As agents increasingly join the workforce, we’ll see the rise of the agent boss: someone who builds, delegates to and manages agents to amplify their impact and take control of their career in the age of AI. From the boardroom to the frontline, every worker will need to think like the CEO of an agent-powered startup. In fact, leaders expect their teams will be training (41%) and managing (36%) agents within five years. For those ready to lean in, AI will be a career accelerator — but leaders are ahead. We measured the agent boss mindset across seven indicators — from regular use and trust to career impact. Leaders outpace employees on every measure: 67% are familiar with agents (vs. 40% of employees) and 79% believe AI will accelerate their careers (vs. 67%). But this shift won’t stop at the top. As agents become embedded into daily work, roles across every level and function will evolve — along with the broader workforce. While 33% of leaders are considering headcount reductions, 78% are considering hiring for new AI roles. And 83% say AI will enable employees to take on more complex and strategic work earlier in their careers. This shift is multifaceted — every industry and role will evolve differently as the technology diffuses across business and society. Just as the internet era created billions of new knowledge jobs — from social media managers to UX designers — the AI era is already giving rise to new roles, with many more to come. Preparing for what’s next is no longer optional. Employees must build AI skills and companies must support them with the right tools and training. This moment calls for honest conversations, intentional communication and real investment in reskilling. The companies that invest now won’t just keep up — they’ll shape what comes next. Copilot is the new UI for AI Today we’re announcing the Microsoft 365 Copilot Wave 2 Spring release — designed to power the next era of human–agent collaboration. The Microsoft 365 Copilot app is now your window into the world of agents, with new capabilities for this next phase — driven by more advanced models, adaptive memory and reasoning agents that work alongside you. Updates include: Researcher and Analyst agents powered by OpenAI’s deep reasoning models rolling

Scroll to Top