<div dir="ltr">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:<div><br><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Jan 4, 2026 at 2:31 PM Michał Olszewski via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>Hi all,</p>
<p>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 [<b>1</b>].</p>
<p>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.</p>
<p>Open ended questions (with my opinion for each of them):</p>
<ul>
<li>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 [<b>2</b>].</li>
<li>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.</li>
<li>given above, would local, task-oriented LLMs provide first
class experience for us, just like one-size-fits-all models for
the broader world? </li>
</ul>
<p>References:<br>
</p>
<ol>
<li><a href="https://www.anthropic.com/engineering/claude-code-best-practices" target="_blank">https://www.anthropic.com/engineering/claude-code-best-practices</a></li>
<li><a href="https://github.com/maxim-ist/elixir-architect/blob/main/skills/elixir-architect/SKILL.md" target="_blank">https://github.com/maxim-ist/elixir-architect/blob/main/skills/elixir-architect/SKILL.md</a></li>
</ol>
<p>Cheers,<br>
Michał</p>
</div>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div>