5 Real PR Comments I Got from GitHub Copilot (and What I Learned)

GitHub Copilot has become an essential tool for many developers, streamlining the process of writing code and reducing cognitive load. But in recent months, I decided to take it a step further — I used Copilot not only for writing code but also as my first PR reviewer.

To my surprise, Copilot wasn’t just generating code suggestions; it was also pointing out areas for improvement, offering refactoring suggestions, and even flagging potential issues. In this post, let's walk through five real comments I received from Copilot during a PR review and share what I learned from each one.

1. "Consider using a more descriptive variable name than data2."

We’ve all been there—rushing through variable names like temp, data1, or data2 when we just need something quick to hold data. In one of my PRs, I had a variable called data2. It was just a temporary structure, but Copilot flagged it immediately, suggesting I use a more descriptive name.

What I Learned:

Naming variables properly is crucial. Descriptive names not only make your code more readable but also ensure that it’s easier to maintain and debug later. Even when you're just throwing together a quick prototype, spending a minute to choose the right name can save a lot of time down the road, especially when refactoring or debugging.

2. "You should consider adding error handling here with a try/except block."

I was making a request to an external API but didn’t include any error handling. As you can guess, if the request failed, the code would crash—and I didn’t even realize it.

Copilot suggested adding a try/except block around the API request to handle potential exceptions gracefully. It was a small but powerful suggestion that improved the stability of my code.

What I Learned:

Error handling is often overlooked, but it’s essential. Without it, your app can crash in unexpected situations, especially when interacting with external services. Even simple try/except blocks can help ensure that your app behaves predictably and doesn’t break when things go wrong.

3. "This method could be split into two smaller methods for better readability."

In this case, I had a method that was doing a little too much. It was responsible for fetching data from an API, processing it, and returning the result. Copilot flagged it and suggested that I break it down into smaller, more focused methods to improve readability.

What I Learned:

Single Responsibility Principle (SRP) in practice: A method should do one thing, and it should do it well. Splitting large, complex methods into smaller ones not only improves readability but also makes your code easier to test and maintain. Keeping things simple benefits everyone, including your future self.

4. "There’s a security risk here. You're using eval() with user input."

This one really got my attention. I was using Python's eval() function to evaluate a user-provided string. While this seemed like a harmless and quick solution, Copilot immediately flagged it as a security risk. It explained that using eval() with untrusted input could allow code injection—something I definitely wanted to avoid.

What I Learned:

Never, ever use eval() with user input. It's an incredibly dangerous practice because it allows malicious users to execute arbitrary code on your server. Copilot steered me toward safer alternatives, like using ast.literal_eval() in Python, which only evaluates literals, or better yet, validating and sanitizing input thoroughly before processing it.

5. "There’s no unit test for this function. Consider adding tests to improve coverage."

I had been focusing on building out features quickly and hadn’t written unit tests for some of my core functions. Copilot quickly flagged this and pointed out that the function lacked test coverage.

What I Learned:

Unit tests are the backbone of maintainable code. Even if you're in the early stages of development, writing tests ensures your code stays stable and bug-free. It also makes refactoring easier and gives you confidence that changes won’t break your application unexpectedly. Never underestimate the power of testing.

Conclusion

GitHub Copilot is evolving from a code suggestion tool to a first-level reviewer. In each of the examples above, Copilot helped me spot issues I might have missed, refactor code for readability, and even flagged potential security risks. While it’s not perfect and shouldn’t replace human reviewers, Copilot has proven to be a reliable assistant in improving code quality.

Using Copilot as a first reviewer in your PR process can speed up your workflow and help you ship better code faster. It’s not just about getting your code done; it’s about getting it done right from the start.