Published via [GitHub Executive Insights](https://github.com/solutions/executive-insights "Executive insights, curated just for you")

We've gathered everything enterprise teams need to hit the ground running with GitHub Copilot. From initial setup to advanced features, this guide will walk you through the essential resources to make your Copilot implementation successful.

Foundation & setup
   - [Comprehensive quickstart guide](https://docs.github.com/en/copilot/quickstart)
   - [Enterprise setup instructions](https://docs.github.com/en/enterprise-cloud@latest/copilot/setting-up-github-copilot/setting-up-github-copilot-for-your-enterprise)
   - [Scaling and adoption best practices](https://docs.github.com/en/copilot/rolling-out-github-copilot-at-scale/driving-copilot-adoption-in-your-company)

Team resources
   - [Step-by-step tutorial series](https://github.com/features/copilot/tutorials)
   - [Real-world examples and use cases](https://github.blog/developer-skills/github/what-can-github-copilot-do-examples/)
   - [Practical workflow integration tips](https://resources.github.com/learn/pathways/copilot/essentials/tips-for-a-successful-rollout-of-github-copilot/)

Get the most of copilot
   - [Copilot Chat Cookbook for enhanced productivity](https://docs.github.com/en/copilot/copilot-chat-cookbook) (Find examples of prompts to use with GitHub Copilot Chat)
   - [Usage tracking with metrics API](https://docs.github.com/en/copilot/rolling-out-github-copilot-at-scale/analyzing-usage-over-time-with-the-copilot-metrics-api)
   - [Latest capabilities across programming languages](https://docs.github.com/en/enterprise-cloud@latest/get-started/learning-about-github/github-language-support)

 Tackling Technical Challenges
   - [Strategies for documenting legacy code and maintaining clean, efficient codebases](https://github.blog/ai-and-ml/github-copilot/documenting-and-explaining-legacy-code-with-github-copilot-tips-and-examples/)

Looking forward
   - [New model options including Google Gemini 2.0 Flash](https://github.blog/changelog/2025-02-05-google-gemini-2-0-flash-is-now-available-to-all-copilot-users-in-public-preview/)
   - [OpenAI o3-mini availability](https://github.blog/changelog/2025-02-06-openai-o3-mini-is-now-available-in-github-copilot-free/)
   - [Upcoming features and improvements: GitHub Copilot, The Agent Awakens](https://www.youtube.com/watch?v=C95drFKy4ss)

Your development teams are about to experience a significant boost in productivity with GitHub Copilot. These resources will help ensure a smooth rollout and optimal usage across your organization. As Copilot continues to evolve with new features and capabilities, bookmark our "[What's Next](https://github.com/features/copilot/whats-new)" page to stay current with the latest updates and improvements.

---

Want to learn more about the strategic role of AI and other innovations at GitHub? Explore [Executive Insights](https://github.com/solutions/executive-insights) for more thought leadership on the future of technology and business.

Getting started with GitHub Copilot doesn't have to be complicated.

Resource Page for /enterprise/essential-copilot-resources

Essential GitHub Copilot resources for enterprise teams

# AI-powered DevOps with GitHub and Azure

Infuse generative AI, best-in-class security, and cloud-native capabilities to your DevOps pipeline with the GitHub platform and Azure.

In this e-book, AI-powered DevOps with GitHub and Azure, learn how to drive efficiency, enhance security, and deliver value faster by:<br>
- Automating the mundane and working smarter with AI.<br>
- Protecting every line of code with integrated security.<br>
- Boosting productivity with built-in automation and CI/CD workflows.<br>
- Further elevating development teams with Azure knowledge bases.<br>

Form_Gated_PDF - "Read the ebook"

Tell us a bit about you.

Read the ebook

Boost the productivity and time to value of your DevOps practice with the integrated AI and security capabilities of the GitHub platform with Azure integration.

# AI-powered DevOps with GitHub and Azure

Infuse generative AI, best-in-class security, and cloud-native capabilities to your DevOps pipeline with the GitHub platform and Azure.

In this e-book, AI-powered DevOps with GitHub and Azure, learn how to drive efficiency, enhance security, and deliver value faster by:

- Automating the mundane and working smarter with AI.
- Protecting every line of code with integrated security.
- Boosting productivity with built-in automation and CI/CD workflows.
- Further elevating development teams with Azure knowledge bases.


/ai-powered-devops-with-github-and-azure

CO-GHP-CNTNT-FY25-02Feb-13-AI-powered-DevOps-with-GitHub-with-Azure

AI-powered DevOps with GitHub and Azure – GitHub Resources

Published via [GitHub Executive Insights](https://github.com/solutions/executive-insights "Executive insights, curated just for you") | Authored by [Jakub Oleksy](https://github.com/JakubOleksy "@JakubOleksy") and [Matt Nigh](https://github.com/mattnigh "@mattnigh")

As engineering leaders, we’re always being asked to get the most out of engineering teams. This is most often measured by what things we can ship, and how fast. But it can be easy to fall into a common trap: doing too much at once, convinced that more parallel work means more output. 

We often fool ourselves into thinking that we’re making progress by simply having at least someone spending cycles on each thing.

*But what if the key to shipping more is actually doing less?*

First, we have to acknowledge that until we ship something and it is being used, it’s not valuable. So our goal should always be to get things out.

Once things are out, we can learn, adapt, and adjust—including deciding to not further pursue. 

This seems obvious; we should, after all, always prioritize finishing what we deem most critical. 

So, where do we fall short? Most often it is simply our inability to say no. The other things are also great ideas and it's hard to not at least try to do them. But each of these decisions (or, really, lack of decisions) only delays the things that are most important.

The other, related problem, is that even if we do select the most important work, we often execute on it in a monolithic fashion. That means it’s hard to pivot if needed, until we finish. 

There are some core principles we should follow as we look to run nimble engineering teams that ship ongoing value to our customers:
- Make all work visible
- Define work in small chunks
- Limit work in progress
- Fund to capacity
- Bonus: leave capacity for the unknown

### Make all work visible
As engineering leaders, we often think we have a clear picture of what our teams are working on. 
> Making work visible makes it impossible to ignore reality. When you see everything written down in one place, you can't maintain the fiction that your team can handle "just one more small feature." 

The list becomes your reality check, your shield against overcommitment, and your tool for having honest conversations about capacity and priorities. But visibility isn't just about seeing problems—it's about enabling solutions. 

When you can see all the work your team is focused on, you can:

- Make informed decisions about what to prioritize
- Identify which work to stop or pause
- Keep teams focused on completing rather than just starting

Think of it like packing a suitcase. You can keep cramming things in until the zipper breaks, or you can lay everything out on the bed first, see what you're really dealing with, and make conscious choices about what makes the cut.

Remember: the goal isn't to track everything forever. The goal is to see reality clearly enough to make better decisions about where your team's time and energy should go. Because in the end, the most productive teams aren't the ones doing everything—they're the ones doing the right things, and finishing them.
### Define work in small chunks
One of the most powerful shifts you can make in your engineering organization is breaking work into smaller pieces. I learned this lesson repeatedly throughout my career, most often when I needed to adjust course and had to deal with the consequences of stopping things mid-flight. 

> When you let work items grow too large, they become black holes that consume your team's energy without showing meaningful progress. Talented teams can get stuck in months-long development cycles, their momentum grinding to a halt as they chase ever-moving finish lines.

__The magic happens when you constrain work to one-to-two week increments.__ This isn't arbitrary—it's about human psychology and team dynamics. When developers can complete meaningful work within a week, they experience regular wins. They stay motivated. They maintain their flow state. Most importantly, they can pivot quickly when needed without throwing away months of work.

Breaking work into smaller chunks also creates moments in time for reflection and adjustment. At GitHub, this approach helped us evolve from shipping massive internal tools to making iterative improvements that benefited both our internal development teams and our customers. Each small chunk gave us the opportunity to ask: "Is this still taking us in the right direction?"

Small chunks enable better collaboration too. When work is constrained to one-to-two weeks:

- Code reviews become more manageable
- Knowledge sharing happens naturally
- Teams can pair effectively
- Feedback loops tighten
- Deployment risk decreases

__But here's what really matters: small chunks of work help support developer flow.__ When developers can see the finish line, when they know they can complete something meaningful in a short time frame, they stay focused. They don't get lost in the complexity of massive features. They maintain momentum.

I've seen the difference this makes in code quality too. Smaller chunks mean more focused testing, more thorough reviews, and fewer risks in deployment. It's the difference between trying to review 1,000 lines of code at once versus reviewing 100 lines five times over a two-week period. Which do you think gets better scrutiny?

This might feel slower. And in fact, if you could plan a feature perfectly from day one that takes X months to finish and then just execute on it straight through, you would likely get it done faster. 

However, it’s important to consider the risks. First, the risk of having the wrong plan from the onset and not having any defined milestones to reflect. Next, the cost of pivoting the team's work if something else, unforeseen, becomes a higher priority. And finally, scope creep will inevitably occur, the size of which is often proportional to the total size of the project. 

You're not trying to slow down development by breaking things into smaller pieces. You're actually speeding it up by making progress visible, maintaining momentum, and enabling your team to deliver value continuously rather than in sporadic, massive chunks. And when you cross that finish line, you’re doing so while still feeling good, instead of exhausted from an unpredictable race.

One key practice to make this successful is starting every 1-2 week sprint with a deep planning session that outlines exactly what the exit criteria are, who is doing what and breaking that work down to even smaller pieces, often by identifying tasks that will take half a day or even less.
### Limit work in progress
Multiple features per developer might seem like a path to higher productivity, but it's actually a productivity killer. 
> When developers juggle multiple projects, it can be challenging to make meaningful progress on any of them. It's like trying to cook five meals at once—you'll likely burn something, forget ingredients, or end up with everything taking twice as long.

Context switching becomes particularly costly. Every time a developer shifts between features, they need to reorient themselves around the entire context of a new feature—the requirements, the technical constraints, the related code, and the outstanding questions, among other things. Research suggests [it can take up to 23 minutes to fully regain focus](https://lifehacker.com/how-long-it-takes-to-get-back-on-track-after-a-distract-1720708353) after a switch. With multiple features in flight, developers spend more time context switching than actually writing code.

Quality may suffer too. When attention is divided across multiple features, important details can get missed, edge cases go unconsidered, and technical debt accumulates. We've seen this pattern repeatedly at GitHub: the more work in progress, the higher the bug count and the lower the overall code quality.

Perhaps most importantly, team frustration sets in. Developers thrive on the satisfaction of completing work and shipping features to users. When everything is "in progress" but nothing is getting done, morale takes a hit. I've watched talented teams become discouraged simply because they couldn't see their impact. Instead,they were too spread thin across too many initiatives.

The solution isn't working longer hours or pushing harder. It's doing less at once. When we limit the work that’s in progress and focus our teams on one or two features at a time, we actually ship more—and we ship better quality work with happier developers.

### How do we know when teams take on too much work simultaneously?
__Indicators at the team-level include:__
- Multiple active features per developer (e.g., four-plus concurrent tasks)
- Features taking weeks or months longer than estimated
- Many partially completed features, few shipped ones

__Indicators for individual developers:__
- Difficulty maintaining focus or getting into flow state
- Long delays in responding to code reviews
- Increased time spent in status meetings explaining in-flight work
- Difficulty articulating current priorities
- Large pull requests (PR)

__Morale symptoms__
- Team frustration from lack of completion
- Decreased sense of impact and accomplishment
- Rising stress levels from juggling multiple priorities
- Burnout from constant task switching
- Loss of enthusiasm for new initiatives

__Delivery patterns__
- Many features at 80% complete, few at 100%
- Increasing time between deployments
- Features being abandoned mid development
- Rising number of emergency fixes
- Longer cycle times from start to completion

### Fund to capacity
This is the idea that you should fully fund your highest priority work before moving on to the next thing. It's a simple concept that challenges a common anti-pattern I've seen across many engineering organizations—the "one developer, one feature" approach.

Here's what typically happens: You have a team of eight developers, so you assign eight different features, one to each developer. It seems logical, right? Everyone's busy, everything's moving forward. But this is actually a recipe for slower delivery and fragmented knowledge.

I often see managers do this because every individual on the team wants projects that can get them promoted. Managers think the only way to do this is for every developer to lead a project, so naturally, they create a project for every developer.
> Try this: Take your top priority and put as many developers on it as you can—until they're literally stepping on each other's toes. Only then should you move on to the next priority. This is what we call "funding to capacity," and it's transformative.

Let me be clear about why this works. When you swarm as a team on a single feature:

- Knowledge spreads naturally across the team
- Solutions emerge faster through collaboration
- Code quality improves through real-time peer review
- The feature ships significantly faster
- Team energy builds through shared accomplishment

At GitHub, we've seen this approach repeatedly outperform individual assignments. For instance, when we tackled our deployment pipeline improvements, we didn't distribute the work across individual developers. We swarmed it. The result? Not only did we ship faster, but we ended up with a team of developers who all understood the deployment system deeply, rather than just one or two experts.

Here's something that might be controversial: in this model, it can be helpful to pair developers to work on a discrete task. Yes, it might seem like you're "wasting" a developer's time by having them work together. But think about the hidden costs of isolation—knowledge silos, longer review cycles, lower code quality, and the bus factor of having only one person who understands each feature.

When you fund work to capacity, you're not just optimizing for speed.You're building team resilience. Every feature becomes a shared learning opportunity. Every challenge becomes a chance for collective problem solving. You're creating an environment where developers aren't just coding—they're growing together. 

And reflecting on the desire for individuals to get promoted, this is where what you reward is what you get. Promote those individuals that embrace the team over individual accomplishments, those that strive to improve the outcomes, together, rather than those that think individual productivity is the key to success.
### Leave room for the unknown
A highway operating at 100% capacity isn't a highway—it's a parking lot. The same principle applies to engineering teams. You need space to absorb the unexpected. Some teams might need less, others more. 
> If your team is working at 100% capacity, you're actually operating at a deficit. Because here's the reality—unplanned work isn't actually unplanned. It's inevitable. What's unplanned is just the timing and the specifics.

__Here's what happens when you don't leave room for the unknown:__

- Teams become reactive instead of creative
- Quality suffers as corners are cut to "make up time"
- Developer satisfaction plummets
- Innovation decreases because there's less space to experiment
- Technical debt accumulates because there's never time to address it

__But when you deliberately maintain buffer capacity:__

- Teams can respond to issues without derailing planned work
- Developers have space to think creatively about solutions
- There's room for learning, experimentation, and innovation
- Quality remains high because teams aren't constantly rushing
- Morale stays strong because the pace is sustainable

Here's a counterintuitive truth: Teams with built-in buffer capacity often deliver more than teams running at "full" capacity. They're more innovative, more resilient, and ultimately more productive. Because when everything is an emergency, nothing gets done well.

__So what's the right amount of buffer?__ Start with 20% and adjust based on your team's needs. Infrastructure teams might need more, feature development teams might need less. The key is to be intentional about it. Don't treat buffer capacity as waste—treat it as a crucial investment in your team's ability to handle reality.

Your team's capacity isn't just about the work you can predict. It's about maintaining the resilience to handle what you can't predict while keeping your developers creative, engaged, and doing their best work.
### Take this with you
We learned that the path to shipping more wasn't about increasing our velocity or adding more developers—it was about having the discipline to do less at once.
The formula is deceptively simple:
- Make work visible so you can't hide from reality
- Break it into small chunks that maintain momentum
- Limit work in progress to enable focus
- Fund priority work to capacity
- Leave room for the unexpected

But simple doesn't mean easy. These principles challenge our instincts as leaders. They require us to say no more often than yes. They demand that we resist the siren call of parallel work and trust that focusing on fewer things will actually help us ship more.
Your team's true capacity isn't measured by how many features they can juggle, but by how effectively they can deliver value to your customers. Sometimes, the most powerful thing you can do as a leader is to take something off your team's plate rather than add to it.

---

Want to learn more about the strategic role of AI and other innovations at GitHub? Explore [Executive Insights](https://github.com/solutions/executive-insights) for more thought leadership on the future of technology and business.


Form_Ungated_Contact

Tell us more about your needs

Wondering how GitHub can help your business?

What if the key to shipping more is actually doing less?

Resource Page for /developer-productivity/engineering-team-focus

The art of engineering team focus: less is more

During the webinar, Richard Erwin, Principal Solutions Engineer at GitHub, showcased Copilot's advanced features, constant evolution, and practical applications. We’ll start with a high-level understanding of GitHub Copilot, and then dive deeper to show practical tips that can boost your productivity and improve your code quality thanks to key feature demos.

Learn more about:
- How GitHub Copilot uses an advanced language model trained on public code to assist with secure coding across multiple platforms.
- How to evaluate GitHub Copilot’s value based on developer time, potential time-saving, and overall developer satisfaction.
- Tips on installation and using Copilot for pull requests, summary notes, repository queries, and more.
- Enterprise-level features, such as how to set policies around how GitHub Copilot is used in your organization.

*https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-in-the-enterprise-with-accenture/ 


Gated video page generic form

Tell us a bit about you

Sign up to watch

Designed and backed by the leaders in AI, GitHub Copilot is an AI pair programmer that helps developers write code faster and smarter. GitHub Copilot supports multiple languages across the developer workflow. GitHub Copilot’s powerful features have been proven to help developers code up to 55% faster*, accelerate the pace of software development, and enhance the developer experience. 

<div class="embed-responsive embed-responsive-16by9">
  <iframe src="https://www.youtube.com/embed/giPoDt_Ujzo" width="640" height="375" frameborder="0" allowfullscreen></iframe>
</div>

During the webinar, Richard Erwin, Principal Solutions Engineer at GitHub, showcased Copilot's advanced features, constant evolution, and practical applications. We’ll start with a high-level understanding of GitHub Copilot, and then dive deeper to show practical tips that can boost your productivity and improve your code quality thanks to key feature demos.

Learn more about:
- How GitHub Copilot uses an advanced language model trained on public code to assist with secure coding across multiple platforms.
- How to evaluate GitHub Copilot’s value based on developer time, potential time-saving, and overall developer satisfaction.
- Tips on installation and using Copilot for pull requests, summary notes, repository queries, and more.
- Learn about enterprise-level features, such as how to set policies around how GitHub Copilot is used in your organization.

*https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-in-the-enterprise-with-accenture/ 


AI Background - Artificial Intelligence pillar - Dark 4

Resource Page for /artificial-intelligence/introduction-to-github-copilot

CO-GHAI-CNTNT-FY25-01Jan-23-Intro-to-GitHub-Copilot-8292

Introduction to GitHub Copilot

This session will delve into real-world applications and a future where AI fortifies defenses and helps preemptively identify and mitigate emerging threats. This session is designed for developers, security experts, and executives alike.

Key takeaways:

- __Key Takeaway 1__: Turn "I don't know what I don't know" into a firm grasp of current challenges in application security.
- __Key Takeaway 2__: Walk away with an understanding of how AI and GitHub can help solve current challenges in application security.
- __Key Takeaway 3__: Learn actionable next steps to apply AI to your application security using GitHub.

AI is far from reaching its peak in application security. How GitHub applies AI to help streamline remediation and enhance alert interpretability.

<div class="embed-responsive embed-responsive-16by9">
  <iframe src="https://www.youtube.com/embed/xvDzKXASPSI" width="640" height="375" frameborder="0" allowfullscreen></iframe>
</div>

This session will delve into real-world applications and a future where AI fortifies defenses and helps preemptively identify and mitigate emerging threats. This session is designed for developers, security experts, and executives alike.

Key takeaways:

- __Key Takeaway 1__: Turn "I don't know what I don't know" into a firm grasp of current challenges in application security.
- __Key Takeaway 2__: Walk away with an understanding of how AI and GitHub can help solve current challenges in application security.
- __Key Takeaway 3__: Learn actionable next steps to apply AI to your application security using GitHub.

AI Background - Artificial Intelligence pillar - Dark 1

Resource Page for /artificial-intelligence/mission-copilot-autofix-securing-the-worlds-software

CO-GHS-CNTNT-FY25-12Dec-26-On-demand-Mission-Copilot-Autofix-8191 / 466749

Mission Copilot Autofix: Securing the world's software

This will explore how GitHub Advanced Security (GHAS), powered by GitHub Copilot, revolutionizes vulnerability remediation and security debt management. The speakers will showcase current capabilities that can help developers rapidly address vulnerabilities and preview upcoming Copilot Autofix expansions.

Learn how these innovations can transform security practices, enabling efficient vulnerability management and proactive security debt reduction, encouraging developers to both build and run code, and help quickly and more easily secure it.

__Key takeaways:__

- __Key Takeaway 1:__ Discover how GitHub Copilot solutions can help reduce security debt at scale.
- __Key Takeaway 2:__ Learn how GitHub is redefining "shift left" by working to identify and address vulnerabilities before they reach production.
- __Key Takeaway 3:__ Gain insight into upcoming Copilot Autofix features that aim to expand security issue resolution.

Software vulnerabilities accumulate over time, creating security debt. While traditional AppSec tools identify issues, fixing them remains challenging due to limited expertise and time.

<div class="embed-responsive embed-responsive-16by9">
  <iframe src="https://www.youtube.com/embed/4hXe7WBFzwo" width="640" height="375" frameborder="0" allowfullscreen></iframe>
</div>

This will explore how GitHub Advanced Security (GHAS), powered by GitHub Copilot, revolutionizes vulnerability remediation and security debt management. The speakers will showcase current capabilities that can help developers rapidly address vulnerabilities and preview upcoming Copilot Autofix expansions.

Learn how these innovations can transform security practices, enabling efficient vulnerability management and proactive security debt reduction, encouraging developers to both build and run code, and help quickly and more easily secure it.

__Key takeaways:__

- __Key Takeaway 1:__ Discover how GitHub Copilot solutions can help reduce security debt at scale.
- __Key Takeaway 2:__ Learn how GitHub is redefining "shift left" by working to identify and address vulnerabilities before they reach production.
- __Key Takeaway 3:__ Gain insight into upcoming Copilot Autofix features that aim to expand security issue resolution.

Resource Page for /security/mission-copilot-autofix-securing-the-worlds-software

CO-GHS-CNTNT-FY25-12Dec-26-Found-means-fixed-On-Demand-8190 / 466295

Found means fixed: Addressing security debt at scale

Home > Bottom > Banner (Accelerate...)

Curate blazing fast developer environments and help your organization be more agile, secure, and efficient.

Home > Bottom > Card #1 (Codespaces)

Ship secure applications with a community-driven, developer-first approach.


Home > Bottom > Card #2 (Adv. Sec.)

Automate your software workflows with a powerful DevOps toolkit and built-in CI/CD.

Home > Bottom > Card #3 (Actions)

Safely publish and consume packages within your organization.

Home > Bottom > Card #4 (Packages)

Home > Feature > Banner > CTA

Home > Feature > Banner (Learning Pathways)

Bring the power of generative AI to engineering teams with GitHub Copilot. Learn how you can maximize developer velocity and innovation.


Copilot card

Stay one step ahead by shipping your software securely within GitHub: Identify and fix security issues directly in the developer flow.

Security Card

Learn why more than 90% of the Fortune 100 use GitHub—the leading developer platform compared to alternative solutions.

Why GitHub? Card

Become a GitHub expert in CI/CD, application security, governance, and AI-developer tools through expert-guided learning pathways with tips and insights from leading enterprise organizations.

Resource Page for /learn/build-like-the-leading-tech-innovators

CO-GHG-CONTACT-FY23-10Oct-01-WW-Resources-Contact-Request/406214

GitHub Learning Pathways

Home > Final > Banner > CTA

Home > Final > Banner (Sales Team)

Home > Hero > CTA #1

Home > Hero > CTA #2

Set your business up for success with solutions to any number of common questions.

Essential GitHub Copilot resources for enterprise teams

AI-powered DevOps with GitHub and Azure – GitHub Resources

The art of engineering team focus: less is more

Browse by topic

Latest videos

Introduction to GitHub Copilot

Mission Copilot Autofix: Securing the world's software

Found means fixed: Addressing security debt at scale

Accelerate innovation with the platform developers love

Codespaces

Advanced Security

Actions

Packages

Questions? Reach out to our sales team