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.
“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.
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.
If I want to not care about implementation details on an era of AI written code, abstraction is exactly what I need.
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.
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.
> 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.
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.
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.
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.
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
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.
In two words, accept slop.
No.
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.