# thinking-together


11/19/2023, 6:28 PM
An idea is starting to form for me around prototype-based modeling being a good metaphor for programming effectively with LLMs. Essentially you can provide an example of a patttern/component/class/etc and have it return a version of it modified in specific ways, which can then be used as a prototype for future generations/instantiations. A version of this idea can be seen here with tldraw: where he generates the next more specific interface step off the previous one. Another I'm kind of using this in my agent framework: where we generate new agents based off a simple agent template (and works surprisingly well). I know Hofstatder digs into this concept in GEB and Steve Yegge calls it the Universal Design Pattern Does this resonate with anyone here? Is anyone familiar with any other writing about prototype-based modeling/prototypal inheritance/etc for me to take this further?

Lu Wilson

11/19/2023, 7:39 PM
Hey I built the tldraw "make real" thing! Making that 'game loop' was the thing I added to Sawyer Hood's original version. I thought it was really important to have this 'back-and-forth' going on, like you can get with chatgpt.
It's been interesting seeing alternatives pop up this week, which sometimes miss that as the important part. eg: In Figma's version, you can't annotate the generated html


11/19/2023, 7:57 PM
Ahh awesome! Yeah the make real thing is amazing, my mind has been racing since I’ve seen it. Great job!
But yeah, being able to annotate and generate and regenerate is definitely a key
Like we’re doing with the agents (in a purely code way) - we can then customize a generated agent and use that as a template for a future one (in a pre-release version we had one that returned a list of command line commands to then be run on the local machine)

Csongor Bartus

11/20/2023, 8:14 AM
It reminds me of functorial semantics from category theory: one syntax, many semantics.

Alex Cruise

11/24/2023, 12:24 AM
I see this mainly as metadata, i.e. in many (especially "platform-flavoured") projects, it's necessary to know how the user thinks about their data
User-defined types, or at least "custom fields", always turn up eventually, and users always want to attach types and validation rules to them
In my experience the metamodel (i.e. the language in which user types are expressed) is interesting and takes maybe 5 pages to fully describe, but rarely needs to grow
Once you have entity types (those with an ID), struct types (object-like things that don't exist persistently outside of an entity), scalar and multivalued properties, reference properties (i.e. FK values)... you start to run out of necessary new ingredients
of course, it's important to point out that heavily metadata-driven systems tend towards illegibility: it gets more and more difficult to look at a piece of raw data and intuit what it means... e.g. rather than a
type: Fruit
field it might have a
typeId: <36-character UUID>
I mean this is pretty fundamental, not specific to LLMs or agent-based stuff or whatever: if you want your thing to accept user-defined types at all, and you care that the types are meaningful in some sense, not just descriptive... you need metadata 🙂
you can mitigate legibility and performance problems to some extent with codegen