Why Copilot Is Making Programmers Worse at Programming
darrenhorrocks.co.uk
darrenhorrocks.co.uk
I will personally never use Copilot, or any other AI code generation tool, for the simple reason that I enjoy writing code.
Even if I were unfamiliar with a new language, I'll still never use it. Instead, I'll consult the documentation and follow examples. I like coding, and I neither need nor want a machine to do it for me.
It's exactly the same as writing English. There is great pleasure to be found in writing, it's worth your time. Just be careful when doing so to not end up sounding exactly like ChatGPT.
I noticed that too, found it quite ironic =)
And of course the fact that each heading has exactly 2 paragraphs in similar lengths and the overall tone as well.
The whole blog including the other articles looks like AI generated.
I had an XML file format, I needed it converted to JSON. I haven't parsed XML in over a decade, and I didn't want to relearn. I also didn't want to match up XML fields to JSON fields. Both file formats had well defined schemas available, but were also common enough that most major LLMs were trained on them.
I just asked Claude to write a program to convert from one file format to another.
There is no joy in that task. Doing it myself would have been the very definition of a useless chore.
Was it correct?
How did you know?
Aside from that; Following logic as you develop it vs following logic as you read it are two different skills. Also, with the latter, it's easier to miss details. Further, when you're not experienced on the subject of the code, it's critical to develop an understanding by doing, and not only by reading. Further still, following the logic of genAI code is complicated by the fact that AI can make different mistakes than humans do, and it speaks/documents with much more authority, both of which make it not only more difficult to spot issues, but make it difficult in a frustrating way, reducing energy and satisfaction.
In 2 days, GPT, Claude and Llama 3 helped me solve 4 different problems. 1) I wanted to load in a webpage a json file, parse and read it, using Rust + webassebly. GPT solved it in 10 minutes. 2) Then i wanted to use this code and make it as a Chrome browser extension. GPT solved it as well. 3) Then i wanted to parse recursively directories with Rust source code, run tree-sitter queries, get the points and print matches, not with cli but using the libraries. GPT solved it in an hour. 4) Right now i finished analyzing a git repo, and fetching all branches and commit messages using git2. Llama 3 + Claude Sonet solved it in an hour or two.
DHH did an interview yesterday [1] in which he mentions that he will be programming by hand even if everyone else uses A.I. assistance. I think he is pretty smart and he will not be stuck in the era of meaty fingers pressing keyboards to make programs.
Perhaps there is no reference implementation in Pancake Stack, but your language has to be quite arcane to not have something available.
I could get a little bit of benefit out of an autocomplete that only showed legal suggestions, but even with deterministic autocomplete I frequently had to look at too many suggestions and it was faster to throw a query at Google.
And sometimes if you do abstract it away too much, edge cases handling and everything affecting everything else might not be worth it.
I also think with Copilot in the house, it's completely acceptable to have it write utils fn even if they are not DRY, in the sense that you could import leftPad as a package, but it doesn't matter since you can just write function leftP and copilot will do it for you within few seconds, which is faster and more flexible for the future. And without unnecessary, unknown dependencies with potential vulnerabilities baked in.
I think there's going to also be some sort of enlightening in terms of overusing libraries and idea of everything having to be DRY. Because frequently this will cause more problems than it wins even though you think the code is really, really clean.
It's mostly full stack web applications, with React frontend and APIs with databases, so it's not exactly something groundbreaking.
Every time I play with web or GUI development I get the impression that the languages and systems are misaligned with the way people express their intentions in the space. It makes me want to develop a language (or family of languages) directly for expressing GUI concepts, but I don't understand the space well enough to do a good job.
For a practical example, lets say I define protobuf models, I start by writing
```
service X {
rpc doSomething([cursor]
```
It'll generally be smart enough to complete to the same pattern as every other one in the codebase
I can then put my cursor after and get it to generate the models by just tabbing a bunch:
```
service X {
rpc doSomething(DoSomethingRequest) returns (DoSomethingResponse);
[cursor]
```
```
service X {
rpc doSomething(DoSomethingRequest) returns (DoSomethingResponse);
message DoSomethingRequest {}
message DoSomethingResponse {}
```
Then I can go to my actual code file where this is implemented, and having had both the context of the codebase and the context of the protobuf file, it'll generate
```
class DoSomethingImpl extends some.grpc.package.DoSomethingService {
override def doSomething(request: DoSomethingRequest): Future[DoSomethingResponse] {
// Some usually bad code I just delete
}
```
Nothing here is super complicated, I know it's right at a glance, it's super easy to write, but I hate having to do the boilerplate. Could I write a simple script that kind autogenerates this for a given API? Maybe. But a bunch of typing and piping things around becomes just a bunch of "tab" presses. And an LLM is more flexible to slight changes in the pattern.
This is multiplied times 10 if I then want to consume this from some other language, and it has both in it's context. I literally just need to create the one definition, and the LLM will complete the required code to product / consume the API on both sides as long as it's all in the same context window (and tools are getting good at doing this)
What I really want now is to just have to say "Add a proto api for `doSomething` and add boilerplate to give a response and then consume it. Put it in X existing grpc service" and just have it do all of this without a series of smaller completion.
Typing the code yourself incentivizes you to write code that's concise and easy to read and avoids repetition.
Even if I were unfamiliar with a new keyboard, I'll still never use it. Instead, I'll consult the technical guides and follow examples.
I like typing, and I neither need nor want a word processor to do it
Certain things may seem strange, or that they take away from the experience, but sometimes it is simply progress... good or bad.
Or take requirements and propose extensible design patterns. There aren't many design patterns per se but that task has a lot of value. Perhaps the most value.
Also an AI that can find similar concepts using different patterns where they should be consolidated. This could even be for something "as simple as" file access. So many bugs and issues due to one person not knowing how to access resource X.
I think that code generator models need to understand the abstract syntax tree, like using treesitter to better understand the structure, and as you said, the patterns involved in the code. Plus generators could then check that their new code correctly implements a pattern.
I'd love to be able to feed a repo into a model and get documentation and diagrams out of it.
I still read the docs and examples because it isn't reliable enough to tell me accurately how to use most packages. It's absolutely a mess of flaws and sharp edges so I get the hesitation in using it, and for sure it has allowed less than stellar coders to confidently present steaming trash heaps with a pretty bow on top, but I don't think it's always fair to assume using AI tools means being less involved with the code you produce.
This will sound extremely harsh; but I noticed I strongly favour colleagues who do use AI-assisted tooling over those who do not. The PR, documentation and code just looks cleaner.
So if it comes to who I favour working with; it's usually people who rely on AI-tools. They deliver code I like maintaining more.
It’s a very useful tool to see how to do something a different way, and sometimes it’s surprising and has some really good ideas!
The problem is people expect these tools to “just do it”, but that doesn’t work. You need to iterate—if it makes a mistake, nudge it in the right direction and you’ll find it knows how to intelligently adjust where it goes wrong.
q 'write a an article called "Why Copilot is Making Programmers Worse at Programming"'
2. Lack of critical thinking skills: When using Copilot, programmers may rely too heavily on the tool to generate code for them. This can lead to a lack of critical thinking skills and an inability to solve problems independently.
3. Overreliance on automation: Copilot is designed to automate certain tasks in programming, which can lead to an overreliance on automation. While this can be helpful in some cases, it can also make programmers less able to think creatively and outside the box.
4. Dependence on a single tool: Copilot is just one tool among many that programmers use to write code. By becoming too dependent on a single tool, programmers may be less well-rounded in their skills and less able to adapt to different programming environments.
5. Lack of creativity: When using Copilot, programmers may not have the opportunity to be creative with their code. This can lead to a lack of originality and an inability to come up with innovative solutions to problems.
6. Inability to learn from mistakes: With Copilot, programmers may not have to deal with as many errors in their code. However, this can also make it harder for them to learn from their mistakes and improve their programming skills.
7. Lack of attention to detail: When using Copilot, programmers may be more likely to overlook small details in their code. This can lead to bugs and other issues that could have been caught with a little more attention to detail.
8. Conclusion: While Copilot can be useful in certain situations, it is also making programmers worse at programming in several ways. By becoming too dependent on the tool and not developing critical thinking and problem-solving skills, programmers may be less well-equipped to handle more complex programming tasks. It is important for programmers to use Copilot as a supplement to their existing skills rather than a replacement for them.
mistral-7b-instruct-v0.1-Q4_K_M-main.llamafileWhat I see is that new programmers do use it extensively though and if the service is down they often remain helpless. Still think it is a very good support in the beginning as long as some knowledge remains retained, which it very likely will.
LLM code generators are a problem for those who write code for a living, not for pleasure. They may well eventually be forced to use such systems, whether they like it or not. When your paycheck is on the line, you will conform.
For those who both enjoy writing code and have to do it for a living, their everyday jobs may just get a lot more tedious and boring than they are right now.
Im pretty sure I will enjoy riding horses. But if I have to deliver things to people, I think I will be using a truck.
If you're getting paid to ship features, no one cares whether you're learning, or learning the "correct" way. You simply have to get the job done. If tools like copilot help you meet your goals and budget, then they are a good thing.
I heard the same thing in the 90s when Java (and even C++) came on the scene. The C programmers bristled at the idea that you no longer had to deal with memory management. They thought it would make the programmers sloppy, generating poorly performing code bases.
They were right, and it didn't matter.
The funny thing is that is the same example I was thinking of.
Obviously you have to read the code to make sure it makes sense, and much of the work is deleting the main bit of functionality it attempted to implement, and re-implementing it correctly.
However, having it autocomplete entire function definitions, including all the {} () => | : `${x.y}` fiddly bits, sure saves a lot of time.
The one point I don't agree with at all is `Dependency on Proprietary Tools` there are already plenty of open source alternatives, and these will only improve with time.
The critical feature, which also counts out some paid tools, is the ability to avoid regurgitating training data into your codebase. GitHub has the raw dataset to be able to offer that (and the legal indemnification that comes with it). I don't know of any open source system that can offer the same, even in principle.
Calculators did make us bad at arithmetic. It's just that people stopped caring.
I don't think this is bad, though, anything to avoid typing repetitive boilerplate, which is pretty miserable regardless of your skill level.
You'd assume so based on the prevalence of information, but I'm not sure there's any evidence of this. Hell from my own interactions about the past with others, you might as well have completely wiped everything before WWII from cultural consciousness and pretended like the last 80 years are the only ones that matter. Some days it's feeling more like the last 40 years represent the only world people can even imagine, let alone have an opinion on.
On the other hand, thanks to the invention of writing, we have a chance at having at least some reliable knowledge about how people lived thousands of years ago, across the world. (I assume your comment is at least partially tongue in cheek. But I take your point that, just because writing gives us incredible ability to make records and to learn about the past does not mean people will use it.)
Otherwise the information the average person knows about the past is probably even worse, pop memes aside ("Cleopatra's nose", "Egyptians worshipped cats").
Even the immediate past - like 10-20 years before people were born, would be a foreign concept, if it weren't for the ocassional period movie and tv series reference.
Not if you care about these skills! It's not like Socrates was wrong, it's just that the world moved on without him. Having a good memory has nearly zero value these days.
It's one thing to use LLM's to assist you in understanding the codebase, and even helping to write some of the changes. It's another thing entirely to blindly trust the LLM - which is what ~90% of LLM users are going to do, especially given enough time.
We've all heard the tall-tales about people crafting prompts and getting complete video games as output, etc. They're nearly entirely BS, but people believe in that type of result and therefore will believe their results are just as good.
We see this now - the stories of non-programmers using ChatGPT to hallucinate-up poorly understood/written scripts/webpages and then getting really upset at their IT team for refusing to use it. "They're just afraid AI will steal their jobs!"...
Has it really?
https://media.licdn.com/dms/image/v2/D5612AQG5D1oqhEfgnQ/art...
And calculators are mere helper tools, they don't take over the solving/thinking part.
Over time, more people will realize that tools like Copilot aren't worth the headache. The solutions are often wrong, the explanations of those solutions are wrong, the corrections when you point out a mistake are wrong, etc.
Once "AI" hype dies down and people see these tools for what they are, glorified Markov chains, it won't really matter. Maybe it will get some use in making boilerplate code for the most basic of applications, but that's about it. And the occasional junior dev stumbling into it not realizing just how bad their output can be.
While not using Copilot, I have GTP-4o assistant with a system prompt setup from trial and error to convert a given test from Enzyme to RTL. There are certain scenarios where a given test cannot actually exist in RTL due to a difference in testing philosophy between the two frameworks and I am required to make some decisions, but overall this is probably 10x faster than refactoring these tests by hand.
One of the important aspects of this, though, is when a I encounter a repeated failure of the LLM, I update the system prompt going forward. Even though this is a simple 1-shot approach, it still works well for a task like this.
This is case by case of course.. I used it the other day to generate fairly idiomatic table-driven tests. It took a few swings plus some manual tweaking but as I don't particularly enjoy writing tests I was pretty satisfied with the outcome and it had more coverage than I probably would've written. Well worth the 25 cents in API credits. On the other hand, there have been more than a few times I've given up trying to nudge the AI and just did it myself. In those cases it was just a net negative and just wasted time. So the trick is feeling out where that line is for each model so wasted time < saved time.
Tools like the replit bot evoke similar emotions. I have no idea why they generate so much negativity from most HN comments. This cohort must be on average younger than myself. I'm pushing 50 and for the first time in decades I fee like we are actually about to witness actual productivity boost in programming craft because let me tell ya, server side js or spa or nosql certainly weren't it.
It may suck, but facts are facts. Dealing with them is better than pretending they don't exist.
Technology can be disruptive, but "just deal with the disruption," is not a viable response. It breads resentment. It favors populism. It says, "sorry, but your problems are not worth fixing."
Hillary Clinton? Is this bait?
When that equation changes en mass, and we respond with "things change, too bad," it is a social failure.
However, in this case there is empirical evidence copilot makes code quality worse: https://visualstudiomagazine.com/articles/2024/01/25/copilot...
I work in such an industry and it's certainly not "self-evident". Clearly it's also not self-evident to many other people commenting on this post.
> However, in this case there is empirical evidence copilot makes code quality worse: https://visualstudiomagazine.com/articles/2024/01/25/copilot...
One study does not prove anything, although at least it is _some_ evidence. But other studies linked in that very article show opposite results.
To be clear I don't know if LLMs are better or not for developer productivity. I think it's too early to tell. But given that people, in general, are prone to conservatism, combined with the fact that past developer tooling enhancements have not caused the negative outcomes that many people at the time predicted they would cause, leads me to believe LLMs will probably be a positive change.
I’m not sure how true this is. Any place I worked, whoever checked in the code is responsible for it.
Personally, I've been making the same arguments against using even vanilla auto-complete. It's a distraction, erosion of the mind, encourages bad habits, etc.
If some significant portion of the humans doing the job can be replaced by LLM, or by much cheaper humans augmented by LLM, they will be so replaced. By the time it creates a real problem, those folks will have cashed out and moved on.
That isn't new behavior, but folks who fall back to that as a way of dismissing concerns lack a good grasp of the scale enabled by technology, here.
"Interesting times".
Blaming Copilot feels a bit like the wrong target. Like the Luddites, the real question is the relationship between employer and employee, and how the presence of the machine empowers or endangers the worker. To put it another way. Suppose a perfect Copilot existed, that required a human to drive it but made that human a 10x developer. Do you think they would get paid 10x as much? Or would the worker stay where they were, perhaps under threat of replacement, and the employer take the spoils?
https://www.flyingpenguin.com/?p=28925
Edit: to be clear, I am actually a big fan of Copilot for increasingly one's personal productivity, rather like a super-Google or a non-snarky-Stack Overflow. But I remain rather cynical about how those benefits might work in the new corporate environment.
At a basic level, which of these two practices are more likely to result in you retaining information and learning: reading, writing, and debugging your own code, or copy-pasting someone else’s?
So was Ptolemy's model of the solar system.
That doesn't make it right or valuable.
The analogy you're making between reading, writing, and debugging your own code versus copy-pasting someone else's is a good one, but it's not a direct comparison to AI-assisted coding. When you copy-paste someone else's code, you're still reading and understanding the code, even if you're not writing it yourself. You're still learning from it, even if it's not through the process of writing it.
With AI-assisted coding, the issue is that the AI is generating code that you may not fully understand, and you're not necessarily learning from it in the same way. You're not reading and understanding the code, you're just accepting it as a solution. And that's where the problem lies.
It's not about whether AI-assisted coding is good or bad, it's about how it's being used. If you're using it as a tool to help you learn and understand the code, then that's one thing. But if you're using it as a crutch to avoid learning and understanding the code, then that's a problem.
So, to answer your question, I think it's more likely that copy-pasting someone else's code would result in you retaining information and learning, simply because you're still reading and understanding the code, even if you're not writing it yourself. But that's not the same as AI-assisted coding, where the AI is generating code that you may not fully understand.
I'm pretty negative about the LLM hype, but this is just a low-effort, low-value "back in my day" rant.
I still retained the 10000 foot view, and that mechanical sympathy has definitely helped me with fixing supposedly intractable performance issues with some regularity.
Like a lot of things in education, there's an important distinction between learning something to use it, and learning it to appreciate or inform what you do with what we have now.
Similarly there are processes we try to deploy 24/7 at work that I think would be better off being done for four weeks twice a year just to knock the cobwebs off of how we perform the job the rest of the year.
- Erosion of core horse-riding skills
Getting from point A to point B used to be a highly-skilled task, involving a fusion of man and beast working in tandem to accomplish the job. Now, by using a so-called "automobile" (more like "auto-mo-blah", am I right?) we're losing these core skills. Rather than deeply understanding the inner working of the horse's digestive tract, we're left with only the choice: basic petrol or premium?
- Over-reliance on roads
When driving a car, drivers can quickly reach their destination without understanding the underlying terrain. This leads to what experts (me) call "road dependence", where drivers are too reliant on roads, without checking if the route is the most efficient. There could be a badger path cutting 20 minutes off of your commute!
- Lack of ownership and responsibility
When going from point A to point B, car drivers shift responsibility for the drive to the roads they drive on. But the roads could expose them to rockslides, ice, highway robbers, bank robbers, and dangerous wildlife. They may think "if the road goes through here, it must be safe", rather than do due diligence and thoroughly research the route beforehand.
- Reduced learning opportunities
Getting from point A to point B used to be a highly trial-and-error process that forced you to LEARN THE HARD WAY that certain cliffs are too steep for the average horse. Rather than falling off a cliff repeatedly, road drivers don't learn these lessons at all.
- Narrowed creative riding
When riding a horse, you are beset by constant questions. "Is that cliff safe for my horse to scale", "are those berries safe for my horse to eat", "is that a bee nest in my path or just a lumpy tree branch". These force you to think creatively about your travels. As a road driver, the way is predetermined for you, and you won't be as adaptable if you run into unusual situations.
- Dependency on proprietary engines
All horses are exactly the same, right down to the color and number of hooves! This makes it easy to transfer your expertise from one horse to another. Unfortunately, once you become a car driver, you'll find that the manufacturers put the damn volume knob in a different place on every single model. And there's nothing you can do to change it, because it's proprietary.
Most assignments done by students are basic problems that have been solved tens of thousands of times and could be found everywhere all over GitHub.
Assignments where you have to write algorithms like bubblesort or binary search are as easy as typing the function signature and then having copilot fill in the rest.
Therefore, using copilot as a student will make you worse at programming, since you are robbed of the fundamental thinking skills that come from solving these problems.
It's been frustrating to request a simple feature or tool and see interviewees spend hours fighting with a LLM to make it do what they want instead of just trying to do it themselves first and correctly picking the spots to use the AI.
Personally, I don't think the aspects of writing code that AI tools help with the most are the important parts. I think AI tools are great at taking out the rote aspects and the glue code so that programmers can concentrate on the core issues and broader structure.
I have no problem with using LLMs to act as rubber ducks, or find alternative ways to do something, or filling in boilerplate. But for the first two, anyway, you really need to already know how to do the task in order to determine if the LLM got it right or not. Or at the very least, know the language well enough to spot problems.
[0]: https://blog.cloudflare.com/details-of-the-cloudflare-outage...
"Its going to make you reliant on the [compiler], and you will never be able to do anything that the [compiler] cant already do."
LLMs are here to stay, even if they don't write perfect code -- they are clearly very useful to an increasing number of existing developers and, more importantly, bringing new developers into the art of software creation.
Counterpoint: the field is already chock-full of juniors trying to get a job, and the ones who are actually good at coding are now even more diluted in a sea of shiny nonsense.
Copilot saves me a lot of time. It frees me up to think more critically of the code I’m writing.
That being said, I’m interested to see what happens to LLM effectiveness over time as the amount of LLM-generated code starts infecting training data.
The very, very short version is that it lets programmers move faster and try more things, which helps them learn quicker.
The rate at which I learn new libraries, frameworks and languages has accelerated dramatically over the past two years as I learned to effectively use Copilot and other LLM tools.
I have 20+ years of experience already, so a reasonable question to ask is if that effect is limited to experienced developers.
I can't speak for developers with less experience than myself. My hunch is that they can benefit too, if they deliberately use these tools to help and accelerate their learning instead of just outsourcing to them. But you'd have to ask them, not me.
making systematic mistakes is the trait of the character, there is nothing that can fix that, except the subject itself
It's just another abstraction layer, like high-level languages were. Responsible use combined with continuous learning can boost productivity without sacrificing knowledge.
The impact differs between experienced devs and beginners. As these tools evolve, we'll likely develop new meta-skills around AI collaboration. Like any tool, it's about how we use it.
in reality, Copilot and other LLMs are just tools, and like any tool, they can be used well or poorly. If a programmer is relying on Copilot to do all their thinking for them, then yeah, they're probably not going to learn much. But if they're using it as a starting point to explore new ideas and learn from the code it generates, then that's a different story.
And let's not forget that AI-assisted coding is not a replacement for human judgment and critical thinking. If a programmer is not reviewing and understanding the code they're writing, then that's a problem with their workflow, not with the tool they're using.
I'd love to see some actual data on how Copilot is being used in the wild, rather than just anecdotal evidence and hand-wringing about the 'dangers' of AI-assisted coding. Until then, I'll remain skeptical of this article's claims.
I also don't think it's a great starting point for exploration. There's a lot more value out of learning a couple different quirky frameworks and reasoning through why they exist than there is hacking together something quickly within the bounds of what the LLM's can do.
yes you can absolutely sink time and lose efficiency
i encounter it many times, i have it generate large amount of code that seemingly does what i asked it to do
but then it takes many revisions to finally arrive at edge-case-free state
I also end up having to read through the code generated to build a mental model of what the app is doing and to gate keep future revisions.
But what makes all this worthwhile is that it saves my employer a lot of money.
For example: We've generated a large enterprise react application for roughly $100 USD within a month using all the available code gen tools out there. I'm talking the entire stack: backend, frontend, documentation.
Trying to pull that off with a real team? it would cost 1000x minimum and roughly 3 quarters, maybe the entire year.
A business won't care about the "art" side of things. They just see they can generate software at almost 99% discount.
I'm very worried about our software engineering jobs beyond 2024. It's going to massively shrink and wages are going to reflect this new cost saving that code gen provides.
Building high quality software on the other hand takes a lot of empathy, skill and experience; neither of which is attainable for a computer.
I feel bad for the users of these discounted applications...
When you've lived through enough piles of barely-working garbage produced by contractors who didn't understand, or coworkers who didn't care, you'll know why they were emotional. You'll also have a suspicion that they are not yet out of date.
this technology is getting better not worse. ive already been able to do without a dedicated frontend react developer. i cant be alone.
In 10 years time, we will have a generation of coders where the majority have never coded anything without the help of some LLM. If that's even the thing, when that time comes.
Some posters here are living in some luddite delusion, if they think the "AI hype" will somehow just blow over, and people will go back to sifting through stack exchange, or simply read the man pages for something.
Sorry, that's just not going to happen. In the past two years we already have junior devs that are dependent on LLMs to work efficiently.
These posts remind me of how older folks (25-30 years ago) warned about search engines, and how they'd make the youngins lazy and uncritical.