It was a summer holiday, sometime in the late 1990s. I was a young kid, around 8 or so. My dad had taught me the rules of chess before and we played from time to time. But this time was different: As we were about to start he stood up and walked away from the board, sitting down in a chair across the room and facing the other way.

Whenever I moved a piece I was to simply say the move "pawn from E2 to E4" out loud. My dad would then reply back with his move, which I could re-enact on the board to actually see what was going on. We were playing blindfolded chess. I remember telling him I was moving a piece from X to Y, while the piece wasn't on X. Without hesitating he told me exactly where the piece was. I lost the game pretty quickly, but I was fascinated.

I never got deep into chess, instead I turned to computers and programming.

With the rapid rise of LLMs in programming over the last year and a bit, everything is changing drastically for software engineers. Everyone is trying to figure out how to effectively do things in this new world. Opinions are all over the place. What is clear to everyone is that if you use AI in a way where you spend little time saying what you want, and no time reading what it coded up - you are vibecoding and the resulting software is not going to last very long (if it works at all).

So how much coding should you let the LLM do, and how much should you control and read (and deeply understand)? I am here to argue: less than you think, but you need similar skills to a blindfold chess player.

Positions, not moves

Blindfold players don't hold a picture of the chess board and all pieces in their head, instead they think in patterns and positions: Where the key pieces are, what they are attacking and defending. Tactical relationships between pieces like pins and forks. Those in combination with their general knowledge of chess allows them to reconstruct the actual board in their head.

Similarly, when a good programmer is working in a codebase, there are many things more important than individual lines of code: the overall architecture of the code, the components and the interfaces between them. They have good mental models about the overall program and can think deeply about how to change existing or introduce new code without having to look at all the lines. These skills have always been important for programmers, long before LLMs came about.

The mental model

In the past you would build this mental model over time as code gets planned out and written (by your hands and those of other contributors). This happened at a digestible pace. If you use LLMs in a way where the code gets built at a pace you cannot follow, you will never have such a deep understanding. And the resulting code will be alien, and if not built with care: probably slop.

If you want to develop this mental model, you need to build step by step, while discussing and thinking about every step. This is the same as how a blindfolded chess player still needs to register all the moves, even though the thinking that follows is about higher level concepts changing as a result of the moves.

A pattern I use a lot is thinking about interfaces and components myself, only to then pass them off to the LLM to implement them. I do sometimes discuss the design of these interfaces and components beforehand, but only so I can make a better decision on what they should look like. I always stay in control of the high level positions, where I skip the details and let the LLM worry about them. It's not always obvious which decisions are positions and which are details, and I'm still improving myself.

A strong mental model means you notice when something is off. When I told my dad I was moving a piece that wasn't there, he corrected me straight away without having to see the board. My move simply didn't fit the position in his head. The same happens when the LLM tells you it did something that doesn't fit your model of the codebase: it stands out. That's when you open the code and look.

I believe that this way of working is how the best software will get built in the near term: As these LLMs and their tools get better and better, those who can really tame these beasts and stay in control can move faster and smarter than ever before. Not limited to the speed at which one writes/reads the underlying code. Did you know the very best blindfolded chess players can play many chess games at once?