@pmadden - Thanks for the suggestion. I gave it a screenshot and it came up with this - still not good. Also, had one of my team members convert an app that he's been working on for a month and it didn't bring over any event handlers so he created a markdown file using assist to fee to the new app builder to see what happens. Fingers crossed.
1 Like
I use Assist every time I make additions/edits to our apps. I like it because while it leverages LLMs, I can still generally understand how the app works. I feel that with the new prompt based builder I will lose that level of understanding (but maybe I just haven’t used it enough). Is it really that hard to maintain Assist while focusing on the development of the new app builder?
Thanks
1 Like
I’m really bummed (and, yes, annoyed) about this, too. We have used Assist quite a bit on our sprawling classic app, and it’s been very helpful. Can implement complex transformers in seconds, not hours of fiddling. Get some CSS in place that allows tweaking a component beyond what is available in the inspector without spending a ton of time experimenting in the browser element inspector. And so on.
I feel like Assist is a very reasonable and welcome “split the difference” compromise between the classic environment and the AI-only “black box” of the new builder.
Yes, I converted our classic app, for funsies, but the amount of testing that is going to required is prohibitive, and is pretty much a nonstarter until the ability to robustly support multiple environments is implemented. Not to mention that we’re continually tweaking our classic app to the point that we’ll just have to re-convert it again down the road.
Appreciate the feedback, @DylanSeq and @Schteevynn. 
You both touch upon common themes that I've seen from other users. Specifically, though, it sounds like the new app builder's biggest gap in your estimation is a lack of transparency - you want to understand what's being built and have confidence that it's working as intended. To that last point, @Tanner_Pierce is currently looking at native testing support and would probably be interested in hearing your thoughts.
Ultimately, though, the primary reason we're choosing to sunset Assist is focus - both for our internal engineering teams and for the market at large. It's certainly been a little bittersweet to see such vocal support for Assist, but we believe that being decisive at this juncture is the right play for Retool in the long term.
If there is any lower-hanging fruit that we can address in order to help ease the transition - like support environment switching in published apps - don't hesitate to let us know!
We have built over 50 Classic apps linked together under a common navigation framework supporting all of our core admin functions. Assist has been integral to this, enabling us to build much faster and iterate on highly complex logic within our existing framework.
While we would love to leverage your multipage structure, it represents an architectural blocker for us. Retool does not support deployment or semantic versioning on a per-page basis. Because we must deploy and scope individual Retool admin portals in strict lockstep concert with their underlying, distributed customer-facing microservices (rather than as one massive, monolithic unified admin app), multi-page consolidation breaks our CI/CD and blast-radius boundaries.
While the new AI App Builder is technically impressive, from a developer perspective, it shifts Retool's paradigm toward creating standalone, hardcoded React codebases. This introduces the exact same maintenance regressions we see when vibe-coding directly with Claude Code or Cursor—where simple, localized code iterations occasionally trigger unexpected cascading UI/state failures.
Retool’s true enterprise differentiator has always been the standardized component framework paired with the flexibility to seamlessly pivot between AI acceleration, raw code, and manual drag-and-drop. Assist was a massive leap toward that workflow. Removing it on September 30th without an architectural bridge will severely degrade our team's velocity or we would have to sacrifice the unified end user experience.
We understand the engineering overhead of maintaining classic engines, but we urgently need an interim bridge. Please consider alternative mitigation steps, such as:
-
Exposing the Classic App schema to an official Retool MCP server, allowing us to safely leverage external LLMs (like Claude Code) to manipulate legacy internal components.
-
Providing a cross-engine interoperability layer that allows legacy shared modules to be natively exposed or embedded inside the new app builder context.