Hacker News new | ask | show | jobs
by ryandvm 20 days ago
They don't have Claude write assembly because there is no training corpus on people making CRUD apps in assembly.

I'm as hateful of LLMs hollowing out the job market as the next guy, but the reality is the frontier LLMs are really good at writing anything that's been done and documented on the Internet a million times and unfortunately most of what software devs have been doing the last couple decades is shitting out cookie cutter CRUD apps.

I have my doubts about whether the state of the industry is going to advance as long as we're having LLMs do all the creation, but that's another diatribe.

8 comments

Claude is perfectly capable of writing assembly. Here's a working (basic) Prolog interpreter that Claude Fable 5 wrote in WebAssembly in 61 minutes for $16.75 in token costs: https://github.com/emk/fable-wasm-prolog/blob/main/prolog.wa...

WebAssembly is slightly easier than real assembly, but here Fable used WASM GC extensions, which are poorly documented and not yet super common.

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

I have feelings about this, but I'm not pretending it isn't real.

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.
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.
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.
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.)

The guys with unlimited Fable/Mythos access are for some reason incapable of producing a flawless Claude Code app built entirely in native assemblies.
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.
They're so busy winning that they don't care about improving their own web apps ;)
they use React to render their TUI :)
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!

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.

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.
Let's hope open models will continue to improve and avoid the price ramping.
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.

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.

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...
I would assume a human would require multiple hours for the same output though
And ofc the Chinese workers are a lot cheaper.
> 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

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.

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.
Yeah I had it remake my favorite TI-89 graphing calculator game in Python and it one shotted it perfectly.
Which effort setting did you run this with?
> They don't have Claude write assembly because there is no training corpus on people making CRUD apps in assembly.

I suspect that despite its translation abilities, this is true, but I'd like to see it do things in languages that are more or less appropriate for tasks to see how much the training corpus matters vs. its ability to translate. Assembly is a bit of an extreme example because you're either writing it as close to C as possible (C is essentially portable assembly) or you're writing complex, unreviewable code that happens to work. And who know if it's been trained on register allocation, or resorts to doing everything on the stack because it works.

> C is essentially portable assembly

Not really, assembly shows you what the machine instructions actually are. In C you have loops, functions structs. All things that make no sense in assembly.

Both points are specious. C disassembly is usually not an orthogonal translation of the structures in the code, usually due to optimisation.

> In C you have loops, functions structs. All things that make no sense in assembly.

One can reasonably infer that a loop will roughly translate to some type of conditional jump instruction. Function structs are just pointers and call instructions. The former point was that there is little runtime getting in the way of how the constructs could be expressed, and a long time ago it may have been the truth, but not for modern compilers.

Loops (conditional JMPS - JE/JNE/JZ/JNZ/JB/JNB.. and a dozen others) and functions (CALL, RET) exist in assembly. Goto is there too (all JMPs). C makes assembly sense.
Oh that's an interesting thought. Goto's are considered harmful, because holy hell as a human trying to understand and reason about code, the spaghettifcation if someone else used gotos all over the place and I have to reconstruct their thought process just doesn't sound like fun. But if we're no longer writing code by hand (which, I gotta be honest, I'm using AI to write a lot of code for me these days), then does that still matter? If a human isn't going to have to understand the code, can we get more performance out of existing systems by considering goto's useful?
goto is already useful as an end-of-function cleanup. You pop one at the end of each function (the naming is local to the function) and that's the place where you free ram if the pointer's not null and close the file if the handle is not null and so on.

Then you don't have to litter all of your if/else clauses with hundreds of memory frees and cleanups - you just "goto"

The fact that this is controversial to some people just shows how rules like "Dont use goto" become stupid - if one is trying to make code simpler then there are cases were not using it is the more confusing and error prone choice.

As for "can we now do anything" well if you don't ever need to debug "anything" then yes and if you have any small doubts about your LLM then no.

I assume there's a clear technical reason why GOTO is harmful, it adds to the complexity of the code, makes it harder to understand and fix and evolve. Wouldn't the same difficulties affect the LLMs ability to understand and fix and evolve the code as well?
As a human with a human level of working memory, the number of things I can keep in my head and map to concepts and functions is unfortunately limited. An AI running on an Nvidia supercomputer has higher limitations on what it can hold in its working memory, so could theoretically handle more than my human brain can.
Compilers only really use them for things like break and the end if blocks. There isn't much to gain by being able to execute anything arbitrarily, and then go...where? There might be places here and there within a function where compilers already take advantage of it, but I doubt it's useful in the way you think.
in C it's quite normal to set a return code and jump to a cleanup section where all the buffers are freed, all the files closed and so on.
LLMs are perfectly capable of translating between programming languages at this point. The main bottleneck for them is logic, not language.
And the amount of logic needed to understand code, including how to fix it or modify it further depends on how complicated the code-structure is.

I wonder about this: Does LLM write better code in a better language?

Humans often have more difficulty fixing existing code than reqriting it from scratch, and un-structured un-constrained code would be a big reason for that.

But maybe it doesn't apply to an LLM if it always rewrites all code from scratch?

> I wonder about this: Does LLM write better code in a better language?

The whole point is to rewrite everything in a language you don't understand and then ignore whether it's better because you can't tell.

That language, of course, must be Rust.

What's there to advance to?

Without a revolutionary new platform to build apps on that no one has ever developed for before, there is basically no reason to believe there is any software left that has some business or economic value that hasn't already been written.

This gives "let's close the patent office"
> This gives "let's close the patent office"

This is a really good idea for completely different reasons. :-)

This is probably true in the consumer facing software space. But in business, industry, and academia, often there are novel data generated by some new or refined process. And this needs new software that correctly handles both the nature of these new data and meet the goals the data is collected to advance. This sort of software is also usually poorly represented in training sets, if represented at all.
If you think we're "done", you have no imagination.
What are you gonna make? Yet another CRUD app? An API subscription? A game? A mobile app?

We’ve created software for virtually every place we can put software. There’s nothing new.

It’s like bridges. We’ve seen all the ways bridges can be built by now. There’s nothing new left to discover.

> There’s nothing new left to discover.

It's the end of history. What could we possibly discover about a series of technologies that are already nearly 100 years old now?

I've heard people say that various things are "solved" now because of LLMs too -- programming included. This implies we've "solved" thinking. I'm worried about these sentiments.

https://en.wikipedia.org/wiki/End_of_history

When Gutenberg invented the printing press, he could not have predicted the teleprompter. Now that code is easy to generate, it’s plausible that we will use much, much more of it than before.

It’s also a bit ironic to imagine that we’re at the end of new software ideas on a site owned(?) by YC.

Are teleprompters a net positive achievement? They were needed for live television, they will be superseded I guess by AI generated news avatars. And 24-hour news coverage is in the business of generating content non-stop, to sell advertisements, regardless if there are newsworthy events or not, the machine never stops producing.
it's also plausible that with an ability to generate as much code as we want with little effort, we will quickly discover how much code we actually need, and then plateau at that point.

Personally, I think we've already reached that point.

Even at YC, I have not really seen any startup doing anything interesting where their main value prop is enabled by new proprietary code that does stuff no one else can already do.

We have more code than we need. Proof for me is every "smart" device that worked better before we put a computer in it.
Mature tech evolves more slowly. Think about cars, there's nothing new about them any more. But wait, what about electic cars? Aren't they a new thing? And driverless cars. And soon flying taxis. Automobiles are an old invention but they are still evolving.
The reason the evolution of cars has slowed down so much is mostly regulatory compliance.

With the current ongoing revolution in home manufacturing (starting with 3D printing; currently there is a lot of work done in home CNC machining), it would be easily possible to get a huge leap towards "print your own car".

The reason why you see nothing of this is basically red tape.

Why did we even need bridges in the first place
Well, a short time ago somebody made the first LLM. Was that the end of it?
this implies that the only thing that can change what needs doing are technology platforms, which about 6000 years of human civilization would indicate is not the case.
that you don't see this as inevitable worries me dearly
couldn’t the frontier labs simply compile their existing source code training data and have an assembly corpus to train on?
It's still possible to make CRUD apps in assembly with an AI agent but it would be a research project.
By "research project" you you mean by people who understand assembly? Because then we're back to where we started.
I mean for the agent. They are good enough to conduct research now.
LLMs are designed to imitate humans not compilers. Hardly anyone is capable of writing modern optimized Assembly code by hand outside of a few snippets here and there (not in a reasonable amount of time at least)
>They don't have Claude write assembly because there is no training corpus on people making CRUD apps in assembly.

I'm disputing this. You can have a training corpus in assembly as big as any other language: just feed the compiled result(in assembly) of the CRUD apps to the LLMs.