GitHub's Copilot lies about its documentation. Why would I trust it with my code

> When IDEs first emerged in the world of web development, many developers proudly claimed that a simple text editor was all they needed. For them, saying "I'm using Notepad / VIM" became a badge of honor, symbolizing their minimalist approach.

Whenever some new technology is being sold, someone always tries to delegitimize any criticism by citing some superficially similar criticism of some past technology that was adopted. Or, fairly frequently, they just reflexively cite Socrates's/Plato's OG critique of writing.

> Today, I sense a similar mindset among those who oppose AI assistants in software development. They tend to focus on the perceived limitations of these tools, often failing to see the bigger picture of how AI can enhance productivity. Instead, they quickly latch onto any shortcoming to justify their resistance, missing the potential long-term benefits.

So your message is: "Who are you going to believe, the sales pitch or your own lying eyes? You should focus on selling yourself on the new thing."

I think you should listen to the criticism, and try to understand and empathize with it instead of trying to dismiss and disregard it. There's something there. Maybe the people who critique it are the careful and thoughtful developers, and the ones who sing its praises are the sloppy ones who aren't careful enough to see the problems or just don't care (e.g. the kind who see their job as closing tickets not writing working software)?

Maybe this thing will get adopted despite its shortcomings and change everything, like NFTs did, but that doesn't mean those shortcomings aren't important.

That's an interesting comparison because it seems to me that there are still a significant fraction of experienced developers using text editors like vi and sublime, without any apparent loss in productivity. Also, I use VS almost all the time but have had to learn how to bypass it when there are errors that aren't flagged up by its particular build process. I wonder if the same will apply in the case of AI assistants - they'll be great for more junior developers who will never need to learn good practises for refactoring, debugging etc... until suddenly they do. Not saying it's a bad thing, just that you may not need to worry too much about "losing out" if you're not on the hype train.

I was there when IDEs first started becoming popular amongst my cohort. Yes, there were people like that who prided themselves on their hard-earned skills.

But there's a key difference here.

I don't remember an IDE trying to autocomplete something which didn't exist. Similarly, an IDE never pointed me to documentation which it had just invented. If it had, I'd've been one of those people living out my days in Nano.

If my IDE autocomplete sometimes generated invalid syntax, I would throw that IDE in the trash and never do business with the people who made it ever again.

Why would it be any different with "AI"?

Writing the code is not where I spend most of my time: it's in planning, optimizing, and debugging. AI only helps modestly with the second and third of those right now, and it certainly doesn't need to be in my code editor to do that. In fact, I spent a lot of mental cycles when I tried copilot removing potential bugs it was hallucinating into the code in the first place.

What are these long-term benefits?

Also, Vim (and Emacs) and notepad are not even in the same class of editor.

Respectfully, no.

IDEs made it easier to navigate a huge codebase with things like autocomplete and one-click refactor. This made it easier to make huge codebases that _require_ these QoL add-ons over time. I think this was a factor that made outsourcing software development (to countries with weak or non-existent worker rights) possible at scale.

In a similar vein, highly paid software engineers are using LLMs to generate more and more of the code they ship.

If highly paid SWEs can write code by shoveling a sentence into Copilot, _literally anyone can._

We seem hellbent on destroying our profession for the sake of "productivity" (i.e. using less of our brainpower to churn our features faster).

But what do I know? I'm just a simpleton that uses vim and writes code the old-fashioned way.

I find IDEs add complexity to development, even today. They're very bad at hiding irrelevant information. There are so many buttons I've never used in Visual Studio that are always displayed, it makes it very visually cluttered and harder to find the buttons I actually need.

And configuring tools through IDEs is very opaque. How do I add a flag to the compiler command line in this IDE? Who knows. How do I change the CMake config? Maybe I can edit the CMakeLists directly, or maybe that will make the IDE blow up, so I have to use some arcane GUI built atop an already arcane text UI.

Plus, you can usually forget about scripting your workflow. Unless the exact workflow you need is built in to the IDE already, you'll be clicking the same sequence of buttons over and over ad infinitum. An IDE is one big complex tool in place of a handful of simpler composable tools, and the only way to extend an IDEs functionality is to make it more complex instead of adding another simple tool or composing existing tools in a different way.

AI is. a tool. a power tool for sure but ultimatly it multiplies what the developer brings to the table. I personally have found it of limited use outside a few situations such as knocking out a bunch of boilerplate.

That said, I would keeo this thing the hell away fro junior engineers and I wouldn't want a junior who has used AI his entire career anywhere near my codebase. AI is gasoline and without someone with experience behind the scenes, they are just going to be 10x faster at knocking out unmaintainable spagetti code.

When you run a saas company, code is only ONE factor among many you are maintaining. The other arguable more important one is the domain specific knowledge that exists in the heads of your talent. Give me the nerd that uses emacs with 5+ years of experience thinking though and solving problems without AI. I'll let him have copilot because he'll be the one writing and maintaining the code. More importantly, he'll have teh experience to know when copilot is leading him astray.

The biggest speed up was when I was refactoring some code and it “learned” the pattern I was moving to. It felt great!

. . . Except it got one so wrong I couldn’t trust it and had to be just a meticulous as I would’ve been in the first place, so that was a net loss of time.

What is the bigger picture? For me it is not with writing the code, it’s a great multiplier for learning and troubleshooting , however.

I do not see how it could fit into my workflow other than how I use it today — a google expert I can talk to about anything.

What is your workflow like?

We're talking about chat bot UI elements plastered all over a webpage. I wouldn't want it if it was a human chat.

I'm very optimistic when it comes to AI. I use chatgpt all the time at work and for personal code, but copilot just feels much worse. Perhaps I just gotten used to prompting and guiding (and copy pasting code) to the model in a way that gives me exactly what I want. Would I love an Ide that automated it? Sure, but none does it well!

The single biggest use I've found for LLMs has been search or lookup functionality. Instead of a carefully crafted google search + "reddit" I can just ask a question and get a specific answer with references. Some times it's wrong, generally not.

Runner up is copilot integration in the IDE that I ask to transform data or reorganize lines of code. It's grunt work and having smart automation around it is helpful.

Anything requiring "thinking" generally falls over pretty quickly. For example I've found broader feature code generation has generally been crap or worse and often using APIs that just don't exist. Catch is that LLMs have been sold as thinking machines that will replace people and VCs have thrown all their money into that fire.

P.S. VIM has a growning following and vscode user counts are astronomical, so I'm not sure your point stands.

Umm, hi? I still use emacs, and I'm one of the top developers in my field. Never figured out how one of those IDE would be more useful for what I do, which is to develop novel low-level algorithms.

Also, neither vim nor emacs are simple text editors.

I was one of those guys, but it was Emacs.

Quite frankly, IDEs at the time were really bad. They were slow and clunky. Intellisense didn't always work. People who relied too much on IDEs didn't understand their project's build process and couldn't debug it. The code templating stuff spit out awful code.

I kept using Emacs for a long time because I was more productive with it. I had a lot of customizations and add-ons that made it a dream to browse the codebase and churn out good code.

I finally switched to VSCode some time after it was open sourced because the plugins for my languages had gotten really good, and emacs development felt like it had slowed down and everything was starting to get bitrotten.

Are you serious? Did you just put Notepad next to Vim?

Things like completion or build integration in Vim and Emacs go back to the 90s. Ctags goes back to 3BSD from 1979.

Aside from the fact that it's not all that comparable, it's just flat-out wrong in its description of events.

If you knew what to do, why would you consult a Copilot in the first place?

It's not like GH tells you to use Copilot exclusively for writing boilerplate code. What the OP tried to do was a legitimate use case, wasn't it?

Then it shouldn’t be called a copilot because I very much would trust a copilot by default.

I think the same. it very often has some reasonable suggestion, then I mostly need to fix some minor things and it's good to go. overall it definitely helps to reduce the amount of time required to write code

Siri will tell you how by giving you the exact steps and a link to the documentation. I just tried it on 18.1 Beta.

I've literally just said "Alexa - how do I disable notifications?" It answered with accurate information.

If I ask it something it doesn't know, it says "Hmm. I don't know that."

So, yeah, it is surprising that this supposedly advanced AI doesn't have the same level of functionality as a smart speaker.

Not really. GH advertises that its Copilot can go through documentation and fetch relevant results. I don't see anything wrong in asking the copilot to fetch any kind of results from its own documentation.

Why do we focus on the promise of a technology instead of its state as is right now ? How many time should we be duped before we learn from our mistakes?

The burden of proof is on the new generation, not on old timers. And this is coming from a new generation software engineer.

Does it predict the next most likely word or sample proportionally from the space of possible next words? I don't get consistent results, so I assumed it generated a sequence by sampling. I guess I also don't understand how these things work.

If one of my interns lied about something I asked them, why would I trust the same intern with literally anything else?

A key skill is learning when to say "I'm sorry, I don't know that."

AI is currently trained to be overly friendly and helpful - to the point of deception. They often "hallucinate" entire software packages. At which point, they become worse than useless.

If your intern delivered false information or wrote broken code as Copilot is wont to do, at the rate Copilot manages to, you would fire that intern. Especially if they argued with you that their completely made up solution was, in fact, real.