Vibe-Prolog

I'm vibe coding a fantasy console with the feel of early 90s computing. 100% vibe coded WASM based. It runs Doom so far. I'm building that because I'm building a free-to-use vibe coding platform (ala Lovable) but the entire world off all apps is too hard to one shot with the current set of free LLM models... So now I have something it can target. I've spent a lot of time with free models because I use them heavily in my VibeProlog project (https://github.com/nlothian/Vibe-Prolog/), which is actually in pretty good shape now. Next step is to rebuild the parser so it can load libraries in a somewhat reasonable way.

But re-reading your statement you seem to be claiming that there are no 50k SAAS apps that are build even using multi-shot techniques (ie, building a feature at a time). In that case my Vibe-Prolog project would count: https://github.com/nlothian/Vibe-Prolog/ - It's 45K of python code - It isn't a duplicate of another program (indeed, the reason it isn't finished is because it is stuck between ISO Prolog and SWI Prolog and I need to think about how to resolve this, but I don't know enough Prolog!) - Not a *single* line of code is hand written. Ironically this doesn't really prove that the current frontier models are better because large amounts of code were written with non-frontier models (You can sort of get an idea of what models were used with the labels on https://github.com/nlothian/Vibe-Prolog/pulls?q=is%3Apr+is%3...) But -

https://github.com/nlothian/Vibe-Prolog chews a lot of tokens. Have a bunch of other side projects as well as my day job. It's pretty easy to get through lots of tokens.

How do we know in advance if something it going to be hard enough? For example I have a bunch of closed PRs on my Vibe-Prolog project that took multiple attempts to get right: https://github.com/nlothian/Vibe-Prolog/pulls?q=is%3Apr+is%3... As a specific example: https://github.com/nlothian/Vibe-Prolog/pull/214 which implements https://github.com/nlothian/Vibe-Prolog/issues/204 I'd be very interested if it is eligible!

Maybe don't say things like this then? > So there are two reasonable explanations: > A) There is no way to show prompts used when "vibe coding". > B) This claim of "vibe coding" a Prolog is disingenuous. The actual explanation is that it never occurred to me that this would interest anyone! There's some more prompts here: https://github.com/nlothian/Vibe-Prolog/blob/main/docs/WORKF...

Wait, you think I'm coding this by hand! That is amazing. I love it! I don't remember when which part happened, but I've been gradually moving over to the tools in https://github.com/nlothian/Vibe-Prolog/tree/main/ai-tools for most of the development. Most of the coding itself there is done with kilocode. Most of the early conversations don't seem to be available in Claude code now (is there a way to see complete history?), but here's a typical session: > can this interpreter pass command line arguments to the prolog program? [no] > add these as missing to @FEATURES.md [done] > use `gh issue` to create an issue to address this. > - Explain comprehensively what needs to be done > - Note that new test cases must be created > - Note that @FEATURES.md needs updating > Do not provide estimates That raised: https://github.com/nlothian/Vibe-Prol

> I do not think that [0] was vibe coded. Vibe coding something does not mean that everything is vibe coded ... The author claims in the project README.md[0]: I was working on something else and as a side effect accidently vibe coded a prolog interpretor on my phone over the weekend. And has yet to show any evidence of "vibe coding", to the point where I chose one of many commits challenging this position. So there are two reasonable explanations: A) There is no way to show prompts used when "vibe coding". B) This claim of "vibe coding" a Prolog is disingenuous. Which do you think is the case? 0 - https://github.com/nlothian/Vibe-Prolog

Here's an idea. There have been over a dozen commits in the last 2 hours. If you are actually "vibe coding" a Prolog, then post the prompts you have used in the last 2 hours here. If it helps to have a specific starting point, commit 7bbe652[0] is as good as any. 0 - https://github.com/nlothian/Vibe-Prolog/commit/7bbe652eaf0b0...

>> If the project is about testing Claude's capabilities, the prompts will be more interesting to have. > It's not like it's a single shot generation or anything. Since you've submitted a "Show HN: Vibe Prolog" and shared in the repo: I was working on something else and as a side effect accidently vibe coded a prolog interpretor on my phone over the weekend. The GP's observation of the prompts being highly relevant is substantiated. Arguably even more so than the Python code committed. Especially since there have been 82 commits in the span of 3 days. EDIT: And I am really interested in how you "vibe coded" the commit[0] which made this singular change: - uv run pytest tests/ttest_additional_builtins.py -v + uv run pytest tests/test_additional_builtins.py -v 0 - https://github.com/nlothian/Vibe-Prolog/commit/0bf4beba70de

I've done something similar here but for Prolog: https://github.com/nlothian/Vibe-Prolog It's interesting comparing what different LLMs can get done.

Like a lot of people I got the $250 Claude Code credit and didn't use it up. I decided to try to use it up over the weekend using (mostly) my phone and vibe coded a Prolog interpreter. Now I'm seeing how far I can push it.