That thing where you keep asking for more until it breaks, that happens because of how awful the code is that Claude writes (and it is _really_ awful). When trying to build projects I find myself continually fighting with Claude to get it to avoid certain patterns.
The biggest of all is that Claude absolutely hates writing fail-fast code and by default goes to extraordinary lengths to hide failures and bugs in hopes you don't notice them. Every CLAUDE.md file I write is prefaced by 5-10 examples of fail-fast code, showing what not to do and what to do.
Despite this, my relationship with Claude feels ridiculously adversarial. It definitely seems like it's continually testing the waters to see what it can get away with and not at all like it's trying it's best to follow style guidelines in spirit.
That said, sometimes when it writes something particularly awful, I've noticed I can just highlight a section of code and say "clean this up" and it actually does a decent job, so maybe I should try the Ralph Wiggum technique more
As an example, here I was asking it to add some features to RoundingSat. I encountered a bug and asked it to print some debugging info. Then later, as soon as it had an excuse to touch that section of code, it attempted to delete the debugging info and replace it with a BS "fix": https://x.com/i/status/2005378022044795222
This happens constantly to the point where even without understanding the code, I can now recognize, if there's a conditional statement being added, an assertion being deleted or a log line being deleted, it knows it doesn't have a fix, it's just hoping it can hide the bug somewhere I won't notice it.
The only reason this does not annoy me is that Gemini is much, much worse. It writes Python code like the main purpose is to keep the program running at all cost, so every possible place where bugs can nest or contracts can be broken must be silently swallowed by exceptions.
This really helpfully characterizes my problem, thanks for the concept. There's a compounding effect there, because AI agents code best with tiny feedback loops, and its additions tend to lengthen those loops.
It sounds like you are using it way outside of its training distribution. PyTorch pipeline for deep learning: excellent. Summary of a pile of messy documents: great. Anything involving logic or discrete mathematics or other areas where tiny changes massively change the outcome: watch it like a hawk.
Not in my experience. Usually significant bugs can stay undiscovered until someone is benchmaxxing and really needs to eke out that last 0.1% of performance so looks at the code in detail. The models do fine with a bunch of inactive neurons, misclassified data, off-by-one errors, and so on. But flip a bit in a CNF solution and usually there goes satisfiability. Maybe this isn't a fair comparison, and I should be comparing with messing around with the heuristics of a SAT solver.
"However I also think that there is no contradiction between ‘recursive self-improvement is super dangerous and likely to get us all killed’ and ‘you should be taking full advantage of Claude Code for practical purposes and you’re leaving a lot on the table if you don’t.’"
I'm actually curious why there isn't a contradiction. Whenever I mention to people who know I'm a doomer that I use AI a lot, they think I'm in a contradiction as well. I can't shake the feeling myself that it is one, either.
Each time you use an AI heavily, some bits of information are returning to the AI lab and used as part of calculating various vectors for RL that infinitesimally make the product better. Your payments for subscriptions and tokens contain profits past your actual usage and lumped together with millions of other people justify to VCs the valuation on the next series.
Your marginal contribution to "doom" is 1 part in millions though, while your marginal benefits are 30-3000 percent more personal productivity and answers to many questions.
So that's why. Like sheep overgrazing a common pasture.
You write that there is no contradiction inherent in having enthusiasm for technology that is, in the limit, likely very destructive. I do not disagree. There is, however, an obvious tension. I'd really appreciate a post that collects your thoughts on the best way to navigate that tension.
>Cowork is available as a research preview for Claude Max subscribers in the macOS app
Oh no.
Research preview or not, when the target user base is 80-90% running Windows, usually you develop for that platform first to make sure it's always the 'first class citizen', with the most features, least bugs, most tested, you understand the use cases best etc. Your trial users should also be maximally similar to the final users.
I've made this mistake before, picking the "comfortable" development option over the one best suited to the users. It's like the classic drunk looking for his keys under the streetlamp, not because he dropped them there, but because that's where the light is.
You can just ask Claude "which OS should we target for our preview of an agent for non-coders eg. to create Excel spreadsheets", and it will tell you do to Windows first even if all your developers have macbooks.
I expect they will do that very soon, but keeping the beta test to the platform the devs use themselves is probably a good way to speed up the early development phase.
>There is a new method called the ‘Ralph Wiggum’ technique, where you tell Claude Code continuously to ‘improve the code’ it has already written. Some say it works great, but the name does not inspire confidence.
"Ralph Wiggums" does not work well for creative writing IMO—the first pass is a bit better, after 3+ the text will visibly start feedbacking to crap.
LLMs have trouble saying "no, this is fine" when the user wants a revision: they faff around and do pointless busywork (and inevitably "fix" something that isn't broken). Combined with their lack of taste you generally want to give them as few opportunities as possible to fall into their favorite cognitive basins.
I guess it works better with programming, and with very specific task requirements.
That thing where you keep asking for more until it breaks, that happens because of how awful the code is that Claude writes (and it is _really_ awful). When trying to build projects I find myself continually fighting with Claude to get it to avoid certain patterns.
The biggest of all is that Claude absolutely hates writing fail-fast code and by default goes to extraordinary lengths to hide failures and bugs in hopes you don't notice them. Every CLAUDE.md file I write is prefaced by 5-10 examples of fail-fast code, showing what not to do and what to do.
Despite this, my relationship with Claude feels ridiculously adversarial. It definitely seems like it's continually testing the waters to see what it can get away with and not at all like it's trying it's best to follow style guidelines in spirit.
That said, sometimes when it writes something particularly awful, I've noticed I can just highlight a section of code and say "clean this up" and it actually does a decent job, so maybe I should try the Ralph Wiggum technique more
As an example, here I was asking it to add some features to RoundingSat. I encountered a bug and asked it to print some debugging info. Then later, as soon as it had an excuse to touch that section of code, it attempted to delete the debugging info and replace it with a BS "fix": https://x.com/i/status/2005378022044795222
This happens constantly to the point where even without understanding the code, I can now recognize, if there's a conditional statement being added, an assertion being deleted or a log line being deleted, it knows it doesn't have a fix, it's just hoping it can hide the bug somewhere I won't notice it.
The only reason this does not annoy me is that Gemini is much, much worse. It writes Python code like the main purpose is to keep the program running at all cost, so every possible place where bugs can nest or contracts can be broken must be silently swallowed by exceptions.
This really helpfully characterizes my problem, thanks for the concept. There's a compounding effect there, because AI agents code best with tiny feedback loops, and its additions tend to lengthen those loops.
It sounds like you are using it way outside of its training distribution. PyTorch pipeline for deep learning: excellent. Summary of a pile of messy documents: great. Anything involving logic or discrete mathematics or other areas where tiny changes massively change the outcome: watch it like a hawk.
Isn't a deep learning PyTorch pipeline a thing where tiny changes massively change the outcome?
Not in my experience. Usually significant bugs can stay undiscovered until someone is benchmaxxing and really needs to eke out that last 0.1% of performance so looks at the code in detail. The models do fine with a bunch of inactive neurons, misclassified data, off-by-one errors, and so on. But flip a bit in a CNF solution and usually there goes satisfiability. Maybe this isn't a fair comparison, and I should be comparing with messing around with the heuristics of a SAT solver.
Podcast episode for this post:
https://open.substack.com/pub/dwatvpodcast/p/claude-coworks
"However I also think that there is no contradiction between ‘recursive self-improvement is super dangerous and likely to get us all killed’ and ‘you should be taking full advantage of Claude Code for practical purposes and you’re leaving a lot on the table if you don’t.’"
I'm actually curious why there isn't a contradiction. Whenever I mention to people who know I'm a doomer that I use AI a lot, they think I'm in a contradiction as well. I can't shake the feeling myself that it is one, either.
It's tragedy of the commons.
Each time you use an AI heavily, some bits of information are returning to the AI lab and used as part of calculating various vectors for RL that infinitesimally make the product better. Your payments for subscriptions and tokens contain profits past your actual usage and lumped together with millions of other people justify to VCs the valuation on the next series.
Your marginal contribution to "doom" is 1 part in millions though, while your marginal benefits are 30-3000 percent more personal productivity and answers to many questions.
So that's why. Like sheep overgrazing a common pasture.
The fact checker and alternative perspectives giver: I literally have it. https://www.unbubble.news
I don't understand the difference between Claude Coworks and the Claude Code tab of Claude Desktop for macOS. They are both user friendly Claude Code.
You write that there is no contradiction inherent in having enthusiasm for technology that is, in the limit, likely very destructive. I do not disagree. There is, however, an obvious tension. I'd really appreciate a post that collects your thoughts on the best way to navigate that tension.
>Cowork is available as a research preview for Claude Max subscribers in the macOS app
Oh no.
Research preview or not, when the target user base is 80-90% running Windows, usually you develop for that platform first to make sure it's always the 'first class citizen', with the most features, least bugs, most tested, you understand the use cases best etc. Your trial users should also be maximally similar to the final users.
I've made this mistake before, picking the "comfortable" development option over the one best suited to the users. It's like the classic drunk looking for his keys under the streetlamp, not because he dropped them there, but because that's where the light is.
You can just ask Claude "which OS should we target for our preview of an agent for non-coders eg. to create Excel spreadsheets", and it will tell you do to Windows first even if all your developers have macbooks.
I expect they will do that very soon, but keeping the beta test to the platform the devs use themselves is probably a good way to speed up the early development phase.
>There is a new method called the ‘Ralph Wiggum’ technique, where you tell Claude Code continuously to ‘improve the code’ it has already written. Some say it works great, but the name does not inspire confidence.
"Ralph Wiggums" does not work well for creative writing IMO—the first pass is a bit better, after 3+ the text will visibly start feedbacking to crap.
LLMs have trouble saying "no, this is fine" when the user wants a revision: they faff around and do pointless busywork (and inevitably "fix" something that isn't broken). Combined with their lack of taste you generally want to give them as few opportunities as possible to fall into their favorite cognitive basins.
I guess it works better with programming, and with very specific task requirements.
> Build systems, not one-off tasks.
What do you mean by this?