"one-shotting" is fun for a low (human) effort toy, but it's a mistake to get overly hung up on LLMs getting everything right on the first try, since a lot of that is the harness and the internal prompting that makes it burn extra tokens to test everything to get it in that one "shot" (ui turn).

While it's nice that LLMs are getting better at arriving at the desired deliverable with fewer surprises (or broken things) doing it is not necessarily a sign that the model is actually smarter, just an indication that what you are doing is likely a well-trodden path for the model, the RL and the harness.

▲

aenis an hour ago | parent | next [-]

But for how long?

I have a personal benchmark suite that runs a bunch of difficult algorithmic problems in 3 tiers: vibe coded prompt (just a few sentences), vibe coded prompt plus a description on what the solution will be evaluated on, and finally a fully specc'd prompt that leaves little space for interpretation.

The current Fable models are approaching a level where the -eval runs perform systemicallty better than the "clear spec" runs. (And right now its just Fable 5.1 and Opus 5.5 that behave so well, all the other models I tested - all the OpenAI and the leading Chinese models - work better with clear specs). I'd encourage everyone to experiment a bit; I am running my serious workflows with labourious force-me-through-all-the-design-questions mode, whereas my hobby projects, some of them hard, I am trying to see how much I can get away with with vibe-grade prompts. My conclusion is, with Fable its starting to look like what Vibe coding was promissed to be a year ago - a magical box that generally does things very well.

Btw, congrats to the OP -- the game is enjoyable and I played a few levels. I dont remember when I last played any games for more than 5 minutes. Good stuff.

▲

everforward an hour ago | parent | next [-]

My experience has been that cruft accumulates and creates back pressure via growing token usage.

The APIs aren’t clean, which creates indirections to other parts of the codebase to check on leaking abstractions. It doesn’t learn, though, so you pay for those indirections every time (right now, anyways).

I’ve not been impressed with its ability to clean that up with a generic “make it gud” kind of prompt. I have to point it at something crufty, but it will fix it then

	▲	aenis 3 minutes ago \| parent [-]
		I agree, but for some projects, that first vibed version is just about good enough and becomes the final version. I have a few things like that and it was nice not to have to bother. For work stuff, I don't dare 'vibing' anything, and force myself through torturous design cycles and regular refactoring runs. But thats serious stuff with hundreds of thousands of users. Btw. Fable 5.2 seems to burn through tokens with gusto. I ran my benchmark suite on it, added a complex feature to a hobby project (a gothic cathedral designer), and voila, 2 resets gone.

▲

tharkun__ an hour ago | parent | prev [-]

I definitely remember a game I played for more than 5 minutes recently. A lot of those were not AAA(A) games but rather indie or previously-indie-now-got-a-publisher-to-notice games. None were "AI one shots" that just built something that looks like a re-skinned version of "Teenage Mutant Ninja Turtles: Shredder’s Revenge", which I'm sure is pretty abundant in training data? And that was a great game btw!

▲

tty456 an hour ago | parent | prev [-]

But one shot prompting does not mean one shot testing. I see continually that Fable can design and test prototypes before committing to a design goal and testing multiple layers until the goal is reached. Many of the tests are code unit or integration tests that can be re-used without token spend.