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.
Retire the Abstractions
51–60 of 61 posts
Re: Retire the Abstractions
#52Precise 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.
Re: Retire the Abstractions
#53Reading 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.
Re: Retire the Abstractions
#54Precise 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.
> 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
Re: Retire the Abstractions
#55We 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.
Re: Retire the Abstractions
#56I 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 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...
Re: Retire the Abstractions
#57I 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.
Re: Retire the Abstractions
#58This 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.
Bruce Lee was ages ahead of its time with the Water phrase.
Re: Retire the Abstractions
#59The 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).
Re: Retire the Abstractions
#60This 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.