LLMs Bring New Nature of Abstraction

This would require Martin Fowler to know about this article and to appreciate that it might be important.

He might, but I am not encouraged by his prior work or those of his contemporary Agile boosters. Regardless of how you feel about the Agile Manifesto (my feelings are quite mixed), these boosters over the last 25-ish years tend to love citing Agile and OOP things and rarely seem to look beyond that to historical or fundamental CS.

They found a lucrative niche telling management why their software process is broken and how to fix it. And why the previous attept at Agile wasn't really Agile and so things are still broken.

Perhaps now they have to ride the AI hype train, too. I can only guess that whatever AI-driven lucrative consulting / talk-circuit may emerge from this will also be able to explain why the last AI attempt wasn't really AI and that's why things are still broken.

Interesting read and thanks for sharing.

Two observations:

1. Natural language appears to be to be the starting point of any endeavor.

2.

> It may be illuminating to try to imagine what would have happened if, right from the start our native tongue would have been the only vehicle for the input into and the output from our information processing equipment. My considered guess is that history would, in a sense, have repeated itself, and that computer science would consist mainly of the indeed black art how to bootstrap from there to a sufficiently well-defined formal system. We would need all the intellect in the world to get the interface narrow enough to be usable, and, in view of the history of mankind, it may not be overly pessimistic to guess that to do the job well enough would require again a few thousand years.

LLMs are trying to replicate all of the intellect in the world.

I’m curious if the author would consider that these lofty caveats may be more plausible today than they were when the text was written.

But that's not really automation.

It's more search and act based on the first output. You don't know what's going to come out, you just hope it will be good. The issue is that that the query is fed to the output function. So what you get is a mixture of what is a mixture of what you told it and what's was stored. Great if you can separate the two afterwards, not so if the output is tainted by the query.

With automation, what you seek is predictability. Not an echo chamber.

ADDENDUM

If we continue with the echo chamber analogy:

Prompt Engineering: Altering your voice so that the result back is more pleasant

System Prompt: The echo chamber's builders altering the configuration to get the above effects

RAG: Sound effects

Agent: Replace yourself in front of the echo chamber with someone/something that act based on the echo.

Determinism isn't always ideal. Determinism may trade off with things like accuracy, performance, etc. There are situations where the tradeoff is well worth it.

I think this gets at a major hurdle that needs to be overcome for truly human-level AGI.

Because the human brain is also non-deterministic. If you ask a software engineer the same question on different days, you can easily get different answers.

So I think what we want from LLMs is not determinism, just as that's not really what you'd want from a human. It's more about convergence. Non-determinism is ok, but it shouldn't be all over the map. If you ask the engineer to talk through the best way to solve some problem on Tuesday, then you ask again on Wednesday, you might expect a marginally different answer considering they've had time to think on it, but you'd also expect quite a lot of consistency. If the second answer went in a completely different direction, and there was no clear explanation for why, you'd probably raise an eyebrow.

Similarly, if there really is a single "right" answer to a question, like something fact-based or where best practices are extremely well established, you want convergence around that single answer every time, to the point that you effectively do have determinism in that narrow scope.

LLMs struggle with this. If you ask an LLM to solve the same problem multiple times in code, you're likely to get wildly different approaches each time. Adding more detail and constraints to the prompt helps, but it's definitely an area where LLMs are still far behind humans.

Same reason humans use high-level languages: limited context windows.

Both humans and LLMs benefit from non-leaky abstractions—they offload low-level details and free up mental or computational bandwidth for higher-order concerns. When, say, implementing a permissioning system for a web app, I can't simultaneously track memory allocation and how my data model choices aligns with product goals. Abstractions let me ignore the former to "spend" my limited intelligence on the latter; same with LLMs and their context limits.

Yes, more intelligence (at least in part) means being able to handle larger contexts, and maybe superintelligent systems could keep everything "in mind." But even then, abstraction likely remains useful in trading depth for surface area. Chris Sawyer was brilliant enough to write Rollercoaster Tycoon in assembly, but probably wouldn't be able to do the same for Elden Ring.

(Also, at least until LLMs are so transcendentally intelligent they outstrip our ability to understand their actions, HLLs are much more verifiable by humans than assembly is. Admittedly, this might be a time-limited concern)

Why would the ability to generate source code imply the ability to generate bytecode? Also you wouldn’t want that, humans can’t review bytecode. I think you may be taking the metaphor too literally.

I agree here. English (human language) to Bytecode is the future.

With reverse translation as needed.