Comment by XCSme
1 day ago
I could probably look over, and get some snippets, but currently only the client-side is live, so the code is sort of there, albeit I assume it's minified for production.
The game seems quite bug free though, including minigames. The UI could be better, but it's not done yet.
I do for example have an automated system that simulates progression, takes screenshots of the game to find potential hidden buttons or overlapping elements, to test for performance, etc.
If it looks like a duck, and quacks like a duck, I honestly don't see why I would review 100k's of lines of code.
EDIT: I might have replied in a wrong thread, but it was about this entirely "vibe-coded" app: https://game.ultimidi.com
That is an untested toy app that has no users.
> why I would review 100k's of lines of code.
If the core or that app is more than a few thousand lines of code, something is seriously wrong.
I don’t want to shit on your app. It’s cool. I’m glad you built it. I’ve vibe coded all kinds of toy apps for myself and my kids.
But it’s not strong evidence that code is irrelevant.
Thanks for your words.
> If the core or that app is more than a few thousand lines of code, something is seriously wrong.
That's the thing about vibe-coding: it is not the core, it is the entire app. We no longer make MVPs and release those, with AI we can make directly the app including all bells and whistles, entire progression, not just one level, all the systems around it.
Why? Because if something needs changing, it's just one prompt away. I do think code is fluid now, any choice of architecture can be instantly changed at basically no cost.
Maybe my mind is just finding ways to cope, thinking that I "wasted" thousands of solving coding challenges and fixing bugs, but I do think, for better or worse, that manually coding is gone. Same as we no longer code in assembly anymore. We no longer write C. We no longer write JavaScript. We no longer write TypeScript. Maybe not today, people don't like change, but manually writing or even viewing code will only be done in a few educational and high-performance/risk cases.
An LLM isn’t a compiler because there’s no formal method for translating prompts to code. It’s chaotic and small changes in prompts will result in vastly different code.
Come back to me when your app has users and adding new features subtly (or not so subtly) breaks every work flow that you haven’t explicitly tested.
You can’t commit the prompt and regenerate the source code each time because the whole reason that an LLM is useful is that it makes thousands of decisions for you. And those decisions are different each time you regenerate.
The only way to enforce that those decisions are the same each time you regenerate is to encode all of them in tests. But at even moderate complexity that leads to an overconstraint problem that will halt development.
We see this when using LLMs on large apps. Anthropic gave up on their C compiler. Even with an unlimited budget they stopped being able to make progress on it.
I see this in some games I made for my 4 year old. I had them one shot some “juice” when he gets an addition problem right. Combination of screen shake, sounds, flashing light, explosions etc…
It looks pretty cool, but when I tried to tweak the animations with prompts it was always worse. I eventually went in and edited the code myself and I could see why it was so hard for the LLM to change anything because it was a horrific mess of interwoven animations.
I was able to pull everything apart and manually adjust what I wanted.
7 replies →