Coding with Copilot: When to Trust It and When to Take the Wheel

Over the curse of the past few weeks, I have put Copilot to the test as a reliable tool for generating new solutions. I have to admit that I have been impressed with what it can do, but I have also seen it blunder. Over time, a new standard for using it has emerged and I believe that standard probably pertains to every aspect of AI development, be it coding assistance or generative AI. More on some of those things later.

AI coding is like driving a smart car. I doubt many would rely on a vehicle to drive them from one coast to another while sitting in the back reading a book and not paying attention to the road. That might work well out in the country, but the closer you get to suburbia, the more likely things are going to jump out at you. There will be times - and no shortage of them - when it is just best to take the wheel yourself.

Below are the places where I have found Copilot to consistently blunder. These are the places where it may just be best to take the wheel.

Now, where were we?
Probably the largest blunder that I saw Copilot make was when I first started using it to generate code. I was giving Copilot large tasks to do (database, boilerplate, and UI) using long sets of directions. This was early on in my trial-and-error with AI-assisted coding, and I was really challenging it. At that time, my application was a monolith (C#, EF/SQL, Razor) all wrapped under one umbrella.

I got to a stopping point one day and retired from development for about 48 hours. When I returned, I tried to pick up where I left off, but Copilot had other plans.

Upon instructing Copilot to add another section to a page I was working on, it followed my instructions but also proceeded to delete a section of the site that had nothing to do with the new feature. Suddenly, an existing feature we had worked on was gone.

I tried to get Copilot to roll back the last changes it had made, but that only made matters worse, and it still did not return the previous feature.

Being on pins and needles when I first started my experiment with AI-assisted coding, I set up my local environment to back up my repositories every hour, and I was still making manual backups on top of that. I also backed up the database after every change. Naturally, I just reverted to a backup and started working on the new feature again.

This was when I learned that it is always best to go in small doses when adding new things to an application that is being built with AI tools. While I had written a lot of the LINQ and boilerplate that existed in the application, everything is connected in a monolith. Copilot erased its own work and mine!

From that point forward, I never had that happen again. It may have also helped that I switched my model from GPT-5.2 to Claude Sonnet 4.6, but I really can't say for sure. After that experience, I have always considered Copilot to be reliable only in one long working session. After a break, be careful. Always go in small doses and always back up your work.

No, no, no. Your broke it, not me
Copilot has a funny way of blaming everything on you. If you ask it, "Why did you do that?", it usually responds with, "The error occurred because you did... whatever."

I probably encountered this the most when scaffolding new database tables or asking Copilot to add a new query for a new section of an analytical page. It often creates new classes and names them the same as existing classes. It often creates new classes when a perfectly good one already exists. It also has a bad habit of not adding new DbSets to the DbContext file.

When these things occur, you may ask, "Why did you add a new Hockey class when we already had one?". To which it will respond, "You created two Hockey classes. You need to delete one."

Well, I didn't add anything. You did!

I learned early on that it is probably best to just add these things yourself. On a side note, I found Copilot to be very reliable and a real time-saver when it comes to creating the shell of a new project with a code-first approach. As long as you give it detailed instructions of what you want, it will create everything for you in an acceptable fashion. However, once it is established, you are probably best expanding it with your own hands.

Lost Focus on BACPAC File Process
In my AppService on Azure, I spun up an Azure SQL Database for use with an application I am working on. I then transferred my local database to Azure via a BACPAC file. The BACPAC file had everything I needed and all I had to do was move the BACPAC file from one database server to the other. Schema, objects, data, etc... It should all be there and it should just be a matter of uploading the BACPAC file to the Azure database.

During the process of putting this together, I realized that you can also upload BACPAC files directly through the Azure portal by navigating to your SQL Server and importing the file (import database). With this being a new process for me, I asked Copilot, "How do I add a BACPAC file through SQL Logical Server?"

This became one of those times when Copilot went ahead and did something when all I wanted was textual instructions. You might even say I wanted a summary or an opinion. After a few seconds, my chat window updated with: "I have generated the following SQL file for you to run in Azure SQL Query Editor. This will create your database schema on Azure SQL. Once you run it, we can upload the BACPAC file to Azure."

And that is incorrect. The BACPAC file creates everything. In fact, if you run the schema scripts first, the BACPAC file will fail. There doesn't need to be a schema script. The BACPAC file should have everything.

7-1-0 Does Not Mean Undefeated
One of the projects I am working on at the moment is an analytics portal for sporting events. Hockey is one of the sports covered.

In hockey, a team's win-loss record is recorded and displayed as Wins-Losses-Overtime Losses. Thus, a team that has a record of 7-1-0 is a team that is 7-1, straight-up (no overtime losses). Conversely, a team that is 5-2-2 has 5 wins, 2 regulation losses, and two overtime losses. Hence, they are 5-4, straight-up. If you are wondering why hockey scores are recorded this way, it is because a team is awarded one point in the standings for an overtime loss. You lost the game, but you still get a point—a topic of much debate amongst puck enthusiasts.

Taking a small list of statistics (five or so) and running them through the Copilot window for a programmatical reason, I got an unexpected natural language summary of the data I had entered. One section of the summary said the following:

"The Edmonton Oilers absolutely own the New York Islanders when they play in Edmonton. The Oilers are 7-1-0, going undefeated in the past 8 games."

Does anyone see the problem?

Closing
You have to keep an eye on Copilot as you code. You have to look for those places where it works well and where it doesn't. You always want to be assessing the risks of it going on tilt. My best advice is to find the places where it works well, avoid the scenarios where it seems to fail, and always go in small doses.

And always backup your work!