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.
> 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.
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?
> 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.
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.
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.
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.
RDD is using an external object, the rubber duck, as an external anchor from which to project sub/unconscious processing elements onto. Think about it. Your brain doesn't know the difference between imagining an interaction, and actually having the interaction. The passive duck, even as little more than a passive anchor to project mental faculties not currently employable without consciousness destabilization, still gets you into an "effective collaboratory mode" with yourself. Like have you ever tried and succeeded at RDD without the external focus? Tis' a pain in the ass. The addition of a model that isn't your brain* spitting out output just gets registered as just another message from somebody's brain matter, not yours. I am increasingly looking at generative coding with an LLM as having a substantive rewriting effect on expectations around how computers are capable of behaving. This isn't just transform hiding a pile of abstractions that our brains mirroring systems can accurately feed forward, giving us a sense of interoception and the ability to kinesthetically navigate and "feel" what we're doing with the machine or how the machine should behave given our inputs. It just does. It breaks the rules. We're helpless in the face of knowing or simulating what's next. This forces neurons to start to rewire. Rewiring and severing of old connections in times of great change, at least to me, comes with feelings indistinguishable from acute depression. Please don't ask how I know. It should, in theory, settle down given enough time to learn the quirks of a specific snapshot of a model, and probably flare up again after substantial changes to weights occur. Our brains, like it or not, are specifically designed to use anything outside themselves to "pour" subconscious faculties into.
Just started messing with these things, and it at least to me seems to resonate.
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.