Why Programmers should fear GitHub Copilot

And other Transformer Driven Coding Tools

For those who don’t know, GitHub Copilot is an AI powered code auto-completion tool developed by OpenAI in collaboration with GitHub and Microsoft. It is built on top of GPT and is a (sort of) cousin of ChatGPT. It supports a range of programming languages including Python and JavaScript.

This article is not based on a large survey of thousands of programmers. It is based precisely on the experience of one programmer — i.e., me. So, take my conclusions not as confident and quantitative predictions, but more as hand-wavy and qualitative warnings. I hope that much of what I’m going to say might happen doesn’t happen.

[When you read “Copilot” in this article, intepret it as “GitHub Copilot or similar tools”. Competing products are likely to emerge fairly soon.]

Two types of programming

When I write code, I do two types of things: which I’ll label “artistic” things, and “boring” things. Or Type-A and Type-B.

• Type-A coding involves creating new things, or new ways of doing old things. I use the world “artistic” because they innately involve creativity.
• Type-B things involve mechanical tasks, which are not very interesting (boring), but must be done. For example, writing unittests can be a bit mechanical. You know the inputs and outputs, and you need to make sure that every processing path is covered.

Type-A and Type-B coding tend to intermingle.

How I work with Copilot

My working experience with Copilot so far, as followed the following pattern:

While Programming Task is not complete:
    Nuwan codes some Type-A stuff.
    Copilot “completes” the related Type-B stuff.
    Nuwan checks what Copilot completed.

In other words, I do Type-A, and Copilot does Type-B.

For example, I could code-up a class, and Copilot completes the corresponding unittest class. Or in a more local scenario, I start a for-loop or a list, and Copilot adds the body.

Before Copilot, I spent about 80% of my coding time on Type-B tasks, with the remaining 20% of Type-A.

[The 100% described here is strictly “coding time”; not “designing time” or “thinking time”. So technically, the total time for Type-A is much more.]

Now, what this means is that the time needed to code has reduced by 80%. Or alternatively, for a given span of time, I can get 5x more things done.

[Note, I’m implicitly assuming that Copilot cannot do Type-A. This is partly “evidence based”-my understanding of the underlying AI, and party “need-to have-faith based” — my need to have faith that humans in general, and programmers in particular, will always have some use in this world. The assumption is, by no means, guaranteed to hold.]

Why Programmers must fear

Almost all programmers can do Type-A and Type-B tasks. But there is a lot of variance or how much and how well.

For example, consider an extreme organization which has five programmers. One does solely Type-A work, while the other four do solely Type-B work.

Now how would Copilot affect such an organization? The first programmer would be able to do what they do just as before, because Copilot cannot do what they do. But the remaining four would be replaced by Copilot.

As I said, this is an extreme, charicatureque case, but all organizations will have some version of the above.

Conclusions and next steps

1. Currently, most programming work is of Type-B. As a result, most programmers spend most of their time on mostly Type-B work. This work is going to flow to Copilot and similar tools. So, if we are a Type-B programmer, we really need to make sure that we start getting and doing more Type-A work, and if we don’t know how, we must try and learn.
2. While overall productivity will significantly increase, gains will be felt in extremely unequal ways. Companies doing mostly Type-A work (e.g. those producing high-value intellectual property) will see the biggest gains. Companies doing exclusively or mostly Type-B work (e.g. Business process outsourcers development — already on the wane) will be completely wiped-out. If we fall into this latter category, we need to change gears to building the former type of high-value products, and change gears very quickly, because death stares us in the face.
3. We all need to try and hire more Type-A people. There is already a shortage of them, and soon, the shortage will get much worse.
4. We need to find ways of creating more Type-A programmers. Degree programmes producing Computer Scientists and other “supply chains” will need significant reforms. Sadly, this can’t happen overnight, and any reforms will need at least 2–4 years to start bearing any fruit, and much longer to reach full potential. Also, we will need to diversify beyond “conventional supply chains” (like universities) and find other ways of “manufacturing” programmers.
5. In the short term, sadly, there is going to be a zero-sum game, where an increasing demand will chase a (effectively) constant supply of Type-A programmers. The worst case could be a sort of hiring arms race.

An oil painting by Salvador Dali titled “Why Programmers should fear AI” — by DALL.E 2