DEV Community: Maxim Berenshtein

Guardrails for AI-Assisted Development: Skills, Gates, Hooks and Mutation Tests

Maxim Berenshtein — Wed, 16 Sep 2026 12:09:10 +0000

When a model writes the code, writing it stops being the expensive part. Proving you didn't break something nobody was looking at becomes the expensive part.

That sentence took me a few months of building to arrive at, and once I had it, most of my tooling decisions stopped being arguments.

This is a walkthrough of the verification layer in a real project of mine: a wellbeing analytics platform with a Next.js core and a Python AI service. Four agent skills, sixteen repository gates, a hook that runs them at edit time, and a narrow mutation testing pilot. Everything here is running code, and I'll be specific about what each piece does not catch, because that turns out to be the more useful half.

Why conventions in a README don't survive

Let me start with the failure that convinced me.

My repo has an AGENTS.md saying that .agents/skills/ is the single source of agent instructions. A month earlier, GEMINI.md had said in plain prose: don't create client-local copies of these skills.

A 3,442-byte partial copy of one skill showed up in .gemini/skills/ anyway. Two weeks later there was still an empty leftover directory next to it.

Here's the part that matters: .claude/ and .gemini/ are in .gitignore. The copy was invisible in every diff and every code review. Not missed by a reviewer. Invisible to the mechanism of reviewing.

Two copies both claiming to be canonical, drifting apart with nothing comparing them. Prose has no enforcement mechanism. That's not a discipline problem, it's a category problem.

Layer 1: a skill tree with exactly one root

Skills are markdown files that tell an agent how to work in this repository; mine cover product invariants, session/branch state, verification, and the gates themselves. The design has four rules.

One canonical location. .agents/skills/ and nowhere else. There is no list of skills in any config file. The canonical set is the directories on disk:

const skillNames = fs
  .readdirSync(SKILLS_ROOT, { withFileTypes: true })
  .filter((entry) => entry.isDirectory())
  .map((entry) => entry.name);

A folder appears, a skill exists. This is why a copy elsewhere is dangerous rather than merely redundant: if the filesystem is the source of truth, any folder with a familiar name becomes a second source of truth.

Routing in the entrypoint. AGENTS.md carries a plain markdown list mapping tasks to skills:

- Verifying, testing, proving a fix, checking readiness, reviewing evidence, or
  about to claim a substantive change is complete →
  `.agents/skills/shalomut-verification/SKILL.md`.

Why bother if some clients discover skills automatically? Because a client with discovery and a human reading the file directly must arrive at the same rules. Discovery changes how a file is found, never what it says.

A reading map inside each skill. Every skill has a How to read this skill section splitting its own sections into "always in force" and "open when this condition holds." That map, not the entrypoint, decides how much of a skill a task needs. The rule next to it: loading a section is cheap, skipping a rule is not, so when a condition is ambiguous, open the section.

A check that all of the above holds. npm run lint:skills refuses: a skill copy outside the canonical root (including an empty directory named after one), a broken or orphaned link in references/, a ## section the reading map never classifies, and any client entrypoint that routes nowhere.

Layer 2: gates, or how a convention becomes unignorable

A gate is a script that reads the repository and exits non-zero when it finds a violation. Nothing executes. No arguments get fuzzed, no mutants get generated. It reads — not just paths, but anything knowable without running the program: where a repository gets constructed (lint:composition), what a response body contains (lint:error-bodies), whether a document still agrees with the configuration it quotes (lint:doc-numbers).

What actually deserves a gate

This is the decision rule I'd most want to hand to someone starting out, and it took me a while to get right:

Kind of rule	Where it belongs
Lives inside a module, expressed through its API	An ordinary test. No gate.
About the shape of the repository: what may be imported, where a literal may stand, which interpreter runs, where skills live	A gate
Editable source with a derived copy	A `--check` mode on the generator, not a second equality test
A machine cannot judge it: is this architecture right, is this audit record genuinely closed	Prose. And say so in the gate's doc comment, so a green gate never reads as proof of what it never checked

The tell that you need a gate: the violation is silent. Tests green, build passing, reviewer sees nothing, and the rule is already broken. If a violation fails the suite anyway, a test is enough and a gate is overhead.

One gate in full

The audit of my repo counted 21 route handlers interpolating a raw error.message into what they sent back. On /api/auth/login that went to anyone. Every one was written by somebody being helpful.

The naive check is a regex for error.message. I wrote that first. It let (error as Error).message straight through, and the audit itself had missed error?.message for the same reason.

So the rule became two rules:

a catch in a route handler binds the name error;
the argument of NextResponse.json(...) never mentions it.

Rule 1 exists to make rule 2 complete. Refusing the whole identifier makes the spelling irrelevant, and an identifier rule is only as good as the identifier, so rule 1 stops a handler slipping past with catch (e).

The implementation is not a regex either. It's three passes:

// 1. Strip strings and comments, but KEEP ${...} inside templates.
//    Without stripping, { error: 'Internal error' } fails on its own wording.
//    Stripping templates whole would let `failed: ${error}` through,
//    and that is the leak itself.
export function stripTextAndComments(source) { /* hand-written scanner */ }

// 2. Find the argument region of a literal call by counting parens.
export function argumentRegions(source, call = 'NextResponse.json(') { /* ... */ }

// 3. Only now, a pattern. A property access is fine (`produced.error` is our
//    own field). A spread is not: { ...error } puts the whole thing in the body.
new RegExp(`(?<![\\w$])(?<!(?<!\\.)\\.)${BINDING}\\b`).test(readable)

Two places in the codebase used the name error for the product's own refusal wording. They got renamed rather than exempted. An exemption list is a place the next leak hides.

And the blind spot, stated in the doc comment rather than discovered later: a body assembled into a variable and passed by name goes unnoticed. That gap is accepted, because the alternative is parsing TypeScript in a fitness check and every occurrence the audit found was a literal at the call site. With the follow-up that matters: if that stops being true, this needs a parser, not a wider regular expression.

The shape every gate shares

// scripts/check-<subject>.mjs
/**
 * <The rule. Why it exists — name the actual incident. What this cannot see.>
 */
export function findViolations(source, file) { /* pure, returns string[] */ }

function main() { /* reads files, prints, process.exit(1) */ }
if (process.argv[1] === fileURLToPath(import.meta.url)) main();

Pure exported functions so the test can import them. main() guarded so importing doesn't run it. And on success, a line saying how much was checked:

Error-body fitness check passed: 47 route handlers, no caught error in a response body.

A silent success is indistinguishable from a check that read nothing.

Wiring, and why every gate has its own test

"lint:error-bodies": "node --test scripts/check-error-bodies.test.mjs && node scripts/check-error-bodies.mjs",
"verify:core": "npm run lint:literals && ... && npm run typecheck && npm test && npm run lint && npm run build"

The gate's test runs before the gate. That order is the whole point: prove the check can fail, then trust it. A check whose pattern never matches anything is worse than no check, because it manufactures confidence.

Gates that guard the gates

The cheapest way to fix a red gate is to delete it from the chain. So:

lint:gate-inventory refuses:
  - a gate that isn't a step of verify:core
  - a gate missing from the inventory table
  - an inventory row with no gate behind it
  - a lint:* command that doesn't run its own test

Without this, the whole safety system rests on good faith, which means it doesn't rest on anything.

Same principle inside the skills: the guardrails skill says outright that weakening a check, adding a file to an exemption list or narrowing its scope is a change to the rule, not a fix to the build — do it deliberately, update the doc comment and the tests on both sides. And: never bring a gate's test in line with current behaviour to make things green. The gate's test is the record of the rule.

Layer 3: the hook, so the agent hears it now

CI is the record. But CI tells you at 11:00 about something written at 10:00, by which point it's buried under later edits made on top of it.

.claude/settings.json is the one file under .claude/ that Git tracks — .gitignore un-ignores exactly it:

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit|Write|MultiEdit|NotebookEdit",
      "hooks": [{ "type": "command", "command": "node scripts/gate-hook.mjs", "timeout": 90 }]
    }]
  }
}

gate-hook.mjs holds no rules. It takes the path of the file just written, maps it to the gates that could care, and runs those:

const RULES = [
  { gate: 'lint:error-bodies',
    when: (file) => /^src\/app\/api\/.*\/route\.ts$/.test(file) },
  // ...
];

On refusal it exits with code 2, which feeds stderr back to the agent, and the message points to the relevant skill section and explicitly says not to weaken the check or rewrite its test to make it pass. That last line is defence against the first thing an agent tries.

Three limits, all stated in the file itself:

15 of 16 gates are mapped. lint:literals is deliberately out: its Python half needs an interpreter from .venv, and a missing local environment must not read as a violation.
The mapping is narrow on purpose. A gate that fires on every edit is a gate people learn to wait out.
It runs in one client only. A rule that lives in a hook doesn't exist for Copilot, for Gemini, or for a person in a terminal.

One implementation detail worth stealing: the hook runs only the check half of each command, not the node --test half. The first version buried a one-line violation under sixty lines of passing TAP.

Layer 4: tests, and proving the tests are worth anything

Gates check shape. Tests check behaviour. Neither checks whether the tests are any good. That's mutation testing: deliberately corrupt the code, see whether tests notice. Mine runs on two files — the AI contract validator and the scoring bands — and the full run isn't a CI gate: the score moves when a function migrates between files or a test file enters the list, which has nothing to do with test strength.

The checks around it keep that number meaningful. lint:mutation-config re-derives tap.testFiles from the repo, because a missing entry doesn't lower the score honestly — it reports as survived a mutant a real test would have killed. lint:contract-refusals demands a negative-test suite for every contract version; it proves a suite exists, not that it is complete. And when a product rule leaves a mutated file, mutate follows it in the same change, or the rule silently drops out of measurement.

Layer 5: how much checking is enough

This is the part I'd defend hardest, and the part most teams skip.

My verification skill carries a selection matrix: rows are areas a diff touched, cells are the mandatory minimum. The principle: choose the smallest set of checks that proves the changed behaviour, then widen in proportion to risk.

A few rows:

Changed	Mandatory minimum
Markdown / skills only	Frontmatter and links, `git diff --check`, `lint:skills`
A repository gate	Its paired test and the gate, `lint:gate-inventory`. Weakening the check = changing the rule
`src/app/api`, services	Nearest tests, then `npm test` and `npm run build`
AI contract	`lint:contract-refusals`, contract/registry/client tests, Python tests, local boundary E2E
Python dependencies	`lint:python-deps`; production runs 3.11 and dev machines usually don't have it, so the one real proof is `docker build` plus the suite inside that image
Auth or secrets	Unauthorized / missing-secret / tenant-isolation tests plus a security-focused diff review

Running everything for a docs edit is the same mistake as running one small test for an auth change. Both look like diligence. Neither is.

One check belongs to no row: typecheck is mandatory for any .ts change. build types only the application graph, lint doesn't check types at all, and npm test runs through tsx, which strips types without checking them. A green test run tells you nothing about types.

Say what counts as evidence

With an agent this stops being pedantry. Models report affirmatively by default, so the rules are written down:

Label the context — local, test, or deployed — and never mix them silently.
npm run dev starts a runtime. It is not evidence.
A mock MCP server is not proof of real transport, and a wrapper that delegates to the same command is not a second piece of evidence.
Don't promise repo-wide mutation coverage. Separate killed / survived / no-coverage / runtime-error.
verify:core is an && chain: it stops at the first failure. The steps after it did not run — don't report them as passed.

Every rule carries its incident

The habit I'd transplant into any codebase regardless of AI: each check's doc comment names what broke, with a date.

Fonts. Until 2026-08-12 the build downloaded five .woff2 files from a Google host; when a runner got a stale stylesheet, all five 404'd and the build failed with a message mentioning neither fonts nor the network. The same commit built cleanly in the neighbouring job, so the gate had become a coin toss instead of a red light.
Tenant chokepoint. A context loader recorded the visit from the request rather than the answer, so an administrator reading the only tenant left no audit row at all, and no test failed.

The corollary is a cleanup rule: a rule with no incident behind it is a candidate for deletion. Either it isn't needed, or nobody remembers what it defends — and the first person it inconveniences will remove it.

What this doesn't do

Gates read text. A determined rename or a dynamic call walks around them. They defend against accidental violation, not adversarial.
Presence checks don't check agreement. A client adapter passes if it contains the string .agents/skills, even if the surrounding sentence says the opposite. Stated in the code; it stays a review question.
None of this judges whether an architectural decision is right.
It costs. Sixteen gates is sixteen scripts plus sixteen tests plus an inventory plus a gate guarding all of it. On a two-week prototype that's absurd. In a regulated domain where the question is "prove this data couldn't leak," it's the cheapest answer I know.

If you're starting tomorrow

Take the last silent bug you shipped. Write the smallest script that would have refused it. One rule.
Give it a test that proves it can fail, and wire the test to run first.
Put it in one verify chain with everything else, and put that chain in CI.
Write the incident in the doc comment, with the date, and write down what the check can't see.
Only then hook it into your agent's edit loop, so the refusal arrives while the context is still warm.

Steps 1 through 4 work with no AI involved at all. Step 5 is just the feedback arriving earlier. That ordering is deliberate: the reason any of this holds is that the rules live where every client and every human reads them, and the agent integration is the last mile rather than the foundation.

What Angular Actually Re-renders When a Model Streams Your UI

Maxim Berenshtein — Mon, 14 Sep 2026 16:22:36 +0000

When a model streams a UI into an Angular app, the spec behind the screen changes many times per second. Two questions follow from that, and both are easy to answer by guessing:

Angular has no render(node) function that calls itself. So how does it draw a tree when nobody knows how deep it goes?
On every patch, does Angular redraw everything? And when one deep child changes, how does Angular even know?

I measured instead of guessing, and read Angular's source where the answer wasn't obvious.

The examples come from ngx-json-render, an Angular renderer for json-render specs. If the format is new to you, my first article explains it. But the mechanics below are plain Angular: NgComponentOutlet, @for, dependency injection and signals.

How Angular draws a tree it has never seen

A spec describes a tree as a flat map of elements:

{
  "root": "card",
  "elements": {
    "card":  { "type": "Card", "props": {}, "children": ["title", "list"] },
    "title": { "type": "Text", "props": { "content": "Hello" } },
    "list":  { "type": "List", "props": {}, "children": ["a", "b"] },
    "a":     { "type": "Text", "props": { "content": "A" } },
    "b":     { "type": "Text", "props": { "content": "B" } }
  }
}

There is no recursive function in the renderer. The recursion is made of three ordinary Angular tools that call each other through templates.

Tool 1: NgComponentOutlet picks a component class at runtime. One small component does only that: take a key, find the element, create the matching component.

@Component({
  selector: 'jr-element',
  imports: [NgComponentOutlet],
  template: `
    @if (component()) {
      <ng-container *ngComponentOutlet="component(); injector: injector" />
    }
  `,
})
export class JrElement {
  readonly elementKey = input.required<string>();
  // "Card" → CardComponent, looked up in the registry
}

Tool 2: @for renders the children, one jr-element per child key:

@Component({
  selector: 'jr-children',
  imports: [JrElement],
  template: `
    @for (key of childKeys(); track key) {
      <jr-element [elementKey]="key" />
    }
  `,
})
export class JrChildren {}

Tool 3: your own component puts <jr-children /> wherever its children should go:

@Component({
  selector: 'app-card',
  imports: [JrChildren],
  template: `<section class="card"><jr-children /></section>`,
})
export class CardComponent {}

Put them together and you get the loop:

jr-element "card"  → app-card
  jr-children      → jr-element "title" → app-text
                   → jr-element "list"  → app-list
                       jr-children      → jr-element "a" → app-text
                                        → jr-element "b" → app-text

Nobody calls anything recursively. Components create components, and the tree grows as deep as the data says.

How does a child know where it is?

The parent passes only one input: the key. Everything else travels through dependency injection. Each jr-element creates a small injector for the component it renders:

readonly injector = Injector.create({
  providers: [
    { provide: RENDER_CONTEXT, useValue: this.renderContext }, // props, events
    { provide: RENDER_PATH, useValue: this.path },             // my ancestry
  ],
  parent: inject(Injector),
});

Your component calls injectRenderContext() and gets its props as signals. The next jr-element down injects the parent's RENDER_PATH and adds itself to it.

That's the part I find elegant: Angular's injector tree plays the role of the call stack. In a recursive function, each call sees its caller's arguments. Here, each level sees its parent's providers.

And since every component was compiled ahead of time, the runtime never compiles anything. It only decides which already-compiled component to create next.

The cost of recursion that lives in Angular

Angular creates and checks views with plain recursive JavaScript functions. And each level of the JSON becomes several nested Angular views: jr-element, its @if block, your component, jr-children, its @for block.

So the depth of the JSON becomes the depth of the JavaScript call stack. That has a price: two elements that name each other as children are enough to run the stack out and kill the tab. Where that recursion has to stop is a story of its own.

Streaming: does Angular redraw everything?

With streaming, the model doesn't send a finished spec. It sends small patches, one per line:

{"op":"add","path":"/elements/card","value":{"type":"Card","props":{},"children":["title","list"]}}
{"op":"add","path":"/elements/title","value":{"type":"Text","props":{"content":"Hello"}}}
{"op":"replace","path":"/elements/a/props/content","value":"A2"}

Each patch produces a new spec object, which reaches the renderer through a signal. The natural fear: new object at the top means every component redraws, dozens of times per second.

I measured it instead of guessing. The spec above, with counters in every component: how many components were created, and how many component templates ran again.

What the patch changed	Components created	Templates re-run
First render, 5 elements	5	5
A prop of a deep leaf (`a`)	0	1 (only `a`)
A new child key in `list`, element not arrived yet	0	1 (`list`)
That child's element arrives	1	1 (the new child)
New spec object, nothing inside changed	0	0

So no, it doesn't redraw everything. Four ideas make that work, and the first one isn't about Angular at all.

Idea 1: a patch replaces only what it touches

The patch doesn't mutate the old spec, and it doesn't deep-copy it either. It copies only the objects on the path to the change:

before:  spec  → elements  → card, title, list, a,  b
patch:   replace /elements/a/props/content
after:   spec' → elements' → card, title, list, a', b
                              (same objects)   (new)

card, title, list and b are the same objects in memory as before. So "did this element change?" becomes a single ===.

Idea 2: each element watches only its own piece

Every jr-element reads its element through a computed:

readonly element = computed(() => this.root.spec()?.elements?.[this.elementKey()]);

When the spec changes, all these computeds run again, and each one is a single lookup. But a computed only reports a change when the new value is a different object. For card, title, list and b the lookup returns the same object, so the change stops right there. Nothing that depends on them runs.

Idea 3: Angular refreshes views, not the whole tree

This is the answer to "how does Angular know a deep child changed?"

It doesn't search for it. In modern Angular every view has its own reactive consumer, which remembers exactly which signals its template read. I checked this in Angular 21's source. When one of those signals changes:

that view is marked dirty;
its parents only get a flag saying "a child below needs checking". Their own templates don't run (markAncestorsForTraversal);
before refreshing a dirty view, Angular checks whether the signals it read really got new values, and skips the view if not (consumerPollProducersForChange).

So on a deep change, Angular walks down the path to that one view, runs its template, and updates only the DOM bindings whose values actually differ. The parents stay untouched.

In a zoneless app, and zoneless is the default for new apps since Angular 21, there's nothing else that could trigger a check. The signal notification is what schedules the update.

Idea 4: new children don't rebuild the list

@for (key of childKeys(); track key) compares children by key. When list gets a third key, Angular keeps the two existing views and creates one new one.

Streaming adds a twist: a parent often lists a child before the child's element has arrived. That's fine. The jr-element for the key is created and renders nothing. When the element arrives, only that one component is created. That's rows 3 and 4 of the table.

What isn't free

To be fair about the limits of this:

Every patch still does a small amount of work per element. Each element's computed runs once, and Angular walks the tree to find dirty views. It's cheap, but it grows with the size of the spec.
Data is not structure. That one deserves its own section.

When the data changes, not the UI

Specs also carry data. A text can read { "$state": "/user/name" }, a list can repeat over /todos. A user types into a field, or the stream sends a new value, and the data changes while the structure stays the same.

The state store itself does this well. It copies only the path to the changed value, and writing the same value again does nothing at all.

The renderer layer is where precision gets lost today. Every element resolves its props against the current state, and resolving always builds a new props object, even when every value inside it is the same. A new object counts as a change, so Angular re-runs every component's template. The DOM still changes only where a value really differs, but the template work covers the whole tree.

I measured it on a small spec: a card, a static text, a text bound to /user/name, and a todo list. Then I tried one small change: treat two props objects as equal when all their values are the same (a shallow compare on the props computed).

What changed in the data	Templates re-run today	With a shallow compare on props
`/user/name` (read by one text)	6 of 6, the static text included	1 (only that text)
The same value written again	0	0
A todo appended to `/todos`	7 of 7 (and 1 new component)	1 (the new todo)

Same idea as with patches: keep identity, and "nothing changed" becomes cheap. The fix just has to restore identity one step later, after props are resolved.

When I wrote this, it was an experiment, not a shipped change. It isn't free of trade-offs:

Every element still re-resolves its props on every data change. The compare saves Angular's work, not that JavaScript. The next step would be remembering which state paths each element reads, and skipping the rest.
Props that resolve to nested objects or arrays are new objects every time, so the shallow compare doesn't help them. It's no worse than today, though.
An external store that mutates objects in place could be shown stale, because the reference stays the same while the content changes. That case is exactly why the renderer treats every store update as a change today.

Update (0.5.1): this is now shipped. A resolved element keeps its previous object when its props hold the same values, and the right-hand column of the table is what the release's tests measure. Three details differ from the experiment:

With the built-in store, object and array values compare by reference. The store copies every path it writes, so a { "$state": "/todos" } prop keeps its identity until /todos itself changes. Literal objects with expressions inside, and $computed results, are still rebuilt on every resolution.
With an external store, object and array values always count as changed, because such a store may write into its snapshot in place. Primitives still compare by value.
Elements with a $bindState or $bindItem prop keep the old behaviour. Their input can hold text that state hasn't seen yet, and the component's props effect has to run to put the DOM right.

The short version

How Angular recurses

There's no recursive function: NgComponentOutlet → your component → @for → NgComponentOutlet.
The injector tree works as the call stack. Each level sees its parent's context.
JSON depth becomes JavaScript stack depth.

What streaming re-renders

Patches keep unchanged objects, so "unchanged" is a ===.
Each element watches only its own piece through a computed.
Angular doesn't search for changes. It refreshes only views whose signals really changed, and walks through the parents without re-running them.
@for ... track key keeps existing children and creates only new ones.

What data changes re-render

Before 0.5.1, every template. The DOM still changed only where values differed.
A shallow compare on resolved props brought it down to the one affected element in my test, and 0.5.1 ships it.

Fast streaming in Angular isn't about rendering fast. It's about keeping object identity, so that "nothing changed" is a === and Angular can skip almost everything.

Repo · npm · Live demo

Dynamic Rendering in Angular Is Easy. Trusting Dynamic UI Is Not.

Maxim Berenshtein — Thu, 03 Sep 2026 12:25:37 +0000

Dynamic rendering in Angular sounds like a fairly narrow technical problem:

“I don't know which component I need until runtime.”

Angular already gives us several good tools for that.

But there is a big difference between dynamically choosing a component and dynamically constructing an entire UI from a runtime specification.

And that difference becomes especially important with Server-Driven UI and Generative UI.

1. `ngComponentOutlet`: when the problem is really just component selection

For simple cases Angular already gives us:

<ng-container *ngComponentOutlet="componentType" />

This works very well when the application already knows its possible components and runtime logic only decides which one to display.

componentType =
  condition ? UserCardComponent : AdminCardComponent;

The advantages are obvious: very little infrastructure, normal Angular lifecycle, AOT-compatible components and a relatively declarative template.

But this approach starts becoming uncomfortable when the runtime input is no longer:

UserCardComponent

and instead becomes:

{
  "type": "Card",
  "children": [
    {
      "type": "Input",
      "props": {
        "label": "Name"
      }
    }
  ]
}

Now we are no longer selecting a component.

We are interpreting a UI description.

2. `ViewContainerRef.createComponent()`: more control, more responsibility

Angular also allows components to be instantiated programmatically:

const ref =
  viewContainerRef.createComponent(componentType);

ref.setInput('label', 'Name');

This is a powerful primitive.

We control where the component is created, which component is used, how inputs are assigned and when the component is destroyed.

For relatively contained dynamic behavior, this can be exactly what we need.

But once a runtime specification controls many components, application code often starts evolving into something like:

switch (node.type) {
  case 'input':
    ...
  case 'select':
    ...
  case 'button':
    ...
  case 'dialog':
    ...
}

Then we add input mapping.

Then events.

Then nested components.

Then state.

Then validation.

Soon the difficult part isn't createComponent() anymore.

It is everything around it.

3. Component Registry: separating runtime intent from Angular implementation

A natural next step is a registry:

const registry = {
  Card: CardComponent,
  Input: InputComponent,
  Button: ButtonComponent
};

Now the runtime specification doesn't need to know anything about Angular classes.

It only says:

{
  "type": "Input"
}

and the application decides:

"Input"
   ↓
InputComponent

This separation is more important than it initially appears.

The external system describes intent.

The frontend controls implementation.

And the registry also starts becoming a security boundary: only explicitly registered components can be instantiated.

4. Recursive rendering: when UI becomes a tree

Once a specification can describe nested content, recursion becomes the obvious model.

For example:

Card
 └─ Form
     ├─ Input
     ├─ Select
     └─ Button

A renderer can conceptually do:

render(node) {
  const component = registry[node.type];

  create(component);

  for (const child of node.children ?? []) {
    render(child);
  }
}

This is where dynamic rendering becomes significantly more powerful.

Forms, dashboards, dialogs, layouts and even entire workflows can now be represented as data.

But this is also where I think an important architectural mistake can happen:

A recursive renderer should not blindly render whatever tree it receives.

The UI tree should be validated before it is trusted.

AOT doesn't compile the runtime UI tree

There is sometimes confusion around this part.

If the structure is dynamic, how can Angular's AOT compiler know what to render?

The answer is: it doesn't need to know the future structure.

AOT compiles the building blocks.

For example:

BUILD TIME

CardComponent
InputComponent
ButtonComponent
DialogComponent
      ↓
     AOT
      ↓
compiled Angular components

At runtime, a JSON specification only decides how those already compiled components are composed:

RUNTIME

JSON specification
       ↓
Component Registry
       ↓
Recursive Renderer
       ↓
Card + Input + Button

So the important distinction is:

The UI composition is dynamic. The Angular component implementations are not.

The runtime is not compiling new Angular components.

It is assembling already compiled components.

This also means we don't need to ship Angular's JIT compiler just to support dynamic UI.

What about sending HTML or Angular templates from the backend?

This is another tempting approach.

Why not return something like:

<app-user-card [user]="user"></app-user-card>

from the server?

Because injecting that HTML into the page does not make it an Angular template.

Angular doesn't suddenly compile arbitrary HTML received from an API into AOT components.

And trying to introduce runtime template compilation changes the trust model completely.

There is a major architectural difference between:

Server describes UI

and:

Server sends executable Angular templates

I strongly prefer the first model.

Especially when AI becomes part of the system.

Dynamic UI also creates a trust problem

This is the part I find more interesting than the rendering itself.

Imagine that the UI specification comes from a backend, CMS or AI model.

That specification is now external input.

Even if it is “just JSON”, it controls what the application creates and potentially what the user can do.

So I think dynamic UI should be treated similarly to any other untrusted runtime input.

Unknown components

The specification should not be able to instantiate arbitrary Angular classes.

This:

{
  "type": "AdminPanel"
}

should only work if AdminPanel belongs to an explicitly controlled catalog.

The registry therefore isn't only a convenience.

It is an allowlist.

JSON
 ↓
"Input"
 ↓
Component Registry
 ↓
InputComponent

No registry entry?

Nothing gets instantiated.

Props are also external input

Even a trusted component can expose dangerous inputs.

Imagine a component receiving:

html
url
redirect
resourceUrl

The fact that the component itself is trusted does not automatically mean every possible value supplied to it should be trusted.

So a component catalog should ideally define not only:

"Button" → ButtonComponent

but also the valid shape of its props.

For example:

Button: {
  props: z.object({
    label: z.string(),
    disabled: z.boolean().optional()
  })
}

Now the runtime contract becomes much stronger.

Actions are probably the most important boundary

Rendering UI is one thing.

Allowing generated UI to execute application behavior is another.

I would never want a specification like:

{
  "click": "deleteUser()"
}

and definitely not anything remotely resembling:

{
  "click": "eval(...)"
}

Instead, the specification should only describe an action:

{
  "action": "saveProfile"
}

and the application resolves it through another controlled registry:

"saveProfile"
      ↓
Action Registry
      ↓
known application code

The external specification can request a capability.

It cannot invent one.

This gives us a very useful separation:

The Component Registry controls what UI can exist.

The Action Registry controls what that UI is allowed to do.

Validate the UI tree before recursively rendering it

This is one part I think deserves much more attention.

Suppose a backend or model produces:

Container
 └─ Container
     └─ Container
         └─ ...

Thousands of levels deep.

Or maybe the tree contains hundreds of thousands of nodes.

There may be no XSS.

No JavaScript injection.

The JSON may even be structurally valid.

But rendering it can still freeze the browser.

And if the specification uses references:

A → B → C → A

a malformed graph may create recursive cycles.

So validation shouldn't stop at:

JSON.parse(...)

or even basic schema validation.

A robust runtime boundary may eventually need to reason about component types, props, missing references, illegal parent/child combinations, cycles, maximum depth, maximum node count and potentially maximum repeat expansion.

The architecture I prefer is:

Backend / AI
     ↓
Untrusted UI specification
     ↓
Schema validation
     ↓
Structural validation
     ↓
Catalog / props validation
     ↓
Runtime limits and policies
     ↓
Trusted specification
     ↓
Angular renderer

Only the last step should create Angular views.

Streaming makes this even more interesting

Generative UI adds another complication.

The model may not send the entire UI at once.

Instead:

patch
patch
patch
patch

gradually builds the screen.

That means a half-generated UI can naturally contain temporary inconsistencies: a parent may reference a child that simply hasn't arrived yet.

So validating every intermediate state with exactly the same rules as a completed UI can produce false errors.

I think the model should instead be:

stream patches
      ↓
build partial UI
      ↓
generation completes
      ↓
validate completed specification
      ↓
accept / reject / persist

Potentially with additional lightweight limits while streaming to prevent a generation from growing without bounds.

This becomes much more than “dynamic component rendering”.

It is a small UI runtime.

This is the problem that led me to ngx-json-render

While exploring these patterns, I realized that Angular itself already solves the lowest-level problem very well.

Angular knows how to create components.

What I wanted was the layer above that.

That became ngx-json-render.

The library takes a different approach from runtime Angular template generation.

An external system produces a JSON UI specification.

The Angular application provides a catalog of components and actions.

The renderer connects the two.

Conceptually:

AI / Backend
     ↓
JSON UI specification
     ↓
Catalog / Schema
     ↓
Component Registry
     ↓
Action Registry
     ↓
Angular Renderer
     ↓
AOT-compiled Angular components

There is no need to send executable Angular templates, use innerHTML as a component mechanism or evaluate generated JavaScript.

The external system generates UI intent, not frontend code.

The current library already provides the main building blocks around this model: a controlled component registry, catalog-defined component props, registered actions, recursive composition, state/bindings, streaming JSON patches and optional structural validation that can reject a malformed completed specification before it is accepted.

But I don't think the security story should be overstated.

There are still boundaries worth strengthening.

In particular, catalog-level validation and structural validation are different concerns, validation currently has to be explicitly enabled, and resource limits such as maximum graph depth, maximum rendered nodes or explicit cycle protection are areas I consider important for a hardened dynamic UI runtime.

Update, Sep 14: those limits have since shipped in ngx-json-render 0.4.0 — an unconditional cycle guard plus opt-in maxElements, maxDepth and maxRepeatItems — and catalog checks now run in the same pipeline as the structural ones. Validation itself is still opt-in. What they cover, and what is still up to your app, is in the README's Security section.

And maybe that's the larger point.

The interesting question is no longer:

“Can Angular dynamically render components?”

Of course it can.

The more interesting question is:

How do we safely turn an untrusted runtime UI description into a predictable Angular component tree?

As Generative UI moves from demos into real applications, I suspect this boundary will matter much more than the component creation API itself.

Dynamic UI does not have to mean dynamic trust.

The structure may be generated at runtime.

The capabilities should still belong to the application.

Generative UI in Angular: the LLM streams a JSON spec, you render real components

Maxim Berenshtein — Sat, 29 Aug 2026 16:48:51 +0000

There are two ways to let a model build a UI, and only one of them is a good idea.

The first: ask it for HTML and drop the result into innerHTML. It works in a demo and falls apart everywhere else. You get no design system, no event handlers, no type safety, and a permanent XSS surface with the model on the wrong side of it.

The second: give the model a vocabulary — a catalog of components you already ship — and let it describe the UI it wants in a constrained JSON format. Your renderer maps that description onto your actual components. The model never emits markup, never emits code, and literally cannot reference anything outside the catalog you handed it.

json-render from Vercel Labs is a well-built implementation of the second idea. It had official renderers for React, Vue, Solid and Svelte. It did not have one for Angular.

So I wrote ngx-json-render.

The shape of the thing

Three pieces, and it's worth being precise about which one does what.

The catalog is your vocabulary — component names, Zod schemas for their props, a description of each so the model knows when to reach for it, and optionally a set of actions:

import { schema } from 'ngx-json-render';
import { z } from 'zod';

export const catalog = schema.createCatalog({
  components: {
    Card: {
      props: z.object({ title: z.string().optional() }),
      slots: ['default'],
      description: 'A card container',
    },
    Button: {
      props: z.object({ label: z.string() }),
      slots: [],
      description: "A button that emits a 'press' event",
    },
  },
  actions: {
    refresh: { params: z.object({}), description: 'Reload the data' },
  },
});

catalog.prompt() turns this into the system prompt that teaches the model the vocabulary and the output format. catalog.jsonSchema() gives you a JSON Schema if you'd rather use structured output or a tool call. catalog.validate(spec) checks a finished spec against the catalog.

The spec is what comes back — a flat map of elements, each with a type from the catalog, props, and child keys:

{
  "root": "root",
  "state": { "count": 0 },
  "elements": {
    "root": { "type": "Card", "props": { "title": "Hello" }, "children": ["btn"] },
    "btn": {
      "type": "Button",
      "props": { "label": "Tap me" },
      "on": { "press": { "action": "setState", "params": { "statePath": "/count", "value": 1 } } },
      "children": []
    }
  }
}

Flat, not nested — which matters more than it looks, and I'll come back to it when we get to streaming.

The renderer walks that spec and instantiates your components:

<json-render [spec]="spec()" [registry]="registry" [handlers]="handlers" />

The catalog components are ordinary Angular components. They read their props from an injected render context and render their children wherever they like:

@Component({
  selector: 'app-card',
  imports: [JrChildren],
  template: `
    <section class="card">
      @if (ctx.props().title) { <h3>{{ ctx.props().title }}</h3> }
      <jr-children />
    </section>
  `,
})
export class CardComponent {
  readonly ctx = injectRenderContext<{ title?: string }>();
}

<jr-children /> is a router-outlet for the spec tree — it renders this element's children at that position. Named slots work the same way: <jr-children slot="header" />.

defineRegistry ties catalog names to component classes, and it's typed against the catalog — register a component the catalog doesn't declare and the compiler stops you:

const { registry, handlers } = defineRegistry(catalog, {
  components: { Card: CardComponent, Button: ButtonComponent },
  actions: { refresh: async (params, setState) => { /* ... */ } },
});

What the spec can actually express

A format like this lives or dies on whether it can describe a real screen rather than a static mock. The baseline json-render contract is fairly rich, and ngx-json-render implements all of it:


Dynamic props	`{ "$state": "/user/name" }`
Two-way binding	`{ "$bindState": "/form/email" }`, `{ "$bindItem": "done" }`
Conditionals	`{ "$cond": {...}, "$then": ..., "$else": ... }`
Templates	`{ "$template": "Hello, ${/user/name}" }`
Visibility	`"visible": { "$state": "/count", "gte": 5 }`
Repeat	`"repeat": { "statePath": "/todos", "key": "id" }`, nestable
Events → actions	`"on": { "press": { "action": "...", "confirm": {...}, "onSuccess": ... } }`
Watch	`"watch": { "/country": { "action": "loadCities" } }`
Validation	field rules, `validateForm`, `injectFieldValidation`

Every <json-render> owns a state store addressed by JSON Pointer. setState, pushState, removeState and validateForm are built in, so the model can wire up a working form without you writing a handler for every button. Anything beyond that is a named action you implement in TypeScript — the model can only request it by name, with params validated against your Zod schema.

Actions can declare a confirmation: "confirm": { "title": "Delete this?" } renders a real dialog and waits for the user before the handler runs. Which is the general theme — the model proposes, your code disposes.

Streaming is the interesting part

Here's the thing that makes this feel different from ordinary server-driven UI.

A model generating a dashboard takes several seconds. You could wait for the whole spec and then render it — spinner, pause, pop. Instead, json-render streams the spec as JSONL: one RFC 6902 patch per line:

{"op":"add","path":"/root","value":"page"}
{"op":"add","path":"/elements/page","value":{"type":"Stack","props":{},"children":["title"]}}
{"op":"add","path":"/elements/title","value":{"type":"Heading","props":{"text":"Weekly sales"},"children":[]}}

Each line is applied to the spec signal as it arrives, so the UI assembles on screen while the model is still generating. This is where the flat element map earns its keep: a patch can add a deeply nested element without rewriting its ancestors, and add /elements/foo is a single, order-independent line.

On the client that's one hook:

@Component({
  template: `
    <json-render [spec]="ui.spec()" [registry]="registry" [loading]="ui.isStreaming()" />
    <button (click)="ui.send('A dashboard for weekly sales')">Generate</button>
  `,
  imports: [JsonRenderer],
})
export class GeneratePage {
  readonly ui = injectUIStream({ api: '/api/generate' });
  readonly registry = registry;
}

injectUIStream POSTs { prompt, context, currentSpec } and expects a JSONL body back. The loading input tells the renderer to tolerate dangling child references — mid-stream, an element routinely names children that haven't arrived yet, and that's normal rather than a bug to warn about.

The server is whatever streams text. With the AI SDK it's genuinely this small:

app.post('/api/generate', async (req, res) => {
  const result = streamText({
    model: anthropic('claude-sonnet-5'),
    system: catalog.prompt(),
    prompt: req.body.prompt,
  });

  res.setHeader('Content-Type', 'text/plain; charset=utf-8');
  for await (const chunk of result.textStream) res.write(chunk);
  res.end();
});

There's also injectChatUI for the chat case, where an assistant message can carry prose and a spec — the stream is split into text lines and fenced JSONL, and each message ends up with a text and an optional spec.

Why it's built the way it is

The renderer is signals all the way down: input() / output(), computed, OnPush on every component, no zone.js requirement. That isn't box-ticking. A streaming spec means dozens of small state changes per second, and a computed graph over a flat element map only recomputes the elements a patch actually touched.

Everything sits on @json-render/core — the same spec grammar, expression evaluator, state store, action dispatcher and stream compiler the React, Vue, Solid and Svelte renderers use. A catalog is framework-specific (it names your components), but a spec is portable: the same generated JSON renders in any of them. That's also why I didn't invent a dialect. Parity with the baseline contract was the whole point, and the library is laid out so src/lib could be adapted into a packages/angular PR upstream.

If you'd rather not write a catalog before seeing anything work, there's a companion package — ngx-json-render-material, a ready-made catalog of 28 Angular Material components — so you can generate and render a spec on day one.

How this differs from ngx-gen-ui

There is one other Angular library that turns up under "generative UI", and the two get filed together, so it is worth saying plainly which problem each one solves.

ngx-gen-ui puts the model call in the component. You attach a directive to an element, give it a prompt, and the response streams into the template. Its structured mode constrains the model to a schema of markup primitives — the README's own example is { "tag": "h1", "content": "Title" } — and converts that JSON into DOM elements. Firebase with Vertex AI is the default provider, with an AiAdapter interface for swapping in another one, though firebase and @firebase/ai are non-optional peer dependencies either way. MIT, Angular ≥ 17.

ngx-json-render never talks to a model at all. Generation happens on your server; the library only consumes the resulting stream. And the vocabulary is not HTML — it is your component catalog, so what comes out the other end is your Card, your DataTable, your ConfirmButton, with their own inputs, their own styles, and their own event handlers.

That difference decides what the generated UI can do. Markup primitives give you a rendered document. A component spec gives you an interface: state bindings, two-way $bindState, events mapped to actions you implemented in TypeScript, confirm dialogs, form validation, repeat over a state array. The model can hand you a working form rather than a picture of one.

So, roughly:

Want a model's prose streamed into a page, with Firebase already in your stack? ngx-gen-ui is less work — a directive, and no server of your own.
Want the model to assemble screens out of your existing design system, with real handlers behind the buttons, in a format that is portable to React/Vue/Solid/Svelte? That is what the json-render spec is for, and this is the Angular renderer for it.

They are not really competitors. If anything, the interesting thing is that Angular now has two takes on this at all.

Try it

Live demo — an interactive spec with bindings, repeat, confirm and watch, plus a replayable SpecStream. The Streaming tab is the one to look at.
Repo · npm · Open in StackBlitz

npm install ngx-json-render @json-render/core zod

Angular ≥ 20, Apache-2.0 — matching upstream.

It's young. It has full parity with the baseline renderer contract and a real test suite, but @json-render/core moves fast and I track it release by release. Issues, PRs, and "why didn't you just…" questions are all welcome.

DEV Community: Maxim Berenshtein

Guardrails for AI-Assisted Development: Skills, Gates, Hooks and Mutation Tests

Why conventions in a README don't survive

Layer 1: a skill tree with exactly one root

Layer 2: gates, or how a convention becomes unignorable

What actually deserves a gate

One gate in full

The shape every gate shares

Wiring, and why every gate has its own test

Gates that guard the gates

Layer 3: the hook, so the agent hears it now

Layer 4: tests, and proving the tests are worth anything

Layer 5: how much checking is enough

Say what counts as evidence

Every rule carries its incident

What this doesn't do

If you're starting tomorrow

What Angular Actually Re-renders When a Model Streams Your UI

How Angular draws a tree it has never seen

How does a child know where it is?

The cost of recursion that lives in Angular

Streaming: does Angular redraw everything?

Idea 1: a patch replaces only what it touches

Idea 2: each element watches only its own piece

Idea 3: Angular refreshes views, not the whole tree

Idea 4: new children don't rebuild the list

What isn't free

When the data changes, not the UI

The short version

Dynamic Rendering in Angular Is Easy. Trusting Dynamic UI Is Not.

1. ngComponentOutlet: when the problem is really just component selection

2. ViewContainerRef.createComponent(): more control, more responsibility

3. Component Registry: separating runtime intent from Angular implementation

4. Recursive rendering: when UI becomes a tree

AOT doesn't compile the runtime UI tree

What about sending HTML or Angular templates from the backend?

Dynamic UI also creates a trust problem

Unknown components

Props are also external input

Actions are probably the most important boundary

Validate the UI tree before recursively rendering it

Streaming makes this even more interesting

This is the problem that led me to ngx-json-render

Generative UI in Angular: the LLM streams a JSON spec, you render real components

The shape of the thing

What the spec can actually express

Streaming is the interesting part

Why it's built the way it is

How this differs from ngx-gen-ui

Try it

1. `ngComponentOutlet`: when the problem is really just component selection

2. `ViewContainerRef.createComponent()`: more control, more responsibility