[LatencyKills]

> But talking with an Llm isn’t teddy bear/rubber duck debugging because your llm has some high odds of outputting good feedback.

That isn't how we did it at either Microsoft or Apple. There, we defined it as walking another engineer through a problem. That person may or may not have been an expert in whatever I was working on at the time. You truly aren't suggesting that rubber duck debugging only works when you don't receive feedback?

I use Claude to bounce ideas around just like I did with my human teammates.

I think you're being pedantic, but it doesn't matter to me: in the end, I work must better when I can talk through a problem; Claude is a good stand-in when I don't have access to another human.

[righthand]

No I’m suggesting that RDD is not a mechanism to reason and solve your problem, but rather a mechanism to get your mind thinking into the problem solving state. It is asking you to physically repeat what is in your brain. The same as writing it out on a marker board or handwritten notes. Rubber duck debugging is about debugging you, not debugging the code. That’s why it doesn’t matter who you talk to about the problem in rubber duck debugging.

The part where your colleague or Llm returns more information or advice is past the rubber ducking state. Depending on the difficulty of the problem you may not need to ask a colleague to lead you to water. And if rubber duck debugging can be done solo, what is the actual process you get from it as non-relative to you coworker/code assistant?