This is the strongest argument as to why AI should only be used as small solvers (at this point).
Similarly, the incentive is to design it so you will need to spend 10 years working on it, instead of 10 hours.
Remember, analogy is not territory. Every analogies fail at some point
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.
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?
[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
Tell them where the game is and stand back as they play.
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.
| 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.
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.
"You learn a lot more by reading trigonometry than by doing problems"
See how ridiculous that sounds?
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.
> 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.
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
[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.
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 )