Hacker News Reader

Comment by Verdex | Hacker News Reader

I don't believe that AI is the 'higher level of abstraction[1]' that it is often claimed to be. However I wonder if it's possible to work with a codebase when other developers are treating AI as a higher level of abstraction.

Analogously, people can write in assembly, but can you write in assembly when the codebase is frequently altered by someone with an optimizing compiler?

[1] - Do higher levels of abstractions even exist? By my way of thinking that's called not an abstraction. C isn't a higher level of abstraction; it's a different abstraction implemented by assembly. There are more powerful abstractions and more ergonomic abstractions, but that doesn't make them 'higher level'.

View on HN

You wouldn't be the first person to eventually conclude that C is just a very fancy macro assembler.

But AI generated code is much like every other generated code: it is more voluminous and rather less elegant than what you'd write as a person. And here too there is a link with assembly: early compilers routinely put out absolutely terrible assembly by assembly programmers' standards of the day. And then they got better. To the point that today it takes some pretty rare niches that it pays off to break out the assembler and roll your own.

I expect AI generated code to develop in the same way, and the way to get them to improve is to hold generated code to high standards. The problem is the perverse incentive: generated code of low quality will eventually result in many more tokens burned than a one-shot piece of perfect and elegant code. Here you can draw a link with medicine...

> Analogously, people can write in assembly, but can you write in assembly when the codebase is frequently altered by someone with an optimizing compiler?

Yes. There's an interface boundary in the form of function prototypes and ABI rules. To the optimizing compiler, your assembly code is undistinguishable from separately compiled high-level code, and to your assembly code, the compiler output is undistinguishable from separately assembled low-level code.

One problem with LLMs, is that they don't respect these boundaries like an optimizing compiler would.

Sounds like you just don't like the phrase 'higher level'. To most people this is synonymous to 'powerful abstractions' and 'more ergonomic abstractions' in the sense that they allow us to think "at a higher level" - map instead of loop, objects instead of memory addresses and size, modules instead of gotos.

To be sure I don't like the phrase. But more importantly I also don't like the outcomes when improper abstractions are setup and vital details ignored.

There are no true scotsmen.

> can you write in assembly when the codebase is frequently altered by someone with an optimizing compiler

This itself is quite normal (e.g. we have .S files and .c files and link them together), but I suppose a more accurate analogy would be that someone is dumping their optimising compiler output directly into your .S files.

Maybe what we need is better ways to partition the slop-code and the not-slop code.

Clearly I misspoke. But it looks like you've got the gist of what I was trying to say.

Reply on news.ycombinator.com