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

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): The picture is inspired by Grigori Kozintsev’s 1964 Hamlet featuring Innokenty Smoktunovsky

Part 1 raised this question that if AI can provide means to implement our ideas via programming, do we still need to know how to code and reason about it?

Before going any further it is the right time to ground the term AI. By AI, I mean the mainstream large language models (LLMs) and the set of tools, technologies, and services that collectively provide AI-assisted software development capabilities.

To answer the question, let us use a thought experiment:

3D Printer Thought Experiment

Let’s imagine we are living in a clone of our world where no 3D printers have been invented up until year 2025. PrintREAL is a new startup that aims to bring 3D printing to reality. Their pitch is text-to-3D capability. Everyone can print any 3D model. Consumers need not be engineers or designers; so long as they have a feasible idea, they can print their model out. Their prototype is an AI ChatBot along with a primitive 3D printer. The ChatBot user interface has a preview pane that shows the outcome of the idea iteratively. The prototype is functional and the team is gradually transitioning from pre-seed stage to Seed. As the team pursues product-market fit (PMF), very soon PrintREAL founders realize that if they don’t modify their minimum viable product (MVP) specification, they will face an epic failure soon. They realize that for their target market, they cannot ship their product without providing an interface for precision modelling. Users cannot be precise through the normal means of communication i.e., via prompts (text or audio). Users can still provide an image, spreadsheet, a markdown table, or some other representation that communicates the dimensions that users are targeting, as part of their prompt. But prompts are unstructured and their feedback loop is not fast enough for iterative design processes. But none of these are the main problem. The main problem is: prompts don’t provide the right fidelity that is required for design work. They lack precision. The team’s insight is that their AI-native design tool must be able to provide such precision.

Design needs precision control; but why? In my view, the reason is far more general. As it stands today, AI is an assistant, and our intention is largely to keep it subordinate. As an assistant, it helps us achieve a set of desired outcomes. Sometimes we can delegate an effort completely and it produces the outcome for us; but, at the end of the day, the outcome must be the one that we want. We need to verify that the outcome is correct and it is aligned with our wants. We can even delegate the verification and alignment task to AI, but ultimately, there will be a human in the process to accept or deny the outcome. As Noah Smith argues, your future job will be to keep AI on task.

Assume AI can write programs for us across every kind of problem. Not knowing how to program or reason about programs can take us part of the way, but it won't give us the precision needed for verification and alignment. We can vibe-code an entire project; we can spin up as many agents as we want, but without knowing how to code, we cannot be precise about the outcome.

Back to our assumption. As my friend Ān Shìgāo has pointed out in this comment, LLMs simply cannot solve all problems. As problems become more difficult, their ability to predict the solutions stochastically diminishes. So our assumption doesn’t hold. We may be able to vibe-code an entire static website, a bug fix, an integration test, or a new feature in a back-end stack, but without understanding abstractions, reasoning about them and their implementations, we raise the risk of producing outcomes that work only partially, break easily, or can be compromised.

Let’s grant the assumption anyway. Even if a different AI paradigm could solve every problem better than any human, keeping AI subordinate would still require us to be precise; i.e., to verify that the output is correct and aligned with what we actually want. In software, the precision interface is the code itself. Reading it, writing it, and reasoning about it are what lets us accept or reject what the machine produces. This returns us to where Part 1 left off: the programming think-not is the person who can only gesture at what they want through iterative ideation, hoping the machine does the right thing under the hood to produce the output; they cannot reason about the code performance, abstraction leaks, runtime implications, etc. Because they can't read what it produced well enough to tell whether it’s correct and it won’t break.