Rendered at 20:34:09 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
simonw 7 hours ago [-]
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.
andai 5 hours ago [-]
>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.
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.
youre-wrong3 27 minutes ago [-]
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.
simonw 4 hours ago [-]
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.
NameError 7 hours ago [-]
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.
danielovichdk 6 hours ago [-]
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.
lelanthran 5 hours ago [-]
> You learn a lot more by reading code than writing it.
"You learn a lot more by reading trigonometry than by doing problems"
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.)
lelanthran 14 minutes ago [-]
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.
DoctorOetker 5 hours ago [-]
I can find a kernel of truth in both statements:
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.
bwfan123 5 hours ago [-]
> See how ridiculous that sounds?
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.
dgellow 4 hours ago [-]
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
bwfan123 3 hours ago [-]
> 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.
throwawee 6 hours ago [-]
> You learn a lot more by reading code than writing it.
Really? In my experience it's been the opposite. It's like how you can learn more about art by trying to recreate it than just looking.
DoctorOetker 5 hours ago [-]
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.
vunderba 6 hours ago [-]
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).
relativeadv 6 hours ago [-]
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.
vunderba 6 hours ago [-]
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.
trollbridge 6 hours ago [-]
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.
circuit10 3 hours ago [-]
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
shakna 6 hours ago [-]
Floating point matrix calculations are non-deterministic. You need to invent new hardware, that doesn't use floating point math, first. [0]
Floating point math is entirely deterministic. For a given set of inputs, the same outputs come out, every time.
mrob 5 hours ago [-]
>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.
feelamee 5 hours ago [-]
using which floating point standard?
IEEE754 is totally deterministic
Folcon 6 hours ago [-]
> You can 100% predict where the weights “will take you” given a set of inputs.
Do you mean reproduce?
Sorry it's just if you are saying what your statement implying then either the model is very simple, or you've figured out something incredible
trollbridge 1 hours ago [-]
Sure. Take the inputs and run it through the model.
You now have the output which will be perfectly reproduced with the same inputs.
simonw 6 hours ago [-]
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.
trollbridge 1 hours ago [-]
I could use my brain to run a set weights, given enough time (on the order of millions of years).
simonw 5 hours ago [-]
Can you provide steps to reproduce so I can see one of these deterministic LLMs running myself? API based or local models.
trollbridge 1 hours ago [-]
I’d recommend starting with llamafile due to its simplicity and then move up to llamacpp and Unsloth.
andai 5 hours ago [-]
Could you give some examples?
techpression 6 hours ago [-]
You should publish, likely a Nobel price or Turing award waiting, and generational wealth at some tech giant.
qbane 5 hours ago [-]
I do not think the metaphor can go very far. Have blindfolded chess become the "productivity trend" that every one should learn it to enjoy chess? Have normal chess players been replaced because skilled players can do blindfolded?
3 hours ago [-]
dzonga 2 hours ago [-]
it's a Sunday - I don't have time to put things into buckets.
there's coding - writing code to do something could be a game, utility to move files around. what have you. inherently the nature is a closed domain. AI is perfect here - the impact if something goes wrong is close to 0 or null.
then there's software engineering - which is both an art & science. u r dealing with rules of thumb. nothing is ever coded / written down. but a feel to whether something feels right or not. the domain is unbounded. the impact of something going wrong is catastrophic in all dimensions. coding is a delivery mechanism for software engineering. but not the actual work. using A.I here is useless.
but we keep having these pieces - I guess that's just shallow the industry is.
yipinwong 6 hours ago [-]
Analogies work at an abstraction, and gotta take the chess analogy at its face value, as deeper people go into what's different between the chess and real life (deterministic vs non-deministic), one is not getting the lesson the author is presenting.
Remember, analogy is not territory. Every analogies fail at some point
tikimcfee 6 hours ago [-]
I really like this idea, because I think people forgetting that when you are writing code there exist a time T greater than zero, where you're not actually writing code and you're doing this thing called "thinking", ha ha. I find that there's a lot of times where I'm sitting staring at the screen and the lines of text sort of blur, and I'm in my head thinking about the connection of everything and not really worried about the actual implementation and how bites are moving, but wondering about the structure and the nature of the actual flow of the code. There's a wonderful XKCD about this, where a person sitting on a computer has this very beautiful stack of thoughts and clouds about what's being written, and then someone walks up to them and says something, and the entire cloud pops. If I understand this article, I think that's exactly a reasonable analogy to it. There is something that happens in the mind, and perhaps a neural weights, where the non-execution is where creativity and problem solving happening by mapping to the higher level concepts and stitching them together without having to specifically worry about the line level details. They still crop up, and implementation will probably always be king, But I do think I agree with this entirely!
yellow_lead 5 hours ago [-]
Is there anything new in this article? Yes, experts use AI better than non-experts for tasks in their domain. See LLMs reward expertise [1] and Terrance Taos conversation with LLM [2].
I think the need for expertise is also going away. For example, when Claude made progress on the Riemann conjecture,
> Jarred's input was mostly limited to sending Claude messages of encouragement (mostly variants of “keep going” or “believe in yourself”).2 This seems to have helped Claude overcome some initial skepticism that it could make meaningful progress.
We're on the border of fully outsourcing expertise.
yellow_lead 5 hours ago [-]
> Two mathematicians at Anthropic studied and validated Claude’s paper, and produced an informal note for experts stating Claude’s proof concisely.
No, experts are still needed
a2ff6eeb0 5 hours ago [-]
Yes, that's why we're on the border: AI is doing its thing without us, but we're not yet confident enough to let the AI do its thing without checking.
You may notice that humans only checked the work and explained. You may also see that that the person prompting the AI, Jared of bun.js fame, is not a noted expert in mathematics.
_diyar 4 hours ago [-]
The analogy can be dragged one step further: once the engine is good enough, it’s functionally impractical for a human to play.
dimitarbogdanov 3 hours ago [-]
I disagree. A chess engine has a very well defined goal and is working its patterns to reach that goal.
In software development, except in a minority of cases, the goal is being set by non-technical people, who have no clue how the resulting system should end up, only what it should look like to a user. I think a well-versed programmer can give the AI direct instructions on how to implement something, and just let the LLM write the code to implement/refactor the infrastructure behind the feature they're developing. For me the plan mode of Claude Code is (anecdote incoming) much faster(TM) and better(TM) if I give it concrete instructions - then it writes the plan, asks questions - and then implements it. Very little complaints after that (I usually don't let Claude do any sort of visual QA)
a2ff6eeb0 5 hours ago [-]
This makes no sense. The skills needed for AI coding are the same skills needed to hire Gary Kasparov to play chess.
Tell them where the game is and stand back as they play.
lordnacho 6 hours ago [-]
I think I agree. I guess I don't know enough about chess to be sure, but the idea seems to be that although to novices a blindfolded player must reconstruct the board in his mind, that is not actually what is done by the expert.
That is something I can agree with, having spent a heck of a long time coding in the trading domain.
I've managed to vibe code a trading system. It's a hobby project directed on my phone on my commute, but it does do all the things I find important about trading systems. I can connect to external exchanges and see that I have sent valid orders, I get fills, and I can see debug logs of the timestamps. It doesn't allocate memory on the hot path, cores can be pinned, and so on. There are benchmarks that say how fast the code is parsing messages. It works.
So I've somehow built a thing that I've barely examined in the traditional sense, which nonetheless satisfies certain business needs for this hobby project.
How could that be? If you transported me back two years, I would know exactly where to make whatever changes you desired. I had the IDE open all the time, and I knew where things were. Now, I don't even know what the internal structure is like, I just know whether consideration has been made for some aspect of the system.
And I think this is what seems so baffling to a lot of people. How are software developers getting such different experiences with LLMs? Some people genuinely are producing things with incredible pace, while others find the AI just produces slop for them.
Some people are ready for the blindfold, but many are not. It's incredibly frustrating, especially if you are reasonably advanced but not yet at that overview stage.
2 hours ago [-]
dumbfounder 6 hours ago [-]
Meh. Chess exists to entertain the players. Coding exists to solve problems. I see way too often the programmers think it’s all about the coder and the code. Solve the problem. Don’t write code at all to do that if you can (AI generated or otherwise).
andai 5 hours ago [-]
Yeah, it's about incentives. Software development is about solving business problems, but sometimes the solution is "use this thing that already exists instead of paying me to build it."
Similarly, the incentive is to design it so you will need to spend 10 years working on it, instead of 10 hours.
Supermancho 6 hours ago [-]
Once you get past trivial problems, the issue is not just "solving the problem" but proving the solution "solves the problem".
This is the strongest argument as to why AI should only be used as small solvers (at this point).
F7F7F7 5 hours ago [-]
This article reads like it was written by prompting AI for connections between two loosely connected things.
brazukadev 4 hours ago [-]
No, this article does not look like it was written by prompting AI just because you didn't like it.
mikeaskew4 6 hours ago [-]
My dad just had a computer around and looked the other way when I spent all night on it. And I learned chess on my own.
This may not be the argument Mike makes here, I have always felt that seeing the board and not knowing what it means is more valuable than knowing everything about it without seeing it.
If you’re drowning, who do you want to save you, the lifeguard who can’t read or the author of the book on water lifesaving techniques who can’t swim?
TZubiri 5 hours ago [-]
Au contraire, playing blindfold is removing a tool, depending on nothing but your mind.
Vibe coding is the opposite, not just depending on the chessboard, but depending on a couple of Gflops to even think.
Blindfolded programming would be the programming we do in the shower
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.
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.
( See the Forgetting Curves https://en.wikipedia.org/wiki/Hermann_Ebbinghaus )
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.
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.
| 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.
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.
"You learn a lot more by reading trigonometry than by doing problems"
See how ridiculous that sounds?
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.)
If reality differs from the results of academic studies, it's not the reality that is wrong.
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.
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
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.
Really? In my experience it's been the opposite. It's like how you can learn more about art by trying to recreate it than just looking.
> 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).
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.
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.
You can 100% predict where the weights “will take you” given a set of inputs.
[0] https://arxiv.org/html/2506.09501
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.
Do you mean reproduce?
Sorry it's just if you are saying what your statement implying then either the model is very simple, or you've figured out something incredible
You now have the output which will be perfectly reproduced with the same inputs.
there's coding - writing code to do something could be a game, utility to move files around. what have you. inherently the nature is a closed domain. AI is perfect here - the impact if something goes wrong is close to 0 or null.
then there's software engineering - which is both an art & science. u r dealing with rules of thumb. nothing is ever coded / written down. but a feel to whether something feels right or not. the domain is unbounded. the impact of something going wrong is catastrophic in all dimensions. coding is a delivery mechanism for software engineering. but not the actual work. using A.I here is useless.
but we keep having these pieces - I guess that's just shallow the industry is.
Remember, analogy is not territory. Every analogies fail at some point
[1] https://www.seangoedecke.com/llms-reward-expertise/
[2] https://chatgpt.com/share/6a5fdc7a-d6f8-83e8-bbea-8deb42cfed...
> Jarred's input was mostly limited to sending Claude messages of encouragement (mostly variants of “keep going” or “believe in yourself”).2 This seems to have helped Claude overcome some initial skepticism that it could make meaningful progress.
https://www.anthropic.com/research/riemann-zeta
The full transcript is here: https://www-cdn.anthropic.com/8a0d1add3c637b858a9a181e98c40e...
We're on the border of fully outsourcing expertise.
No, experts are still needed
You may notice that humans only checked the work and explained. You may also see that that the person prompting the AI, Jared of bun.js fame, is not a noted expert in mathematics.
In software development, except in a minority of cases, the goal is being set by non-technical people, who have no clue how the resulting system should end up, only what it should look like to a user. I think a well-versed programmer can give the AI direct instructions on how to implement something, and just let the LLM write the code to implement/refactor the infrastructure behind the feature they're developing. For me the plan mode of Claude Code is (anecdote incoming) much faster(TM) and better(TM) if I give it concrete instructions - then it writes the plan, asks questions - and then implements it. Very little complaints after that (I usually don't let Claude do any sort of visual QA)
Tell them where the game is and stand back as they play.
That is something I can agree with, having spent a heck of a long time coding in the trading domain.
I've managed to vibe code a trading system. It's a hobby project directed on my phone on my commute, but it does do all the things I find important about trading systems. I can connect to external exchanges and see that I have sent valid orders, I get fills, and I can see debug logs of the timestamps. It doesn't allocate memory on the hot path, cores can be pinned, and so on. There are benchmarks that say how fast the code is parsing messages. It works.
So I've somehow built a thing that I've barely examined in the traditional sense, which nonetheless satisfies certain business needs for this hobby project.
How could that be? If you transported me back two years, I would know exactly where to make whatever changes you desired. I had the IDE open all the time, and I knew where things were. Now, I don't even know what the internal structure is like, I just know whether consideration has been made for some aspect of the system.
And I think this is what seems so baffling to a lot of people. How are software developers getting such different experiences with LLMs? Some people genuinely are producing things with incredible pace, while others find the AI just produces slop for them.
Some people are ready for the blindfold, but many are not. It's incredibly frustrating, especially if you are reasonably advanced but not yet at that overview stage.
Similarly, the incentive is to design it so you will need to spend 10 years working on it, instead of 10 hours.
This is the strongest argument as to why AI should only be used as small solvers (at this point).
This may not be the argument Mike makes here, I have always felt that seeing the board and not knowing what it means is more valuable than knowing everything about it without seeing it.
If you’re drowning, who do you want to save you, the lifeguard who can’t read or the author of the book on water lifesaving techniques who can’t swim?
Vibe coding is the opposite, not just depending on the chessboard, but depending on a couple of Gflops to even think.
Blindfolded programming would be the programming we do in the shower