[righthand]

But talking with an Llm isn’t teddy bear/rubber duck debugging because your llm has some high odds of outputting good feedback. Teddy bear/rubber duck debugging involves the other party not knowing anything about your problem let a lone even capable of giving a response (hence why it’s not go-ask-a-coworker/teacher/professional debugging). It’s about getting yourself to refocus the problem and state what you already know and allowing your brain to organize the facts.

I’m not trying to be rude but it seems like you’re conflating collaborative problem solving with rubber duck debugging. You haven’t actually collaborated with a rubber duck when you’re finished rubber duck debugging.

[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?

[nottorp]

> involves the other party not knowing anything about your problem let a lone even capable of giving a response

I prefer grabbing a colleague that is technical but does not work on this particular project. Seems to force me to organize the info in my head more than an actual rubber duck.

[righthand]

Sure no one likes being seen ranting at no one either. Rubber ducks can be pencils, dogs, hamsters, and teddy bears, even friendly Carroll in accounting too.

[salawat]

Rubber duck debugging is a null-llm offloading to your gray matter for the other half of interlocution. A fancy way of recruiting your other brain matter into the problem solving process. Perhaps by offloading to a non-null LLM, there is decreased activation/recruitment of brain regions in the problem solving process, leading to network pruning over time. Particularly in the event you take the position that the "tool" isn't something worthy of having it's inner state reacted to and modeled via mirror networks.

But what do I know man, I'm just a duck on the Internet. On the Internet, no one knows you're a duck.

Quack.

[righthand]

But the point is that as soon as you get feedback and a response you’re back in traditional reasoning, puzzle solving, teaching, learning, etc. paradigm. Not in the rubber duck debugging paradigm. RDD is clearly defined as different. The GP is just choosing to remove the elements that make it unique but keep the metaphorical branding. Even bots responding is not RDD. Rubber ducks can’t respond or understand.

You don’t send kids to Rubber Duck Debugging Class (you send them to School) because you can’t see the teacher in the classroom while you’re at work.

You’re debugging yourself, not the actual problem per say.