top | item 43688669

(no title)

SteveDR | 10 months ago

> vibe coding allowed me to figure out some rough edges of my design document, and experiment with "what would it look like built with threads? As async code? As procedural?”

This doesn’t fall under my understanding of the phrase “vibe coding”. In the tweet from Karpathy which many point to for coining the phrase, he says that when vibe coding you essentially “forget the code exists”. I think it’s distinct from regular ol LLM-assisted development

discuss

order

linsomniac|10 months ago

I surely did a hybrid approach, but for a large swath of it I was pretty purely "vibe coding", where I wasn't looking at the produced code at all.

I initially had Gemini 2.5 build some code and then did a code review of it. I tweaked my design document and then had Claude and ChatGPT take a stab at it and at this point I wasn't looking at the code at all. These implementations had some deadlock or early termination problems so I asked for some different async and threaded implementations, but ultimately they went off into the weeds in ways I couldn't really reason about, so I went back to a straight select/procedural implementation and had it start tracking outstanding blocks, which got something working reliably. Then I asked for fancy progress displays, tried several attempts at that. Then at this point I started cleaning up the code some, had it add type annotations, etc...

Big swath of pure or nearly pure vibe coding in the middle there.

gyesxnuibh|10 months ago

I'm a little confused on how this helped your design doc? It seems like you picked the design that the LLM could best implement?

I was really curious about how it helped you iron out the problems but couldn't figure it out from your description