The Copilot Advantage: Transforming Development Across Your Company 

At Xebia we have helped a lot of companies to really embrace GitHub Copilot as the revolution it is to our industry. There is a lot more to do then just handing out a license to everyone and hope that you get “10x developers”. To get the most out of Copilot you need to accept that this is a complete rewire for both engineers and stakeholders alike (users, product owners, scrum masters, etc). We see that Copilot touches our entire software development lifecycle (SDLC): from ideation and requirements engineering, to handling bugs in production code.  

With the enablement of our stakeholders, it becomes critical to follow the best practices that we have been advocating for years: have a good safety net that looks if there are no regressions with new incoming changes, validate in multiple environments, and fail fast and early with graceful fallbacks in case of issues. 

Proper enablement 

In this article I’ll take you through the steps we take with customers that want to get the most out of their new way of working and really reap the benefits of the new age of AI enhanced development. As you can guess from this article: really enabling engineers is more then just handing out a license to everyone😁.  

We’ll go over the following steps in the enablement process: 

To top it all of I will conclude with the ways that tools like GitHub Copilot impact the Software Development Lifecycle (SDLC), as this can be in more ways then you’d imagine! 

Getting a license 

An often underestimated topic is the process of handing out licenses. We have seen companies where “everyone just gets a license”, and we have seen companies where you need to know the right path and then still beg for receiving a license, and everything in between. There is a lot more to it: first of all the process should be an invite to join the Copilot community and be open to start learning about how this tool impacts your normal way of working. Next up, it is the first opportunity to welcome the new employee or new Copilot user, so communication is an important part: can people request a license through self-service, what kind of training is required, and how do they hand back the license in case they decide not to use it? The next level is automatically revoking the license in case of the employee leaving a certain role, team, or even the company. All steps in this entire process need to be in place, to prevent spending money on licenses no-one is using. Key in this is communication to users and defining what you expect them to do. Add in the communication which trainings that people are expected to take (see next section), as well as the ways to contact support in case they need help with installing the tools into their editors, or with logging in for the license. 

Training 

Using tools like GitHub Copilot really comes with a learning curve. I have been training engineers for years now on Copilot, and even I still learn new things, almost every week/ The minimal training engineers should have in my opinion is a basic “Getting started with GitHub Copilot” training as well as “Using AI tools responsibly”. Next to that there are a whole extra list of topics to dive into, to get the most value out of GitHub Copilot. Some of these topics are: 

Hands-on experience 

This part of the rollout process should not be taken to lightly: If you do not focus on the hands-on experience, then you will be missing out. We have seen teams where people do not progress from just using the chat to the other functionality!  

There are a lot of features that depend on where you are using GitHub Copilot from: if you only use GitHub in your editor, then you are missing out on the features that it offers on github.com.  

With the hands-on experience we do focussed hackathons in different flavours: 

Giving teams the time to spend hands-on with the new tools also sends out an important signal from the management as well: it indicates you understand that there is a ramp-up in becoming more efficient, and you are willing to spend that time for them to fully embrace it (instead of just focussing on getting the next new feature in your application out the door). 

Q/A sessions 

We advise to hold at least in the beginning (bi-)weekly sessions where people can ask questions on how to do things. Even though you might hear some good feedback after doing all the other things, there will be questions running through the teams, that you won’t pick up if they stay within the teams themselves. Open up a space where people can come and explain a thing they are thinking about, or share issues they might be running into. This gives you visibility into the things Copilot users are working with. It is a opportunity to keep feeding the users information about the different extensions, or about new models coming out. We kick of the session with a topic to inspire and get people going, and then we open up the floor for any questions that might arise. We then capture frequent topics in wiki’s, additional training material, and sometimes even kick off internal collaboration on a specific topic (for example: sharing your custom instructions and prompt files within the company! 

Newsletters 

Often we see that companies have not really setup a great engineering community that regularly shares knowledge internally. Often the communication stays within the different teams or tribes, which is rather locally. With GitHub Copilot you have the opportunity to transcend that level and go global! A starting point can be as simple as setting up a chat channel for Copilot, where you can share news and updates, and engineers can find each other and ask questions. From that channel you can gather the email addresses from enthusiasts (or grab the people that have a Copilot license!), and start sending out the news and updates: that can be just new features and models coming up, but also internal training videos that team members create. Go someone that is enthusiastic about Copilot and can keep shut on how they build something cool? Hand them a microphone, record a short demo, and share it will all users! This is a great way to bridge the internal gaps between teams, and slowly build out the community. 

Community 

Setting up a community goes further then just a chat channel and a newsletter. It is all about bringing people together so they can freely share things, and thus learn from each other. The amount of times we have seen that engineers from different teams where reinventing the wheel are countless. Without an open way to communicate with each other, teams are just not aware of the other teams, let alone what they are working on or what they are struggling with! At Xebia, we say that building up a community around knowledge sharing, is part of building an “Engineering Culture”. A knowledge driven organization is one of the seven pillars of the engineering culture. You can learn more about what that entails here: E-book: Building Engineering Culture 

Impact on the SDLC 

Now that we have seen the ways to really enable people and take them through the learning curve on GitHub Copilot and “engineering augmentation”, lets take a step back and take a more holistic look at how these new AI tools impact our Software Development Lifecycle. 

Ideation 

Often people are not aware, but the ideation phase can see a massive impact with AI as well. This can elevate an engineer that is researching the requirements for a specific feature that a stakeholder has requested, or a product owner by mapping those requirements into actual work that can be planned. With tools like Copilot Spark you can go from an idea to a prototype in mere minutes. Our challenge is enabling all these types of roles with AI, so that these people can focus on what they do best: adding business value for the end users of their solutions. 

Coding 

The impact on the coding cycles seem evident and that is why people choose Copilot. What they often forget is to dive deeper then just the tools inside of the editor. Copilot Coding Agent is a game changer (read more info here: About GitHub Copilot coding agent - GitHub Docs) to go from a work description to a PR with Agentic AI. Don’t forget to also take a look at the new Copilot CLI: where you can run a prompt straight from your CLI, and collaborate with an agent outside of the IDE. 

Reviews 

Another agent is the Review Agent, that can lower the burden on the review process. We often still see that there are one or more folks responsible for reviewing incoming changes. Since the other engineers producing the changes now have Agent Mode and Coding Agent, the amount of changes (and often their size as well) increases dramatically, making the reviewer the bottleneck between changes and production. Use Copilot for handling the simpler things in the review process: either use the Review Agent or let the VS Code PR Extension review the changes in your editor. It can handle the low hanging fruit, and sometimes surprises us with findings that we did not even think of! 

Handling CI/CD runs 

Similarly you can embed Copilot into the pipelines parts of your workflow: if there is an issue anywhere in your pipeline, you can let Copilot see the exception message, and analyze what part of your codebase could have this impact. Even better: with that information, Copilot can also propose a fix! For usage in GitHub Actions there is a button to directly feed the error to Copilot, letting you analyze it directly from you pipeline! Of course this also works with any other CI/CD system, as long as you can share the errors.  

Closing the feedback loop with AI 

Any place in either your pipeline or production is an opportunity to leverage AI to speed up initial analysis or even generate suggestions and fixes. Got an error in your pipeline or in production? Use AI to write a detailed analysis, including a reference to a part of the codebase where the error is coming from. Then drop that into an issue and let Coding Agent handle the rest of the analysis and let it create a PR from it!  

The next step is to automate recurring tasks the same way: want to get a grip on your technical dept? Schedule a workflow (you can embed the Copilot CLI into that for example), have an AI analyze the codebase and find a recurring issue, or pick a random finding on the codebase. With that information: create an issue and assign it to the Coding Agent.  

We have seen teams use this to their benefit, with examples like creating a daily task to look at the next class that has low code coverage with regards to unit testing. By doing so the managed to continuously improve over time which let them catch up much quicker then they could do by running the improvements slowly over time from using Agent Mode. 

Closing off 

Use the engineering capabilities in your teams, as you have been brought onto the team because of your creative thinking skills. The engineers are not in the team to write the next for-loop or if-statement: they where hired to focus on systems-thinking: they can think of requirements, changes, and the effect those changes can have on the system. Using AI in the right places in the SDLC can be a massive improvement, as long as you properly enable people, both with training on the new skills and giving them the time to embrace all the new options they see, so that they can focus again on adding more business value for the end-user of their solutions.