Improvements to app generation using Assist

📣 Retool Announcements 💥 Product Updates
,
1

Retool made significant updates that improve Assist's app generation capabilities :partying_face: :rocket:

  • Improved quality of app generation. Assist has an improved ability to successfully set a wider set of properties across a wider set of components.
  • Quicker app generation. Generating an app from scratch is approximately 20% faster.
  • Better token efficiency, especially for app editing. Token use has decreased by approximately 40-50%, depending on the change type. Users will notice a decrease in the number of context window issues they encounter.
  • Improved support for building forms and using repeatable components inside apps.

This change is currently rolling out to cloud instances and will be available to self-hosted instances in an upcoming edge release.

3 Likes
3

Amazing Retool team!

Do you have any sort of benchmarks around app building? If so, it would be great if you could share them openly so that we know what can we expect.

For example, every time assist tried to do a setting with a tabbed container, it failed to set up tabs properly, and ended up adding all components in the first tab.

You mentioned "improved support" with repeatables. But what does that mean, really? Can we expect interaction between components on each instance, what about repeatables + variables.

Lately you launched assist for multi page apps, how good is at passing context between pages, and how, is it better atdoing it with urls or variables?

I'll be super honest with you guys, the 4-5 times I tried using assist (even for simple mock-ups) I ended up ditching the app and starting from scratch...

I guess what I'm saying is, a benchmark would set expectations AND allow us to provide feedback on whether they representative our user experience or not.

Thanks!

3 Likes
4

I used it a lot. The assist function for me was a game changer. For instance it could do paginated queries on different APIs. Something I would have never managed to do even with the help of other tools.

Then also what was super useful is multi-page support and let it implement a page switcher on top. After the latest releases I was also able to do that.

2 Likes
5

Also what it was very helpful with is batch processing, where you can select different entries of a table and process them with the same API request in a loop.

3 Likes
6

Hey @MiguelOrtiz, I’m one of the engineers working on Assist. I’ll do my best to answer your questions!

We don’t have any benchmarks to share externally. We do run “evals” internally, across a number of app building scenarios that utilize common resource types and building patterns. In those evals, with the improvements, we tend to see higher quality apps built in less time.

This new version of Assist has a much better understanding of what properties are available to configure on different components. It should generally do a better job of configuring components correctly.

To speak to some of your specific points:

Tabbed containers: this is still not supported. As of today, Assist can’t manipulate the UI inside the tabs of a tabbed container. This is a limitation of the way that we have Assist edit UI. Assist can replicate the pattern of a tabbed container using a standalone tabs component and conditionally hidden containers.

Multipage data passing: In my experience, Assist can now pass data between pages using global variables and url parameters.

Repeatables: Previously, any ability that assist had to work with repeatables was luck - we hadn’t given it any tools or context to do this. There is now is actual support for repeatables. Assist should be able to build and edit UI that uses list views and grid views, including features like instance values, and write code that interacts with those repeatables.

I hear your frustration on starting with Assist and then ditching it and starting over. Assist has at times had issues with undoing work done by the user and false confidence that it successfully completed a task. It still can’t do everything, and it will still make poor decisions sometimes, but I believe this new version of Assist is a much better “partner” for building, and that it can save you a lot of time even if you do some of the building yourself.

Out of curiosity - what sort of benchmarks would you find useful?

2 Likes
7

Hey Ford,

Thanks for the thorough response.

I guess the benchmarks should be helpful for builders to know what to delegate and what not to delegate to AI assist. For example:

  • Table with variable as data source: I usually have this set up where a table's data source is a variable (usually pointing to a query as default value) with changes in the table triggering logic which a) updates the variable, b) runs the query to save records in the back end c) sets fallback logic to reset the variable + send notification if the query fails. This provides a nice "excel-feel" to the table and it limits the time waiting for query refresh.
  • Using additional scope as good practice: After years of experience, I heavily use queries with an additional scope variable within the object for the record/records to edit. This allows me to reuse it (e.g. if an opportunity is edited from different pages, I keep it in global scope, and I have only 1 editOpp query).
  • Transformer vs JS queries: This is one of the things that most LLMs fail to understand (mostly the transformer is not well understood). My guess is that LLMs will default to JS queries ,as that is the universal language everywhere, but transformer are incredibly helpful when knowing when to use them.
  • Table's expandable rows and grouped rows: These functionalities are very powerful, but can give a headache to many. How good is Assist at understanding the trade-offs for each, how to use currentRow (or something known to a very few ri[] (which is an easy way to get the index of the currentRow - in abscence of a much needed currentRowIndex property).
  • Queries' transformers: How much is Assist using Querie's transformer vs transforming the data with other queries?
  • DRY best-practices: Something that I do, and I've seen many builders do as well, is recycle one form for several CRUD operations. E.g. the same form for edit and new records, with the form's data source dynamically changing based on a variable's value. Does Assist understand the data key form and how that maps to the form's data source and pre-populates the fields, or will it try to use the default values field to achieve this goal?. Also, when you want to trigger different actions with a form, it is a common mistake to forget to change the form's submit action to default, otherwise your "run only when" settings in the event handler will be ignored (I realize this point is more about forms than about DRY, but I hope I'm making a point).

I guess maybe the answer to all of the above would be, it would be great if you could have a public version of the evals you're running.

Just having a list of supported / unsupported components/resources is not enough, as what assist should achieve is overall logic, not just a dump of components and logic that needs re-wiring. If I'm able to see the results of certain apps that Assist built, then I'll feel more encouraged to use it, and maybe refine my prompts and explanation of what I want to achieve.

I hope this helps!

Best,
Miguel