Skip to content

Comment on I accidentally turned LLM memory into program analysis

Comments

So he's using an LLM to generate data stored in an "is_a" representation. That's so classic AI.

Soon, he'll discover that he needs quantifiers. Then that "for all" is too strong sometimes, and he needs "for most". That way lies Cyc.

It's not a bad idea. But it does have a history.

In general, what all the big LLM providers are doing is moving towards classical & neural (neuro-symbolic) AI - even though they dont publicly admit it because that would counter their claims for years of "scale is all you need" (which has vanished with diminishing returns, see $MS / altman's GPT-5 bet).

It seems like the two approaches compliment each other nicely. Human intelligence also relies on parallel information processing. LLMs are like a massive working memory, incredibly effective but with a similar set of limitations. What they lack is a symbolic model of reality, something that they can build and refine.

It's strange to frame this as classical vs scale. Us humans have a powerful inference engine in our heads. We also use a calendar to avoid re-deriving everything from first principles before we've had our morning coffee. Businesses couple many creative (human) agents together. They also have processes and rules.

It isn't, and it is not what was described: its about unbounded imagination (neural / LLM) that needs reality constraints (symbols / rules) to produce useful output.

Think of it like human imagination may do anything (flying cars), but the real world has constraints and we use language/writing (symbols) and rules bound to them to simulate and reconcile our imagination with reality to actually flow our energy into something that may work in the real world.

they dont publicly admit it because that would counter their claims for years of "scale is all you need" (which has vanished with diminishing returns, see $MS / altman's GPT-5 bet).

Is my reading comprehension just completely broken or something? The above certainly sounds like "the powers that be want us to believe that attention is all you need".

The various advances in LLM technology tend to rhyme with the advances in computer programming in general. For example, the stunts that involved getting LLMs to create compilers and browsers are really just extremely expensive[0] versions of genetic programming (none of it would have worked without using the test-suite as a fitness-function). The recent news of migrations from one test-framework to another (featuring Asana, I believe), was something that we could always do trivially in a language that was based on S-Expressions (Lisp, Scheme, etc).

In fact, both Cyc and the "AI" Labs have the _same basic thesis_: Intelligence is, primarily, a data entry problem. They just disagree about what kinds of heuristics should be run over that data (logic-programs, neural-nets).

Whenever I read about someone using LLMs to write code, it _very closely_ resembles how Lenat was using Eurisko/Cyc to solve problems: they let the system run continuously, and they "nudge" it in "interesting" directions, "when it gets stuck", or "runs out of steam". (Quotes indicate their phrasing, not mine)

Even Lee Spector noticed something analogous with his genetic programming system. When he tried to get it to discover optimal data structures (or maybe it was sorting algorithms, I forget), the system would quickly "run out of steam", without a solution. But when they added new verbs/opcodes to the system, that were a better fit for that domain (e.g. index-based memory loads + stores), it converged on a solution very quickly (even for GP, domain specific languages keep delivering unreasonable wins). You will note that this rhymes with the "micro-theories" of Cyc, which in turn rhyme with the SLMs of the AI labs.

In my personal experience, most of the "silver bullets" do not work (obviously), but some of them do nudge you towards being a better programmer (by refining your intuition about the problem specifically, and computers more generally).

EDIT: just remembered something. LLMs tend to produce larger and larger programs over time, and most people (IIRC) interpret this as a kind of entropy. This happens to rhyme with a similarly observed behavior in GP. Most genetic programs that do not have a fitness function that rewards smaller size, tend to grow in an unbounded way. The reason for this, is that most of the code/genes are useless, and random mutations do not lobotomize the program under evolution. I suspect that the coding LLMs tend to grow their code for similar reasons.

[0]: I suspect that, this was mostly a triumph of enormous amounts of hardware, more than the actual LLM technology. I further suspect that a traditional GP approach, on the same quantity of hardware, could have gotten there faster (if not better as well).

I would not necessarily call it genetic programming. But you can discover the same pattern e.g. for human knowledge. We have a domain language for math and when we go deeper we will have domain language for algebra, discrete math etc.. and we could go even further to breaking it to even for more specific areas simply to compact the information to deliver. The goal is more and precise information with less words, it might be for communication or to be able to fit the knowledge into the processing capacity. So for me it is not like the advances in programing languages, but more like to compacting information/representation with domain language. It's similar but not quite genetic programming.

nz

I am not calling it GP. I am pointing out that AI-coding systems tend to resemble GP systems in terms of both broad architecture, and in terms of how the code/genome is generated. Also, I already mentioned domain specific languages, in the context of GP, and how (effectively) creating one (i.e. selecting only relevant genes/verbs) that was a better match for the problem domain, made the GP find a solution infinitely faster[0]. Clearly these two things are not contradictory, and are clearly related, to the point that they can be combined. I am not sure what about my comment gave you the impression that I thought one was contradictory with the other. Hope this follow-up clears things up.

[0]: Because, in effect, we are decreasing the size of the search-space. Every programming-language project is basically a set of bets, that the design choices will decrease the size of the search space for the users of that language (most Unix commands fit this pattern, as do most well designed APIs). Mathematics is similar, in that the notation is specialized and sparse (even the named constants and variables have symbolic names, instead of meaningful names). Most system dynamics models could have the names of entities replaced with id-numbers, and they would continue to function. The whole point of (for example) a library is to give a tiny parameterized notation/language, that the user can use to express a solution to their problem, in terms of the problem domain itself. This decreasing of the search-space, is an act of compression. I have to say, I am a little confused by your reply, because it has the tone of a disagreement, but it does not really disagree with anything that I have written. Also, I have given various examples to support my analogies, but you have offered zero examples, and I suspect that there would be less confusion (on my part) if you did.

I find your perspective on LLM generated programs to be an interesting and fresh take

How do you know this?

They're probably referring to tech like reasoning models, or agent harnesses for example, which are arguably slowly moving things towards the symbolic end of the spectrum.

LLMs using REPL are one instance of symbols to "bounce" their prediction against domain constraints for verification. Also shout out to Gary Marcus who was right after all (and LLM companies wasting 100s of billions of dollars for years in-between on pure scaling).

With validity intervals mentioned it'll also be nice to have LTL's "next" and "until" too.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.