json-render Adds AI Component Selection

The useful limit in Vercel Labs' json-render is that the model does not get to invent the interface. With its experimental Jev integration, the model chooses from component candidates the application already supplied, then the app turns those choices into a UI specification for the existing renderer.

That makes this open-source release interesting for agentic coding work that touches product UI. The project already frames itself as a generative UI framework: define a catalog, let AI produce JSON that matches the schema, then render it through known components rather than arbitrary markup.

Read the release as a renderer boundary

json-render is mainly TypeScript, Apache-2.0 licensed, and, as of September 21, 2026, the repository was active and had 18,119 GitHub stars. The README says the framework constrains AI output to components you define, with JSON specs, progressive streaming, and renderers across React, Vue, Svelte, Solid, and React Native.

The important artifact in the repo is the package split. @json-render/core carries schemas, catalogs, AI prompts, dynamic props, and SpecStream utilities; the framework then has renderer packages around that core idea.

The Jev part adds a sharper boundary. Your app supplies configured component candidates, including prepared content and allowed actions. Jev chooses which candidates to include and where they go, but the renderer still receives a structured spec rather than a free-form answer.

Give Jev choices, not wishes

The candidate set is the design surface. If you want the interface to choose between a line chart and a bar chart, supply both candidates, with the data already shaped for each component.

Do not hand Jev a vague chart request and expect it to discover your component system. The current design puts the work on the application: text values, data values, actions, and available components need to be prepared before the model chooses.

A dashboard workflow makes the point. If the product already has RevenueLineChart, RevenueBarChart, MetricCard, and OpenInvoiceAction, the experiment is not to ask the model to build a dashboard from scratch; it is to give Jev those candidates with real series data and let it select the layout that fits the prompt.

That is a smaller claim, and a better one. It turns AI UI generation into selection under constraints, not invention under pressure.

Notice what is still rough

The Jev docs describe the integration as experimental, and the Jev APIs are currently unreleased. Trying it requires building from source, so I would not treat this as a drop-in dependency for production code yet.

There is also a product design cost. Every candidate needs enough prepared content to be useful, so the catalog can become a second product surface that needs names, defaults, action boundaries, and test cases.

This is different from giving an agent another external tool through MCP. In a browser-agent story such as jev-ultrafast Narrows Browser Agent Actions, the boundary is about what actions the agent may call; here the boundary is what UI vocabulary the model may arrange.

For Claude Code users, I would keep that distinction clear in review. Ask the coding agent to help wire a small candidate catalog or test the emitted JSON shape, not to blur the renderer boundary by adding escape hatches.

Try one screen without touching routing

Use a boring screen first. A settings summary, billing overview, or internal dashboard is better than a checkout flow because you can inspect the generated spec without making user-critical actions depend on it.

Copy this note into the issue or PR description before you experiment:

I would also save one emitted spec as a fixture. That gives reviewers something concrete to diff when the catalog changes.

Decide from the spec, not the chat

The review object is the UI specification. The chat that produced it may explain intent, but the spec is what the app will render.

In the Review step of our methodology, I would ask for three things in the PR: the candidate list, one representative emitted spec, and the renderer test that proves unknown components are rejected. That keeps the discussion on code and constraints instead of prompt taste.

A simple pass condition is enough for the first branch. If the candidate list is clear, the prepared values are explicit, and the renderer refuses anything outside the catalog, the experiment is doing the job json-render is built around.

Further reading

• json-render on GitHub
• MCP specification
• Cursor Agent docs
• Claude Code docs

Try one real screen next

Pick one low-risk screen with two genuine component choices, build the json-render candidate set from source, and review the emitted spec before you wire any user action to it.