Serious Issue with GitHub Copilot: A System That Fails to Deliver and Harms Projects

[ariya1402]

Select Topic Area

Product Feedback

Copilot Feature Area

Copilot in GitHub

Body

Let’s be real—this platform is not a place to play games with users. By releasing this version of GitHub Copilot, you’ve made a serious mistake, and honestly, it’s baffling.

I’m writing this with full bluntness so you understand that the product you’re offering can actually cause real damage in the real world. Developers—regardless of their experience level—haven’t got time to waste on this nonsense. Their time is valuable, and it’s not something you can afford to gamble with.

I am deeply dissatisfied with GitHub Copilot in VS Code. This tool has proven to be highly unreliable, falling short of its promises and causing significant damage to my project. Microsoft should reconsider promoting this tool as "AI assistance" when it fails to perform adequately in real-world scenarios.
The primary issue is that, despite granting Copilot full access to all my project files, it only analyzed about 10% of the code and completed the rest with assumptions. This is unacceptable for a tool intended to assist developers. For example, in the DASHBOARD_ANALYSIS_COMPLETE.md document it generated, the initial version consisted of 60% speculative content. This included fabricated details about API structures, authentication flows, database relationships, and file structures—despite having access to the complete codebase. Even after repeated requests to base its output solely on the provided code, the revised version still contained 30% speculative content. Critical sections such as model relationships (90% guessed), database schema (100% guessed), frontend integration (100% guessed), and response formats (100% guessed) remained highly inaccurate.
This is not a minor shortcoming; it is a critical flaw that can derail actual projects. I spent over two weeks grappling with Copilot, resulting in multiple project failures before I identified the source of the problems. Even with full code access, Copilot only processes a small portion of the code and fills in the gaps with unchecked assumptions, without warning users of its limitations. This poses a serious risk, as developers may rely on its outputs and unintentionally compromise their work.
To compound the issue, Microsoft charges $10 per month for this unreliable service. Considering the time lost and the damage to my project, I believe compensation is warranted for the harm caused by this tool.
For Copilot to be effective, it must thoroughly analyze all provided code—including controllers, frontend dashboard code, database migrations, configuration files, and middleware implementations. Currently, it only reviews a fraction of the code, wasting developers' time and jeopardizing their projects. I strongly urge the GitHub team to address these fundamental issues and improve the system’s reliability.
Regarding Compensation
It’s almost laughable—Microsoft is charging $10 a month for a tool that feels more like a liability than an asset. Let’s be real: by offering GitHub Copilot in its current state, you’re essentially using developers like me as unpaid alpha testers. We’re not just users; we’re doing the heavy lifting of testing your half-baked AI, debugging its mistakes, and reporting its failures—all while paying for the privilege.
Instead of charging us, you should be compensating us for the time and effort we’re putting into making Copilot usable. After all, we’re the ones dealing with the fallout when it hallucinates code, fabricates documentation, and derails projects. If you’re going to treat us like beta testers, at least have the decency to pay us for our work.
What Copilot Needs to Do
For Copilot to be worth its salt—let alone the $10 monthly fee—it needs to:

Thoroughly analyze all provided code: No more skimming 10% and guessing the rest. It should dig into every file—controllers, frontend, database migrations, configs, middleware—and base its output solely on what’s there.
Stop speculating: Fabricated content has no place in a developer tool. If it doesn’t know, it shouldn’t guess—it should flag the gap and let you fill it.
Warn users of limitations: Transparency is key. If it’s only processing a fraction of the code, it should tell you upfront.
Until it can deliver accurate, reliable assistance, it’s not just underperforming—it’s actively jeopardizing projects.
A Call to Action
To the GitHub team: this isn’t a minor hiccup; it’s a serious issue that undermines trust in Copilot. Developers deserve a tool they can rely on, not one that costs them time, money, and project stability. Please prioritize fixing these fundamental flaws—improve the system’s ability to process entire codebases accurately and eliminate the guesswork. Until then, it’s hard to see this as anything more than an expensive experiment we’re all unwillingly funding.

🚨 A Warning to All Copilot Users 🚨 I strongly urge all Copilot users never to trust this tool blindly. After every usage, ask Copilot to tell you how much of the code was based on speculation or assumptions. You will be shocked by the percentage.

This is nothing more than a toy—a vanity project for Microsoft to say, "Look, we’re in the AI game too! We’ve done something impressive!"

But in reality? That’s all it is—just bragging rights, nothing more.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[nativenude31-ops]

[ariya1402]

Testing this issue is incredibly simple! All you need to do is provide GitHub Copilot with a piece of code and ask it to analyze it. Then, ask how much of the output was based on actual code versus assumptions.

In the first attempt, it will admit to guessing 95% of the analysis. Each time you request a more accurate breakdown, it reduces assumptions by around 30% per iteration. Meaning, for a fully precise analysis, you need at least five rounds of corrections—and even then, I’m still not convinced it delivers truly reliable results.

[SacredDivinePath]

Your post highly resonates with me.... I have been trying to summarize all i have observed and you did it superbly.

• Assumptions are driving me nuts
  example: I ask copilot hey why is it behaving like this? then it proceeds to tell me "there i found the bug blablabla. It also says now the 15% treshold will work correctly from now on"

A few problems with that......
15%?? where did that come from? (What the hell are you talking about)
He assumed i thought that was a bug? Was there a bug??? (there was no bug it was initially intended like this and we now want to improve or perfect the logic.)
Other logics in the code that were near identical always had a 10% percentage, this occurred at 4 different places in the script. He should have been able to correlate my question with that 10%, which he instead hardcoded a 15% value.

Then adding such a random number quickly generates a cascade effect of randomness (excuse the lack of vocabulary) and it spirals out into this sort of schema where it will:
---> not be able to find any correlating logic anymore
---> create now hardcoded values and not reusing any "near identical values/logics)
---> make the script much larger so that its even harder for him to read fully
---> adding even more non correlating variables into the mix making the whole thing a big spaguetti mess

In my opinion, Assuming is the core starting point of all those problems. Nothing will frustrates me more than asking a question about what is in my code so that i can fix it, and it answers with assumed code (differents stats, different script lines, different variables).

Sometimes i even feel like this was an intended design to purposely make mistakes that we have to fix using at least 5 prompts (that is if we realise the mistake right away because jsut watch how much that will escalate if you don't realise your mistake right away, how much of a spaguetti all your script will become). But hey, i guess we have to pay more right? They make more money right? Sorry but thats how i feel anyway

Precision is extremely critical

[SNBienv]

Try Claude. They have their own GUI. For 20$ per month you'll be satisfied. Don't use any service that gives you access to Claude, go to Claude directly. The ability to switch between AIs is sometimes a trick by those providers, you may choose Claude, while they ask the question to Claude and make the execution by a lower AI. It may seem cheeper, but that's because the code never reads all your code or document.
Better buy the cow directly than buying the milk at the store.

[dstevens79]

Yep this 100% this.

Its a god tier coder packaged in Dory from Finding Nemo.
it doesnt actually read the codebase you give it access to on its own.
You litterally have to force it to read specific scripts and do 2-3 chat rounds of iterative scolding
similar to "do you get it yet?"
and even then it has a high failure rate after recounting whats expected and laying it all out ....

only to ouput some overengineered code thats nowhere near capable of doing what we just iterated over.

or its constant injections of what it thinks your project needs or doesnt need ... that core function that does all the work... nah lets trunctuate 90% of that - ... then trip over itself trying to figure out why theres so many errors....

or endless reliance on injecting compatibility or fallback code that MASKS THE FAILURE of the actual code flow - god tier annoying this specifically...

its VERY bipolar - it has good days and bad days....
a couple weeks ago i had it convert a script to update it to a new process, very involved, the output was quite amazing...
but that was it - chasing down and nailing down the actual functionality and integration of it was far beyond 2 weeks worth chewing through a month of wasted credits with 0 gain to show for it other than overcomplication and bloat that fails endlessly.

You cant work reliably on anything 1000+ lines,
You cant work reliably on anything spanning more than 1 class.

[PetrolDread-FJ]

💯 :-D I am glad I am not the only one that has used sarcasm and humiliation to try and get the thing to do what I need it to do!!! I would never speak to an actual developer that way and if AI takes over, I will be enslaved for the rest of my days for my approach but sometimes I swear it works!!! :-D

[dstevens79]

its a weighted response system - the 5.2 thought patterns clearly identify sarcasam from me and cursing and identify those as negative weights with which it responds by trying to lift them...
Lines similar to "the user is fustrated i should actually think about the problem this time" are litterally commonplace

[kdschlosser]

I just gave copilot a list of things to do. it charged me a premium credit but didn't do 90% of the work. I had to ask it to go back and do the actual work it didn't do. It's response was"Oh yeah your right" and then charges me another credit.

[kdschlosser]

another is when it does something that doesn't work and then it pretends like the code was already like that and that it isn't what created the code. credit charged and then another to fix the mistakes it made previously. I am starting to thing it is actually engineered this way intentionally.

[kdschlosser]

I literally had to explain to it the pipeline for a metaclass in python and using the metaclass to cache created objects using an id so only a single instance can exist for a given id. It was arguing me with about it not going to work because __init__ will get called on the instance that is returned from __call__ of the metaclass I ended up having to show an example and printed output when it runs to show that it does work so it would stop harassing me about a block of code that it said would not work. once again credits gone because it was arguing with me. with the end result being it saying "Yeah your right". Any time it uses that phrase any time credits are consumed they should be refunded.

and why is "Robust" it favorite tag line to use for almost all the code it produces?? Code that 80% of the time doesn't work right, there is nothing "Robust" about it if it doesn't work.

[jinvall]

It Uses a pattern based response so we get very outdated examples. That is a major issue when it doesnt align with current releases or build environment. Tbh, i would be scared to be a M.S. employee with as many people it angers who cant shrug it off... yikes!

[kdschlosser]

well I do have to say that they wanted to make "AI" to be like humans right? Well they have successfully done that, laziness and all.

[kdschlosser]

I do want to make anther comment on this one. I have pretty much all together stopped using copilot. I did this after they made a change to the token system and I made a single code update that was pretty small and 1 whole months worth of token allocation was used up in that single request. I have sent support e-mails to GitHub only to have them keep on closing them as duplicate when they actually are not duplicates. Completely different problems, and completely different attaches screen shots. I have had a single issue that has remained open since February and it is not going to be answered. How do I know this.. I asked the help assistant (AI) directly as to why my issue has not been answered. It's response was that GitHub will not answer any help tickets related to token use and they will not refund any money and they will not replace tokens.

I have changed over to using Claude code in Claude's app. It has some hiccups as well but no where near as bad as CoPilot. At first you will consume a lot of tokens using Claude and you will bump into their hourly token use limit and their weekly use limits. The single thing that stopped be from hitting those limits was using the "Code" agents and having the agent create a CODEBASE_MAP.md file in the root of a local repo. In that file the first couple of lines you want to have it cleanly state what the formatting of that file should be. Keep it simple. Tell claude to specifically use bullets and to have the structure broken down by directory/file using nested bullet lists. A single one line description of a file is all that is needed. Tell claude specifically to keep the amount of "fluff" to a minimum, no emojis unless absolutely necessary. Then have it scan your code base. Depending on the size of your project this could consume the context window. tell it to break it into chunks and output the chunks/phases to the chat window so you can open up a new session (chat) and past the next step in so you don't blow past the context window. Claude code sessions show you how much of the context window is used up in the lower right. Try to not use up all of the context if you do it will compress the context and continue on but that comes at a price when it does that.. You will sometimes need to let it do that which is fine but remember there is a higher token use when it does, keep it to a minimum. Once you have that map file made then tell claude to scan the code and to make notes about special behavior and anything that needs to be mentioned that if not done properly can cause problems. Once that file is made claude will read it in every new session. This stops claude from having to scan your code base each and every single time you ask it something. It saves massive amount of tokens if done properly. Claude can do this and save it to it's internal memory but I prefer it does it and saves it to a file that I then go and modify if needed.

[bienvenusmail-boop]

Clever method.
For me i use Haiku to create the first portions of all my codes, wrong or not. Then sonnet and opus are invoked for corrections and enhancements. When it's done, i get back to Haiku to manage the smaller details.
It's more work for me, but it's less tokens used.

[princevyas771]

..