I agree with your take, particularly because of this line in the article:
| the skills that define a strong blindfold chess player are the same as those of a programmer who can thrive behind a Claude Code terminal whilst not reading nor writing any code.
If you're actually not reviewing the outputs, you're just getting a fuzzy description of the state of the chessboard.
But I (and everyone I work with) use Claude Code in a workflow where I -do- review the outputs, or at least I make an honest effort to try. Rather than blindfolded, I think bullet (1-minute) chess is a fairly good analogy for this: you have all the info you need to keep your mental model up to date with reality, but the pace of change is too fast to do a good job unless you have a lot of preexisting chess expertise.
You learn a lot more by reading code than writing it.
So reading the output i believe is an immensely big gift by an LLM, because if you actually take note - and of course know your skills - then ot becomes such a great pal to work with.
I like reading what the LMM gives me, not always, but a lot of times.
a lot of people get stuck, or code up a naive brute force algorithm and call it a day, nothing intrinsically forces a coder that refuses to look at the work of others to write better code.
As long as the literature contains insights a reader isn't aware about, reading the literature is low-hanging fruit compared to having to derive all the things yourself.
As soon as the literature no longer contains insights, it becomes more productive to explore mathematics oneself by trial and error.
Organized education will model this on a topic by topic basis: during class you're handed the more valuable insights on a silver platter, during an exam you are prevented from looking at your textbook.
Every time you read a chapter and do the exercises it's a small simulacrum of catching low hanging fruit followed by making sure you can derive similar statements with trial and error for fixing any gaps. The trial and error while you do problems does improve your intuition, but only trial and error is like having every student redevelop the frontier starting from antiquity.
For most of us, writing code is the way to carve out intuition into an artifact. But, I have noticed some people are able to read deeply - and by that I mean, reverse the code to understand the intuition that brought it to life. This is a rare skill and I dont have it, but some do. Not just for code, but also for any book - fiction or non-fiction - some are able to deconstruct the scenarios much better than others, and in that sense understand what they read.
I feel one need to also have developed the intuition by writing lots of code for reading to be really effective.
An an analogy I’m reading a lot of German those days as I’m aiming to become fluent, and it’s very effective to improve only because I spend so much time developing a the intuition by going through the whole grammar, forcing myself to write, forcing myself to speak, etc. Doing only the reading improves your pattern recognition, but doesn’t make you go as deep as one who also writes and speak. If you combine the different aspects they reinforce each other and you progress way faster
> I feel one need to also have developed the intuition by writing lots of code for reading to be really effective.
This is one of the problems young engineers are going to face who rely excessively on AI to generate code. Their intuitions on what constitutes good code will not sharpen, since they are not exercising the tool that sharpens it which is writing code. Intuitions start fuzzy, and incorrect, and gradually sharpen with precise communication of said intuition in the form of writing code or proofs. Reading alone may delude one into a sense of false mastery where intuitions are actually fuzzy, but one thinks otherwise.
It's quite a surprising result: it turns out that there are cases where seeing someone else work through a worked example is more effective than struggling through the problem yourself.
(Obviously it doesn't apply universally, but your "see how ridiculous that sounds?" suggests to me you may not have heard of this before.)
As that link says, this approach is used in Maths textbooks, and yet, as the parent of two kids, I have never come across a single student who is able to pass trig without working the problems.
If reality differs from the results of academic studies, it's not the reality that is wrong.
| the skills that define a strong blindfold chess player are the same as those of a programmer who can thrive behind a Claude Code terminal whilst not reading nor writing any code.
If you're actually not reviewing the outputs, you're just getting a fuzzy description of the state of the chessboard.
But I (and everyone I work with) use Claude Code in a workflow where I -do- review the outputs, or at least I make an honest effort to try. Rather than blindfolded, I think bullet (1-minute) chess is a fairly good analogy for this: you have all the info you need to keep your mental model up to date with reality, but the pace of change is too fast to do a good job unless you have a lot of preexisting chess expertise.