Debugging Intuition: C

### Style fanciness (by default): D I described the project as vanilla Python, and I mostly want to keep it that way. Claude on the other hand enjoys using the full range of language constructs available. The most striking example was when I realized that where I would just make a function call, Claude would sometimes spawn a subprocess and make a function call within that, for no good reason that I could see. This led me to write style guides that I have Claude re-read every so often (see Instruction Following below). ### Robustness over correctness: D I suspect that Claude Code was quite literally trained (fine-tuned?) not to write code that crashes. Since my overall system largely runs in batch mode most of the time with me as operator, I don’t care much about uptime, but care intensely about correctness. Subtle silent bugs are killers. If something has gone wrong I want the code to fail with an informative fatal error. Claude, on the other hand, wants to write code like this: … Claude lacks this intuition (which of course leads to the question why I have the expectation that Claude should have reasonable intuitions, or any intuitions at all. It’s because it is so competent otherwise!). But I’ve had the experience of having Claude write and modify web-crawling code, and respond to a newly-broken crawler with a theory that 1000 different independent webservers have simultaneously been reconfigured to return HTTP 500 errors in response to all requests. Or respond to newly-broken code that determines directory paths for file lookup by guessing that someone has maliciously deleted all the files since the last run. … Server: “Excellent choice!” Where Claude fails is not in willingness to following instructions, but in remembering what they were, and sticking to them. Whenever I start a new session Claude is asked to re-read a style guide that tells it not to multiprocess unnecessarily, avoid cascading fallbacks, only put import statements at the top of code files, don’t explicitly catch signals like cntrl-c – a long list of prescriptions that are a mix of basic Python style and my own idiosyncratic desires for how the project should be structured and coded. … ### Machine Learning Methodology: A Claude has clearly seen enough ML projects to have a well-developed sense of all the methodological pitfalls: feature sparsity, overfitting, data leakage, and so on. If you are working on an AI or ML project it’s definitely worth just asking Claude to spin through your codebase not just to find code bugs but also to audit your ML code for soundness.