Let’s talk about nil pointer checks in Go. You want to prevent panics in production, but that doesn’t start with a deferred recover. It starts with defensive programming. Check your inputs, check your bounds, and check pointers for nil before dereferencing them. I’ve started to see more nil checks in Go code. In the right place, they are necessary for writing safe code. In the wrong place, they are a sign that the code has stopped being clear about what can and cannot be nil. I have noticed this pattern more in generated code, but this symptom is not new and is not limited to AI.