Dynaboard AI(dynaboard.com)
dynaboard.com
Dynaboard AI
https://dynaboard.com/blog/dynaboard-ai
4 comments
Very cool. Way to go!
Amazing, wonder how the code refactoring works and how do you make sure that the llm output can always be compiled ? Or I guess the task of the llm is just about selecting from a list of pre defined components and giving the input in the correct format ?
Dynaboard founder here.
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.
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.
Thanks Alex :) Looking forward to the release