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

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.

Hey @Shawn_Optipath :waving_hand:

First off, thank you for taking the time to run such a careful experiment and write it all up. This is genuinely the kind of feedback that helps us get better, so it really means a lot. I've gone ahead and moved your topic to Discussion so the community can keep chiming in.

You're totally right to flag this. Asking Assist to "add one component, touch nothing else" and then seeing three others move (one by hundreds of pixels) is frustrating, and I completely understand why the quiet, easy-to-miss changes feel unsettling in a bigger app. Wanting to trust that a change stays scoped to what you asked is completely fair.

On questions 1 through 4, I'd like to check in with our engineering and product teams so I can give you confirmed answers. Give me a little time and I'll follow up right here.

As our attention shifts to the new app builder, improving Assist specifically inside classic apps isn't a primary area of new investment for us going forward. A lot of our focus right now is naturally going toward the new builder. What I can commit to is that classic apps themselves aren't being left behind: Timofey from our product team shared that we're supporting classic apps for at least two years from when the new app builder reaches GA (it's still in beta today), and during that time we're investing in the new builder and its classic apps conversion experience, so that over time you'll be able to successfully re-create, and in some cases perhaps even improve, your existing apps. :heart_hands: You can read his note here:

And to everyone else reading, please keep the feedback coming! Detailed write-ups like Shawn's are exactly the kind of feedback we love to see, so if you've hit something similar or have thoughts to add, we'd love to hear them. :folded_hands:

I'll follow up here soon!

1 Like