Yes, this is the way. We need programming languages that make this easier.
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...
That is some seriously convoluted writing.
No matter how intelligent the executor is, without knowledge of the relevant external context, specs will always have to be clearly defined and 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
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.
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.
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.
Discarding abstractions is nothing more than rediscovery of a Big Ball of Mud[0].
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
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.
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.
"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.
Call me when the agents can take my high level directives and write assembly.
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.
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.
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.
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.
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.
i would be shocked if a well designed framework were less efficient than "bespoke" clankercode for low-level work
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.
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 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.
If a passerby told me this story I’d have the same guess though!
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.
No.
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.