AI for Engineering Teams. Copilot Adoption Tips

I’ve previously mentioned that Akvelon has embarked on its journey to become AI-turbocharged, and we are currently working towards the following main directions:

1. Active adoption of existing AI tools such as Copilot, Copilot Chat, ChatGPT, Postman AI, etc.
2. Working on our own solutions and Intellectual Property (IP) tailored to specific projects and client needs — both client and engineering-facing.

Around 51% of our teams have started using Copilot, and we plan to collect adoption metrics soon. But before that, I’d like to share our GitHub Copilot adoption tips that helped us successfully onboard the tool across 80+ engineering teams.

Tip1. Ensure Copilot can benefit the project before discussing it with a client and onboarding

GitHub Copilot is a powerful and useful tool that can boost team performance. However, it also has restrictions and limitations that make it applicable only to some of the projects.

Being aware of this, we decided to start with a preliminary evaluation of Copilot’s possible impact on each project before approaching our clients and asking all engineers to start using it, selecting a champion from teams, and conducting research.

We were surprised that in 23% of cases, our teams reported that Copilot is not applicable or can add a very limited value. We discovered that on many complex enterprise projects, teams spend most of their time on technical engineering support and troubleshooting complex issues that do not involve writing a lot of code, which Copilot is very good at.

Below is our short checklist for the teams and project assessment template.

Tip 2. Be prepared to address the clients’ main concerns

The fact that Copilot sends your code to the server side (learn more) has brought up different questions regarding its security and privacy compliance and possible Intellectual Property (IP) violations. Below are the most popular client concerns.

I worry that my code will be compromised

Our recommendation to address this concern is to use a combination of best engineering practices, such as “no sensitive information, connection strings, PII data, etc., is stored as part of the source files” so that GitHub Copilot doesn’t access this information. We also actively refer to information provided in the GitHub Copilot Trust Center and GitHub Copilot Product Specific Terms. Here are some key takeaways from these resources:

• GitHub Copilot does not access all project files. Copilot’s context is very limited to a few files you work with.
• The data sent to the GitHub server is encrypted in transit and is deleted once a suggestion is generated (it’s not stored at rest).
• GitHub Copilot won’t use your data for any purpose other than generating suggestions. AI model won’t be trained on it.
• The data you have provided and generated suggestions won’t be shared with other users.

Who owns the generated code

GitHub does not claim ownership rights for generated suggestions. You retain ownership of your code.

What if the code generated by GitHub Copilot contains copyright violations?

• It is important to understand that Copilot does not “copy-paste” code. Instead, it generates suggestions based on the current context using probabilistic reasoning.
• There are still scarce instances where suggestions from GitHub may match examples of code used to train GitHub’s AI model. To avoid this risk, Copilot has built a filter to help detect and suppress suggestions that contain code that matches public code on GitHub. With this filter enabled, Copilot checks code suggestions alongside its surrounding code for exact and close matches against public code on GitHub within a range of 150 characters.
• The Copilot Copyright Commitment guarantees that Microsoft will protect your ownership rights and handle your case.

There is a very detailed video from GitHub explaining Copilot and Copyright that effectively addresses these concerns as well.

I worry about the quality of the generated code

We actually see the tendency of improved code quality. Copilot’s suggestions are based on vast amounts of high-quality code from diverse sources, including open-source projects and GitHub repositories. Our experience shows that with Copilot, developers write cleaner, more efficient code that easily passes all tests.

At the same time, it’s also important to note that Copilot should be used as an aid, not a substitute for critical thinking and understanding of the code. Developers should still review and verify the suggestions provided by Copilot to ensure they align with project requirements and security considerations.

Note: one of the directions we’re working on is using GitHub Copilot alternatives based on local LLM models. This approach will substantially reduce AI risks related to transiting customer code and other data.

Tip 3. Be prepared that not all engineers will like GitHub Copilot

It was interesting to see that many engineers were under the impression that if they started using Copilot, everyone would expect them to show higher capacity and faster delivery. So, they felt threatened.

To address this concern, our team:

1. Communicated that using AI will actually help them to complete routine tasks faster (where applicable), allowing them to focus on more important/interesting tasks, and might potentially make them happier. Based on Quantifying GitHub Copilot’s impact on developer productivity and happiness research, GitHub Copilot is:

• Improving developer satisfaction. Between 60–75% of users reported feeling more fulfilled with their job and are less frustrated when coding, as they can focus on more satisfying work when using GitHub Copilot. That’s a win for developers feeling good about what they do!
• Conserving mental energy. Developers reported that GitHub Copilot helped them stay in the flow (73%) and preserve mental effort while performing repetitive tasks (87%). That’s developer happiness right there since we know from previous research that context switches and interruptions can ruin a developer’s day and that certain types of work are draining.

1. Used internal marketing channels to share real success stories and cases from other teams.

To motivate people to invest their time in learning how to use such tools more efficiently, we’ve also launched an internal company contest titled “Best AI/ML Application on My Project,” where engineers are able to submit their stories of how AI helped them and win sizable prizes. Results will be announced in December.

Tip 4. Provide training materials for developers

Although Copilot is very easy to install and start using, we found out that having a centralized place with the following materials is very helpful. We have provided our team with:

1. A few links with recommended Copilot usage and tips videos. When there are tons of materials on using Copilot, it becomes challenging to select the right one. A curated list with a few recommended links and best/worst practices for Copilot usage can be immensely helpful.
2. Mandatory Copilot settings to guarantee security

• Enabling or disabling duplication detection should be set to Block so there’s zero chance that the generated code will match any public code.
• Copilot for Business must be used as it does not retain any Prompts or Suggestions. For a Personal license “Allow GitHub to use my code snippets for product improvements” must be deselected so that your code, prompts, and suggestions are not collected and retained by GitHub or Microsoft (Enabling or disabling code snippet collection)

Our internal adoption survey confirmed that the tips above worked for us, and engineers reported smooth onboarding and understanding of where and how to use Copilot.

Next, we will share our approach to measuring Copilot’s impact on team productivity and discuss our first real-life cases where GitHub Copilot was used.

Never miss an update from our AI Journey series! Subscribe to our blog for the most recent updates and best practices for GitHub Copilot usage!