It's a good demonstration of when agents still don't get everything right when you place things into Markdown documentation. You have to be really valiant and verify everything from top to bottom, if you want to control how things are implemented to that degree, otherwise the agent will still take shortcuts where they can.

In https://github.com/lowrescoder/BlueHeart/blob/68ab2387a0c44e... for example, it doesn't actually do SSE at all, instead it queues up a complete HTTP response each time, returns once and then closes the stream, so basically a normal HTTP endpoint, "labeled" as a SSE one. SSE is mentioned a bunch of times in the docs, and the files/types/functions are labeled as such, but that doesn't seem to be what's going on internally, from what I could understand. Happy to stand corrected though!

▲

zh3 an hour ago | parent [-]

Yes, I haven't even read most of the files, just threw it up there as an example for the OP (I too am tired of the lack of examples, so stepped up to the plate on this one).

As a personal bit of development last weekend. I can see inconsistences myself, some of which result from scope creep during development (starting with the idea of a text-only app and then grafting on the web side) - it literally only started because I wanted a working example of bluetooth and dBus in C, the rest of it just joined the ride.

As for the SSE, no expert on that myself, however if you watch the messages in the browser console it appears to push updates with sporadic notes about using polling instead.

▲

embedding-shape an hour ago | parent [-]

> Yes, I haven't even read most of the files, just threw it up there as an example for the OP (I too am tired of the lack of examples, so stepped up to the plate on this one).

Right, kind of like an LLM skimming and missing the core points :)

OP didn't ask for "Anything you've vibe-coded" but explicitly asked for code written with LLMs that is high quality and structurally sound, and "creates more value than it creates technical debt". That's why I felt like reviewing the code in the first place, and why I gave the feedback.

I understand now that maybe it felt like my impromptu code review came out of nowhere, but I thought you were actually trying to give OP a accurate sample, so sorry if it felt like it came out of nowhere :)

▲

zh3 an hour ago | parent [-]

NP, and the exact definition of vibe-coding is, I think, yet to be determined. This wasn't a yolo, it was read all the prompts and generally accept them. Overall I'd say the code and web page are at least of a quality I've seen in many commercial settings; the code itself looks reasonable and if I was to do anything to it for a real 'release', I'd update the documentation which has suffered due to the extensive scope creep during implementation.

	▲	embedding-shape an hour ago \| parent [-]
		> the exact definition of vibe-coding is, I think, yet to be determined Huh? No, that's been established since Karpathy coined the term, you don't review the code, only use the agent and don't care about how it was done, just about the results. The actual interesting stuff is how to use LLMs together with a human, to build high quality code. More "augmenting the human intellect" rather than "autonomous robots building for you". Overall I'd say if someone handed you a specification that named SSE specifically, you created files with SSE in the name, and the implementation talks about doing SSE, yet it doesn't actually do SSE in the end, it's pretty much on par with code in commercial settings, yeah :) But maybe our bar should be slightly above the ground at least? :)