[Cuis-dev] [Loose Discussion] LLM agents in Smalltalk

[Phil B]

I've played around with the LLM / Smalltalk combo... at a superficial level
it looked promising, but the more I dug into it the more problems I had
(far more than with other languages out of the mainstream)  I think this
was due to:

1) While none of the major LLMs were trained extensively on Smalltalk, it
was a 'long-tail' language that happened to have some code ingested for...
that's the pro: that it knows it at all.  This is likely due to places like
Stackoverflow and programming blogs that contain far more mainstream
language/library content but also have some Smalltalk coverage.

2) Smalltalk dialect fragmentation made generating anything too far beyond
tutorial level coding all but impossible.  The long-tail content
ingested by the LLM was a mashup of Smalltalk/Squeak/Pharo/Cuis/etc and it
would constantly confuse and get things wrong due to evolution across and
within dialects.

It was far better at summarizing/tweaking existing code than writing new
code.  While this seems to be generally the case with LLMs, it was far more
pronounced with Smalltalk code.  I'd say that the history of
Smalltalk's image-based development as well as dialect divergences has
probably hurt it as far as out of the box LLM support goes.

If you're thinking about anything serious with an LLM, I think you're going
to want to go with a RAG solution that feeds in code from the image as well
as other relevant code (from Smalltalk as well as other languages) and
other information for what you are working on.  Could you feed in just the
code from a Smalltalk image into a 1 million+ token context window?  Sure,
but I don't think you'd get nearly the results you're expecting... unless
you're doing image development rather than application/library
development.  I have gotten some stunning results with RAG-based systems
and lesser used programming languages/libraries precisely because the RAG
environment had comprehensive coverage of how to solve problems in other
languages and it was able to translate the answer in my target language.

LLMs aren't that smart... they just look like they are because of all
the human generated content they've ingested.  I tend to get better results
if they can translate an answer from one (programming) language to another
rather than trying to 'reason' their way through it without having a
reference implementation.  If you don't keep them on the rails both with
your prompt and context, they will often tell you pretty much what you want
to hear regardless of whether or not it is correct because that's what they
were designed to do.


On Sun, Jan 4, 2026 at 2:31 PM Michał Olszewski via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> Hi all,
>
> I'd like to start a loose discussion around trend that has been happening
> in the past two years, namely using LLM agents for rapidly building
> prototypes and applications alike (infamously known as "vibe coding" if you
> don't know what you're doing :). More neutral term is "AI assisted
> workflow"). The "state of the art" advanced to the point where it's
> possible to generate, refactor and document entire codebases without a
> sweat using multi agent workflows, MCP servers, task-oriented instructions
> etc. - see Claude Code (Sonnet 4.5, Opus 4.5) ecosystem for example [*1*].
>
> Since Smalltalk environments are quite walled gardens (code pretty much
> lives in the binary image, with attempts from Cuis and others to store
> packages in textual format) there hasn't been much motion towards
> integrating LLM workflows with the internal tooling, as it's requires
> dedicated communication protocol (any packages for that already? :)) and
> besides that, there wasn't opportunity to train on large chunks of ST
> sources.
>
> Open ended questions (with my opinion for each of them):
>
>    - given there would be proper integration (fine-tuning, dedicated
>    package for interfacing, set of human-written instructions etc.), what do
>    you think about using LLM agents for: 1) rapid building of prototypes or
>    entire applications 2) progress verification e.g. whether implementation
>    matches functionality spec 3) knowledge finding and example generation? For
>    1) and 2) see director-implementor pattern [*2*].
>    - do you think Smalltalk-like systems are more suitable for LLMs than
>    file based languages? - The tight integration of tools-system is already
>    there - there is no need to implement heavy MCP servers or RAG, just
>    ask/explore the system for the answer! There is also question about token
>    usage - context windows don't need to store entire text blocks anymore,
>    only relationships provided by the tooling.
>    - given above, would local, task-oriented LLMs provide first class
>    experience for us, just like one-size-fits-all models for the broader
>    world?
>
> References:
>
>    1. https://www.anthropic.com/engineering/claude-code-best-practices
>    2.
>    https://github.com/maxim-ist/elixir-architect/blob/main/skills/elixir-architect/SKILL.md
>
> Cheers,
> Michał
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260104/6ef46f78/attachment.htm>