I'm not completely convinced by this comparison between blind chess and prompting LLMs.
In blind chess you get deterministic information about the state of the board: each mental update to your board model can be precise, and you have the full state at every point in time.
LLMs are notoriously non-deterministic, and even at temperature zero you still can't predict exactly where the weights will take you next.
I suppose you can get closer to deterministic if you adopt a prompting style where you almost dictate every line of code, but at that point the coding agent is more of a typing assistant.
The productivity benefits of coding agents unlock themselves when you figure out how to turn short prompts - "add tests that exercise the registration form and check the happy path and all failure states" - into larger changes.
If you're completely blind to the results of those you're going to end up with a system you don't 100% understand very quickly. In blind chess terms you'll no longer know the positions of every piece on the board.
>you're going to end up with a system you don't 100% understand very quickly
This has been my experience with all software projects. Even if I wrote all the code, my understanding of how everything works and fits together decays.
Yeah, that's a fair point. I have plenty of older projects where I no longer understand how they work despite having written the code myself.
I guess the key thing is that you need to be able to demonstrate to yourself that you understand the code at least once, because that means you should be able to revise how it works in the future.
You also can't evaluate if a solution is fit for purpose if you don't understand it.
You don't buy the article's position but have forgotten a lot and not known a lot; so no need to care about your opinion I guess
This is my beef with modern software engineers; complete detachment from physical reality where entropy is eroding structure (memory, generational churn).
Code is just a euphemism for a desired electrical state. No need to dump biz contexts in code. Just make a game engine that efficiently handles geometry on screen and label the presentation layer.
All ya'll are doing is recreating front end rendering technology, forgetting in time and recreating it in new semantics. It's absolutely fucking asinine.
I look forward to models in chips and a tiny universal code base coupled to the machine.
This whole allowing a bunch of unelected rhetoricians tell myself and other hardware engineers we need them to use our property is exhausting.
It's rhetorical nonsense that goes in these broad loops recreating old work.
Time to move on from what titillated you all as children. Or you will just end up entitled Boomers.
Writing code like its 1970s is not high tech. It's old low tech
While that may be true, you can be confident that it works in a way you personally understand. Because you understood it in the past.
Also, if you finish your work on a module with care - you return to a module you can trust with clear boundraries and known flaws. This is not true of AI output.
No. You can absolutely build things with AI small or large and understand it. If you don’t understand it. Then you’re not caring about the output to begin with and not guiding it to build the solution you want.
The word "understand" seems to mean something different to you.
If I understand something, I could write it in assembly if I wanted to. It might take a long time, but I know every level of the stack under my code down to bare metal.
Maybe an AI level of "understand" i.e the same understanding a Senior has of a Junior's code based on daily check-ins is enough for 95% of "boring" programming. But for some tasks you need to either fully understand the code or just tolerate bugs.
At the level of complexity I work at, it's (often) faster to just code it myself than to expect AI to converge on a result I like and then hand check it.
Look, goals can differ. If you don't need to understand and predict every part of the code the AI is generating and you just need it to meet a "sketch" of what you want - by all means use AI. I do use AI in that situation for related or unimportant code.
But if you need full understanding, in my experience the only way to get that is to program it yourself. Unless what the AI is generating is so trivial you already understand it and it's grunt work, you will learn the detail by doing it yourself. Controlling the approach here is important.
However often the best way to handle grunt work is to write better abstractions, something AI sucks at.
It's the programming equivalent of many PG essays. https://www.paulgraham.com/useful.html for instance. There was one on how PG refined their thoughts via writing. It's in there somewhere.
> At the level of complexity I work at, it's (often) faster to just code it myself than to expect AI to converge on a result I like and then hand check it.
Would love an example because no one has ever been able to give a coding example that AI isn’t helpful for. I had one person on linked in try claim their undocumented audio hardware won’t work with ai but when we got ai to probe it and build docs it ended up solving a bunch of complex bugs they couldn’t fix.
Impressive, also horrifying. I love what I do and if AI can do it better than that sucks.
Anyway the use case for me is to realize a new visual style through graphics programming. It's a lot less measurable for an interative AI agent than "Meet this hardware specification from a device with a discoverable API"
I have no doubt AI could create a LOT of variations on "a new visual style" but it's less controllable than just doing it yourself.
Btw, did you "understand" the sound driver after the AI coded it? Could you modify it without further help?
I'm skeptical of this. I have yet to build a codebase using AI that I wasn't able to subsequently understand after taking the time to do so, esp. when aided by AI that will tirelessly answer my questions. I mean, LLMs don't always code the exact way I do, but it's not writing totally alien code that's incomprehensible to the human mind here.
I use Claude Code, primarily writing web applications and JavaScript. I'll have it use various frameworks. It's built apps for me using React, Ember, Astro, etc. I don't restrict myself to frameworks I'm particularly familiar with, since it's easy for the AI to teach me the basics whenever I would like to dig in.
As for specific practices, these are my main ones:
- I have a gotchas-log.md file that acts as a log of gotchas likely to trip up future runs. I have the AI write to this occasionally when things go haywire in the same way multiple times. And I have it read it as part of its iterative reviews, described below.
- I have a good-code-guidelines.md file where I write my preferences for code. I have the AI read this as part of iterative reviews, described below.
- I have a plan-and-execute.md file that prompts the LLM to make a plan, and then to review and iterate on that plan repeatedly (while reading gotchas-log.md and
good-code-guidelines.md) until its reviews stop finding issues. I tag this file to implement almost every non-trivial change.
- I have other various helper prompts. For example, I can simply tag @make-a-git-commit.md and it tells the LLM to make a commit and write the message the way I like it. I have @simplify.md, which I can tag to have the LLM explain whatever it just did to me using simple language that makes it easier for me to understand, and using concentric circles of explanation that go from broad to specific so I'll repeatedly encounter important topics; this makes it much more bearable for me to read its responses.
- Occasionally, whenever a particular system of my codebase starts to get hairy, I spawn a Claude Code session to read through and trace all the relevant code paths, then write a short guide to that system in a markdown file that lives in the codebase. IT's useful for me to read and also useful to tag for future prompts to get the LLM up to speed quickly. Only challenge here is that these guides go stale and require updating, so it's important to prompt the AI to write them at the appropriate level (not to specific) that prevents them from being overly brittle and getting out of date with every little change. They're mostly high-level guides.
> Even if I wrote all the code, my understanding of how everything works and fits together decays.
Some understanding decays, but in my experience it never fully decays to the point of never having known how it worked.
My code from 3 years ago is more foreign to me than code I wrote yesterday, but if I need to I'll get back up to speed on it much quicker than I will on code someone else wrote that I never understood.
Even with the decay of time, remnants of the experience persist, roughly in the same way that if you get in really good shape and then allow yourself to fall out of shape, getting back into shape is difficult, but not as hard as it was the first time. Your nervous system has made adaptations the first time through that make running it back much easier even if you've let years pass.
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.
IMHO the thrust of the article feels a bit forced, but LLM = Blindfold chess is not what the author is saying:
> Thus in many ways programming with AI is the opposite of blindfold chess: you don't have to pay attention every turn, you don't have to remember what the important pieces are, the details of the tactical relationships (such as code interfaces and APIs).
That sentence was awkward. Maybe even a typo? The following sentences to the one you just quoted ignores that and proceeds to argue FOR blindfolded chess being like programming with LLMs.
The article itself takes several paragraphs to get to the argument it wants to make and then ends having only argued for a few more sentences. No real evidence is provided either.
Well no, it argues that the SKILLS for playing blindfold chess are similar to people who use LLMs to develop code - not that blindfold chess = vibe coding.
And then earlier in the article defines said skills as having a sense of high-level relationships (chunking, positioning, etc) over the board rather than a photographic memory of the board.
But as I said, the whole article feels very fluffy anyway.
LLMs are notoriously non-deterministic, and even at temperature zero you still can't predict exactly where the weights will take you next.
An LLM can be made to be completely deterministic. I use them in this mode so I can reproduce test cases. Of course it requires complete control over the model, etc. but this myth that a computer program is non-deterministic needs to end.
You can 100% predict where the weights “will take you” given a set of inputs.
By "can't predict exactly where the weights will take you next" I meant with your brain. The blind chess analogy suggests you can predict, using your own thought process, the exact output of a prompt.
>Floating point matrix calculations are non-deterministic.
This is not inherent to floating-point math. That actual (true) claim in the article is that different hardware and different hardware configurations produce different results. But deterministic inference is possible, e.g. llama.cpp on CPU is deterministic by default.
The software standard is. GPU matrix calculations, are not. The hardware, has tiny shifts that rarely matter, except in high finance and... AI modeling.
I think when people say non-deterministic what they mean is closer to chaotic, like https://en.wikipedia.org/wiki/Chaos_theory as in very small changes in conditions can produce completely different output making predictions difficult
In blind chess you get deterministic information about the state of the board: each mental update to your board model can be precise, and you have the full state at every point in time.
LLMs are notoriously non-deterministic, and even at temperature zero you still can't predict exactly where the weights will take you next.
I suppose you can get closer to deterministic if you adopt a prompting style where you almost dictate every line of code, but at that point the coding agent is more of a typing assistant.
The productivity benefits of coding agents unlock themselves when you figure out how to turn short prompts - "add tests that exercise the registration form and check the happy path and all failure states" - into larger changes.
If you're completely blind to the results of those you're going to end up with a system you don't 100% understand very quickly. In blind chess terms you'll no longer know the positions of every piece on the board.