Rendered at 19:39:31 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
rtpg 17 hours ago [-]
I'm having a bit of trouble reading this over understanding the case where I would rather the agent update itself, vs having the agent write out tools and then call those tools.
I rarely find myself thinking "ah I need the agent interface to change". And the vague generality of how agents work play into making it fairly easy to "just" have it rely on some external tooling to do anything special.
Maybe this is just a counterargument to the lisp philosophy as a whole but... well... I use Emacs for example and am fine with a model of "an agent can look at my Emacs config" rather than "my agent _is running my Emacs session_".
magnusi 4 hours ago [-]
(disclaimer: I made Autolith)
Well, having the agent write out tools and call those tools is something I consider to be under self-modification also.
But there are other things, when it's useful:
- You want the agent to update without restarting a session and e.g. killing child LISP REPLs and long-running sub-agents
- There is a bug in the harness that bothers you (Autolith records papercuts and can generally solve them via self-modification)
- You want to temporarily or permanently hook into literally any part of the agent lifecycle
- You are of a ricing persuassion and want to change how the agent looks (very surface level, but I have seen people do it)
- Related to the hooking point, you want to integrate Autolith with something else or make it emit something. We cannot predict all the knobs where you might do this, or how selectively you might do it, but self-modification lets you do it
- You want to add support for yourself for non-standard or proprietary/secret providers
That's off the top of my head. The secondary benefit is that this is great at developing the agent itself as a project. It can try/triage the changes it's working on, try its own tests, probe at things, and so on. This is why by far, the changes submitted to Autolith developed by Autolith are by far the highest quality out of all clanker-submitted changes.
rufius 2 days ago [-]
This is an interesting idea. I was thinking about something similar in Smalltalk or Erlang the other day. Mostly building on the actor/object+mailbox concept.
I didn’t actually do anything with that idea yet but may look at the idea in Elixir this weekend.
magnusi 1 days ago [-]
Hi!
I was thinking about Smalltalk as well before I made Autolith. I ended up going with Common Lisp because I know Lisp much better (last time I used smalltalk was like, whew, 2014 or so) and because it has better platform support and ecosystem (at least in my experience).
I think Elixir could be great, I knew a guy who was trying to do an agent in Elixir, but sadly didn't get far.
Keep me posted if you get anywhere! And if you'd like to try Autolith, I am happy to help with issues/questions on our Zulip, haha
magnusi 2 days ago [-]
Hello guys, I am the author of Autolith (github.com/luciusmagn), I am pretty new to Hacker News. I will respond to your posts as soon as I can :)
cc_ashby 1 days ago [-]
This is really interesting. I have felt for the past couple years that the moldability of Common Lisp lends agents the appropriate affordances to “do the right thing” via experimentations.
I see there is a section on RLMs; have you ran Autolith via agentic benchmarks? I would love to see comparisons with Prime Agent.
magnusi 1 days ago [-]
We have not done that yet, it's one of the major priorities. Autolith implements RLM a bit differently than Prime Agent (although it both comes from the same paper):
In Autolith, the top level agent is traditional, but has RLM tools which it can use for the things RLM is good at, namely exploratory work, processing a lot of files at once, backward context research and so on.
iovrthoughtthis 1 days ago [-]
This webpage is beautiful.
magnusi 1 days ago [-]
Thank you!
hankbond 17 hours ago [-]
i'm also an enjoyer of one-bit focused design (https://hank.bond) and love your take on this type of minimalism!
hsaliak 19 hours ago [-]
Ever since coding agents came out, It felt a little like we were implementing the self improving lisp programs of old.
This idea almost gets us there.
Could the next step be to make it the program itself?
magnusi 3 hours ago [-]
Well, I've had success loading Lisp programs into Autolith and letting it poke at them from the inside, haha!
ggangsir 2 days ago [-]
How do differentiate with cursor ?
magnusi 1 days ago [-]
Hi, I am the author of Autolith. What do you mean by that? I'd love to give you a good answer, haha
bbor 14 hours ago [-]
Well I'll be damned if that isn't one of the best sites I've ever seen, with a great ethos. And in Lisp! Inspiring stuff. Godspeed, Lucius :)
magnusi 3 hours ago [-]
Thank you, I am glad you like it, haha! I was inspired by Xerox PARC stuff, mostly Interlisp! :)
Hi, thank you both for this. I built my own, worse, harness in my own, worse, lisp and I will also be joining the chat
magnusi 3 hours ago [-]
Glad to have you!
yogthos 4 hours ago [-]
It's a fun thing to do. I'm really intrigued by the idea of a harness that can tune itself to a particular project. As I've been hacking on samizdat, I realized that you want to have a set of canned workflows as a starter pack. Then the tool makes a copy of that in each project, and keeps adjusting the workflows based on where it gets stuck, or when it thinks of ways to do stuff better. So, each project can evolve in its own way.
The key trick is that workflows are represented as state machines which are just data structures. So, the LLM can easily inspect and change them to add or remove behaviors as it sees fit.
I have a specific supervisor role whose sole job is to watch how implementer agents are doing and whether they're making progress. When it sees them get stuck, its job is to unblock them.
yogthos 1 days ago [-]
Oh yeah sure thing, would be fun to chat and swap ideas. :)
eeyzs1 1 days ago [-]
[flagged]
vivzkestrel 2 days ago [-]
stupid question: why are so many people obsessed with LISP?
magnusi 1 days ago [-]
It's the most flexible language there is, while also fairly performant and having great features for extensibility and debugging
a2ff6eeb0 2 days ago [-]
Given that the most important feature for agent performance is the popularity of the language, ie, the amount of training data, (https://danluu.com/pl-tokens/), why would you cause problems for yourself by using Lisp rather than Python/Javascript if you care mainly about results fast, or C/C++/Rust if you care about performance too?
magnusi 1 days ago [-]
Well, I made Autolith in Common Lisp because I like Lisp and I think it's by far the best and most practical language for self-modifiable live image agents.
I have been trying Scheme and CL with LLMs for the last three years or so, and in recent months, I have finally decided that they are good enough.
My idea is that well, it's good enough that I can now produce more training data just by using Autolith with the most basic claude/gpt subs, haha
jbott 2 days ago [-]
> the most important feature for agent performance is the popularity of the language
This is explicitly called out as only weakly supported in that blog post:
- You should use a popular language
- There's weak support for this statement
a2ff6eeb0 2 days ago [-]
Feel free to do your own analysis -- my informal experiments backs this up, though. I see worse results when I try to do anything in an unpopular language.
It makes sense, needing to train the model on things that aren't already in its weighs takes up valuable context. Until we have models that update their weights based on what they've seen in their recent sessions and learn like people, this will be a problem.
For now, though, between the results I'm seeing here, and the lack of need to look at code, I think this kills off any reason for me to use less popular languages.
magnusi 1 days ago [-]
There is a Common Lisp pro you are not seeing and that is that it has by far the best OOB debuggability/introspectability (especially when using SBCL) out of any practical language, while still having great performance
evanjrowley 19 hours ago [-]
I see you're interested in avoiding the need to read any code. It might surprise you to learn that autolith is very capable at reading and updating it's own code. The captured sessions at the linked page are three examples of this.
magnusi 3 hours ago [-]
Correct, that's why I made it! :)
khalic 1 days ago [-]
There are many other confounding factors here, the type of prompting, how familiar you are with the language idioms, the context you gave, random bad quality runs, etc.
You can’t tell that with a few uncontrolled runs
a2ff6eeb0 1 days ago [-]
All of this applies to the LLM prompting subagents too, and the LLM is much more familiar with popular languages.
jauntywundrkind 2 days ago [-]
Your attempt was probably pretty, ahem, weak. How much support would you say you gave your goes, before you threw in the towel?
I don't think there's really ever a downside to leaning in and making use of a language or system that works for you. Trying to tell people they should just use the popular thing is, imo, bad advice to turn hackers and experimenters into boring people.
a2ff6eeb0 2 days ago [-]
A day or so for each of the oddball languages; again, I'm still waiting for an argument on why there's any value here, since the entire point of an agentic system like this is that I don't have to read the code. Experiment with the AI, sure, but you've got a pretty high burden of proof to show that AI is going to pick it up without a high per-prompt token cost.
AI changes the constraints here for now, since it can't permanently learn things. I'm waiting until that changes, but right now it's better to use what it knows out of the box if you want good results.
A better language doesn't buy me anything other than performance; the reason to stick an AI in here is to remove interactions with the code. I don't care what the AI chooses to use, as long as it gets results.
wild_egg 2 days ago [-]
In this case, the better language buys you increased iteration speed in addition to performance, and that is worth a lot.
a2ff6eeb0 2 days ago [-]
Why? I'm giving the system the same prompts either way.
wild_egg 1 days ago [-]
Because the system allows for it. Lisp is a far more powerful language which enables faster iteration and development.
If you give that to an LLM, it is then also able to iterate and develop faster.
a2ff6eeb0 17 hours ago [-]
I don't get how. I'm not interacting with the lisp, and the agents don't really get frustrated with slow compilation times or anything, and are perfectly adept at debugging.
The best that people have said about lisp is that evidence LLMs perform worse with it is weak.
rdb_ 2 days ago [-]
is it that llms write "better" typescript than let's say elixir because it has seen more of it..? or is it that you're relying on something like effect-ts to keep llms from tripping over even small things?
coincidentally, "good code" in popular lang is rarely directly attributed to only that part; and it's also about the underlying principles it tries to follow in the code... another example; is it typescript that's good, or are "types" inherently making things/feedback loops easier to reason about in llms? (only using ts here for all example because it's probably one of the most "trained on" pl)
a2ff6eeb0 1 days ago [-]
The first. Training data on a problem trumps most of the other considerations.
magnusi 1 days ago [-]
On the other hand, the more mainstream a programming language, the higher proportion of the training data is going to be terrible code.
I think there's an optimal ratio somewhere
a2ff6eeb0 1 days ago [-]
I haven't seen that matter. LLM code has tended to be kinda samey regardless of language. Or at least it used to be when I spent time looking at it.
These days I moved up the ladder of abstraction, so I don't really look; the main criteria I have is how the LLM gets things done.
hatefulmoron 1 days ago [-]
If it's samey regardless of language, isn't that in contradiction to your original theory? " .. the most important feature for agent performance is the popularity of the language .. "
a2ff6eeb0 1 days ago [-]
No, not really. It's a similar flavor of output, but there's less iterations to get a correct result. The training is mostly about reducing error rates on generation.
wild_egg 2 days ago [-]
LLMs have been solid at writing Common Lisp since Sonnet 3.5 and have been near flawless since the Opus 4.5 release.
The niche language thing is really not a problem at all any more. If you're working in some esolang it doesn't take more than a 1-2k token primer in the context to get great results, and lisp is popular enough to not even need that.
The benefit of having the agent directly in the image like with Autolith here is that it can directly inspect all defined symbols and explore and orient itself automatically. Really doesn't need much guidance to get great results.
magnusi 1 days ago [-]
(author of autolith here)
This all correct, I'd also add that in my experience, the GPTs are even better at Lisp, namely in the counting parentheses department.
Which is not an issue that much per-se because in Autolith, the harness detects Lisp file edits (CL, Scheme, Clojure) and gives hints when the edits lead to unbalanced files
(The heuristic is pretty simple, we detect if there's a mismatch, and if yes, it provide hints where the extra/missing might be based on indentation)
a2ff6eeb0 1 days ago [-]
But LLMs already do that with text, don't they? And I don't really want to interact with the code directly, so I'm not sure why I should care what language is used other than raw performance and LLMs ability to use it.
Do you have benchmarks on non-trivial tasks (say, generating zstd) that show it does any better than rust?
yogthos 2 days ago [-]
The obvious reason is that Lisp is perfectly suited for writing self modifying programs in a way pretty much no other language is. And as others pointed out, the evidence that agents work better with other languages is pretty thin. I've been using Claude, GLM, and DeepSeek with Clojure for around a year now, and they certainly do just fine in my experience.
In fact, I've had much easier time maintaining LLM assisted programs in Scheme and Clojure than other languages I've tried using because functional style naturally leads to low coupling. And that makes controlling context far easier than the rats nest of shared state that you have in imperative languages.
armitron 2 days ago [-]
This is not just false but egregiously wrong. The regular syntax of Lisp is a tremendous asset when it comes to LLMs being able to work directly in the image. If I had to score languages by how well they work with current LLMs, Common Lisp and Emacs Lisp would be at the very top.
magnusi 1 days ago [-]
It's not just the syntax, but also the tools for debugging, the image paradigm itself, and the iterative approach to development!
Autolith can spawn managed Lisp REPLs either from saved images (so it can do checkpoints) and triage changes before committing them to files, and then run test suites in the same REPL, it's been very useful for this.
a2ff6eeb0 1 days ago [-]
Do you have any benchmarks for larger tasks? The best others here have claimed is that it's not strongly proven to be harmful when you look at benchmarks.
I rarely find myself thinking "ah I need the agent interface to change". And the vague generality of how agents work play into making it fairly easy to "just" have it rely on some external tooling to do anything special.
Maybe this is just a counterargument to the lisp philosophy as a whole but... well... I use Emacs for example and am fine with a model of "an agent can look at my Emacs config" rather than "my agent _is running my Emacs session_".
Well, having the agent write out tools and call those tools is something I consider to be under self-modification also.
But there are other things, when it's useful:
- You want the agent to update without restarting a session and e.g. killing child LISP REPLs and long-running sub-agents
- There is a bug in the harness that bothers you (Autolith records papercuts and can generally solve them via self-modification)
- You want to temporarily or permanently hook into literally any part of the agent lifecycle
- You are of a ricing persuassion and want to change how the agent looks (very surface level, but I have seen people do it)
- Related to the hooking point, you want to integrate Autolith with something else or make it emit something. We cannot predict all the knobs where you might do this, or how selectively you might do it, but self-modification lets you do it
- You want to add support for yourself for non-standard or proprietary/secret providers
That's off the top of my head. The secondary benefit is that this is great at developing the agent itself as a project. It can try/triage the changes it's working on, try its own tests, probe at things, and so on. This is why by far, the changes submitted to Autolith developed by Autolith are by far the highest quality out of all clanker-submitted changes.
I didn’t actually do anything with that idea yet but may look at the idea in Elixir this weekend.
I was thinking about Smalltalk as well before I made Autolith. I ended up going with Common Lisp because I know Lisp much better (last time I used smalltalk was like, whew, 2014 or so) and because it has better platform support and ecosystem (at least in my experience).
I think Elixir could be great, I knew a guy who was trying to do an agent in Elixir, but sadly didn't get far.
Keep me posted if you get anywhere! And if you'd like to try Autolith, I am happy to help with issues/questions on our Zulip, haha
I see there is a section on RLMs; have you ran Autolith via agentic benchmarks? I would love to see comparisons with Prime Agent.
In Autolith, the top level agent is traditional, but has RLM tools which it can use for the things RLM is good at, namely exploratory work, processing a lot of files at once, backward context research and so on.
This idea almost gets us there.
Could the next step be to make it the program itself?
Never heard about Jolt, and I love Chez Scheme, it was my first Lisp!
Would you like to come to our Zulip at https://zulip.lambda-symbolics.com? We can exchange ideas for our harnesses
The key trick is that workflows are represented as state machines which are just data structures. So, the LLM can easily inspect and change them to add or remove behaviors as it sees fit.
I have a specific supervisor role whose sole job is to watch how implementer agents are doing and whether they're making progress. When it sees them get stuck, its job is to unblock them.
I have been trying Scheme and CL with LLMs for the last three years or so, and in recent months, I have finally decided that they are good enough.
My idea is that well, it's good enough that I can now produce more training data just by using Autolith with the most basic claude/gpt subs, haha
This is explicitly called out as only weakly supported in that blog post:
It makes sense, needing to train the model on things that aren't already in its weighs takes up valuable context. Until we have models that update their weights based on what they've seen in their recent sessions and learn like people, this will be a problem.
For now, though, between the results I'm seeing here, and the lack of need to look at code, I think this kills off any reason for me to use less popular languages.
You can’t tell that with a few uncontrolled runs
I don't think there's really ever a downside to leaning in and making use of a language or system that works for you. Trying to tell people they should just use the popular thing is, imo, bad advice to turn hackers and experimenters into boring people.
AI changes the constraints here for now, since it can't permanently learn things. I'm waiting until that changes, but right now it's better to use what it knows out of the box if you want good results.
A better language doesn't buy me anything other than performance; the reason to stick an AI in here is to remove interactions with the code. I don't care what the AI chooses to use, as long as it gets results.
If you give that to an LLM, it is then also able to iterate and develop faster.
The best that people have said about lisp is that evidence LLMs perform worse with it is weak.
coincidentally, "good code" in popular lang is rarely directly attributed to only that part; and it's also about the underlying principles it tries to follow in the code... another example; is it typescript that's good, or are "types" inherently making things/feedback loops easier to reason about in llms? (only using ts here for all example because it's probably one of the most "trained on" pl)
I think there's an optimal ratio somewhere
These days I moved up the ladder of abstraction, so I don't really look; the main criteria I have is how the LLM gets things done.
The niche language thing is really not a problem at all any more. If you're working in some esolang it doesn't take more than a 1-2k token primer in the context to get great results, and lisp is popular enough to not even need that.
The benefit of having the agent directly in the image like with Autolith here is that it can directly inspect all defined symbols and explore and orient itself automatically. Really doesn't need much guidance to get great results.
This all correct, I'd also add that in my experience, the GPTs are even better at Lisp, namely in the counting parentheses department.
Which is not an issue that much per-se because in Autolith, the harness detects Lisp file edits (CL, Scheme, Clojure) and gives hints when the edits lead to unbalanced files
(The heuristic is pretty simple, we detect if there's a mismatch, and if yes, it provide hints where the extra/missing might be based on indentation)
Do you have benchmarks on non-trivial tasks (say, generating zstd) that show it does any better than rust?
In fact, I've had much easier time maintaining LLM assisted programs in Scheme and Clojure than other languages I've tried using because functional style naturally leads to low coupling. And that makes controlling context far easier than the rats nest of shared state that you have in imperative languages.
Autolith can spawn managed Lisp REPLs either from saved images (so it can do checkpoints) and triage changes before committing them to files, and then run test suites in the same REPL, it's been very useful for this.