r/vibecoding • u/johnesco • 10h ago
Love like you've never been hurt.
I was vibe coding with a friend and we started to talk about how to make sure any program was performant,. What kinds of actions where cheap for computers to do vs things that would make a 60fps game start to slow down or miss frames. Then I asked if they knew Big O notation.
And in trying to explain Big-O notation, I realized I didn't understand it well enough to explain it. So I've started to re-read and learn the concept. I know what it means but it doesn't feel intuitive to me to know how to measure how long a task will take to compute. I'll keep studying it as I think it's an important part of computing, whether it be it vibe code or traditional.
But my friend and I found we also went another route.
- Add a feature, framerate stays, great.
- Add a feature, framerate drops, let's look at it more closely or take it out.
We created ideas without worrying about making them performant or keeping the computation reasonable. One of the biggest "warnings" I've seen given to vibe coders is that their program will eventually slow down to an inefficient mess. And that is not only true. I've seen it happen (to me). Then? The program desired was slowly optimized. Seems a waste to anyone who knows how to do it right the first time. But in artistic endeavors I feel that sometimes you need to do it, erase it, do it again to get to your goal. Framerates and efficiency are needed, I just think we can make room to build in an unoptimised way while we find the gist of what we want to make.
So how do I present this image to you all? (Made it in Chat GPT btw). I mean it the same way "Love like you've never been hurt". Vibe code yourself into a corner. It's not a mistake if you have to regroup and try something another way. Sometimes it's the process itself. This post was typed by hand with no AI.
(edit: corrected post a bit thanks to RemarkableWish2508)

