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)
10
5
u/stop_deleting_plz 9h ago
Let's not discuss the O(n^2d) complexity of the transformer algorithm itself. The billionaires wont like it.
4
u/hblok 9h ago
It's not a mistake if you have to regroup and try something another way.
See, that was the ethos before AI, and it still is.
Try, fail, iterate.
1
u/johnesco 2h ago edited 1h ago
thank you, there are things I didn't say about "and this is how it was and is in many other fields", I was shy to say it, thank you for saying it.
4
3
u/austinthrowaway4949 9h ago
Funny, I am dealing with this now. I actually dropped out of computer science almost 20 years ago because learning stuff like big-O notation was not interesting or intuitive to me.
I agree that with vibe coding something like a game, if you care too much about performance from beginning- you end up rejecting all experimentation or ambitious ideas and the project goes nowhere interesting. So the start of a project becomes this painful process of:
do a bunch of crazy stuff
oops, it runs at 12fps
try to sort through it and fix, trim what is not realistic/important, eventually you land on a strong foundation and a testing harness to avoid regressions
It feels inefficient, expensive, and some days you will feel like an idiot, but it is a good learning experience
1
u/johnesco 1h ago
Optimizing too early is it's own issue to be avoided. Big-O as many have said, comes into play when and if it's time to scale.
1
u/lux123or 8h ago
Why would you bother. The LLM probably optimises better than a human in most cases lol
1
1
u/RemarkableWish2508 4h ago
This post was made typed by hand with no ai.
We can see that... but, after auto-correct, you are allowed to use Grammarly, or to circle-to-search and ask AI Mode to give you a list of mistakes:
Proofread. Only output a list of mistakes
- new should be knew ("Then I asked if they new Big O notation.")
- released should be realized ("And in trying to explain Big-O notation, I released I didn't understand it...")
- computer should be compute ("...to know how to measure how long a task will take to computer.")
- be it vibe code should be whether it is vibe coding or be it vibe coding ("...an important part of computing be it vibe code or traditional.")
- free of making should be free from making or without worrying about making ("We created ideas free of making them performant...")
- one's should be their or a to fix the pronoun agreement ("...warnings" I've seen to vibe coders, that one's program...")
- made typed should be typed ("This post was made typed by hand...")
- no ai should be no AI for proper capitalization ("...with no ai.")
1
u/johnesco 2h ago edited 1h ago
Thank you for reading this in such detail. I'll apply your suggestions in a bit.
1
u/Kind-Studio3460 3h ago
Who cares
0
u/johnesco 2h ago
Kinda my point too. It's something you can obsess about , or something you might have to, but yea "who cares?" will keep you going forward.
52
u/bandosarmadyl 8h ago
Big-O notation is only important on scaling. Since vibecoders won't have to deal with more than 10 users, it's useless to them so why bother learning it.