Yeah I had it remake my favorite TI-89 graphing calculator game in Python and it one shotted it perfectly.

The guys with unlimited Fable/Mythos access are for some reason incapable of producing a flawless Claude Code app built entirely in native assemblies.

They're so busy winning that they don't care about improving their own web apps ;)

they use React to render their TUI :)

You’re getting down voted, but it would really be nice if they rebuilt the thing in Rust or something like that. I’m just tired of these enormous JavaScript bundles pretending to be desktop apps. Especially when we need to squeeze as much juice as possible out of our machines.

There’s a very real dichotomy at play here. Position 0: humans depend upon AI. Position 1: AIs depend upon humans.

At first blush, it seems achingly obvious that position 1 is true, whilst position 0 is a false play by con artists.

Well, at first blush I agree! But first blushes are notorious for being famous last words (blushes).

You see, we always knew that the tool shapes the hand. That is, as we use computational (discrete) devices, we ourselves become more computational, discrete.

But what we did not anticipate is that the tool would fool others as the ACTUAL HAND. I am so fooled. Daily.

My friends. Does technique encompass being? Answer me this!

I have a personal game framework that I have LLMs write games in, which is in AssemblyScript. AssemblyScript is certainly closer to TypeScript than it is to WebAssembly, but it's still this thing where the host shares some big chunk of memory with the script and you pick some memory locations to read and write as your means of exposing APIs, and there's not a lot of training data on games written in AssemblyScript and even less in my game framework specifically (none) - and the LLM does an excellent job.

This is for games that run purely in the browser?

No, I typically want to target either mobile or PC first - but I strongly want stuff to run well in the browser too, for early playtesting and for demos at the very least.

I guess since fable has learnt deeply about 10+(maybe 100+) popular programming languages, it can just easily reason about the new 101st programming language.

Just interesting to see Claude’s hourly rate is around $17.

Much cheaper than a human software engineer. But comparable to the wages for some human workers.

And ofc the Chinese workers are a lot cheaper.

As soon as human software engineers are Ubered away from the field, the price will ramp up to that of a human software engineer or more, have no doubt.

ROI won't make itself up.

It is hard to believe that no one sees this coming. I can’t imagine it will happen any other way.

Then everyone just starts running open weight models locally.

Running it on RAM and GPUs which cost like a private jet plane, or have to be smuggled in like cocaine due to import/export tariffs or bans.

U.S. is actively considering restricting highly advanced "open-weights" models due to cybersecurity and national security concern.

Chinese models will be enlisted in NATS - the National Terrorism Advisory System.

Can't have the fat, rich big boys who give the campaign contributions fail.

Let's hope open models will continue to improve and avoid the price ramping.

That’s around 28K EUR/year. I know some junior-mid engineers that earn that (and they are good) in southern Europe.

But now human will produce the same amount of work in an hour - not even close...

claude helped me build a functional visual modem (using the cameras and microphones/speakers) for mac/iPhone in about a day and <100 prompts. i’ve worked on mobile apps once 10 years ago and have never built one from scratch. i've built a handful of UIs in 20 years on different platforms. my actual work was mostly in systems software. so it would have probably taken me weeks to months to build this from scratch. it would have cost substantial money to outsource this and iterate on ui and core algo as i did.

i've been curious about the feasibility of this concept for quite some time and now i have an actual example to study and measure and hack on, for a fraction of the cost of my pro sub. it wasn’t trivial, i doubt a non-swe could get it done in that time, but i'm a pretty happy customer overall.

I would assume a human would require multiple hours for the same output though

Which effort setting did you run this with?

> Fable didn't even need to debug it; I believe essentially all the assembly worked correctly on the first try.

so you don't know if it works properly or not

It's also conveniently forgetting that AI was trained on the whole internet, a corpus of code including every garbage solution in SO wrong answers or random junior blogs. I didn't see any claim AI could select "best practices" from their sources, so putting AI to correct another AI has high chances of statistically selecting the same wrong solution, because that was just a common thread in those old posts they used as reference.

I think you're pretty wrong here, but I'm no expert so anyone who wants to correct me please do so.

As I understand it, there's post-training step that does exactly that, they get real developers to select good and bad code and help the AI figure that out. AFAIK it's the reason why Claude was able to leap-frog OpenAI in coding last year, they did this refinement step a lot better.

And now they've taught the older models this, they can use existing models to bootstrap the newer models without humans involved, and bring humans in to just assess the trickier stuff.

Claude's coding efficiency is largely due to their control plane governing the actual execution of the model - rules, evaluators and basically looping over results. Not related to the model training or fine tuning.

The models were already much better before Claude Code came out, let's not rewrite history here.

Fable wrote a pretty decent test suite covering typical Prolog programs, including things with non-trivial execution patterns like "append" that do complex backtracking on multiple branches. And I've run a modest number of test queries by hand, trying a few things. It's entirely possible that there's a bug there somewhere. But it's better than I would have done on the first try, implementing a Prolog interpreter in assembly. And I've worked on actual production compilers a few times.

I am honestly not happy about the way that models can now just take what should have be a fun multi-weekend project and knock out in a couple of hours. But I'm not going to pretend that Fable is stupid, or that it did a bad job on any of the test projects I gave it. It struggles more on big, messy real-world code bases, absolutely.

WebAssembly has as much to do with assembly as JavaScript has with Java. I highly doubt the "slightly easier" and my attempts with LLM's and assembly so far were largely disappointing, but I also think there is no compelling reason this has to be the case.

I have written assembly for about 5 different processors, including 65C02s, 680x0s, cute little DSP3210s that managed the CPU cache manually, utterly cursed TI320C40s, and (of course) a bit of Intel. WebAssembly is simpler than some of these architectures in some ways.

But it's not that much simpler. And once you add the WASM GC stuff, WebAssembly gets weird. It's a Harvard architecture with separate value memory, linear memory, GC memory and "tables", all accessible in completely different ways, with a weird mandatory type system (especially for the GC stuff). And the docs are often terrible. And yes, I've also written WebAssembly by hand.

So yes, I would, overall, classify WebAssembly as "slightly easier". But not dramatically so. And the training data for actually writing non-trivial things by hand isn't that great, not compared to something like Intel assembly.

(Don't talk to me about TI320C40 assembly. If Fable can one-shot a Prolog interpreter written using that without finding a reference manual, it's time to hang up my hat and learn to make goat cheese.)