[SteveDR]

> 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

[linsomniac]

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]

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

[linsomniac]

Running the first generated version to test, I realized I needed to specify: "Make sure that the client processes messages from the server while it is generating and sending hashes of the source file", because the first implementation would spin on generating the hashes and deadlock because the server end would write messages back to the client that the client wasn't reading and fill up the output buffers, which would fill up the client output buffers once the server stalled. This was obvious just from running it and knowing how all this stuff works (rather than by code review).

Then I started seeing issues with how I had phrased the terminal conditions, the client terminating immediately upon reaching the EOF on input file, and not reading any further server messages. I considered making a 3-way ACK to signal end, but instead changed the design to tell it to keep track of outstanding un-acked packets and only send the EOF/EOFACK when there were no outstanding messages.

The design is that the client generates a bunch of "xxhash64" messages for each block of data, and the server replies to each one with either "ok" (I already have that data) or "send" (send me that data). The "send" is replied to with either "data" (here's the data) or "zero" (the block is entirely NUL).

[ghurtado]

We used to call that "the zone", and it's not exclusive to coding.

[int_19h]

Not in that sense. When you're coding and "in the zone", the code doesn't cease to exist - it's more like it becomes the extension of you.

[barotalomey]

https://en.wikipedia.org/wiki/Flow_(psychology)

[suzzer99]

I only forget that time exists when I'm in flow state, not code.

[ghurtado]

That's actually the term I prefer, but I couldn't remember it