Some people find code easier to read than the English description. It’s more precise and many experienced devs can scan it and know what’s happening
Many other people can’t read code. Or they find English easier to read than code.
Thats not a knock on anyone. Maybe the latter will rule the world because the former focuses too much on irrelevant details. Or maybe me there are just different types of problems that need differing levels of attention to detail.
How can you be sure that's what the code the LLM wrote actually does?
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.
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.
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.
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.
It’s also a bit ironic to imagine that we’re at the end of new software ideas on a site owned(?) by YC.
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.
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.
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.
This is a really good idea for completely different reasons. :-)
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.
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.
> 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.
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.
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.
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!
Much cheaper than a human software engineer. But comparable to the wages for some human workers.
ROI won't make itself up.
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.
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.
so you don't know if it works properly or not
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.
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.
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.)
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?
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.
One time, something didn't work as expected - its the first time it happened with this project. I read through the section of code and it was perfectly readable and well-written.
Turned out a plugin wasn't effecting the audio, so i just got it to pad some blank audio onto the beginning before processing it, then remove it at the end of the process. That fixed the issue, there was nothing wrong with the code but my ability to think laterally is what made it work.
We're getting to the stage where you can just ask them to write code and they will do what you want, and it writes good code. Its up to you to test everything beyond the internal tests it writes.
Yet...
Less about “trusting” the llm and more about how complex it is to work with binaries due to machine code being different per machine and hard to interpret the context of the code as well as offsets.
In that sense because high level languages come with the ability to add context to what code does. It’s like the understanding a human has when given decompiled C code ghidra gives you vs C source code a developer wrote.
Also the compiler helps the llm write “compiled / working code”, if it just spat out machine code it most likely not even run at all.
But yea generally if you can’t write code at all, reviewing it is even harder.
However I do think there is reason to use Java or Python (as much as I loathe both) they have GC, and it'd be a lot easier for AI to fuck up memory safety in something like assembly or C.
One has to program computers to be a computer programmer. If one just prompts LLMs, they are a software prompter. I think both can fit under the title of a software developer or perhaps even software engineer.
There's more to it than that: writing is thinking. If you stop writing code, you aren't thinking anymore.
Many argue that they're now thinking at a higher level (maybe they weren't before?), but, guess what, that high-level design can be done better by the LLM than by you anyway. It's only temporary.
Humans have been thinking long before writing was invented. Why is code special?
And look how poorly they did it until they invented writing.
> Why is code special?
You don't get better at thinking without doing. With code the "doing" part is writing.
In your view, it is reasonable to expect HS students to thoroughly read a book on trigonometry and then ace the exam? We know, from experience, that only by doing problems does the student actually learn. We also know that when you stop doing problems the facility atrophys.
Why is code different?
>And look how poorly they did it until they invented writing.
Yeah, look how poorly they did it until they invented writing.
[peers into the dim ancient past]
Sorry, my time-machine spectacles are on leave or on strike today.
And congrats on being a multi-millen(ium)arian, and a mind reader, who could both 1) exist so far back in the past, and 2) be able to know the thoughts of people who didn't write them down, because they didn't know writing.
/s
How can you know how poorly they did it?
Their lack of progress. Humans existed in the same basic form for around 100k years before they finally invented agriculture, which led to some improvements, and then rapid progress once writing was invented.
IOW, hunter-gatherers follow the best habitat, so controlling for habitat is always going to have the conclusion this paper reached.
I'd be very interested in other studies that support this conclusion; after all, that's how science works - a single study proves nothing if many studies conclude the opposite.
While I mostly agree with this notion, given that all of our understanding of human progress historically comes from writing, there's a selection effect happening here.
Like, why do we talk about the Dark Ages? Because there was less writing, so obviously things were terrible.
There's a bit of a selection bias there, because writing itself is used as a measurement of progress.
But, ignoring writing as a measurement of progress, we can pretty much see that for about 100k years the only tech were primitive tools.
Even after the domestication of wolves (about 40k years ago) there were no visible improvement in tech. After agriculture (10k-12k years ago, maybe?), there's visible progress in tech (tools), but not by much, and visible improvement in societies (also, not by much).
Enter writing - those civilisations that had more advanced writing progressed rapidly, and those that did not barely progressed at all, tech-wise.
Because not all civilisations progressed at the same rate, we can see quite clearly that writing is highly correlated[1] with progress.
---------------------
[1] While correlation does not imply causation, as the data mounts it lends more and more weight to the causation bit.
That's a big "If". The observation we have is that civilisations that never invented writing simply died out with no tech-tree advancement; and this happened for 100k years at least.
We've got 100k years of "no writing, no tech". We've got around 5k years of "with writing came tech".
The actual tech to write was there for much of the 100k years (cave art), but without writing, the tech never improved.
> How can you know how poorly they did it?
You could probably get some sense by comparing illiterate people to literate people.
Each last for a different amount of time and you generally can’t write or even read anything. But in my personal experience, all three lead to solving the most difficult software problems.
When writing, thoughts become forced and linear in my view as opposed to floating in a specific way from point to point. Like I lose the natural creativity.
Writing is about remembering or communicating, so it is summarizing the thoughts, but it is not thinking itself, it is more so thinking about how to communicate efficiently or how to make a note so you don't forget. It is not creativity for me.
Kind of imagine building an idea in your head while running and then you write down the summary of it.
When I sit down to try and write them down, I blank out. Or the thoughts that I thought were good/useful, I second guess when writing them down. Perhaps it's just lack of practice on writing them down (I'm trying to use a typewriter to do so recently).
I am skeptical that you were able to get any good at Maths or Physics without drilling problems.
A lot of people observe that their thoughts get better when they do the work to write them out. It's not just a straightforward encoding process (as maybe a software engineer would conceive of it).
E.g. I iterate and see the architecture or the system work out, or I get other ideas because of something I don't like, etc.
This is a poor argument. The trial and error is the LLMs trial and error of your intention (ironically driven by you), not your trial and error.
It's like saying "It wouldn't matter if I instructed an LLM to solve my trigonometry problem or if I wrote the the solution myself; either way I'm learning trig".
> E.g. I iterate and see the architecture or the system work out, or I get other ideas because of something I don't like, etc.
What exactly are you needed for in this scenario, other than saying "make me $PRODUCT"? The LLm is going to be a lot better at architecture than you are. Your role is limited to A/B testing the result for human use.
I kinda [wrote about this before](https://dielsonsales.github.io/2023/05/11/starting-a-new-blo...) but the takeaway is that writing forces you to structure your thoughts, giving them a final shape and enables you to notice flaws or gaps in your own thinking process. It’s impossible to do this without writing.
As to your post, I think rather than writing it's the act of pressuring yourself to figure the thing out that is making you more knowledgeable about the thing.
You are putting it out publicly out there so you really want to be certain that you are correct, and therefore you do a lot of research.
If you wanted to be accurate and prove a point, the motivation mechanism could vary, but also the eventual communication mechanism could vary. It doesn't necessarily have to be in writing, it could be a live debate or simply something else you built. The writing or the product are end product, but the process of wanting to produce something is what made you research and to understand.
You could be writing to yourself into a Google Docs, and not care and you would not go deep to research since there's no incentive to be accurate.
E.g. I could be doing a home project whether hardware, software or DIY, that in order to produce this output I have to learn and think. Similar to as good set of words to communicate some idea. But also I could build some slop without thinking and I could produce slop writing without thinking, and about nothing special.
by writing code by hand - you're the author & editor at the same time.
if you're skilled enough - you quickly get to the desired state vs the llm which while might produce a lot of code - but it likely won't give the end state you desire.
an analogy - Jason Fried gave - producing software by llm's is like bragging you're a photographer by pressing the shutter button on an automatic camera.
while the art of photography - is about producing the single perfect photo - that communicates the photographers intent (what they want the world to see & experience).
likewise in software - what we make should be deliberate.
Where will you put a line between photography and pressing button?
My point being - tools change with time.
I don't write code anymore and I doubt I ever will ever again.
On the flipside I review exponentially more code than ever before.
>Just ask Claude to dump out assembly, or a compiled binary, but no, they don't trust the LLM that much
It's not "not trusting" the llm its that the llm has been undergoing reinforcement learning is on coding. Plus generating assembly is extremely token inefficient.
However, that would just make the difference in productivity between junior and senior developers even more pronounced! It’s really difficult to see how things will play out in the future without junior developers disappearing, causing a slow death of the profession. LLMs will probably never be good enough to do everything a developer needs to do: understand and improve or clean up requirements, consider future needs, test outside the box, evaluate performance and decide where and when to improve it…
aargh! haalp!
Which rock are you living under these days.
Nowadays everything is IR or MLIR ... or AIR ...
whoops, i may have skipped a few generations. hard to keep up with the dynamic pace these days. got a job to save. sorry suh.
mumble javascript mumble framework of the half-week ...
walks off muttering
I'll byte the bullet.
Hang on a bit while I register that in my memory.
>generate x86 and ARM
So that hardly anyone can review the machine language output, I guess.
HN users' minds be like:
87.654321 %: JS? yeah. mainhipsterstream. gotta be a part. heart.
smaller %: Rust? wannabe. donno how, u c.
much smaller %: C? oh no ... numeric underflow.
Congrats on moving over to the light side.
bobby tables, for another.
No, people do advocate for this. It may simply not be as portable however as something that is high level able to be compiled to assembly for many machines.
Why review it at all? The trend is to vibe code everything with agent harnesses and tokenmaxxxing.
Not all software is mission critical. But some software is.
Thirdly, compilers also do type checking and other static analysis and dynamic checks (array length etc). So it's not only got more guardrails against "mistakes" by the LLM, but it's also most likely "easier" for the LLM to "reason" about (in the sense that LLMs can reason).
There's no intrinsic value to having humans read the code, so as soon as LLMs are good enough to work on their own, companies will no longer need to keep developers who can read code as a backup solution.