Thinking in code
For the last few months, I’ve been having fun solving small coding puzzles around loops, conditions, pseudocode, debugging—the things that probably became invisible years ago to anyone who learned to code properly.
What I didn’t expect was how much this would change the way I use coding agents now.
There is a popular idea right now that LLMs make learning to code less important. I think that is true if by “coding” we mean remembering syntax. I increasingly don’t need to know exactly how to write something in Python. The model is already better at producing code than the average person will ever need to be.
But programming was never really about syntax. It is about taking something vague and making it precise enough that a computer can execute it.
And we are all going to be doing much more of that.
One of the first things you learn in programming is pseudocode: before writing the actual code, describe what should happen in simple instructions.
read email
classify urgency
And there are several ideas hiding inside those three lines.
A loop teaches you to notice when many tasks are actually the same task repeated. A condition forces you to define when something should happen. A while loop makes you answer something humans are particularly bad at answering: when exactly are we done? An if/else makes you think about the other branch—what happens when the thing you expected to be true isn’t?
And debugging teaches perhaps the most useful habit of all: your idea of what the system is doing and what the system is actually doing are two different things.
Lately I notice these ideas everywhere, not just when I’m coding.
A funny side effect is that it has even improved how I communicate with my partner. Earlier I would say, “Can you pass me a cookie from the box?” He would pass me the cookie and leave the box open. Technically, the instruction was completed perfectly.
Now I say, “Pass me a cookie, and close the box after.”
Very good program.
Not sure, how relevant this example is maybe i just need an opportunity to plug his behavior. Anyway, back to computers.
Take a prompt like: Research this market and find the most interesting companies.
There are probably ten decisions hidden inside that one sentence. What counts as the market? Where should it search? What makes a company interesting? Should it include large companies? How many should it find? When should it stop? What happens when two sources disagree?
LLMs are remarkably good at filling in these gaps, which can make us forget that the gaps exist. But every time we leave one undefined, we are implicitly handing over a decision.
The same thing happens with AI coding.
“Build me a page that curates good GitHub discussions” sounds like an instruction. It isn’t really. It is an outcome.
Thinking in code makes you instinctively turn it into something closer to:
Take a GitHub URL. First determine whether it is a repository, issue, or discussion. Extract these fields. If a required field is missing, don’t save it. Show me the parsed result before writing anything to the database.
The second version isn’t better because it uses more words. It is better because it contains more structure.
This has made me think that “prompt engineering” is slightly the wrong frame for what many of us need to get better at. It makes the skill sound like finding better words.
Often the better prompt is not better prose. It is a better program expressed in prose.
For most of computing history, ordinary users didn’t need this skill. Software came with an interface. Someone else had already decided the possible actions and turned them into buttons, forms, menus, and workflows.
LLMs are removing some of that layer. Increasingly, we can tell computers directly what we want: research this, organize this, monitor this, build this, keep doing this until something changes.
Natural language is becoming an interface to computation.
Which is why I suspect computational thinking is about to become useful to far more people than programming ever was.
You don’t need to become a software engineer. You probably don’t need to memorize Python. But it is worth understanding what a loop is. What conditions and branches are. What state means. Why programmers think about edge cases.
Once you understand these primitives, you start seeing their shapes in ordinary problems.
LLMs are getting very good at writing code for us. That might make learning to write code less necessary.
I think it makes learning to think in code much more useful.
Note: Written from my own experience, with AI helping me structure my rambling thoughts into something readable