Original article: Conversational Programming
A month ago, I got a demo of GitHub's Copilot and I've been pondering the implications. Here's what I've realized: Copilot will change what it means to be a programmer.
Will Copilot put programmers out of a job? No more than the invention of typewriters put writers out of a job. What it will do is change the nature of the job. Copilot represents a paradigm shift for the practice of programming.
The naive interpretation of Copilot is improved autocomplete. I believe that's the wrong mental model. Instead, we should think of Copilot as a shift to a conversational model of programming.
GPT-3 Generated Summary: Copilot will change what it means to be a programmer, making it more like a conversation.
About a year ago, I played with an early demo of a GPT-3-powered "teacher" that could impersonate any historical figure. The interface was similar to chat. I talked to Elon Musk, Plato, Alan Kay. Below, you can read my conversation with Plato.
The interesting thing about this experience is how much it actually felt like talking with another human. (That is, if you are, like me, the kind of person where talking about Plato's cave and the purpose of education is a normal conversation 🤣). The responses were rather long, yes. But I found myself hearing a voice in my head while my reading. Just like talking to a human, I found that my question wasn't quite understood and I had to find a way to make myself clear. The conversation moved forward naturally as each response led me to formulate my next question.
And even more interesting, a few months later I found myself wishing for an AI that I could converse with throughout the day. I missed the AI, and was sad that the beta software was no longer available.
I believe programming with Copilot and other AI assistants is going to be more of like that dialogue I had with Plato last year: a conversation between a programmer and the computer. It will change how we work.
GPT-3 Generated Summary: The GPT-3-powered teacher I played with a year ago felt like I was talking to another human. I believe programming with Copilot and other AI assistants is going to be more of like that dialogue I had with Plato last year: a conversation between a programmer and the computer.
In 1967 Marvin Minsky was arguing with his colleagues about how we should think about writing programs. He wrote:
"The programmer does not even have to be exact in his own ideas‑he may have a range of acceptable computer answers in mind and may be content if the computer's answers do not step out of this range. The programmer does not have to fixate the computer with particular processes. In a range of uncertainty he may ask the computer to generate new procedures, or he may recommend rules of selection and give the computer advice about which choices to make. Thus, computers do not have to be programmed with extremely clear and precise formulations of what is to be executed, or how to do it."
Note the action verbs: ask, recommend, advise. Minsky understood, even in 1967, the possibility of a 2-way conversation between programmer and computer, where the program is written in collaboration. He contrasted his view with the view of a "program as a sequence of instructions to be obeyed," stating:
The most common and simple‑minded view is that a computer program is a sequence of clear-cut operations to be performed on some data.
Instead of a sequence of commands, Minsky argues, writing a program could be more like offering "advice" to the computer, guiding to a solution that is "close enough" to what the programmer intended:
"In each domain of uncertainty I am at liberty to specify (instead of particular procedures) procedure‑generators, selection rules, courts of advice concerning choices, etc. So the behavior can have wide ranges–it need never twice follow the same lines, it can be made to cover roughly the same latitude of tolerance that lies in the author's mind."
What we have with Copilot is a "good enough" implementation of what Minksy envisioned that allows us to move from dictation to conversation.
GPT-3 has been available for about a year. Already you can read field reports from people who have worked alongside AI Assistants, and how it shifts their way of working:
"Tried Github Copilot; fascinating. You still need to code, but a new skill of "goading" is required. Your mind starts modeling OpenAI's mind and you're trying to learn how to best express needs to the computer. Maybe engineering is now equal parts coding and teaching ability."
"It does feel a bit strange that my main learning source every day is a giant neural network impersonating long-dead scientists who write me custom essays on topics I’m curious about"
"When I’m working on a hard problem, I’ll use GPT-3 get feedback from foremost expert in the field on it. Like Steve Jobs has unknowingly made tons of product decisions at Debuild."
Note in each case the tendency to personify GPT-3 and frame it as a collaborator in their working process.
GitHub has been using Copilot internally for several months. They chose this headline for their announcement page: "your AI pair programmer."
One of the most upvoted comments on the Hacker News post agreed: "It's really like pair programming, even though I'm coding alone."
GPT-3 Generated Summary: Marvin Minsky's 1967 paper "A Framework for Representing Knowledge" foresaw the possibility of a two-way conversation between programmer and computer, where the program is written in collaboration. This idea was implemented in Copilot, which allows us to move from dictation to conversation.
Copilot's initial implementation is integrated directly into VS Code, a traditional IDE (integrated development environment). Starting inside an IDE is wise as it overcomes the primary risk for a technology like Copilot: disbelief. By integrating Copilot into an existing workflow, programmers can taste the utility without changing their workflow. But what might be possible with a different workflow?
Under the hood, Copilot is a program synthesizer that works by combining the program's context (the existing code, right now limited to the current file) with "developer intent." Alex Polozov gives an excellent overview in this thread.
One important question is "how should we capture developer intent in order to synthesize a program?" Or, in Minsky's terms, "how should the programmer ask, recommend, and advise the computer?"
IDEs have been optimized for many years around a model of programming as dictation. Programming as a process of conversation where intent and context are synthesized into programs implies a different set of constraints. New constraints demand new programming workflows, and new workflows will lead to new tools.
I believe the most interesting embodiments of Copilot (and other program synthesis) will be in a new set of tools that are built from the ground up around this new set of constraints.
What will those new tools look like? We have some clues.
GPT-3 Generated Summary: Copilot's initial implementation is integrated directly into VS Code, a traditional IDE. Starting inside an IDE is wise as it overcomes the primary risk for a technology like Copilot: disbelief. But what might be possible with a different workflow?