To test this idea, I threw together a small proof of concept — a simple personal finance app with an AI chat layer on top. The app itself isn’t the point. What’s interesting are the patterns that emerged and what they suggest about where application development is heading.

The Idea

The core question I wanted to explore was: What happens when you give an LLM full access to your application’s functionality?

Most AI integrations I’ve seen treat the assistant as something separate from the app — a sidebar that can answer questions but can’t actually do anything. I wanted the opposite. I wanted the AI to be a first-class citizen that can do everything a user can do through the traditional UI, and potentially even more.

So I spun up a quick POC — a finance tracker with the usual pages (accounts, transactions, budgets, etc.) — and wired an AI chat layer into every feature. The app took a single prompt to scaffold. The interesting part was what came next: giving the assistant real tools to work with.

The Patterns That Emerged

Once you commit to giving the assistant real tools — actual functions that interact with the app’s services and database — a few powerful patterns emerge.

Navigation as Conversation

The simplest tool: letting the assistant navigate the user to any page. Say “take me to my budgets” and it routes you there. This sounds trivial, but it changes how you think about app navigation entirely. Instead of hunting through menus, you just say where you want to go. Now imagine this in an app with dozens or hundreds of pages — the value scales fast.

Here’s what defining a navigation tool looks like in practice:

const PAGE_ROUTES = {
  dashboard: ['/dashboard'],
  accounts: ['/accounts'],
  transactions: ['/transactions'],
  budgets: ['/budgets'],
  // ...
};

const navigateToPage = createTool({
  name: 'navigate_to_page',
  description: 'Navigate to a page in the app.',
  schema: s.object({
    page: s.string('Page name to navigate to'),
  }),
  handler: async (input) => {
    const route = PAGE_ROUTES[input.page];
    if (route) await router.navigate(route);
    return { navigated: !!route, page: input.page };
  },
});

That’s it. A route map, a name, a description, and a handler. The LLM reads the description, decides when to call it, and fills in the parameters.

Data Retrieval With Generative UI

An assistant that can only respond with text is limited. The real unlock is giving it the ability to render actual UI components inline in the chat — cards, tables, progress bars, charts. The LLM decides which component fits best for what the user asked and renders it with real data.

In my POC, asking “what’s my net worth?” returns a formatted account summary with balances. “Show me my spending this month” renders a doughnut chart by category. The responses feel native to the app because they are native — they’re the same frontend components, just rendered in the chat context. This is a pattern that works for any domain: dashboards, admin panels, analytics tools, CRMs — anywhere you’re presenting structured data.

You expose your existing components to the LLM with typed schemas that describe what each one does and what data it needs:

exposeComponent(ChatAccountCardComponent, {
  description: 'Shows a single account with name, type, balance, and icon.',
  input: {
    name: s.string('account name'),
    type: s.string('account type like checking, savings'),
    balance: s.number('current balance in USD'),
    color: s.string('hex color'),
    icon: s.string('material icon name'),
  },
}),

exposeComponent(ChatSpendingChartComponent, {
  description: 'Shows a doughnut or bar chart for spending data.',
  input: {
    chartType: s.enumeration('chart type', ['bar', 'doughnut']),
    labels: s.array('chart labels', s.string('label')),
    data: s.array('data values', s.number('value')),
    colors: s.array('hex colors', s.string('color')),
    title: s.string('chart title'),
  },
}),

The LLM picks the right component for each response and fills in the props with real data. Ask about your net worth — it renders an account card. Ask about spending — it renders a chart. You don’t code that routing logic. The LLM just figures it out from the descriptions.

Dynamic Database Queries — The Most Interesting Part

Here’s what I find truly fascinating. Beyond pre-defined tools like “get accounts” or “search transactions,” I gave the assistant a generic query_database tool. It knows the database schema — tables, columns, relationships, supported filter operators — and it can construct whatever query it needs to answer the user's question.

This means the assistant isn’t limited to the specific queries I anticipated when building the app. It can join tables, apply complex filters, sort and limit results — whatever the question requires. “Show me all expenses over $100 from the last six months” isn’t a feature I explicitly built. The LLM figures out the right query, executes it, and presents the results.

The tool definition gives the LLM full schema awareness — table structures, relationships, and filter operators:

const SCHEMA_DESCRIPTION = `
DATABASE SCHEMA:
- accounts (id, name, type[checking|savings|credit_card|...], balance, ...)
- transactions (id, account_id FK->accounts, category_id FK->categories,
    type[income|expense|transfer], amount, description, date, ...)
- budgets (id, category_id FK->categories, amount, period, ...)

RELATIONSHIPS:
- transactions.account_id -> accounts
- transactions.category_id -> categories
- budgets.category_id -> categories
FILTER OPERATORS: eq, neq, gt, gte, lt, lte, like, ilike, in, is`;

const queryDatabase = createTool({
  name: 'query_database',
  description: SCHEMA_DESCRIPTION,
  schema: s.object({
    table: s.enumeration('Table', ['accounts', 'transactions', 'budgets', ...]),
    select: s.string('Select string with join syntax'),
    filters: s.array('Filter conditions', filterSchema),
    order: orderSchema,
    limit: s.number('Max rows to return'),
  }),
  handler: async (input) => {
    let query = supabase.from(input.table).select(input.select);
    for (const filter of input.filters) {
      query = query[filter.operator](filter.column, filter.value);
    }
    if (input.order) {
      query = query.order(input.order.column, { ascending: input.order.ascending });
    }
    const { data } = await query.limit(input.limit ?? 50);
    return data;
  },
});

That’s one tool. And it replaces what would otherwise be dozens of filter combinations, custom report builders, and specific views in a traditional UI.

This is the pattern that made me rethink what an in-app AI assistant really is. It’s not just a nicer interface to existing features. It’s a way to unlock functionality that would be impractical to build as traditional UI. You’d need dozens of filter combinations, custom report builders, and specific views to cover what the LLM can do with a single flexible tool. Give it schema awareness and query access, and it can generate whatever the user asks for — no one has to anticipate every possible question upfront.

Why Complexity Makes This More Valuable

One thing that struck me during this experiment: the more complex an app becomes, the more valuable an embedded AI assistant gets.

A simple app with three screens doesn’t really need an assistant — the UI is already easy to navigate. But think about software with hundreds of features, nested settings, data spread across dozens of views. An AI assistant that knows the entire app — every page, every data source, every capability — becomes incredibly powerful in that context. It’s like having a power user sitting next to you who knows every shortcut and every hidden feature.

And it scales in a way traditional UI doesn’t. Every new feature you add to the app automatically becomes something the assistant can help with, without building new onboarding flows or help documentation. The assistant is the documentation. It is the onboarding.

Accessibility — The Angle That Excites Me Most

There’s an aspect of this that I think deserves much more attention: accessibility.

When you can fully interact with an application through natural conversation, you fundamentally change who can use it. This is convenient for everyone — nobody loves clicking through nested menus to find a specific setting. But for some people, it’s transformative.

Think about users who aren’t technically versed. The kind of people who call their kids to help them with an app. An AI assistant that they can just talk to and say “show me how much I spent on groceries last month” removes the barrier entirely. They don’t need to understand filters, date pickers, or category dropdowns. They just ask.

And for users with disabilities — motor impairments that make clicking difficult, visual impairments that make navigating complex UIs challenging — a conversational interface isn’t just convenient. It’s enabling. It means they can use the app at all, or use it without the workarounds they’re currently forced into.

I think this is one of the most underappreciated benefits of in-app AI assistants. We talk a lot about productivity gains and developer experience, but the accessibility implications are enormous.

And here’s the kicker for developers: this accessibility comes almost for free. Traditional a11y is notoriously hard to do well — ARIA attributes, screen reader testing, keyboard navigation, focus management, color contrast, alternative text. It’s a massive effort that many teams struggle to prioritize. But a conversational interface sidesteps most of that complexity. If your assistant can already fetch data and perform actions, you’ve given every user — regardless of ability — a fully accessible way to interact with your app, with virtually no additional development cost.

What I Want to Try Next

The dynamic query tool was the most interesting part of this experiment, and I want to push that idea much further. The next step I have in mind: combine the same flexible data fetching with a rich library of generative UI building blocks — cards, tables, charts, layouts, grids — and let the LLM compose entire pages on the fly.

Right now the assistant renders individual components in the chat. But what if it could assemble a full dashboard view from a single request? “Build me a page that shows my monthly spending trend, my top five expense categories, and my upcoming bills” — and the LLM picks the right components, arranges them in a layout, pulls the data, and renders a complete view.

The part that really interests me: letting users save these generated queries and views. At that point, the user is essentially building their own application within a framework of data and components — without writing code, without navigating a complex UI builder. They just describe what they want, refine it through conversation, and keep what works.

Where I Think This Is Going

I’m genuinely convinced that in the near future, most applications will ship with a capable on-page AI assistant. Not as a gimmick or a marketing checkbox, but as a core part of the user experience.

The technology is already there. LLMs can call tools, render UI, maintain context across a conversation, and handle nuanced requests. The patterns for integrating them into frontend frameworks are emerging. What’s left is mostly execution and refinement — making it reliable, fast, and natural enough that users reach for the chat before they reach for the menu.

When that happens, the way we design applications will shift. We’ll spend less time optimizing navigation hierarchies and more time defining what tools and data the assistant has access to. The UI won’t go away — visual interfaces are still the best way to browse and explore — but the assistant will become the primary way users act on the app. Find this, show me that, create this, take me there.

I think it will make our lives easier and more efficient. And for a lot of people, it will make software accessible in a way it never was before.

I’m very curious to see which direction this takes. But if this small experiment is any indication, the direction is promising.

The POC is built with Angular, Supabase, and Claude, using hashbrown.dev for AI tool calling and generative UI. Check out the source code on GitHub.

What are Trusted Types?

JavaScript offers lots of ways to create or inject HTML and script from strings — think innerHTML, insertAdjacentHTML, document.write, script.src, iframe.srcdoc, and so on. These are “injection sinks.” They’re essential, but they’re risky: they’ll accept whatever you pass to them. Attackers abuse this to inject malicious code.

If you’re assigning HTML strings to these sinks, you should sanitize them first (what is sanitizing?). But people forget, code paths are tricky, and third‑party libraries don’t always sanitize correctly.

Enter Trusted Types. With Trusted Types enabled, the browser refuses plain strings in dangerous sinks. Instead, those sinks require special values — TrustedHTML, TrustedScript, or TrustedScriptURL — that can only be created by policies you define. Your policy can sanitize and validate input first, then hand the browser a “trusted” value. That closes off a big DOM XSS attack surface.

Important: Trusted Types don’t magically sanitize for you. You’re responsible for writing (or using) a safe policy that sanitizes/validates input.

How do Trusted Types work?

Trusted Types have two parts working together: a Content Security Policy (CSP) directive and a trustedTypes global you use to create policies.

CSP

You enforce and configure Trusted Types with CSP. For example:

• Header form: Content-Security-Policy: trusted-types app dompurify; require-trusted-types-for 'script';
• Meta tag form: <meta http-equiv="Content-Security-Policy" content="trusted-types app dompurify; require-trusted-types-for 'script'">

This has two directives:

• trusted-types app dompurify:
  Lists the policy names your page is allowed to create (e.g., “app”, “dompurify”). You can list one or many. You can also use 'none' to block policy creation or '*' to allow any (not recommended).
• require-trusted-types-for 'script':
  Enforces Trusted Types for script-creating and HTML-parsing sinks (e.g., innerHTML, insertAdjacentHTML, iframe.srcdoc, document.write and URLs for script.src/Workers). The only token currently is 'script'.

Tip: You can start with Report-Only to measure impact before enforcing:
Content-Security-Policy-Report-Only: trusted-types app dompurify; require-trusted-types-for 'script';

trustedTypes global

The second piece is the global trustedTypes object on window. You create “policies” with it—named objects whose methods you implement to sanitize and return trusted values. The browser will then accept those values in dangerous sinks.

// Example: using DOMPurify inside a policy to sanitize

const policy = window.trustedTypes.createPolicy('app', {
  createHTML: (input) => DOMPurify.sanitize(input),
  createScript: (input) => input, // This could sanitize for script usage
  createScriptURL: (input) => input, // This could sanitize for scriptURL
});

const untrustedHTML = '<h1>Hello World</h1>';

document.getElementById('container').innerHTML = policy.createHTML(untrustedHTML);

Note: You can define a special policy named ‘default’. In enforcement mode, if code accidentally passes a string to a sink, the browser will run it through your ‘default’ policy.

How can I start using Trusted Types today?

Trusted Types are supported in Chromium-based browsers like Chrome and Edge. In Firefox, implementation work is ongoing and it isn’t enabled by default yet. Safari/WebKit is also in progress.

If you want to adopt the pattern ahead of full native coverage, you can use the WICG/W3C Trusted Types polyfill. It won’t enforce protections to the full extent of native support, but it’s very useful for surfacing violations and preparing your app for enforcement.

Summary

The new Trusted Types feature greatly helps to protect us against XSS attacks. It consists of two parts: enforcement rules and policies, which help ensure that dynamic content added to the DOM is trustworthy. It is currently only supported natively in Chromium-based browsers, with development in Firefox and Safari ongoing. However, polyfills are available, so Trusted Types can be adopted today.

Small demo

<!doctype html>  
<html lang="en">  
<head>  
    <meta http-equiv="content-security-policy" content="trusted-types foo; require-trusted-types-for 'script';">  
</head>  
<body>  
    <div id="container"></div>  
    <script>        
        const myPolicy = window.trustedTypes.createPolicy("foo", {  
            createHTML: (input) => input,  
            createScript: (input) => input,  
            createScriptURL: (input) => input,  
        });  
  
        const untrustedHTML = "<h1>Hello World</h1>";  
  
        // Works  
        document.getElementById("container").innerHTML = myPolicy.createHTML(untrustedHTML);  
  
        try {  
            // Throws because untrustedHTML is a string, not TrustedHTML  
            document.getElementById("container").innerHTML = untrustedHTML;  
        }catch (e){  
            console.error(e);  
        }  
  
        // Throws because bar was not allowed in the CSP  
        const myPolicy2 = window.trustedTypes.createPolicy("bar", {  
            createHTML: (input) => input,  
            createScript: (input) => input,  
            createScriptURL: (input) => input,  
        });  
    </script>  
</body>  
</html>

Sources

https://github.com/w3c/trusted-types
https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/trusted-types
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/http-equiv
https://github.com/cure53/DOMPurify