GitHub Copilot and Other Programming Doom

Hi! It looks like this post has since been updated or rethought in some ways, so you may want to look at this after you're done reading here.

As I’ve hinted at once or twice, I’m recycling some answers I have written on Quora—and some other writing—and updating them for my current line of thinking.

ENIAC Function Table

This post is partly based on…

Obviously, they have been edited substantially to fit together, and to better fit the tone and format of Entropy Arbitrage.


Programming on systems like the Colossus computer has been described as instructing the machine to make specific calculations/counts, and after studying the results, providing the next job. Computers of the day didn’t remember intermediate results, and didn’t have the means to act on any intermediate results it had.

This process included—in addition to many technicians and engineers standing around to make repairs—hand-punching paper tape loops and specifying every single instruction that the machine needed to execute to solve the problem at hand.

In some ways, the ENIAC was even stranger, basically being a fixed collection of complex problem-solvers that were more or less single instructions in a process. Programmers—mostly women, by the way, though they’ve been ignored for decades—specified the instructions by setting switches on panels, such as the panel you can see in the post’s header image.


Today, though? I can write some fairly high-level descriptions of what I want—for some cases, I can even just specify the problem and trust that someone else has solved the problem for everybody—with an editor that will catch a lot of my mistakes for me and make suggestions to improve what I write, probably leveraging frameworks generating a lot of the most boring code and figuring out what libraries I’m going to need to get things to work, compile it in seconds without me needing to know anything about the underlying computer, then send the whole thing out to a dynamically-scaled cluster of computers.

As technology advances, the question consistently comes up: Is this the end of programming? With such sophisticated tools, can’t managers or even uneducated customers can just use those tools directly and cut out the programmers?

Prior Ends of the World

While by no means complete—because not everybody announces every project, and because I don’t want to weigh the post down—I’d like to talk a bit about the various times in the past that we would definitely no longer need programmers.


The cheap shot is the COBOL, the “COmmon Business-Oriented Language.” While the underlying intent of developing the language was to commoditize computer hardware by making it easier to move software between mainframes, you’ll occasionally stumble across a contemporary (non-humor) book or article suggesting that, because COBOL’s syntax looks like English, managers will soon be able to eliminate their developer teams and do the programming themselves, since the managers already know English, and so don’t need the programmers to “translate” for them.

The industry has probably complicated that sentiment, by the fact that most software project managers are former (or current) developers, but the same antipathy and self-hatred still exists towards “management,” as somehow incapable of programming. It’s only worse when executives use “wives” as the low-water mark for technical ability.

Having used COBOL on a couple of projects, I can tell you that…it’s fine. I hate the idea of breaking up the program into sections—the Identification, Environment, Configuration, Data, and Procedure divisions—but I started out programming in BASIC, so I’m not afraid of the occasional GOTO in my code when there’s no other option. And COBOL is fairly similar to other period languages, once you get used to the syntax.


My kindergarten class was taught to read and draw flowcharts, bizarre as that might sound. I never learned why it was in the curriculum, and I’ve never thought to ask students in other classes if they had the same experience, on the rare cases that I run across someone from those days—since I generally prefer to not sound like I’m having a nervous breakdown when I’m excited to see someone—but we also wired up telephones to a couple of car batteries for one lecture. I know that it wasn’t an “advanced” class or a wealthy school district. So, maybe I just had a great teacher who I didn’t appreciate enough.

Digression: For those of you who are younger or less technically inclined, what we now call “landlines” used to be powered by the phone company over the phone lines. If the phone had 48 volts, you could place a call. In most cases, this meant that neighborhoods or houses without electricity still had phone service. It also meant that, in certain cases, if the phone company’s local office also lost power, you could supply power to the phone—though the company wouldn’t be pleased with you if they found out—and could sometimes connect to someone if there was still a working switch. So, my kindergarten teacher showed us how to build an intercom system, basically, by connecting the phones together with power.

Anyway, you can probably see where this is going. Because a flowchart has no fussy syntax rules—well, OK, it actually does, but you don’t type them—even a child can do it, and therefore we don’t really need any programmers, if we only had the technology to draw flowcharts on the screen.

You know what I love (in an ironic way) about this industry, though? “Any idiot can write code with flowcharts” was obviously a flop, and today, most developers I know would laugh if you started drawing a flowchart to explain something. But Blockly and similar systems in the last decade or so, basically just expensive versions of the same idea, still show up regularly as brilliant new ideas. Nothing in the software industry ever goes away permanently…

In between flowcharts and Blockly, we should also mention UML, which…it’s a flow chart for data, instead of code. Let’s leave it at that, because there was about ten years when every office I worked announced that they were requiring every task to include submitting an updated UML diagram, but never actually followed through. If you remember those days, that’s more than enough talk about UML for you, too.

Computer Aided Software Engineering

This is a funny category, to me, because parts of the idea exploded and changed the industry for the better, whereas others never manifested. Computer-Aided Software Engineering was the idea that we could integrate important tools so tightly into the development process, that developers could afford to be far less experienced and far less talented, because the tools would catch issues before anybody else saw them.

In some cases, this was probably valid. For example, distributed revision control means that developers can keep track of their work in the public repository, without contaminating anybody else’s work, until it’s time to merge the pieces together. Automatic code analysis—“linting”—has saved everybody the embarrassment of revealing certain kinds of mistakes.

Other cases never worked well enough for anybody to release it. I remember being shown demonstrations that would generate code from diagrams (like from the last section), but that never manifested. I was once told that multiple companies were just months away from releasing penetration testing systems that were fully automated, able to assimilate results and automatically generate new hypotheses about flaws, but decades later, penetration testing is still manual and expensive.

And then there were cases that where we got what was promised, but the promises were overblown. For example, computer science education for a long time was built around proving program correctness; some classes in my college taught programming with tedious documentation requirements about the expectations of various parts of the program, not for human readability, but for the benefit of a hypothetical code verification system. To my knowledge, that’s still the domain of hiring teams of mathematicians to review critical code, rather than something that companies would do to save time. Similarly, the CORBA advocates promised a future where we—anyone—would be able to stitch together features that we wanted from many vendors across the Internet, only needing to write original code, but we never got anything like the promised flexibility or ubiquity.

No-Code or Low-Code

Going back at least as far as FileMaker Pro, there have been systems meant to take the “coding” out of programming, hoping to make the system accessible to average people. Generally, the idea is that you get a database with an example-based approach to requesting data, a form builder, and the ability to trigger events when certain things happen.

The general idea is that, as long as the application that you want happens to look like what the developers planned for, you probably won’t have much work to do. In reality, while these systems have their advocates—I had a manager who was still using FileMaker as late as 2001 for internal tools—the most important skill in using them is understanding what it’s meant to do and not trying to exceed those boundaries.

Artificial Intelligence

Things were quiet on this front, for a while, but then neural networks came knocking on the door. Now rebranded “machine learning,” we pretend that we’ve cracked artificial intelligence, even though the technique hasn’t changed since long before I took a neural networks class in 1995.

Because machine learning systems have—and I’ll get into this more in a bit—largely replicated every other technique we use for spoofing artificial intelligence, it has become the latest technology to claim to cut down the software development workforce, especially when it comes from one of the Big Five software companies—Amazon, Apple, Facebook, Google, and Microsoft—and so our latest contender enters the ring.

GitHub Copilot

Microsoft has now released GitHub Copilot, a machine-learning tool to generate code to supplement what a human developer has written.

I should note that I haven’t used it, yet. I’m on the wait list and will probably write a post about the experience when I do. But before I get there, the product is…problematic.

The Machine Learning Twist

The big issue is that, as much as Microsoft/GitHub wants to call it a “code synthesizer, not a search engine,” it still admits that’s not true, with variations on the following quote.

…the suggestion may contain some snippets that are verbatim from the training set.

This makes sense, of course. From the original press for AlphaGo playing Go, it’s been obvious that machine learning generally just replicates a combination of Markov processes and alpha-beta pruning, even though it’s difficult to inspect those intermediate representations if they’re not explicit parts of the output. That means that code isn’t being “synthesized.” It’s being regurgitated in various-sized pieces, in such a way that the pieces all fit together seamlessly.

I’m going to guess that the candidates are then filtered by a normal “linter”—mentioned with the CASE tools—to make sure that none of the suggestions are complete garbage. If you follow any of the actual experts—people like author Janelle Shane , rather than someone who’s trying to sell systems—you know that every list of fun things or a great story that a neural network generated involved generating hundreds or thousands of candidates, then manually picking the best; code has the advantage of having a rigorous grammar, but will still need filtering.

In any case, the regurgitation creates a problem, because we don’t know what projects the Copilot team has chosen in their training set. If any of it was posted without a public license, using results that include components would be a derived work, and that would be piracy. If any of the pieces are from code released under the terms of the GPL, you shouldn’t use it in a project that isn’t released under the GPL. Even if the training data was all released under the terms of the MIT license, that has terms to comply with, too. That doesn’t even get into whether the training set includes code created in a jurisdiction with “moral rights” on works.

In other words, Microsoft and GitHub might want to convince everyone otherwise, but there’s a fairly good chance that their project is inciting people to violate copyright law. And I’d be willing to bet that the licensing agreement to use the service doesn’t indemnify the developers who use Copilot, as a company might do if they could guarantee that they weren’t feeding you protected code. More likely, the license disclaims all responsibility for vetting what it recommends to you.

If you think that’s an overreaction, consider an obvious question: Have they ever mentioned training the model with their own code? Is there some tiny chance that it will suggest code copied verbatim from Windows, Office, Azure, or GitHub? If not, why not, if Copilot isn’t creating derived works and there aren’t any licensing problems…?

Keep in mind, even if Copilot manages to somehow be the tool that magically understands human needs—ha!—if it’s doing so through piracy, lawyers charge significantly more per hour than software engineers do.

Regardless, let’s assume that everything with Copilot is aboveboard. There are still reasons to assume that it won’t reduce the need for developers.

Compilers Automate, Too

In the simplest interpretation, Copilot is a compiler. It looks at code that the developer wrote, and produces an error message, offering corrections.

It’s a fancy compiler, sure, but if we strip away all the conceptual frills, it takes input code and outputs different code and some warnings. And improved compilers have only increased the market for programmers. Good tools make programmers more cost-effective, meaning that smaller budgets can afford to get things done.

Even in just the twenty-plus years that I’ve been programming professionally—to say nothing of the years that I was a hobbyist or student—the difference between how I worked then and how I work today is night and day. The point is that, between the time I start working on code and the end-user gets access to software, I would be shocked if ten percent of my work is actually written by me. The amount of automation is shocking, when you actually stop to look at it, and it’s only going to get better.

What might this mean? Probably more opportunity, if history is any indication. As the automated side of the job gains functionality, people have more ideas for what we can be doing with it. It’s not long ago that we never would have considered sending telephone calls and films across computer networks, but today, that’s the default.

However, the jobs will change, like they always do. Years ago, I used to work with people who had titles like “Build Engineer,” people whose actual job it was to make sure that the compilers were configured and the installation packages were generated correctly. Today, that’s mostly a solved problem, and developers almost exclusively work on translating user requirements into solutions. Those that haven’t, have further specialized into “DevOps engineers.” That trend will certainly continue.

Regardless of that trend, programming isn’t likely to go away. No matter what the technology—COBOL, CASE tools, Copilot, whatever—promises that we’ll have “software without programming” always fall short, because someone needs to bridge the gap between translating what people say to the sort of specific, unambiguous explanation that maximizes the chances that people get what they want. And that person is a programmer, even the job looks like talking conversationally with some sort of artificial intelligence.

Writing Code versus Programming

For at least the thirty-ish years that I’ve been paying attention to the software industry, but really going back as far as COBOL, we’ve been continuously promised a tool just over the horizon that’s going to make it trivial for normal people to write code. Every one of them has achieved the goal, and is a failure, because writing code isn’t the hard part of programming. Turning ideas into an unambiguous specification is the hard part, and that requires communication, not code.

I’ll repeat that, because it has been making the rounds on Twitter , so I guess maybe that stumbled on something useful.

Writing code isn’t the hard part of programming. Turning ideas into an unambiguous specification is the hard part, and that requires communication, not code.

Does that clarify why those prior systems haven’t reduced the number of programming jobs? All they do is simplify writing code, the easiest part of the job, the part that doesn’t help programmers grow.

Been There, Done That

Again, I haven’t looked at Copilot specifically, but I’m tempted to add a fourth item, something I’ve already alluded to.

Almost every OMG-we-finally-cracked-AI product just generates Markov chains, but without the ability to inspect and debug the generation process.

A Markov process is basically a special kind of search engine, that asks: Given the most recent inputs, what is the next most likely input? So, while Microsoft is correct in saying that they didn’t write a search engine, the odds that they didn’t produce a search engine are low.

That’s not necessarily a bad thing. There is absolutely a role for an editor or compiler that—for example—queues up relevant questions from Stack Overflow, so that the developer doesn’t need to hunt for them. But such a feature changes the speed of work, not the kind of work.

Making It Perfect

Here’s a maybe-controversial assertion: The only way that artificial intelligence—or any product—might displace human software developers would be if we cede our autonomy to computers, in some dystopian future.

What I mean is that, maybe computers can—one day—produce all the specifics of code. But we only write software in response to a human need, and someone needs to communicate that need and what it means to a computer. Can the person with the need explain it directly?

Possibly, but then we’ll all be programmers, because that is the program. Again, this is the problem with these “even your manager will be able to develop applications” products. They remove the typing from programming to bridge the gap from one direction, sure. But they never bother to teach people how to think about software or how to solve problems, so the gap is never bridged from the other direction.

Like I said, there’s one possible exception. If we’re willing to live in a world where software monitors everything we do and other software is automatically written and rewritten to squeeze more productivity out of us based on some predefined metric, then it’s possible that’s the last program a person will write. At that point, software is no longer written to serve human needs; we’re all just watching our pomodoro clocks and shuffling tickets between swim-lanes to please our robot overlords 🤖.

However, I don’t see the utility in removing all discretion and self-direction from human beings. By and large, the historical societies that have attempted to do that have tended to fare poorly. It’s possible that I write about this topic, occasionally.

The industry will shift, and it may shift dramatically, but it won’t go away unless we all decide to work for computers rather than have them doing work for us.

Bonus: Legalese

A related question to AI replacing programmers revolves around the idea of AI replacing lawyer, especially when dealing in contract law.

And this is a similar answer, too. Legal contracts are already in a language that non-lawyer people understand, after all, generally the native language of the people involved in the contract. The contracts are long and complex to remove ambiguity—just like computer programs—and to prevent the relationship from falling apart due to a misunderstanding. They’re complex, but they’re not (assuming nobody is trying to commit fraud) complicated.

So, while the answer is technically “yes,” software could act as your contract lawyer in that it can just show you the contract, the answer that a person would want is “no,” because any simplification of the text reintroduces ambiguity to and potentially changes the meaning of the contract, so you’re not actually understanding the document you’re signing, just an interpretation.

Robot lawyers, however, introduce an entirely new problem of introducing bias into the relationship. With code, we might not care if the examples used to train our AI to sort names were written by a sociopath. A list is either alphabetized or it isn’t, after all. But when we start talking about the law, medicine, or any other fields that revolve around deciding people’s fates, there are plenty of examples where machine learning has learned to treat Black people worse than everybody else, or that wealthy people should get what they want, because we have a long history of courts making those dumb decisions to draw from. In those fields, handing them off to neural networks is equivalent to depriving people of autonomy.

Preliminary Copilot Verdict

Since this post is nominally about GitHub Copilot and–again—I haven’t actually used it, I’m still comfortable in saying that it probably won’t change the world.

Given the issues, I want to give it a try for personal projects—where licensing isn’t an issue, since I’m going to release things under GPL-variants, anyway—and might consider it for other open source projects. But it’s not going to save anybody any more money than UML saved companies in the ’90s.

If I get to the head of the waitlist and it’s life-changing, though, you’ll all be the first to know…

Credits: The header image is ENIAC function table at Aberdeen by Jud McCranie, made available under the terms of the Creative Commons Attribution-Share Alike 3.0 Unported license.

By commenting, you agree to follow the blog's Code of Conduct and that your comment is released under the same license as the rest of the blog.

 Tags:   quora   programming   career   rant

Sign up for My Newsletter!

Get monthly * updates on Entropy Arbitrage posts, additional reading of interest, thoughts that are too short/personal/trivial for a full post, and previews of upcoming projects, delivered right to your inbox. I won’t share your information or use it for anything else. But you might get an occasional discount on upcoming services.
Email Format
* Each issue of the newsletter is released on the Saturday of the Sunday-to-Saturday week including the last day of the month.
Can’t decide? You can read previous issues to see what you’ll get.