Comment by linsomniac | Hacker News Reader

Comment by linsomniac | Hacker News Reader

Parent Full thread

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.

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

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).

Reply on news.ycombinator.com