rubber duck vibe

I was thinking recently about how I would classify my use of AI in my coding. I have been using AI for a while now, and I have found it to be a useful tool. It can be incredibly useful for writing contextual code, boilerplate, and refactoring. I would be perfectly happy never writing docstrings again - as long as methods and parameters have semi-intuitive names, AI can write a good enough docstring for me.

When it comes to writing new code, I find that it is a bit of a mixed bag when you already have an idea in mind. Sometimes you get a great result, beyond expectations, taking a different approach from what you would have written yourself, and very well suited to the problem. Usually, you get a result that is pretty healthy starting point, and you can iterate and flesh it out to get it to where you want it to be.

Other times, you get a result that is not quite right, and you have to decide where to spend your time… Do you refine the prompt and try again, fix the code, create a bootstrap to get it started or scrap it and do it yourself? Personally, I run the gamut of these options, depending on a variety of factors. I think that is a key to using AI effectively.

How should I classify my use of AI in coding? I don’t consider myself a “prompt engineer” nor do I consider myself a “vibe coder”. I guess in theory a “prompt engineer” or “prompt engineering” is more oriented toward getting non-code results, like writing a blog post or other creative endeavor, while a “vibe coder” or “vibe coding” is more oriented toward getting coding results. In my mind, I think of “vibe coding” as being a relatively non-technical approach using AI to get code results, without a lot of technical knowledge as to what is going on under the hood.

Then I thought about it a bit more, and I feel like “vibe coders” have to be picking up on the technical aspects of what’s going on under the hood. They have to be able to recognize when the AI is not doing what they want, and be able to refine the prompt to get it to do what they want. They need to be able to fix it. Being able to effectively explain the problem to an AI, and iterate on it to help you find the solution, or at least get you started on the right path, is a useful skill to have. The act of iterating and refining prompts is a technical skill - it reminded me of “rubber duck debugging”.

Most all developers have heard of “rubber duck debugging” or “rubberducking”, where you explain your code or problem to a rubber duck/inanimate object to help you find the solution. Sometimes, just explaining the problem out loud is enough to put you on the right track to finding the solution. Taking the time to step back and explain the problem can help you see the problem from a different perspective. Describe what you are trying to do, why you are trying to do it, what you have tried, what’s not working and what is working.

Sometimes while explaining the problem, you realize that you are trying to do something unnecessary, or that you are overcomplicating the problem or solution. Explaining the problem can help you see it from an outside perspective, redefine the problem in your mind, remember the details that you may have forgotten. Just gathering your thoughts enough to figure out how to explain it can help you reframe the problem in your mind, and see a different approach to the solution. It helps pull back focus from the details of the code to the problem you are trying to solve.

The concept of rubberducking is not new, the “Eureka Effect” has been recognized and researched for years. Focusing on a problem too long can lead to a mental block, and stepping away from the problem whether by explaining it to a rubber duck, taking a break, sleeping on it, or whatever it takes to clear your mind, can help you see the problem with fresh eyes. Maybe describing the problem to an AI will be the new take on the same concept.

I can see a “rubber duck vibe” being a good thing for all of us sometimes. For new code that I have some ideas for, but no plan, I sometimes find myself describing the idea or problem to an AI and let it generate things I hadn’t considered or things I know I don’t want, to help me settle the problem in my mind. Refining what I don’t want can help me understand what I do want.

I initially wanted to make this post about how describing the problem to an AI could be a new take on rubber duck debugging, and how that can help inexperienced programmers learn to code, by helping them clarify their thoughts and ideas. But, after writing this for a bit, I think it is more than that. “Take a step back, take a breath, explain the problem…” it’s something we should all do (unless there is no problem, then just relax) from time to time. It incredibly useful for new and experienced programmers alike, if you are stuck, take a break, explain the problem to your rubber duck, and come back to it later.

Actually, I think this is good tip for all of us in life, not just programmers. Maybe, a rubber duck vibe can help us all.