When we set out to build Assist, the latest of Retool’s AppGen capabilities, one question dominated our early debates: should users have to approve every query Retool generates?
The question came up repeatedly in early user testing. One early adopter watched anxiously as Assist chose to query account data from Salesforce instead of Snowflake. "I get very nervous when I see that it's chosen the wrong resource," he explained. "Builders will use this data to build applications our business will run on." In addition, potential costs concerned customers. Sometimes Assist would automatically execute multiple BigQuery queries, each costing a few dollars which added up quickly.
Yet the case for minimal friction was equally compelling. The market expected AI coding tools to be magical and friction-free, generating entire applications from simple prompts.
We realized we needed core principles to guide these tradeoffs. This was especially important for LLM development, where individual engineers could quickly prototype novel features. How could we empower bottom-up experimentation while maintaining focus?
The answer came from our customers and what they’re trying to accomplish (for the product managers out there, the “jobs to be done”). The apps they build in Retool aren't experiments or side projects—they're internal tools their business depends on. This deep understanding of our customers guided two key insights:
- First, speed alone doesn't matter when building production applications for a company. What matters is correctness, precision, and achieving usable solutions.
- Second, every enterprise is unique. Your data model, security policies, workflow patterns, business logic—AI can infer these patterns to a point, but ultimately needs human guidance to capture organizational context correctly.
These insights led us to four principles.
Rather than optimizing purely for speed or individual developer productivity, we designed around a different principle: it builds apps with users, not for users.
This might sound like a subtle distinction, but it changes everything about how the tool works.
When you ask Retool to "build a dashboard," it doesn't just generate code and call it done. Instead, it engages you in understanding what you actually need:
- Which data sources should it connect to?
- What user roles and permissions are required?
- What workflows and state transitions matter?
- Where are the edge cases that could break in production?
This collaborative approach comes from a simple observation: the depth of understanding needed to build production-ready apps only emerges through iteration with someone who knows the business context.
Here's what that looks like in practice. Say you ask to "build an app that lists orders and lets me cancel them." Instead of generating everything at once, Retool works through it step-by-step:
- Identifies the data source: "I found an orders table in your PostgreSQL database. Should I use that?"
- Drafts the fetch query: Shows you the SQL, lets you validate or edit it
- Builds the UI: Creates the table component using the query results
- Handles the cancel action: Writes the destructive query and explicitly asks for review before testing
Each step includes human validation—lightweight when possible, explicit when necessary—but always prioritizing correctness over speed.
Another scenario we ran into: sometimes Retool would write verbose logic code in the frontend. While technically correct, this was hard for a human to understand and maintain. Writing the code this way created apps faster, so we had to decide whether to optimize for AI or human development.
One of our core decisions was to optimize generated code for human builders.
This reflects a bet about how software development will actually work: builders will fluidly move between AI assistance, manual coding, and drag-and-drop. They won't exclusively use one or the other.
That means:
- Generated code follows best practices and remains maintainable
- Builders can easily understand, modify, and extend the output
- The patterns work whether you continue with Assist, switch to manual coding, or use different tools
We've seen this play out with our early adopters. They use prompts to scaffold quickly, then dive into the code editor for specific business logic, then jump back to natural language for the next feature. The solution adapts to their workflow, not the other way around.
The real differentiation comes from what Retool understands about your organization.
Through component libraries and backend functions, platform teams can encode their standards—branding, security policies, approved data patterns—into reusable building blocks. These organizational primitives are reached for first when building.
This means:
- Apps inherit security and compliance properties by default
- UI stays on-brand without manual styling
- Data access respects organizational policies
- New team members work within established patterns from day one
You get both the speed of AI-assisted development and the control of enterprise governance. You don't have to choose.
We made another deliberate choice: be transparent about limitations rather than deliver subpar experiences.
If you ask to work with a feature that isn't fully supported yet, Assist tells you directly. If a task is outside current capabilities, it guides you to the right approach rather than attempting something with a high failure rate. We constrain the solution space intentionally, focusing on what we can do reliably rather than what we can technically generate.
This matters for trust. When builders know they can rely on Assist's output—and when they know it will be honest about what it can't do—they integrate it into critical workflows. Setting clear boundaries on what the AI will and won't attempt isn't a limitation. It's how we maintain integrity in a tool people depend on for production applications.
Two weeks after launch, Assist has already become the fastest-adopted capability in Retool history. Over 2,000 companies are actively using it, with 30% of all new apps now being created with Assist's help. Among the builders who have access, 22% have already incorporated it into their workflow.
These patterns validate our principles: when you build with users rather than for them, prioritize correctness over speed, and design for human developers rather than just AI capabilities, builders keep coming back.
Reader
