Rubber duck debugging. But the duck talks back. Your rubber duck now has Claude and opinions. Duck Duck Duck listens in on your coding sessions, understands what's happening, and responds. Robot optional. - Speaks when Claude runs, fails, or hesitates - Reacts physically (yes, really) - Lets you approve actions with your voice - Occasionally questions your decisions Limitation of liability: We are not responsible for any emotional damage caused by the duck's opinions of your variable names.
So you let your Macbook send you notifications... and then you are on zoom, or sharing your screen and blow you up... so you shut that stuff down.
Then, you use claude code. You send it off to do some stuff, then you go to another app, or you start hitting things on your desk with a hammer thinking everything is just fine. 30 minutes later you realize that 29 minutes ago claude got stuck waiting for your permission.
Some people build robots to help clean your house, or to solve public transportation, or more ambitiously to improve a single desktop notification problem. Such as DuckDuckDuck. It has a servo. It has opinions. It has a backstory it refuses to share.
the physical reaction angle is the most interesting bit. almost all developer tooling assumes your only feedback channel is the screen. having something in your physical space that reacts when claude runs or fails creates an ambient signal you can notice with peripheral attention instead of actively watching a terminal. it's a different mode of awareness entirely.
the 'opinionated' framing is doing more work than it looks. classic rubber duck debugging is you explaining the problem to something that doesn't respond. adding opinions, especially on your variable names and decisions, shifts it closer to a passive code reviewer than a debugging aid. that's a different value proposition and probably a different use case.
The physical reaction part makes it unique, I was wondering does it have specific physical reactions when you ignore it's suggestions.
Jenna Fizel