Assist added one component...and moved three others I explicitly told it not to touch

đź’¬ App Building
, ,
1

Hi all,

I wanted to share a controlled experiment with Assist in a classic app. I’m posting this partly as a caution for other builders and partly to ask the Retool team about the roadmap for making Assist changes more reliable, constrained, and reviewable.

Before starting, I published a test release and recorded the positions and sizes of the app’s top-level components.

I then gave Assist a very specific request:

Add exactly one Text component below the existing filters and above the tabbed container. Do not move, resize, delete, rename, restyle, or otherwise modify any existing component. Do not create or modify queries, event handlers, resources, or data, and do not run any queries.

Assist successfully created the requested component:

  • Name: assistPlacementTestText
  • Text: “Assist placement test”
  • Position: x=0, y=208
  • Size: 318 Ă— 24 px

However, it also made several changes that were not requested:

  • showActiveJobs moved from y=168 to y=144
  • showAddress moved from y=192 to y=968
  • tabbedContainerClients moved from y=264 to y=232
  • The root canvas height changed from 1400 px to 1392 px

No components were deleted and no queries were run, but one component had been moved hundreds of pixels down the page.

The concerning part is not simply that Assist made a mistake. It is that these unrelated changes could be easy to miss in a larger application. A builder might confirm that the requested component was added, continue working, and only discover the collateral layout changes much later. By then, identifying when and why the changes occurred could cost significant time.

In this case, I had intentionally published a release immediately before the experiment, so I was able to revert successfully. Without that checkpoint—and without comparing the component geometry before and after—I may not have noticed every change.

I see a lot of potential in Assist, and this is not an argument against AI-assisted building. But if we are expected to trust an AI tool inside production applications, “only change this component” needs to be more than a best-effort prompt.

A few questions for the Retool team:

  1. Is there work underway to provide a complete, structured diff of every component and property Assist changes before those changes are accepted?

  2. Could Assist changes be staged as a transaction, with an explicit review and approval step before they are applied?

  3. Are scope restrictions planned so that a builder can technically limit Assist to selected components, rather than relying on prompt instructions?

  4. Could every Assist operation automatically create a reliable checkpoint with a one-click rollback?

  5. Is improving Assist reliability in classic apps still an active priority as attention shifts toward the new app-building experience?

I found a related discussion where the Retool team acknowledged that Assist’s layout handling can sometimes produce unexpected results and that complex changes can be inconsistent:

I’d also be interested in hearing how other classic-app builders are using Assist safely. Are you publishing a release before every prompt, exporting the app, reviewing history, or using another process to detect unrelated changes?

I’m sharing this because I want Assist to become something we can confidently use in serious applications. Reliability, transparency, and enforceable scope seem essential if builders are going to trust it with mature projects.

Thanks—I’d appreciate hearing both from other builders and from the Retool team.