There appears to be some underlying principles between intermediate representations and possible, reliable transformations.
Intermediate representations are often used to keep the architecture more manageable -- in compilers, for example. But these internal representations appear to increase expressability, which goes beyond the architecture.
For example, software development development cycle has several transformations: from requirements to user stories to design, and then to code. The stages are getting a revival, because they appear to be helpful when working with LLMs.
If we think LLMs as transformation machines, the transformation is reliable to the extent the source internal representation can capture the explicit semantics. The less LLM needs to make up in the content, the more reliable the end result.
This is close to how LISPers approach coding: invent a DSL for what you want to do, implement it in your DSL, and then implement the DSL. This approach seems to work well when creating systems that use LLMs.
kukkeliskuu•1h ago
Intermediate representations are often used to keep the architecture more manageable -- in compilers, for example. But these internal representations appear to increase expressability, which goes beyond the architecture.
For example, software development development cycle has several transformations: from requirements to user stories to design, and then to code. The stages are getting a revival, because they appear to be helpful when working with LLMs.
If we think LLMs as transformation machines, the transformation is reliable to the extent the source internal representation can capture the explicit semantics. The less LLM needs to make up in the content, the more reliable the end result.
This is close to how LISPers approach coding: invent a DSL for what you want to do, implement it in your DSL, and then implement the DSL. This approach seems to work well when creating systems that use LLMs.