To Be or Not to Be (a Programmer): Part 1

An attempt to understand the relevancy of knowing how to program in the new era of AI-driven programming.

To Be or Not to Be (a Programmer): Inspired by Grigori Kozintsev's 1964 Hamlet featuring Innokenty Smoktunovsky

Paul Graham has a short but exceptional piece on writing. In WRITES AND WRITE-NOTS Paul argues that in the age of AI, as the article puts it: “there will just be good writers and people who can't write”. Paul believes this is bad because writing is thinking; this means that soon there will be a clear boundary between those who can think clearly about problems and those who cannot (i.e., “thinks and think-nots”). I agree with this stance.

Reading Paul’s piece, I felt a strong urge to figure out if Paul’s argument and insight are extensible to programming in the age of agentic AI development.

We are living in an age where some of the programming tasks are absurdly trivial for coding agents. A canonical example is writing tests; perhaps many agree with me that writing tests is (or was) one of the most tedious tasks in programming.

Programming, like writing, involves the process of using a language syntax (which is constructed by a well-defined grammar) to convey a stream of semantics as an output. This is through a medium to a processor (or an agent). For programming, the processor is a computer (or a Von Neumann machine) and for writing, it is (typically) a human brain. The distinction is that for programming, the semantics are reducible to a set of machine instructions, whereas for writing, they are, more generally, human interpretable information.

Going back to Paul’s argument, in my view, it is applicable insofar as programming and thinking are similar: i.e., the process of using a syntax to generate an output; but is that sufficient to be able to extend the article’s point to programming?

Where programming and writing part ways is in the utility of the outputs that each process generates. For programming, the output, the machine code, is there to be executed by the machine. The computation is the end goal, whereas in writing it is to communicate a set of ideas as information. I see writing as, functionally, a superset of programming. But is programming only about generating the machine instructions? The following framing helps:

Computational processes are abstract beings that inhabit computers. As they evolve, processes manipulate other abstract things called data. The evolution of a process is directed by a pattern of rules called a program. People create programs to direct processes. In effect, we conjure the spirits of the computer with our spells.

A powerful programming language is more than just a means for instructing a computer to perform tasks. The language also serves as a framework within which we organize our ideas about processes.

_{—Chapter 1, Structure and Interpretation of Computer Programs, Hal Abelson, Jerry Sussman and Julie Sussman}

So programming is also about directing computational processes that eventually produce effects on the real world. Where does the thinking sit in this picture?

If AI can give us an abstraction that lets us form and combine our ideas for driving the computational processes, why can’t we delegate to AI the thinking effort that goes into writing the actual programs? Why can’t we save our thinking effort for the act of forming and combining ideas for the ultimate effect of the programs and leave the driving part to AI? If we can offload that effort, does that mean not being able to program and reason about programs makes us a think-not?

More on this in Part 2…