3 ms·

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

by simonw 1mo 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.

NameError 1mo 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 1mo 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.
  - throwawee 1mo 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 1mo 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.
  - lelanthran 1mo ago
    > You learn a lot more by reading code than writing it. "You learn a lot more by reading trigonometry than by doing problems" See how ridiculous that sounds?
    - DoctorOetker 1mo 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 1mo 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.
vunderba 1mo 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 1mo 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 1mo 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 1mo 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.
- Folcon 1mo 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 1mo 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.
- techpression 1mo ago
  You should publish, likely a Nobel price or Turing award waiting, and generational wealth at some tech giant.
- simonw 1mo 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 1mo ago
    I could use my brain to run a set weights, given enough time (on the order of millions of years).
- shakna 1mo ago
andai 1mo 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. ( See the Forgetting Curves https://en.wikipedia.org/wiki/Hermann_Ebbinghaus https://en.wikipedia.org/wiki/Hermann_Ebbinghaus )
- simonw 1mo 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.
  - thec0d3 1mo ago
    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
    - names_are_hard 1mo ago
      This is either incredibly advanced, genius-level insight into the future of software engineering, or absolutely nonsensical gibberish. I'm not smart enough to tell which, I suppose we'll find out.
deleted 1mo ago
[deleted]

by simonw 1mo ago

NameError 1mo 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 1mo 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.
- throwawee 1mo 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 1mo 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.
- lelanthran 1mo ago
  > You learn a lot more by reading code than writing it. "You learn a lot more by reading trigonometry than by doing problems" See how ridiculous that sounds?
  - DoctorOetker 1mo 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 1mo 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.

vunderba 1mo 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 1mo 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 1mo 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 1mo 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.

Folcon 1mo 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 1mo 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.
techpression 1mo ago
You should publish, likely a Nobel price or Turing award waiting, and generational wealth at some tech giant.
simonw 1mo 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 1mo ago
  I could use my brain to run a set weights, given enough time (on the order of millions of years).
shakna 1mo ago

andai 1mo 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. ( See the Forgetting Curves https://en.wikipedia.org/wiki/Hermann_Ebbinghaus https://en.wikipedia.org/wiki/Hermann_Ebbinghaus )

simonw 1mo 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.
- thec0d3 1mo ago
  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
  - names_are_hard 1mo ago
    This is either incredibly advanced, genius-level insight into the future of software engineering, or absolutely nonsensical gibberish. I'm not smart enough to tell which, I suppose we'll find out.

deleted 1mo ago

[deleted]