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 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 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.

Subscribe now

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…

It has been a while since I have made any attempts to write or publish outside of what has been needed for my job. For work, over an almost a decade, I have produced many writing artifacts: From design to strategy and roadmap documents, but despite all the longings to write and publish, I have never had a conviction to write consistently—outside work. To share my thoughts and ideas about the topics that I care, or create pieces that might become inspiring or just enjoyable to read for others.

I feel this is the right time but I do not know the exact reason. I would say, maybe because I feel, if not already, it is getting late.

As they say: We have been nonexistent for billions of years and will not exist for likely billions years more. For some reason, we want to extend this short blip of being to eternity and become immortal in the experience of others.

It is getting late because firstly, I believe life is short and like many, I have this urge to leave a meaningful mark before I am out—to make an attempt irrespective of how successful I will be.

Secondly, because I believe if one is lucky enough to have an opportunity to create, it is an unfair treatment to refrain from getting engaged in a creative process. Creating something new may lead to producing something useful either directly or transitively. Even if it is considered a useless piece, in my view, it is debatable that it increases the chance of creating a positive or a useful set of ideas or an artifact in the chain process of human interactions. I think the intention matters though; it is hardly convincing when we face a misinformation or disinformation piece, or plain bullshit—I believe in such cases, the overall impact is negative not a positive sum.

I plan to share my thoughts in this blog by following a cross-disciplinary approach presenting my thoughts and ideas by blending a variety of topics. The topics will be mostly about computer science, software engineering, philosophy, and literature. I plan to refrain from using Artificial Intelligence (AI) to bootstrap or refine my writing effort. I will elaborate more about this decision in a dedicated post.

Finally, I am so excited for this endeavor. Let the fun adventure begin!