I literally just went through this yesterday. Had a few failing tests in an unfamiliar domain. Took a cursory look, couldn't figure it out. Pasted the error messages into Claude to see if it could speed things up for me. We went back and forth for a while, pulling on different threads and trying various things. In the end, it gave up and essentially relaxed the test's assertions to make it pass.

I wasn't happy with that outcome, so I decided to invest some time in debugging through the test, tracing the flow of data, looking at the state of the stack frames and finally figured out what was wrong -- the solution was so simple and so obvious that had I just given the effort up front, it would have saved me some time and tokens.

It's a valuable lesson to take to heart. I think it's better to go from tinkering and trying it out yourself, than to go straight to AI and then giving it a go independently.

That reminds me of why I don't think that if err != nil in Go is actually a problem, because while it's annoying to have to pause each time an error can happen, it's actually very useful, because it forces you to consider all the possible failure states and it often lets you discover the flaws in your original design while you're typing in the code. This eventually leads to much better outcomes and allows for the tools I write to be much more resilient than they otherwise would.

Obviously it all goes out of the window as soon as AI coding comes into question, and that's why I learned that I actually _don't_ want AI to generate code for me. I would only ask it simple questions like "how do I do X in Go" or in some other system, but the implementation I do myself, otherwise I lose this "having to consider every error path" part, which is apparently very helpful when your goal is to write resilient software

I don't think the goal is to reject these tools, but to be more intentional about when we use them

I’ve given these sorts of haystack search struggles completely over to the LLM. Whether it’s finding a bug in code or searching documentation for the answer, I view it as a near-obsolete skill. The past couple of decades it was important to know how to chase down documentation and zero in on the one line of config you were missing. Now it’s not.

I don’t view this as a hollowing out of my skill tree, I view it as freeing myself to focus on modern skills I need to develop. Such as learning how to steer LLM context windows towards maintainable solutions in large codebases.

I’m sure I’ll be thankful now and then that I know how to manually sift through stack traces for answers. But I expect those moments to be rarer and rarer. I basically never look at machine code, but I bet that used to be an important skill for programmers many decades ago.