I feel like this is the exact opposite of the conclusion I've been coming to. In an age where anyone can vibe code stuff at the drop of a hat, I want the ability to assert guarantees/contracts at a high level, and then let AI work out the details. I want to force AI to work within the confines of an abstraction, not independently of it.
I have the same thought on this. Having some abstraction where we have total control and we can make clear judgments is the perfect place where AI should. Removing this abstraction will just make things hard for us and just pray that all the guards around are sufficient.
> I want the ability to assert guarantees/contracts at a high level, and then let AI work out the details. I want to force AI to work within the confines of an abstraction,
The post seemingly tries to get at this with its discussion of 'oracles', but the quality of its writing and argumentation does it no favors. I actually hope it was written by AI, because if not, the authors could stand to benefit from a Claude detox. It's rife with the signs of brainrot from LLM over-reliance.
Earlier when we were writing code by hand, since both specification and coding were done by us we could easily iterate over them in our head and thus keep them in sync.
Now the only input is the specification and it must be precise (however incomplete) so that we can be sure that there is no ambiguity when AI interprets it. Iterate and refine the spec as needed and you are assured that the code does what you want it to do. Inform AI to enforce the invariants from the spec directly in code as asserts/contracts and you have guaranteed traceability through code. This is the "Correctness-by-Construction" (CbC) approach to programming.
It would be worthwhile for folks to study the classic specification languages like Z-notation/B-method/Alloy/etc. and learn to use those productively with AI.
We need abstractions more than ever. The real point is we should retire unnecessary abstractions.
A good abstraction is a single edged sword which simplifies the task. A mediocre abstraction is a double-edged sword. A bad abstraction is like a single edged sword with a restrictive handle and the sharp edge is facing towards you.
I'd say: A good abstraction is a formal and abstract statement about the nature of the underlying (sub)system. It is self consistent and allows an easier way to reason and interact with greater complexity underneath.
And the more you see an abstraction as a "wad of API calls and functionality", the more leaky the story gets.
Some systems are notoriously difficult to get this statement right because they are volatile and prone to changes. But I think as in live or in academia, our aspirations should be to strive for a better abstract understanding and keep building better abstractions.
This is such a poor idea. LLM Agents don't have taste (abstraction capabilities). They are kind of like water, they take the shape of the container they're in. They are so much powerful when you build your own framework they can work in.
Abstractions are ultimately a tool for humans to manage complexity in a particular class of problem, and to reduce cognitive load. Good abstractions come from imaginative human brains with taste and lived experience. Abstractions are also mind constructs that often have analogies in the real world. Even at the level of the CPU circuitry, abstractions serve that role. An LLM can only spit out what was already invented by humans and stitch it together in a tasteless, erroneous manner.
That is not what the text is arguing for and it has many good ideas, dropping the abstractions but keeping the test harness is one of them.
I've worked on many aspect of programming language implementation through the years and I would struggle with the abstractions of parser-generators and bytecode designed by committee like an enterprise Java developer struggles with the Hibernate ORM. Dunno what people are putting in their prompts but ask LLM to roofline and it will pursue that target like a bloodhound.
Many abstractions we encounter in software industry are poor abstractions which are counter-productive. I agree that we should drop those...
But we can't drop all abstractions. It's not physically possible. The AI agent is going to break logic up into files... The AI will create/impose an abstraction for each piece of logic whether we like it or not.
So saying "drop abstractions" is actually saying "let the AI decide what the abstractions should be" and unfortunately because LLMs are trained on average code, those abstractions are often pretty poor.
Coming up with the right abstractions is actually one of the main skills which AI hasn't automated and where the human brings the most value. It affects maintainability directly; including when using AI.
I've worked on projects with poor abstractions and ones with good abstractions using AI. The ones with poor abstractions require 10x to 100x more tokens and time to solve problems and implement new features. You're constantly fighting it to prevent it from coming up with nasty hacks and workarounds. Poor abstractions create the need for hacks and workarounds.
Software abstractions are a reification of problem domain understanding. They embody a solution within the mathematical constraints of a programming language such that the collaborations, when done properly, appropriately reflect said understanding.
Discarding abstractions is nothing more than rediscovery of a Big Ball of Mud[0].
Abstractions aren't a burden though, they are more like a support. A good abstraction let's you write 10 programs in the time it would have taken to write one. Also, we now have "production" languages with generics and monomorphization so abstraction is easier than ever.
Djikstra has a great article as to why English language programming will always be second to a programming language. A "formal system" (edited from regular language) is the most precise way to specify things. An "abstraction" is basically a domain specific language.
The way I like to use LLMs is to build abstractions. I like to build mathematical code and ask the LLM to use it. I think that LLMs are very mathematical thinkers and they like it when they see Semigroup<T>. And it's not hifalutin either, I'm processing calculations along DAGs with a million+ nodes in milliseconds, thanks to abstractions
LLMs have been trained on a lot of data and have built representations of various concepts and links between them from that training data. This is why they are good when seeing names of things like `Semigroup` as they can draw on all the information about that concept from multiple sources (mathematics papers and discussions, programming articles and code, etc.).
There was an article or comment somewhere that said that when an LLM was prompted in comments/variable names about a complex algorithm or something like that in a very specific domain it was very knowledgeable. However, when given different names/terminology for the same thing it didn't understand the problem it was prompted to solve.
This is also why LLMs are good at generating code using Bootstrap, Tailwind or any other technologies as they can relate terms like `flex` and `grid` to various layout patterns. So using sensible names from the literature/specifications/etc. helps both developers and LLMs.
agents are unlike humans in many ways but they have their own limitations. it's magical thinking to believe that they are able to cope with zero software abstractions, especially as a codebase increases in size and complexity
and today's agents increase codebase size and complexity much faster than humans do via traditional software engineering methods, so this is likely to hit a wall faster than if human software teams were to do this experiment.
Just yesterday, for fun, I asked Codex to generate an “online e-commerce site” in ARM assembly. To its credit, it did actually generate a program that served up a webpage over a socket, but it really did not do what I asked. The program still pulled in a large number of shared libraries (something I’ve never really thought to try in assembly). And… it was not actually a functioning e-commerce site. Iterating on that initial prompt proved painful—the program was extremely brittle and now I had to review and talk about ASSEMBLY. Maybe we can dispense with abstractions someday, but holy cow, not yet. I would much rather write an e-commerce platform in C than try to vibe-assembly my way to one.
Many times I wonder if it's possible to collapse abstractions? The idea of making the whole stack simpler. I'm not overly optimistic of LLMs achieving this, but it they do, I will be paying more attention.
Following this argument to its natural conclusion, we should tell LLMs to generate the binary directly. It's still an abstraction, but it's the lowest level we can go to on current consumer hardware.
I don't think raw machine code (not even assembly) is the best form to reason about program logic. It just takes too many steps to execute sophisticated processes to keep them all in your head at once - or keep them all in an LLM context at once.
Personally I think we will just become more ambitious with our abstractions since the LLMs can generate more complex stuff at the lower level. To take the article's examples, LLMs will write kernels that fuse 3+ layers of a model, so the abstractions can enable more complex forms of kernel fusion.
What we decided to do is essentially just hand-rolling PTX with the agents under a harness. If there is lacking some function, we write/take a CuteDSL kernel, export PTX on compilation, transform it with the harness and then feed it into the agents.
We beat cuBLAS, and we beat all of abstractions - Triton, Helion, TLX, Mojo, ThunderKittens, cuteDSL, etc on Hopper and Blackwell for all of our workloads over 3-4 weeks.
vLLM dropped torch.compile support because they realized that they programmers were good enough to just generate the Triton kernels directly for all the passes efficiently.
If you work with this for prod the writing is on the wall sadly. The abstraction layer is just really much lower if you want full perf.
Ish, today I am on the fence because sometimes(half-half) its necessary, a year ago it was completely impossible, but I think its a question of context length, attention and task. Modern models can handle raw PTX pretty well. If you have below 20k lines, it's able to make its own abstractions in the thinking loop Nth pass when it needs to. The only reason we would have to make our own abstractions today would be to fill the limits of the current context context window attention trade-offs the companies make.
I think the article is calling for the redundancy of high-level tiling abstractions. There is simply no need to work at a higher level and give up performance today when code is free.
I feel like both abstractions and LLMs are time savers, so why not combine both.
Also, if I don't create abstractions and guide the LLM I've found that the codebase starts getting out of my reach. And until LLMs can maintain code ad infinitum I like to understand my code.
I can see why it might not matter in hardcore performance coding though.
The tone of the article reminds me of the OMeta effort, where a system would be described by concise mathematical rules and OMeta libraries would generate the concrete code (many times larger).
it sounds like a bad abstraction. ime llms are really bad at reasoning through efficiency and utilization problems. they fail at scheduling and bin-packing for the same reason. it's actually difficult, multivariate, and not great.
i would be shocked if a well designed framework were less efficient than "bespoke" clankercode for low-level work
This is probably true. Today. But I think we're finding the problems LLMs are solving to be both paradoxically predictable but surprising at the same time. Not saying you're wrong, but scheduling and bin-packing seem like cards that will eventually fall to a bespoke prompt.
I mean, the post was written by a Stanford CS lab, so I'm inclined to believe that they know what they're talking about and are not just bad at creating abstractions.
I know nothing about the PhD candidate and professor who co-authored this, but I don't think this statement makes sense in general.
Typically CS labs at universities contain people who have not spent a significant amount of time exposed to large industry codebases and the corresponding complexity. I think the post would have more credibility coming from e.g. the platforms team at a tech company with a monorepo.
Well, they’re also probably not scaling up in the same way as any of the commercial AI offerings, let alone the frontier labs. Faculty at Stanford probably have some decent hardware to play with, but they do not have data centers. I don’t doubt that they know their way around CUDA/PTX, but it’s not clear how relevant their message is given that their research code is very likely not being deployed in production, or at scale.
The machine learning community decided to choose Python as the main language, which costs probably tens of millions of dollars in bugs every year due to it not being type checked (astral sh is fixing this though)
The main problem with Python is that, if you’re not doing your work in highly optimized numeric libraries (which are usually written in C), then you’re paying terrible overheads to use the Python interpreter. Type checking doesn’t help with this because Python is dynamically typed but static types could in principle. Is that what you mean?
I mean yes the python interpreter is not great, but I'm talking about bugs created by accidentally passing a negative number where a positive one should go, using a tensor of the wrong size etc.
I don't have any ml experience with python only numerical libraries and I always have to be careful what I'm doing otherwise an experiment can go Kaput. Types stop that.
I think it's generally fair to assume that you don't become a Stanford CS professor by being bad at writing code and creating abstractions, and that the average professor (let alone one at a prestigious university) is more knowledgable than your average HN commentor
I kind of angree with the anrgument that for an ideal AGI abstractions are not needed. It would write everything perfectly without even needing a programming language. It would know everything to the byte and would create perfect machine code meeting all the requirements as perfect as it’s possible.
But the reality is different. First of all LLM were trained on current data, with the abstractions we currently use.
Secondly they suffer they same problems we do, their context size is way too small to just simply ignore abstractions.
I feel like this is the exact opposite of the conclusion I've been coming to. In an age where anyone can vibe code stuff at the drop of a hat, I want the ability to assert guarantees/contracts at a high level, and then let AI work out the details. I want to force AI to work within the confines of an abstraction, not independently of it.
Yes. Compare also https://www.khoury.northeastern.edu/home/cmartens/Courses/74... where the abstraction itself mechanically enforces certain guarantees and contracts.
I have the same thought on this. Having some abstraction where we have total control and we can make clear judgments is the perfect place where AI should. Removing this abstraction will just make things hard for us and just pray that all the guards around are sufficient.
formal verification? maybe theorem prover or hoare logic can come into play here.
> I want to force AI to work within the confines of an abstraction, not independently of it.
Yes, this is the way. We need programming languages that make this easier.
> I want the ability to assert guarantees/contracts at a high level, and then let AI work out the details. I want to force AI to work within the confines of an abstraction,
Exactly right!
More details in my comment here - https://news.ycombinator.com/item?id=49269323
See also, Software Abstractions: Logic, Language, and Analysis by Daniel Jackson - https://mitpress.mit.edu/9780262528900/software-abstractions...
“First, an abstraction isn't just a way to manage cognitive load; it's a shared surface where application, reuse, and review attach.”
That is some seriously convoluted writing.
Claude seems to love the word "surface". I'm almost surprised to not find the verb "buy" to mean "get" in this generation.
Agreed. Turned into some ai slop quickly.
Precise specs must always be given, they cannot be reasoned into existence, because they are shaped by external considerations.
No matter how intelligent the executor is, without knowledge of the relevant external context, specs will always have to be clearly defined and given.
The post seemingly tries to get at this with its discussion of 'oracles', but the quality of its writing and argumentation does it no favors. I actually hope it was written by AI, because if not, the authors could stand to benefit from a Claude detox. It's rife with the signs of brainrot from LLM over-reliance.
> Precise specs must always be given
This is the paramount need with AI.
Earlier when we were writing code by hand, since both specification and coding were done by us we could easily iterate over them in our head and thus keep them in sync.
Now the only input is the specification and it must be precise (however incomplete) so that we can be sure that there is no ambiguity when AI interprets it. Iterate and refine the spec as needed and you are assured that the code does what you want it to do. Inform AI to enforce the invariants from the spec directly in code as asserts/contracts and you have guaranteed traceability through code. This is the "Correctness-by-Construction" (CbC) approach to programming.
It would be worthwhile for folks to study the classic specification languages like Z-notation/B-method/Alloy/etc. and learn to use those productively with AI.
Some resources:
VibeContract: The Missing Quality Assurance Piece in Vibe Coding - https://arxiv.org/abs/2603.15691
Specification-Driven Development as the Foundation of AI-Native Enterprise Software Engineering - https://arxiv.org/abs/2607.16680
We need abstractions more than ever. The real point is we should retire unnecessary abstractions.
A good abstraction is a single edged sword which simplifies the task. A mediocre abstraction is a double-edged sword. A bad abstraction is like a single edged sword with a restrictive handle and the sharp edge is facing towards you.
I'd say: A good abstraction is a formal and abstract statement about the nature of the underlying (sub)system. It is self consistent and allows an easier way to reason and interact with greater complexity underneath.
And the more you see an abstraction as a "wad of API calls and functionality", the more leaky the story gets.
Some systems are notoriously difficult to get this statement right because they are volatile and prone to changes. But I think as in live or in academia, our aspirations should be to strive for a better abstract understanding and keep building better abstractions.
This is such a poor idea. LLM Agents don't have taste (abstraction capabilities). They are kind of like water, they take the shape of the container they're in. They are so much powerful when you build your own framework they can work in.
Abstractions are ultimately a tool for humans to manage complexity in a particular class of problem, and to reduce cognitive load. Good abstractions come from imaginative human brains with taste and lived experience. Abstractions are also mind constructs that often have analogies in the real world. Even at the level of the CPU circuitry, abstractions serve that role. An LLM can only spit out what was already invented by humans and stitch it together in a tasteless, erroneous manner.
Bruce Lee was ages ahead of its time with the Water phrase.
That is not what the text is arguing for and it has many good ideas, dropping the abstractions but keeping the test harness is one of them. I've worked on many aspect of programming language implementation through the years and I would struggle with the abstractions of parser-generators and bytecode designed by committee like an enterprise Java developer struggles with the Hibernate ORM. Dunno what people are putting in their prompts but ask LLM to roofline and it will pursue that target like a bloodhound.
Many abstractions we encounter in software industry are poor abstractions which are counter-productive. I agree that we should drop those...
But we can't drop all abstractions. It's not physically possible. The AI agent is going to break logic up into files... The AI will create/impose an abstraction for each piece of logic whether we like it or not.
So saying "drop abstractions" is actually saying "let the AI decide what the abstractions should be" and unfortunately because LLMs are trained on average code, those abstractions are often pretty poor.
Coming up with the right abstractions is actually one of the main skills which AI hasn't automated and where the human brings the most value. It affects maintainability directly; including when using AI.
I've worked on projects with poor abstractions and ones with good abstractions using AI. The ones with poor abstractions require 10x to 100x more tokens and time to solve problems and implement new features. You're constantly fighting it to prevent it from coming up with nasty hacks and workarounds. Poor abstractions create the need for hacks and workarounds.
Software abstractions are a reification of problem domain understanding. They embody a solution within the mathematical constraints of a programming language such that the collaborations, when done properly, appropriately reflect said understanding.
Discarding abstractions is nothing more than rediscovery of a Big Ball of Mud[0].
0 - https://www.laputan.org/mud/mud.html
Abstractions aren't a burden though, they are more like a support. A good abstraction let's you write 10 programs in the time it would have taken to write one. Also, we now have "production" languages with generics and monomorphization so abstraction is easier than ever.
Djikstra has a great article as to why English language programming will always be second to a programming language. A "formal system" (edited from regular language) is the most precise way to specify things. An "abstraction" is basically a domain specific language.
The way I like to use LLMs is to build abstractions. I like to build mathematical code and ask the LLM to use it. I think that LLMs are very mathematical thinkers and they like it when they see Semigroup<T>. And it's not hifalutin either, I'm processing calculations along DAGs with a million+ nodes in milliseconds, thanks to abstractions
LLMs have been trained on a lot of data and have built representations of various concepts and links between them from that training data. This is why they are good when seeing names of things like `Semigroup` as they can draw on all the information about that concept from multiple sources (mathematics papers and discussions, programming articles and code, etc.).
There was an article or comment somewhere that said that when an LLM was prompted in comments/variable names about a complex algorithm or something like that in a very specific domain it was very knowledgeable. However, when given different names/terminology for the same thing it didn't understand the problem it was prompted to solve.
This is also why LLMs are good at generating code using Bootstrap, Tailwind or any other technologies as they can relate terms like `flex` and `grid` to various layout patterns. So using sensible names from the literature/specifications/etc. helps both developers and LLMs.
If I want to not care about implementation details on an era of AI written code, abstraction is exactly what I need.
agents are unlike humans in many ways but they have their own limitations. it's magical thinking to believe that they are able to cope with zero software abstractions, especially as a codebase increases in size and complexity
and today's agents increase codebase size and complexity much faster than humans do via traditional software engineering methods, so this is likely to hit a wall faster than if human software teams were to do this experiment.
Just yesterday, for fun, I asked Codex to generate an “online e-commerce site” in ARM assembly. To its credit, it did actually generate a program that served up a webpage over a socket, but it really did not do what I asked. The program still pulled in a large number of shared libraries (something I’ve never really thought to try in assembly). And… it was not actually a functioning e-commerce site. Iterating on that initial prompt proved painful—the program was extremely brittle and now I had to review and talk about ASSEMBLY. Maybe we can dispense with abstractions someday, but holy cow, not yet. I would much rather write an e-commerce platform in C than try to vibe-assembly my way to one.
Enjoy setting thousands of dollars on fire for fun!
As long as they’re not my dollars, fine with me.
Yes exactly.
"Why not bomb every square inch?", "Why would you ever let go of the machine gun trigger?", etc.
I assume there must have been moments in the history of war when such bad and desperate ideas were seriously proposed.
The fact that we're still in this profoundly ignorant era of LLMs is embarrassing.
Many times I wonder if it's possible to collapse abstractions? The idea of making the whole stack simpler. I'm not overly optimistic of LLMs achieving this, but it they do, I will be paying more attention.
> The job of abstraction as a cognitive offloader is starting to retire. Agents are taking that job.
Call me when the agents can take my high level directives and write assembly.
Following this argument to its natural conclusion, we should tell LLMs to generate the binary directly. It's still an abstraction, but it's the lowest level we can go to on current consumer hardware.
I don't think raw machine code (not even assembly) is the best form to reason about program logic. It just takes too many steps to execute sophisticated processes to keep them all in your head at once - or keep them all in an LLM context at once.
Personally I think we will just become more ambitious with our abstractions since the LLMs can generate more complex stuff at the lower level. To take the article's examples, LLMs will write kernels that fuse 3+ layers of a model, so the abstractions can enable more complex forms of kernel fusion.
This holds half-true.
What we decided to do is essentially just hand-rolling PTX with the agents under a harness. If there is lacking some function, we write/take a CuteDSL kernel, export PTX on compilation, transform it with the harness and then feed it into the agents.
We beat cuBLAS, and we beat all of abstractions - Triton, Helion, TLX, Mojo, ThunderKittens, cuteDSL, etc on Hopper and Blackwell for all of our workloads over 3-4 weeks.
vLLM dropped torch.compile support because they realized that they programmers were good enough to just generate the Triton kernels directly for all the passes efficiently.
If you work with this for prod the writing is on the wall sadly. The abstraction layer is just really much lower if you want full perf.
But you end up writing your own abstractions in the process?
Ish, today I am on the fence because sometimes(half-half) its necessary, a year ago it was completely impossible, but I think its a question of context length, attention and task. Modern models can handle raw PTX pretty well. If you have below 20k lines, it's able to make its own abstractions in the thinking loop Nth pass when it needs to. The only reason we would have to make our own abstractions today would be to fill the limits of the current context context window attention trade-offs the companies make.
I think the article is calling for the redundancy of high-level tiling abstractions. There is simply no need to work at a higher level and give up performance today when code is free.
I feel like both abstractions and LLMs are time savers, so why not combine both.
Also, if I don't create abstractions and guide the LLM I've found that the codebase starts getting out of my reach. And until LLMs can maintain code ad infinitum I like to understand my code.
I can see why it might not matter in hardcore performance coding though.
The tone of the article reminds me of the OMeta effort, where a system would be described by concise mathematical rules and OMeta libraries would generate the concrete code (many times larger).
Reading this, a lot of the sentence construction felt like LLM slop and it seems like Pangram agrees. https://www.pangram.com/history/35257829-ad18-4128-9d61-fa03...
Adding slop text makes even the core idea feel like LLM slop, even if the idea was original thought by the authors.
I would also prefer if they add a heading to this article mentioning that they used LLM’s writing it rather than just not mentioning it anywhere.
it sounds like a bad abstraction. ime llms are really bad at reasoning through efficiency and utilization problems. they fail at scheduling and bin-packing for the same reason. it's actually difficult, multivariate, and not great.
i would be shocked if a well designed framework were less efficient than "bespoke" clankercode for low-level work
This is probably true. Today. But I think we're finding the problems LLMs are solving to be both paradoxically predictable but surprising at the same time. Not saying you're wrong, but scheduling and bin-packing seem like cards that will eventually fall to a bespoke prompt.
I mean, the post was written by a Stanford CS lab, so I'm inclined to believe that they know what they're talking about and are not just bad at creating abstractions.
I know nothing about the PhD candidate and professor who co-authored this, but I don't think this statement makes sense in general.
Typically CS labs at universities contain people who have not spent a significant amount of time exposed to large industry codebases and the corresponding complexity. I think the post would have more credibility coming from e.g. the platforms team at a tech company with a monorepo.
There is something to be argued about industry vs academic experience but this post has nothing to do with large industry codebases
Well, they’re also probably not scaling up in the same way as any of the commercial AI offerings, let alone the frontier labs. Faculty at Stanford probably have some decent hardware to play with, but they do not have data centers. I don’t doubt that they know their way around CUDA/PTX, but it’s not clear how relevant their message is given that their research code is very likely not being deployed in production, or at scale.
Disagree. The abstractions they are talking about aren't like, the y-combinator. They're talking about boring software engineering abstractions.
sounds like it might help to know something about the phd candidate and professor
Heh, not really
The machine learning community decided to choose Python as the main language, which costs probably tens of millions of dollars in bugs every year due to it not being type checked (astral sh is fixing this though)
Hasn’t mypy been a thing for years already?
The main problem with Python is that, if you’re not doing your work in highly optimized numeric libraries (which are usually written in C), then you’re paying terrible overheads to use the Python interpreter. Type checking doesn’t help with this because Python is dynamically typed but static types could in principle. Is that what you mean?
I mean yes the python interpreter is not great, but I'm talking about bugs created by accidentally passing a negative number where a positive one should go, using a tensor of the wrong size etc.
I don't have any ml experience with python only numerical libraries and I always have to be careful what I'm doing otherwise an experiment can go Kaput. Types stop that.
why?
I think it's generally fair to assume that you don't become a Stanford CS professor by being bad at writing code and creating abstractions, and that the average professor (let alone one at a prestigious university) is more knowledgable than your average HN commentor
Professors have no reputation for writing good code. Academic code is fairly notorious for being under abstracted, hard to follow, messy, etc.
If a passerby told me this story I’d have the same guess though!
When will we learn?
but what have we learned? roughly quoting the last scene in "burn after reading"
cia boss: what did we learn, palmer? cia officer: i don't know, sir. cia boss: i don't fkin know either. i guess we learned not to do it again.
In two words, accept slop.
No.
I kind of angree with the anrgument that for an ideal AGI abstractions are not needed. It would write everything perfectly without even needing a programming language. It would know everything to the byte and would create perfect machine code meeting all the requirements as perfect as it’s possible.
But the reality is different. First of all LLM were trained on current data, with the abstractions we currently use.
Secondly they suffer they same problems we do, their context size is way too small to just simply ignore abstractions.
Even with an ideal AGI you would need abstractions because in order to talk in specifics you would need an abstraction.