Kaizen Teams

Dropdown

Table of Contents

Time to read

·

12

Published on

·

July 17, 2026

Last updated on

·

August 27, 2026

Santiago Chiappa, Backend Developer at Kaizen Softworks

Santiago Chiappa

Motorcycle enthusiast

Backend Developer

AI

AI

UX Design

UX Design

Generative UI: what it is, how it works, and when to use it

Published on

·

August 27, 2026

Last updated on

·

August 27, 2026

Time to read

·

12

Santiago Chiappa, Backend Developer at Kaizen Softworks

Santiago Chiappa

Backend Developer

‍Generative UI is a full-stack architecture that lets AI create, modify, and render user interfaces in real time, based on what each user needs at that exact moment. Instead of static, predefined screens, the interface assembles itself on the fly: a bar chart, a table, a comparison card when you're comparing things.

We've been building proofs of concept with it for the past few weeks. Most of what's written about generative UI is either too abstract or too exciting, so this is our attempt at neither: what it is, how it works, where it helps, where it doesn't, and what we learned from two demos we built.

The short version

  • Generative UI means the AI designs the screen that answers your question, not just the answer.
  • In production, most systems don't let the AI write code. It configures pre-built components. Safer, and good enough.
  • It shines in open-ended workflows like reporting and data exploration, where you can't pre-design every screen someone might need.
  • It complements standard UI. It doesn't replace it. Anyone telling you otherwise is selling something.

What is generative UI?

Generative UI is a full-stack architecture: the backend talks to the LLM, decides what the answer should look like, and picks the components, while the frontend renders them and handles how the user interacts with what’s on screen.

Compare that with how interfaces have always worked. A designer decides what goes on each screen, a developer builds it, and every user sees the same thing. Forever, or until the next redesign.

Generative UI flips that. The interface becomes dynamic and personal instead of static and universal. The AI doesn't just answer your question, it designs the screen that answers your question.

Dashboards and reporting are the most common use cases, but they're far from the only one. The same pattern works for dynamic forms, onboarding flows, and customer support, as it takes input just as easily as it presents output. It can even adjust font size, contrast, or layout for users with low vision, color blindness, or cognitive load.

‍

The three types of generative UI

There are three levels of generative UI, from most constrained to most open (Google Cloud, 2026):

  1. Static. Everything is pre-built. The AI picks which screen to show you from a fixed library. Low risk, low flexibility.
  2. Declarative. The AI assembles a JSON tree that specifies which UI components to use, in what order, with what properties. It doesn't write code. It configures pre-designed widgets. This balances the AI's flexibility with the system's stability.
  3. Open. The AI generates completely new code from scratch and the frontend renders it. Maximum flexibility, maximum risk.

Most production systems today use the declarative approach, and that's what this post assumes from here on. The AI isn't writing HTML or CSS freestyle. It selects components, fills in pre-designed widgets, and composes them into the right screen.

How does generative UI work?

Generative UI works by turning a user request into structured data that describes an interface, then rendering that data as real components. The flow looks like this:

  1. The user asks for something, explicitly or inferred from context.
  2. An LLM analyzes the request. It invokes tools, pulls data, and makes the design decisions: what to show and how.
  3. The system generates structured data describing both the components and the information they'll display.
  4. That schema travels to the frontend through the AG-UI protocol, a standard for communication between agents and frontends. It defines events that keep the agent's state in the backend synchronized with the frontend framework.
  5. The frontend transforms the schema into actual widgets and renders them.

To the user, the result feels like magic. Behind the scenes, it's structured data flowing through a well-defined pipeline. We prefer the second description. It's the one you can build on.

Pros and cons of generative UI

Generative UI trades real personalization and faster development for added latency, inference costs, and less predictable layouts. That's the honest version. Here are the details.

What you gain

Benefit Why it matters
Real personalization Each user sees the view they need, not the view designed for the average user. When that happens, conversion follows.
Flexibility that scales A small set of components combines into thousands of screens, including views you never explicitly built.
Faster development You build the component library once. The system composes it, instead of your team coding endless specific screens.

What you pay for it

Trade-offs What to watch
Latency There's an LLM in the middle, and that adds response time.
Token costs Every generated screen has an inference cost attached.
Less muscle memory The same request won't always render the same layout. Users can't build habits around pixel positions.
Privacy Sending data through an LLM means thinking carefully about what you send and where it goes.

None of these are dealbreakers. There are known techniques to mitigate each one. 

Generative UI examples: two working demos

We built two demos. One with fictional data, one on top of a tool we use every day.

Aurora Goods: a conversational e-commerce dashboard

Aurora Goods is a fictional consumer e-commerce platform we created for the demo. The interface is simple: chat on the left, canvas on the right. You ask about the business, the LLM figures out what you need, pulls the data, and renders it visually.

Ask about 2025 sales and it shows the numbers on cards, with a short note on anything relevant. Ask it to break that down by region and it extends the same view instead of starting over, because it understands the second question builds on the first. This part took us a while to get right, and it's what makes the whole thing feel like a conversation rather than a search box.

The canvas isn't output-only either. You can click into any element and drill down: revenue by category, then inside electronics, then which products sold most.

You configure the widgets once. The system combines them and adds relevant commentary on the spot.

An internal reporting screen for our time-tracking tool

The second demo is closer to home: a generative reporting layer on top of the time-tracking tool we use every day at Kaizen. The questions in this demo are questions someone here has actually asked.

Instead of building dozens of hyper-specific reports, a small amount of code now handles virtually unlimited queries. How many hours were logged in May? Which anomalies showed up in April? How do billable and non-billable hours compare across two months? Who worked on a given project last month, and for how long? Each answer arrives as the right visualization: cards, lists, bar charts, plus a short summary that's easy to scan.

Two details won us over. The LLM suggests next steps, so exploring the data becomes a conversation. And when it's not sure, it asks instead of assuming. Ask for the hours of someone named Alex and, since we have more than one Alex on the team, it asks which one before answering.

Generative UI complements standard UI. That's the point.

Generative UI is a complement, not a replacement. Standard interfaces still win for stable, repetitive workflows where consistency matters. Nobody wants their checkout button to be creative. Generative UI wins where the workflow is complex and the questions are unpredictable.

It also changes what design systems are for. Beyond designing components and screens, teams will need to define semantic rules: how the AI should react to uncertainty, which interfaces match which intentions, and the guardrails that keep generated screens functional and safe.

That's a new kind of design work. And it's already starting.

Want to see generative UI applied to your own data? 

We build working proofs of concept in two weeks. Your data, your workflows, a real thing you can click.

Start a conversation.

‍Generative UI is a full-stack architecture that lets AI create, modify, and render user interfaces in real time, based on what each user needs at that exact moment. Instead of static, predefined screens, the interface assembles itself on the fly: a bar chart, a table, a comparison card when you're comparing things.

We've been building proofs of concept with it for the past few weeks. Most of what's written about generative UI is either too abstract or too exciting, so this is our attempt at neither: what it is, how it works, where it helps, where it doesn't, and what we learned from two demos we built.

The short version

  • Generative UI means the AI designs the screen that answers your question, not just the answer.
  • In production, most systems don't let the AI write code. It configures pre-built components. Safer, and good enough.
  • It shines in open-ended workflows like reporting and data exploration, where you can't pre-design every screen someone might need.
  • It complements standard UI. It doesn't replace it. Anyone telling you otherwise is selling something.

What is generative UI?

Generative UI is a full-stack architecture: the backend talks to the LLM, decides what the answer should look like, and picks the components, while the frontend renders them and handles how the user interacts with what’s on screen.

Compare that with how interfaces have always worked. A designer decides what goes on each screen, a developer builds it, and every user sees the same thing. Forever, or until the next redesign.

Generative UI flips that. The interface becomes dynamic and personal instead of static and universal. The AI doesn't just answer your question, it designs the screen that answers your question.

Dashboards and reporting are the most common use cases, but they're far from the only one. The same pattern works for dynamic forms, onboarding flows, and customer support, as it takes input just as easily as it presents output. It can even adjust font size, contrast, or layout for users with low vision, color blindness, or cognitive load.

‍

The three types of generative UI

There are three levels of generative UI, from most constrained to most open (Google Cloud, 2026):

  1. Static. Everything is pre-built. The AI picks which screen to show you from a fixed library. Low risk, low flexibility.
  2. Declarative. The AI assembles a JSON tree that specifies which UI components to use, in what order, with what properties. It doesn't write code. It configures pre-designed widgets. This balances the AI's flexibility with the system's stability.
  3. Open. The AI generates completely new code from scratch and the frontend renders it. Maximum flexibility, maximum risk.

Most production systems today use the declarative approach, and that's what this post assumes from here on. The AI isn't writing HTML or CSS freestyle. It selects components, fills in pre-designed widgets, and composes them into the right screen.

How does generative UI work?

Generative UI works by turning a user request into structured data that describes an interface, then rendering that data as real components. The flow looks like this:

  1. The user asks for something, explicitly or inferred from context.
  2. An LLM analyzes the request. It invokes tools, pulls data, and makes the design decisions: what to show and how.
  3. The system generates structured data describing both the components and the information they'll display.
  4. That schema travels to the frontend through the AG-UI protocol, a standard for communication between agents and frontends. It defines events that keep the agent's state in the backend synchronized with the frontend framework.
  5. The frontend transforms the schema into actual widgets and renders them.

To the user, the result feels like magic. Behind the scenes, it's structured data flowing through a well-defined pipeline. We prefer the second description. It's the one you can build on.

Pros and cons of generative UI

Generative UI trades real personalization and faster development for added latency, inference costs, and less predictable layouts. That's the honest version. Here are the details.

What you gain

Benefit Why it matters
Real personalization Each user sees the view they need, not the view designed for the average user. When that happens, conversion follows.
Flexibility that scales A small set of components combines into thousands of screens, including views you never explicitly built.
Faster development You build the component library once. The system composes it, instead of your team coding endless specific screens.

What you pay for it

Trade-offs What to watch
Latency There's an LLM in the middle, and that adds response time.
Token costs Every generated screen has an inference cost attached.
Less muscle memory The same request won't always render the same layout. Users can't build habits around pixel positions.
Privacy Sending data through an LLM means thinking carefully about what you send and where it goes.

None of these are dealbreakers. There are known techniques to mitigate each one. 

Generative UI examples: two working demos

We built two demos. One with fictional data, one on top of a tool we use every day.

Aurora Goods: a conversational e-commerce dashboard

Aurora Goods is a fictional consumer e-commerce platform we created for the demo. The interface is simple: chat on the left, canvas on the right. You ask about the business, the LLM figures out what you need, pulls the data, and renders it visually.

Ask about 2025 sales and it shows the numbers on cards, with a short note on anything relevant. Ask it to break that down by region and it extends the same view instead of starting over, because it understands the second question builds on the first. This part took us a while to get right, and it's what makes the whole thing feel like a conversation rather than a search box.

The canvas isn't output-only either. You can click into any element and drill down: revenue by category, then inside electronics, then which products sold most.

You configure the widgets once. The system combines them and adds relevant commentary on the spot.

An internal reporting screen for our time-tracking tool

The second demo is closer to home: a generative reporting layer on top of the time-tracking tool we use every day at Kaizen. The questions in this demo are questions someone here has actually asked.

Instead of building dozens of hyper-specific reports, a small amount of code now handles virtually unlimited queries. How many hours were logged in May? Which anomalies showed up in April? How do billable and non-billable hours compare across two months? Who worked on a given project last month, and for how long? Each answer arrives as the right visualization: cards, lists, bar charts, plus a short summary that's easy to scan.

Two details won us over. The LLM suggests next steps, so exploring the data becomes a conversation. And when it's not sure, it asks instead of assuming. Ask for the hours of someone named Alex and, since we have more than one Alex on the team, it asks which one before answering.

Generative UI complements standard UI. That's the point.

Generative UI is a complement, not a replacement. Standard interfaces still win for stable, repetitive workflows where consistency matters. Nobody wants their checkout button to be creative. Generative UI wins where the workflow is complex and the questions are unpredictable.

It also changes what design systems are for. Beyond designing components and screens, teams will need to define semantic rules: how the AI should react to uncertainty, which interfaces match which intentions, and the guardrails that keep generated screens functional and safe.

That's a new kind of design work. And it's already starting.

Want to see generative UI applied to your own data? 

We build working proofs of concept in two weeks. Your data, your workflows, a real thing you can click.

Start a conversation.

Common questions

What's the difference between generative UI and a chatbot?

A chatbot answers in text. Generative UI answers with interface: charts, tables, cards, and interactive elements composed in real time for your specific request. Both can live in the same product, like a chat panel that renders visual answers on a canvas.

Does the AI write the frontend code?

In the declarative approach, the most common in production, no. The AI outputs structured data describing which pre-built components to use and how. The frontend renders them.

What is the AG-UI protocol?

AG-UI is a standard for communication between AI agents and frontends. It defines events that synchronize the agent's state in the backend with the frontend framework, so generated interfaces stay consistent with what the agent is doing.

Is generative UI expensive to run?

There's an inference cost per generated view, plus added latency from the LLM. Whether that's worth it depends on the workflow. For complex, open-ended reporting, it usually is.

What do you need to implement generative UI?

Three things: a component library the AI can compose, an LLM that translates requests into structured schemas, and a protocol like AG-UI to keep backend and frontend in sync. You build the components once. The system does the rest.

Is generative UI the same as adaptive or personalized UI?

No. Adaptive UI adjusts pre-built layouts based on rules or user segments. Generative UI composes new views in real time from a user's specific request, using an AI model to make the design decisions.

‍

1
What is the difference between working with Kaizen versus a single designer?

Related Articles

View all articles

·

Oct 19, 2026

Kaizen is certified in the Claude Partner Network: what it means for our clients

Kaizen Softworks is Certified in the Claude Partner Network, bringing AI-assisted development services like prototyping, MCP connectors, and AI agents to clients.

12 read time

Read more

Kaizen Softworks is Certified in the Claude Partner Network.

This milestone recognizes the Claude training and certifications completed by members of our team. It also reflects work we've been doing across Kaizen: testing how AI can improve software development and exploring new ways to build AI into products.

For your team, that could mean testing a product idea earlier, finding information across internal systems, or reducing manual work in an existing process.

We've been exploring these opportunities through internal experiments and client projects. Now we're bringing that experience into services designed to help you identify where AI makes sense and turn promising ideas into working software.

What being Certified means

The Claude Partner Network is how Anthropic works with firms that help customers bring Claude into production. Its Services Track recognizes progress in developing certified teams, delivering Claude use cases, and demonstrating customer work.

Certified is the first partner tier. It recognizes firms whose team members have completed Claude training and earned Claude certifications.

For Kaizen, this is another step in building our team's AI capabilities. The certifications add structured learning to the practical work we've been doing through our Innovation Hub.

How AI is changing the way we build software

AI is changing how we work across the software development cycle, from exploring ideas and designing experiences to writing code, testing, and releasing improvements.

AI-assisted workflows can help teams build up to 6× faster at a fraction of the cost. The actual gains depend on the project, the tools involved, and how the work is organized.

Our experience has shown us that speed alone isn't enough. AI-generated work still needs clear requirements, technical judgment, and careful review to ensure the software is reliable and maintainable.

For clients, this creates opportunities to explore ideas, validate decisions, and ship improvements faster, with less development effort and lower costs.

How AI changes what your product can do

Using AI to build software is different from adding AI capabilities to a product.

When AI becomes part of your product, the starting point is what users need to accomplish.

Maybe they need to find information across several systems. Maybe your team spends too much time gathering context before making a decision. Or perhaps there's a repetitive task that could be completed with less manual effort.

AI can help with these needs, but making it useful takes more than connecting to a model.

We help define what information AI can access, which actions it can take, when people need to be involved, and how the product should handle incomplete or incorrect answers.

What this means for our clients

Whether you're building a new product, improving an existing platform, or modernizing software, AI creates opportunities worth exploring. Your product doesn't need an AI feature for your team to benefit from AI-assisted development.

Here's how we can help.

Test ideas earlier. AI-assisted prototyping and design exploration can help your team review ideas sooner. You can identify usability issues, gather feedback, and decide what's worth building before committing to a full implementation.

Find where AI fits your project. Not every workflow needs AI, and results depend on your systems, requirements, and team. We help you identify specific opportunities, test them, and decide whether the improvement justifies further investment.

Turn promising ideas into working software. A successful experiment is a starting point. We support the design, integration, testing, and engineering work needed to make software reliable, secure, and maintainable.

Our certification marks progress in developing the skills behind this work. What matters for clients is how we put those skills to use.

Services built around those needs

Your team may have useful information spread across applications, databases, and internal systems. Finding an answer often means searching through several tools. Our Custom MCP Connector service helps connect those systems to AI tools such as Claude, so users can find approved information without navigating every system separately.

Some processes involve the same steps every time: reading a request, gathering information, and deciding what happens next. Our AI Agents service helps identify which parts of those processes AI can handle. We define the task's boundaries with your team, including which tools the agent can use and which decisions require human approval.

A prototype can show that an idea works. Making it reliable enough for everyday use requires more work. Our Prototype to Production service helps your team take an existing prototype further, addressing how it connects with your systems and what it needs to run reliably. That includes defining expected behavior, improving code quality, addressing security, preparing deployment, and planning maintenance.

Where to start

Start with a change worth making.

Choose one workflow or product need. Identify what takes time, where information is difficult to access, or what prevents users from completing a task.

Then define what an improvement should accomplish.

That might mean less time searching for information, fewer manual handoffs, or a task users can complete with less assistance.

Start small, evaluate the whole workflow, and use the results to decide what comes next.

If you have a process you'd like to improve or a prototype you're ready to take further, get in touch. We can help you identify the next step and what it needs to prove.

·

Sep 30, 2026

What to set up before your team starts building with AI coding agents

Set up architecture, agent guidance, and verification in Sprint 0 before your team builds with AI coding agents, so engineers stay in control.

12 read time

Read more

An AI coding agent works with the context your team gives it: existing code, documented decisions, instructions, and reference examples. If that context contains inconsistent patterns, the agent can repeat them.

Before implementation starts, engineering leaders need to define how agents should work and how the team will check their output. Choosing a coding assistant does not make those decisions for you.

For greenfield projects, where the team is building a new codebase, our approach starts with Sprint 0. This is when the team sets the architecture, coding conventions, agent guidance, and verification process.

The setup has two parts: guidance that shapes the agent's work before it starts, and checks that catch problems afterward. With both in place, agents can take on more implementation while engineers stay responsible for how the software is built.

Give agents clear guidance before they build

The codebase is part of an agent's instructions. Its structure and existing implementations show the agent which patterns to follow.

A well-structured starting point gives the agent better direction than an empty repository or inconsistent boilerplate. That makes the team's early decisions important because those decisions become context for future work.

Sprint 0 makes that direction explicit through four elements:

  • Architecture decisions. Record key decisions in lightweight architecture decision records, or ADRs, so agents and developers can refer back to them.
  • Repository instructions. Use a file such as AGENTS.md to define the rules an agent should follow in the repository.
  • Skills and prompt templates. Prepare reusable guidance for recurring workflows.
  • Reference implementations. Keep examples that show the patterns and quality the team expects.

The team also needs to decide what agents can access and do. That includes which files and systems they can see, which tools they can use, what they can change, and which reviews they must pass.

Without enough context, agents have to infer what the team wants. Weak constraints can lead to inconsistent implementations.

Setting those boundaries is part of the engineering work that should happen before agents start building.

Set up verification before relying on agent output

Guidance shapes the work, but the team still needs to check what the agent produces.

That process can include:

  • Review rules for architecture, security, and token usage.
  • Automated tests and linting that check code against defined rules.
  • A sign-off process before changes reach production.

Engineering leaders need to define and maintain these checks. Stronger verification gives the team more confidence to delegate implementation work because problems are easier to detect before they reach production.

As agents take on more implementation, engineers can spend more time on architecture, review, and improving the guidance the agents work from.

Start construction with a clear specification

Implementation needs the same clarity: a description of what the team is building.

In this model, Product explores an idea in a separate environment and validates it with customers. Once the idea is ready for construction, Engineering receives:

  • A behavioral specification.
  • A test plan with acceptance criteria.
  • A link to the prototype for reference.

The experimental code stays in the exploration environment.

We cover that handoff in When PMs can ship code, what changes for Engineering?, including what Product should provide after testing an idea.

During construction, the specification defines the behavior the implementation needs to meet, including edge cases and failure modes. Engineering decides how to implement that behavior within the agreed architecture.

This gives the agent a defined target and gives the developer a clear basis for reviewing the implementation.

Keep engineering judgment in the construction cycle

Sprint 0 prepares the environment, but engineers continue making decisions throughout implementation.

The developer chooses the architecture and reviews the agent's execution plan, including which files it will change and which risks it has identified.

During implementation, the developer supervises the work. Before sign-off, the changes go through manual review, automated checks, and security review.

If the work stops matching the specification or architecture, the developer should stop and reset the cycle.

The guidance from Sprint 0 also needs to evolve. As the team builds, engineers can add new rules and examples, update existing ones, and remove documentation that no longer reflects the codebase.

Maintaining the context agents use becomes part of the development process.

Account for the codebase you already have

This approach is easiest to establish on a greenfield project because the team can set the architecture, conventions, and verification process from the start.

Existing codebases are different. Their previous decisions and inconsistencies are already part of the context an agent sees.

Teams can still introduce the same kinds of guidance and checks. Reaching consistent agent output can therefore take more work.

For a new project, Sprint 0 gives the team a chance to make those choices before implementation begins. Define the architecture, give agents clear guidance, put verification in place, and keep engineers responsible for architectural decisions and release approval.

Then keep that foundation current as the codebase grows.

If your team is starting a new project with AI coding agents, we can help you define the architecture, repository guidance, and verification process before implementation starts.

‍

llms.txt