This is an interesting and deep topic, which we plan to share more about in an upcoming technical blog post. We are still experimenting with the best ways to constrain the LLM's output such that it always compiles as expected and "knows" when to use certain Dynaboard-oriented features like {{ bindings }}. At a high level:
- Code refactoring works through a recursive refinement loop of: fetching any relevant DB schema or existing component data -> initial generation prompt -> LLM output -> using tsc (or equiv) to detect errors -> feeding the errors back into the LLM recursively until a fixed point is reached -> format. In our experience it works really well for both simple and moderately complex prompts.
- UI components are first generated as an outline/scaffolding of components which map approximately 1:1 with HTML equivalents in an initial prompt, before being populated with their respective component properties in a subsequent prompt. There's a subset of properties that seem most useful to generate which we focused on for this initial release, but we are looking to expand that list over time.
