StemJSON and the Rise of JSON as an LLM Instruction Language

In September 2026, a project called StemJSON appeared on Hacker News with an unusual pitch: ship a mobile app, then let an LLM extend it on the fly — no new binary, no app store review, no backend deploy. The LLM emits a JSON module; a runtime validates and renders it as native iOS or Android UI inside the app the developer already shipped.

The community reaction ranged from "this is obvious" to "this is dangerous." Both reactions miss the more interesting point: StemJSON is a clean example of a broader shift in how LLMs are used in production systems. JSON is becoming an instruction language — not just a data format. And when JSON carries instructions instead of data, the failure modes change in ways that matter for everyone building AI pipelines.

This post, written by The JSON Medic, explains what StemJSON does, how it fits into the larger JSON-as-action-schema trend, and where JSON-based instruction languages break.

---

What StemJSON Actually Is

StemJSON is a declarative language and runtime built on JSON. Its version 1.1 specification covers component trees, reactive state, expressions, events, actions, navigation, validation, and data access. All of this is expressed as JSON objects that the runtime interprets at the time of rendering.

The workflow is:

1. A user describes a feature in natural language inside the app ("add a feedback form here")
2. The app sends that prompt to an LLM along with the StemJSON spec
3. The LLM generates a valid StemJSON module
4. The runtime validates the JSON, renders it as native UI, and sandboxes it inside the app's defined permissions

No server-side compilation step. No new app binary. The UI is live as soon as the LLM responds.

This is a specific implementation of server-driven UI (SDUI), a pattern that companies like Airbnb and Netflix have used for years to push UI changes without going through app store review cycles. What StemJSON adds is the LLM generation step: instead of a human engineer writing the JSON payload that the SDUI runtime interprets, the LLM writes it.

The appeal is real. If the LLM can reliably produce valid StemJSON — component trees, event handlers, navigation actions, and all — then app developers gain a new surface for user customization without sacrificing native performance or platform-specific behavior.

---

JSON as an Instruction Language: The Broader Pattern

StemJSON is one instance of a pattern that appears across the 2026 AI stack.

LLM tool calls use JSON to carry function arguments. When a model decides to call search_database, it emits a JSON object {"query": "...", "limit": 10} that the runtime validates against a schema and passes to the actual function. The JSON is not data being stored — it is an instruction being executed. MCP (Model Context Protocol) standardizes how tools expose their capabilities to LLMs. Every tool call in MCP is a JSON-RPC message. The schema that describes what a tool accepts is JSON Schema. When an LLM sends the wrong shape — a string where an integer is expected, a missing required field — the tool call fails. AI agent action plans follow the same structure. In frameworks like LangGraph and CrewAI, agents emit structured action objects. A routing agent might produce {"action": "escalate", "priority": 2, "team": "billing"}. Downstream systems parse this and act on it. The JSON is not describing data; it is driving behavior. Generative UI goes a step further. Projects like Renderify transpile LLM-generated component descriptions — expressed as JSON plans — directly into interactive browser UI with no build step. Google's Generative UI documentation describes a similar pattern for agent-powered interfaces.

In all of these cases, JSON serves the same role: a portable, schema-validatable, runtime-interpretable instruction format that sits between an LLM's text output and a system that needs to act on it.

This matters because JSON-as-instruction has different quality requirements than JSON-as-data.

---

Where JSON-as-Instruction Breaks

When JSON carries data, a malformed value is an annoyance. The pipeline logs an error, retries, or falls back. The worst case is usually a 400 response or a rejected database insert.

When JSON carries instructions, a malformed value can mean a wrong action. Consider three failure modes:

1. Schema Drift Under Real Prompts

LLMs generate JSON against a schema they were shown at inference time. If the user's natural language prompt is ambiguous, or if the schema has optional fields with complex constraints, the LLM may produce structurally valid JSON that is semantically wrong. In a StemJSON context: a component tree that renders but displays incorrect state because the reactive expression was generated incorrectly. The runtime accepts it; the user sees the wrong thing.

This is the same problem that BenchLM documented in September 2026: even top-tier models produce structurally valid JSON that contains wrong values. For data, that is a data quality problem. For instructions, it is an execution correctness problem.

2. Truncation Under Token Pressure

A long or complex StemJSON module — with nested component trees, multiple event handlers, and navigation rules — can hit token limits during generation. The LLM truncates mid-object. The result is structurally invalid JSON: a missing closing bracket, an unterminated string, a dangling comma.

This is a standard JSON repair problem. The module fails validation before it ever reaches the rendering runtime. A repair layer — something that closes open brackets, strips trailing commas, and rebuilds the structural envelope — can recover the module if the semantic content was generated correctly before truncation hit.

3. Hallucinated Components

A JSON DSL is only as expressive as its runtime. If the StemJSON runtime supports a component named NativeList with specific props, and the LLM invents NativeScrollList because it was trained on web component names, the runtime will reject the unknown component. From the LLM's perspective, it produced valid-looking JSON. From the runtime's perspective, the value in "component": "NativeScrollList" references something that does not exist.

Schema validation catches this — if the schema uses an enum to restrict component names to the supported set. But spec-complete schema enforcement requires the developer to maintain a tight schema that enumerates every valid value for every discriminator field. In practice, schemas are often partial: they validate structure but not every enum constraint.

---

The Validation Requirement

Any system that executes LLM-generated JSON as instructions — whether it is StemJSON, MCP tool calls, or an agent action router — needs a validation layer between the LLM output and the execution runtime.

The validation stack has three layers:

Structural validation confirms that the JSON is syntactically valid. Closing brackets, no trailing commas, properly quoted strings. This is what a JSON parser does. If the output is broken, a repair tool like AI JSON Medic can close the structure before validation runs. The json-repair library handles truncation and common LLM-specific errors programmatically. Schema validation confirms that the JSON matches the expected shape: required fields present, types correct, enum values within the allowed set. JSON Schema validation against a strict schema catches component name hallucinations, wrong field types, and missing required properties before they reach the runtime. Semantic validation confirms that the values are meaningful given the current state. This is the hardest layer. A component tree can be structurally valid and schema-valid, but reference a navigation target that does not exist in the current app state. Semantic validation requires domain-specific checks that go beyond what a JSON Schema can express.

For most LLM-driven instruction systems, the first two layers are mandatory. The JSON Schema generator can derive a draft schema from example StemJSON modules, which is a practical starting point before hand-tuning the constraints.

---

StemJSON in Context: Why This Architecture Will Spread

Server-driven UI has been around for a decade. The reason it did not take over mobile development is the authoring cost: someone has to write and maintain the JSON payloads. Debugging a broken SDUI payload is slower than debugging code, because the payload is data and most development tooling is built for code.

LLMs change the authoring cost. If a language model can generate a valid, complete SDUI payload from a natural language description, the authoring cost drops to near zero. The remaining costs are schema design (what can the runtime do?), validation (did the LLM emit a valid payload?), and sandboxing (what is the payload allowed to do?).

StemJSON addresses sandboxing and schema design. The validation problem is left to the developer — which is consistent with how every other JSON-as-instruction system works. MCP does not validate for you. Tool-call frameworks do not validate for you beyond basic type checking.

The pattern that works in production is: generate JSON, repair if structurally broken, validate against schema, reject if schema-invalid and retry with a correction prompt, execute only after passing both checks. This is the three-layer pipeline that the AI agent JSON guide and the LLM JSON repair guide cover in detail.

StemJSON is not unique in needing this pipeline. It is the most visible recent example of why the pipeline is becoming standard infrastructure.

---

Key Takeaways

• StemJSON uses JSON as an instruction language for LLM-generated native mobile UI. The LLM emits JSON; the runtime renders it natively without a new binary or app store release.
• This is part of a broader 2026 trend: JSON-as-instruction appears in MCP tool calls, AI agent action plans, and generative UI systems. The format is the same as always; the role is different.
• JSON-as-instruction has stricter quality requirements than JSON-as-data. Structural errors block execution; schema errors cause wrong actions; semantic errors produce incorrect behavior even when the JSON is valid.
• A three-layer validation stack — structural repair, schema validation, semantic checks — is the production-ready approach for any system that executes LLM-generated JSON.
• Tools: AI JSON Medic repair tool for structural errors, JSON Schema validator for schema errors, JSON Schema generator to derive schemas from existing examples.

---

Frequently Asked Questions

What is StemJSON?

StemJSON is a JSON-based declarative language and runtime that lets LLMs generate native mobile app UI features on the fly. An LLM emits a StemJSON module from a user's natural language prompt; the runtime validates and renders it as native iOS or Android UI inside the running app, without requiring a new binary or app store review.

How is JSON used as an instruction language in LLM systems?

In LLM tool calls, agent action plans, MCP messages, and server-driven UI systems, JSON carries instructions rather than static data. The LLM generates a JSON object that describes an action — a function to call, a UI to render, a navigation step to take — and a downstream runtime parses and executes it. This differs from JSON-as-data because the values drive behavior, not just storage.

What goes wrong when LLMs generate JSON instructions?

Three common failure modes: (1) structural errors from token truncation — the model runs out of context and produces incomplete JSON with unclosed brackets; (2) schema errors — the model invents field names or component names that do not exist in the runtime's vocabulary; (3) semantic errors — structurally and schema-valid JSON that references wrong values, navigation targets, or state that does not match the current execution context.

Does StemJSON validate the JSON it receives from the LLM?

StemJSON's runtime validates the module against its spec before rendering. But validation catches schema errors only if the schema is strict enough. Structural errors (broken JSON) fail before schema validation even runs — a JSON repair step is needed upstream.

How do I repair LLM-generated JSON before it reaches an instruction runtime?

Use a library like json-repair (npm/PyPI) to close open brackets, remove trailing commas, and fix truncation artifacts programmatically. For larger or more complex payloads, the AI JSON Medic repair tool handles these cases online. After repair, validate against your schema using a JSON Schema validator before passing the payload to the execution runtime.

What JSON Schema tools help with LLM instruction systems?

The JSON Schema generator derives a draft schema from example JSON payloads — useful for getting a strict schema from existing StemJSON or tool-call examples. The JSON Schema validator then checks LLM-generated payloads against that schema before execution. Together they form the structural + schema layers of the three-layer validation pipeline.