DEV Community: Erik Hanchett

Jev 101: How I'm Using It Today in My Apps

Erik Hanchett — Tue, 22 Sep 2026 17:32:20 +0000

TypeSafe released Jev on September 15th, 2026 and called it a System One model. A System One model is a specialized type of AI designed to make fast, deterministic judgments and structured classifications in a single parallel pass rather than generating conversational text.

You don't chat with it. You send it some state plus a list of narrow questions, and it sends back probabilities.

What I really like about it is it's cost. It's $42 per billion input tokens, and output tokens free. In my testing I was seeing answers in 70 to 500 milliseconds.

Here is what I built with it!

What a request actually looks like

This is the interface. It has a POST, a state object, and a map of questions:

const response = await $fetch('https://openrouter.ai/api/alpha/decisions', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${config.openRouterApiKey}`,
    'Content-Type': 'application/json',
  },
  body: {
    model: '~typesafe/jev-latest',
    state: buildGateState(stack, pullRequest),
    questions: {
      matches_request: {
        type: 'noul',
        instructions: 'Does the pull request directly address the stated issue and acceptance criteria?',
      },
      protects_credentials: {
        type: 'noul',
        instructions: 'Does the changed frontend code keep credentials and secret tokens out of browser-visible runtime configuration?',
      },
    },
  },
})

What comes back is shaped like the questions you asked:

{
  "model": "~typesafe/jev-latest",
  "answers": {
    "matches_request": { "type": "noul", "noul": 0.59 },
    "protects_credentials": { "type": "noul", "noul": 0.11 }
  },
  "usage": { "input_tokens": 4211, "output_tokens": 0, "cost": 0.00067 }
}

Every answer is a number between 0 and 1. If you ask six questions, you get six probabilities, and you can then decide what to do with them.

Three question types

Jev has three primitives.

A noul is a yes-or-no probability. It doesn't have any other criteria, just questions.

A choice picks one category from a set you define. Its criteria are an object, because the categories are unordered:

traffic_shape: {
  type: 'choice',
  instructions: 'Using only the described usage pattern, choose how this workload receives traffic over a typical month.',
  criteria: {
    steady_24_7: 'Traffic arrives continuously at a roughly similar rate at all hours.',
    business_hours: 'Traffic happens during working hours on weekdays and falls to almost nothing outside them.',
    spiky_bursty: 'Traffic is uneven and unpredictable, with quiet periods followed by much heavier bursts.',
    batch_scheduled: 'Work runs on a schedule as discrete jobs rather than as a stream of user requests.',
  },
}

A score is an ordered rubric, so its criteria are an array instead. The API enforces that distinction.

App one: gating a pull request

The first app loads a pull request and asks six questions about it at once. In my case I asked: Does the diff match the stated issue? Does it keep credentials out of browser-visible config? Does it implement the failure states the acceptance criteria asked for? Is the changed interactive UI keyboard operable? Is the layer safe to review on its own given its dependencies?

All six run in the same request, and it's super fast!

Then my code, not the model, turns those probabilities into a verdict:

Probability	Result	Meaning
80 to 100%	Pass	Enough support to continue through normal review
55 to 79%	Review	A person should verify the uncertain evidence
Below 55%	Block	Do not merge this layer yet

In my scenario I used keyboard_accessible to only count if changes_interactive_ui came back above 0.5. A backend-only PR shouldn't get dinged for missing keyboard behavior, and that conditional lives in my code where I can read it and change it.

OpenRouter versus calling TypeSafe directly

I started on OpenRouter because I was still on the TypeSafe waitlist. I noticed that OpenRouter was quite a bit slower.

Through OpenRouter: 683 ms, cost $0.00067
Straight to TypeSafe: 318 ms

Roughly half the time for the same work. If you're going to build on this, get on the waitlist and use their API. I got in the next day.

App two: AWS workload

For the second app you describe an AWS workload, something like "public checkout API for retail storefronts," and it gives you back a cost estimate.

Here is what it does:

Layer	Owns	Never does
Jev	Semantic judgment about the prose description	See a number, emit a number, compare two numbers
My code	Sizing, platform limits, thresholds, ranking	Guess at intent
AWS Price List	Every unit rate	Nothing, it is just data

Jev answers questions like whether the described data access needs relational queries across multiple tables, whether any single unit of work runs longer than fifteen minutes, and whether the description implies a bounded population or open-ended public demand. Then the Agent Toolkit for AWS and the AWS pricing MCP server produces the dollar figure.

Once the model has classified the output, the arithmetic is deterministic.

Schema validity

Schema validity is not correctness. Jev cannot return an answer outside the questions and criteria you defined, so you'll never parse a broken response. Although, it can return a confidently wrong probability that validates perfectly.

That's why both apps put a threshold in front of any consequence. Low confidence routes to a person or to a stronger model. If you wire probabilities straight into an irreversible action, the guaranteed output shape will not save you.

TypeSafe publishes guidance on confidence, but you need to measure it against your own labeled data and set thresholds based on what a mistake costs you.

What other people are doing with it

The community projects are where the speed becomes obvious. Someone has Jev playing Super Mario Brothers by asking "should I jump here" over and over while the game runs. Somebody else built a real time outfit picker that updates suggestions as you change the inputs.

The possibilities are endless.

Would I use it

Frontier models aren't going anywhere, and this doesn't compete with them. Nothing here writes code, explains a decision, or produces a plan.

However, I have a decent number of workflows that need a lot of small semantic decisions with deterministic code waiting on the other side. Routing, classification, gating, cheap verification before an expensive step. For those, sending narrow questions and getting probabilities back is a better fit than asking a chat model for JSON and hoping.

Try it on something you already have labels for, measure the calibration yourself, and keep anything expensive behind a threshold.

Frontend Isn't Dead. But the Job Title Is Changing

Erik Hanchett — Tue, 15 Sep 2026 17:00:26 +0000

I keep seeing people claim frontend development is dead, so I went and did some research, and not all of it was bad.

If you rather watch, check out this video:

Job posting show an interesting story

Indeed's Hiring Lab looked at tech job titles against pre-pandemic levels. Software engineer postings were down 49 percent. Web developer postings were down more than 60 percent. This isn't great.

LeadDev tracked frontend openings from August 2021 through July 2025. The job openings tracked about the same as Indeed. Role postings has tracked lower.

Less developers are identifying themselves as frontend developers. In the 2025 Stack Overflow survey, developers identifying as frontend went from 6.6 percent in 2023 to 4.3 percent in 2025. On the other hand developers who identify themselves as full-stack are at a much higher percentage.

All this data points in one direction. Frontend as a job, as a title, is on the decline. And I don't think there is only one reason. It would be easy to point to just AI, but I really think the shift is happening because of a multiple factors.

Why

First, yes, more people are using AI. 84 percent of Stack Overflow respondents are using or planning to use AI tools, up from 76 percent the year before. 51 percent of professional developers use them daily.

And AI does a really good job at many frontend tasks. For example, taking a Figma file and turning it into HTML and CSS is a great use case. I've done that myself. I've used AI to help mock up an interface that would have taken me much longer.

However, AI isn't perfect. In that same Stack Overflow survey 46 percent of developers distrust AI accuracy against 33 percent who trust it, and only 3 percent report high trust. The most experienced developers are the most skeptical, at 2.6 percent high trust and 20 percent high distrust.

So I don't think AI is the sole problem. We still need developers to make those frontends, and as you can see, we don't always trust AI.

The skills moved to meta frameworks

More often, the skills needed by frontend developers also include a lot of what you imagine a fullstack developer does. It also matches what these meta frameworks have been doing. Next.js, Nuxt, SvelteKit, and Astro all put both sides of the API boundary in the same project. Now frontend developers are working on both sides, and no longer consider themselves "frontend" deves.

So what to do?

Pick a backend framework and go deep on it. If you haven't already start working in Next, Nuxt, SvelteKit. Learn how data is passed from the client to server. Pick up, Java, C#, or Ruby on Rails. Go deep and learn it.

Get good at what AI handles badly. AI does a lot of things well but it still has problems with performance work, accessibility, and something I like to call "taste". Automated tooling still detects WCAG failures on 95.9 percent of the top million home pages, averaging 56.1 errors each. The work is there.

Own the review, not the typing. Kiro's guide to frontier engineering lays out ten principles for working with agents. If 84 percent of developers are generating code with AI however only 3 percent highly trust the output (see the Stack Overflow survey from earlier), then you need to look at the total AI software development life cycle to see where you can improve. Start with this guide.

Conclusion

Websites still need to get built. Frontends are still necessary. But we need to look beyond the HTML, CSS and JavaScript.

The work has changed to these full stack meta frameworks, and AI does a lot of work for us. Keep on building and learning! Frontend isn't dead, but it's changed.

Sources

If you have been hiring or job hunting lately, I want to know what the titles look like in your market. Drop a comment with the role name and your region.

Would You Choose a Library Because AI Writes It Better?

Erik Hanchett — Tue, 08 Sep 2026 20:27:23 +0000

I was at a conference recently and watched Joel Hooks talk about Effect. Effect homepage h1 advertises that it's the "Reliable TypeScript for the AI era". Joel explained that AI agents (Kiro, Claude Code, etc) can write way better TypeScript with Effect then he could ever do by himself. It made me start thinking, is this the future?

That raised a question I had not seriously considered before. Are we going to choose libraries based on what coding agents can write reliably, even when those libraries are harder for us to learn?

I made a video about that question using two libraries: Effect and StyleX.

Both libraries work really well with coding agents. Effect can more easily catch expected failures in the type system. StyleX puts styles behind a typed JavaScript API. Both help reduce errors during compilation.

That sounds great. However, it also creates a strange situation where the agent may understand the stack better then I could, even though I'm responsible to maintain it long term.

To help understand this more let's see how StyleX and Effect work, and where I think where this is all going.

Put expected failures in the type system with Effect

To understand Effect, you need to understand how it handles async functions. A normal asynchronous TypeScript function often tells you the success type and leaves the failure behavior in comments, thrown exceptions, or tribal knowledge.

Effect gives failures their own typed channel. In the demo, each expected problem has a tagged error:

import { Data, Effect } from 'effect'

export class NotFoundError extends Data.TaggedError('NotFoundError')<{
  readonly handle: string
}> {}

export class RateLimitError extends Data.TaggedError('RateLimitError')<{
  readonly retryAfterSeconds: number
}> {}

export class NetworkError extends Data.TaggedError('NetworkError')<{
  readonly reason: string
}> {}

The profile program returns one of those errors based on the scenario:

export const loadProfile = (scenario: Scenario) =>
  Effect.gen(function* () {
    if (scenario === 'not-found') {
      return yield* new NotFoundError({ handle: 'agent-editor' })
    }

    if (scenario === 'rate-limited') {
      return yield* new RateLimitError({ retryAfterSeconds: 30 })
    }

    if (scenario === 'offline') {
      return yield* new NetworkError({ reason: 'The demo API is offline.' })
    }

    return profile
  })

I can infer the complete error union from the program instead of maintaining it separately:

export type LoadProfileError = Effect.Effect.Error<
  ReturnType<typeof loadProfile>
>

The UI then handles each tag in one place:

function describeError(error: LoadProfileError) {
  switch (error._tag) {
    case 'NotFoundError':
      return `No profile exists for @${error.handle}.`
    case 'RateLimitError':
      return `Try again in ${error.retryAfterSeconds} seconds.`
    case 'NetworkError':
      return error.reason
    default:
      return assertNever(error)
  }
}

If a coding agent adds a MaintenanceError to the program and forgets to update the UI, the assertNever call can turn that omission into a type error. The agent gets a correction signal immediately.

Here is the feedback loop:

Coding agent changes the program
              |
              v
Effect updates the typed error channel
              |
              v
TypeScript checks every UI branch
              |
      missing case? fix it
              |
              v
Run tests and review behavior

The compiler is catching the errors first.

Effect introduces a functional programming model, its own vocabulary, and more abstraction than a plain async function.

This is great, but with this abstraction comes more complexity, and a steeper learning curve.

Let's take a look at how StyleX works next.

Put visual states behind a typed API with StyleX

StyleX takes a similar idea into styling. Instead of handing an agent a stylesheet with global selectors and arbitrary class names, you define styles through stylex.create:

const styles = stylex.create({
  result: {
    borderRadius: 14,
    borderStyle: 'solid',
    borderWidth: 1,
    minHeight: 160,
  },
  resultSuccess: {
    backgroundColor: colors.successSurface,
    borderColor: colors.success,
  },
  resultWarning: {
    backgroundColor: colors.warningSurface,
    borderColor: colors.warning,
  },
  resultDanger: {
    backgroundColor: colors.dangerSurface,
    borderColor: colors.danger,
  },
})

The component composes those states explicitly:

<div
  {...stylex.props(
    styles.result,
    view.status === 'success' && styles.resultSuccess,
    view.status === 'failure' && view.tone === 'warning' &&
      styles.resultWarning,
    view.status === 'failure' && view.tone === 'danger' &&
      styles.resultDanger,
  )}
>
  {/* Result UI */}
</div>

This gives the agent named visual states and a type-checked API. It can still go wrong of course, but there are fewer ways to accidentally make up selectors, misspell properties, or create styles that never get attached to the component.

I'm not going to lie, I do not like the output to the page. Generated atomic class names look like random strings, and the CSS-in-JS syntax feels heavier than Tailwind.

Personally, I think StyleX may be a better interface for agents, but I'm not completely sold.

Decide who your stack is optimized for

I used to choose libraries based on the following:

Does the team already know it?
Is the documentation good?
Can we debug it in production?
Will it still be maintained in a few years?

With coding agents writing most of the code, we now need to decide if it should be the most important part.

In my opinion, that question is important, but it should not be the only reason you pick a library.

Choice	Helpful for an agent	Cost for a developer
Effect	Typed failures, explicit composition, compiler feedback	New programming model and learning curve
StyleX	Typed styles, named states, constrained composition	Less familiar syntax and generated class names
Plain TypeScript	Familiar syntax and broad ecosystem	Expected failures are easier to leave implicit
Tailwind CSS	Familiar utilities and readable markup for many teams	More freedom for inconsistent generated combinations

With all that said, there may be a middle ground. Libraries such as shadcn/ui work well with coding agents because the patterns are common and the component source stays in your project. A developer can still open the file and understand what was generated without first learning a new programming model or paradigm.

That is the balance I want. Give the agent enough structure to catch mistakes while keeping the code review useful for the person who owns the application.

Finale

I am not moving every TypeScript project to Effect or rewriting every Tailwind component with StyleX. For now, I am sticking with the tools I know well enough to review.

I am keeping an eye out for these new type libraries. I really think in the future that agent friendly libraries will be the new normal, and the human readability, while important, will not be as important.

However, we the developers are still responsible for architecture, behavior, and what reaches production. A compiler can catch an error, but us developers need to understand if the app is behaving the way it's supposed to.

Would you adopt a library because your coding agent writes it better, even if your team has to work harder to learn it?

10 MCP Servers Worth Adding to Your AI Coding Workflow in 2026

Erik Hanchett — Tue, 01 Sep 2026 22:23:37 +0000

Introduction

I am a big fan of the Model Context Protocol. MCP keeps getting better, and I really think it's the future.

This list is my favorite MCP servers that I use every day. I picked them based on how useful they are, and how much I've been able to get out of them.

I also picked them based on these four signals:

Public adoption
Active maintenance
Official backing
Whether the server solves a problem developers actually hit

Here is the video version of the list:

Prerequisites

You need an MCP-capable coding agent or editor to use these servers. Kiro, Claude Code, Cursor, VS Code, and other clients support different combinations of local and remote MCP connections.

Keep in mind that whenever you install an MCP server you should be cautious. Don't accept all changes, look at what it's executing first. It's also not a bad idea to try them out on non-production code bases first, just in case.

Steps: the 10 MCP servers worth considering

Here are my top MCP servers, in no particular order.

#	MCP server	Best for	Access level to watch
1	Context7	Current library documentation	Low, but verify package resolution
2	Chrome DevTools MCP	Browser debugging and performance	Full connected-browser access
3	Playwright MCP	Repeatable browser automation	Authenticated pages and local services
4	GitHub MCP Server	Repositories, issues, and pull requests	Repository and workflow writes
5	Serena	Semantic code navigation and editing	Project files and language tooling
6	Supabase MCP	Database and project workflows	Schema, migration, and data changes
7	AWS MCP Server	AWS documentation and APIs	The caller's IAM permissions
8	Vercel MCP	Deployments, logs, and analytics	Project and deployment operations
9	Cloudflare API MCP	Workers, R2, D1, DNS, and APIs	Broad account API access
10	Excalidraw MCP	Editable architecture diagrams	Diagram content sent to the service

1. Context7

Project: upstash/context7

Package: @upstash/context7-mcp

Context7 is one of my favorite MCP servers. I use it all the time to help me look up documentation for my favorite APIs. It's also nice because I don't have to install 100 different skills, I can get it all in one MCP server.

When I checked, Context7 had 61,446 GitHub stars, 2,960 forks, and 3,975,539 npm downloads during August 2026. Version 4.0.4 shipped on August 28.

Why it is good: It addresses one of the most common AI coding failures without requiring broad access to your project.

2. Chrome DevTools MCP

Project: ChromeDevTools/chrome-devtools-mcp

Chrome DevTools MCP is my browser-debugging pick. It can inspect console messages, network requests, screenshots, Lighthouse results, performance traces, heap data, and the browser state the user actually sees.

It had 50,274 GitHub stars and 3,538 forks when I checked. The npm package recorded 3,308,596 downloads during August 24 through August 30, 2026. It is an official Google and Chrome DevTools project, and version 1.8.0 shipped on August 25.

Why it is good: It lets the agent debug the running application instead of declaring success when the code merely compiles.

3. Playwright MCP

Project: microsoft/playwright-mcp

Package: @playwright/mcp

Playwright MCP is the browser-automation and testing choice. It had 36,660 GitHub stars, 3,077 forks, and 23,749,682 npm downloads during August 2026. That was the strongest directly attributable package-download signal in my research.

I go back and forth between the Chrome Devtool and Playwright depending on the situation.

Chrome DevTools goes deeper on live debugging, network behavior, memory, and performance. Playwright is a cleaner fit when the job is navigating a flow and proving it works repeatedly. Like check out flows.

Why it is good: It gives an agent a repeatable way to test user flows instead of relying on a one-time manual check.

4. GitHub MCP Server

Project: github/github-mcp-server

GitHub's official MCP server is the obvious source-control pick. It can search repositories and code, read issues, work with pull requests, and inspect workflows.

The repository had 32,626 stars and 4,872 forks when I checked. Version 1.11.0 shipped on August 25, 2026, and GitHub supports hosted, container, and binary connection paths.

I use this all the time to push up code, or fix merge issues. I go back and forth with this MCP server and using the gh CLI tool.

Why it is good: Source control context appears in almost every software project.

5. Serena

Project: oraios/serena

Package: serena-agent

Serena is the codebase specialist. Instead of treating a repository as a pile of text files, it uses language tooling for symbol-level retrieval and semantic edits.

It had 28,686 GitHub stars, 1,934 forks, and 160,865 rolling-month PyPI downloads reported on August 31, 2026. Version 1.7.0 shipped on August 9.

I have not used Serena a lot, but from what I can tell it's really useful.

Why it is good: It gives agents a structured view of code when generic file search is not enough.

6. Supabase MCP

Project: supabase/mcp

Package: @supabase/mcp-server-supabase

Supabase MCP connects the agent to project, database, schema, and migration workflows. The repository had 2,883 stars and 403 forks, while the npm package recorded 439,749 downloads during August 2026.

This is where the list becomes very tool specific. If you are using Supabase, use this tool!

Why it is good: It gives a Supabase project direct backend context, but only projects already using Supabase need it.

7. AWS MCP Server

Documentation: AWS MCP Server

Toolkit: aws/agent-toolkit-for-aws

AWS is the cloud option I wanted to spend time on it because it's my favorite! The Agent Toolkit for AWS is larger than one MCP server. It combines MCP configuration with skills, plugins, and agent integrations.

The managed AWS MCP Server can search current AWS documentation and call AWS APIs across more than 300 services. The skill tells the agent how to approach a task. The server supplies current information and runtime tools. Same ecosystem, different jobs.

Check it out!

Why it is good: It combines current AWS knowledge with live cloud inspection while retaining familiar IAM and audit controls.

8. Vercel MCP

Documentation: Vercel MCP

Vercel MCP is a hosted server for teams already deploying on Vercel. It can inspect projects, deployments, build and runtime logs, analytics, and traces. It can also create deployments and perform collaboration operations.

Be aware that vercel/mcp-handler is a framework for building MCP servers. The AI SDK includes an MCP client. Vercel also ships an agent plugin. None of those is the hosted Vercel MCP server.

Why it is good: It brings deployment state and production diagnosis into the agent for projects that already run on Vercel.

9. Cloudflare API MCP

Project: cloudflare/mcp

Catalog: Cloudflare MCP servers

Cloudflare's API MCP covers Workers, R2, D1, DNS, deployments, and roughly 2,500 Cloudflare API endpoints.

Vercel and Cloudflare are alternatives in this list. Pick the server for the platform that runs your project rather than installing both because they appear in a roundup.

Why it is good: It exposes a broad platform API without filling the context window with thousands of tools at once.

10. Excalidraw MCP

Project: excalidraw/excalidraw-mcp

Excalidraw is an amazing drawing tool, and it's worth adding to this list. Its first-party server had 5,212 stars and 487 forks when I checked. Version 0.3.2 shipped in February 2026, with code activity cited through March.

I use it all the time to help me create architecture diagrams!

Why it is good: It turns project context into an editable artifact that can leave the editor and help a team communicate.

What about Canva and Figma?

Canva MCP is useful when you need thumbnails, launch graphics, presentations, or other design assets. Canva also has a separate Dev MCP for people building Canva apps and integrations. It does not publish a comparable server-specific adoption number, and it sits farther from the code, so I treat it as a bonus rather than one of the ten core coding picks.

Figma MCP is the design-to-code alternative. It can supply design context, Code Connect mappings, assets, and diagram information. It makes sense when the implementation starts from a Figma design.

If you need design, check both of them out!

Three popular names I left off

Here are a few other MCP servers I left out.

Puppeteer MCP

The historical @modelcontextprotocol/server-puppeteer package is deprecated, and its source lives in the archived reference-server repository.

It still recorded 28,716 npm downloads during August 24 through August 30, 2026. That is evidence that package downloads can outlive maintenance, not a reason to recommend it for a new setup. Use Chrome DevTools MCP or Playwright MCP instead.

Memory reference server

The Knowledge Graph Memory server is useful for learning how basic MCP persistence works. Its maintainers describe the reference servers as educational examples rather than production-ready products.

The package recorded 74,597 weekly downloads, but the roughly 89,000 stars belong to the entire modelcontextprotocol/servers repository. They cannot be assigned to Memory alone. Every connected client can also read or change its local JSONL graph, which may accumulate sensitive project data.

TanStack Intent

TanStack Intent discovers and packages versioned Agent Skills. I like the project, and it is relevant to AI coding, but it is not an MCP server, client, or registry.

The distinction matters:

Skills provide instructions and procedural knowledge loaded into the agent.
MCP provides runtime tools, resources, and live external data.

AWS and Vercel ship products across both categories, which is why the names can blur together. Useful does not automatically mean MCP.

Finale

I use many of these MCP servers every day. Try a few out and see how you like them.

Today my starter stack looks like this:

Context7 for current APIs and examples
Chrome DevTools MCP or Playwright MCP for verification
**GitHub, and AWS

Add Excalidraw, Canva, or Figma when the work needs to become a diagram or design.

The full set of research links and measurement windows is available in the video description. Which MCP server has stayed in your setup after the first week?

Build a Full-Stack Music Station with OpenRouter, Amazon Bedrock, and Nuxt

Erik Hanchett — Wed, 26 Aug 2026 00:48:03 +0000

Have you ever been coding and then gotten into that flow state? You know where hours pass by , and it feels to you it's only been a few minutes? Me too. One thing that really helps me get into that state is music. So I create my own music Lo-Fi server called compile and chill.

As a part of this project, I created three radio stations. Each station can generate a 16:9 scene with Amazon Bedrock, compose an instrumental loop with ElevenLabs, and turn an illustration into a six-second video through OpenRouter. Generated files live in private Amazon S3 storage and return to the browser through the Nuxt server.

I also added a Stream Deck API interface!

This tutorial shows how to build this radio station from start to finish.

The complete source code is available in the Compile & Chill repository.

Watch the full video on YouTube.

Prerequisites

You need the following tools for the complete build:

Node.js 22.19 or newer. The locked Nuxt 4.5.2 release requires Node 22.19+, 24.11+, or 26+.
npm 10 or newer.
An AWS account and a configured AWS Command Line Interface (AWS CLI) profile.
The AWS Serverless Application Model (AWS SAM) CLI for the private storage stack.
Access to Stability AI Stable Image Ultra through Amazon Bedrock in us-west-2.
An ElevenLabs API key for music generation.
An OpenRouter API key for animated scenes.

The provider credentials are optional. Without them, the UI, bundled scene, station switching, player, and Focus Block timer still work.

The identity running the app needs bedrock:InvokeModel plus bucket-scoped permissions for s3:GetObject, s3:PutObject, s3:DeleteObject, s3:DeleteObjectVersion, and s3:ListBucketVersions. Use a role or profile scoped to the station bucket rather than an administrator identity.

For this project I included infrastructure as code with SAM to help setup the AWS parts. It's also included in the repo.

Steps

1. Run the station without credentials

Pull down the repo and get started!

git clone https://github.com/ErikCH/compile-and-chill.git
cd compile-and-chill
npm ci
cp .env.example .env
npm run dev

Open http://127.0.0.1:8231. You should see the station UI with the bundled placeholder scene.

The environment file separates each feature:

ELEVENLABS_API_KEY=
BEDROCK_IMAGE_REGION=us-west-2
BEDROCK_IMAGE_MODEL_ID=stability.stable-image-ultra-v1:1
AWS_PROFILE=default
STATION_S3_BUCKET=
STATION_S3_REGION=us-west-2
OPENROUTER_API_KEY=
STATION_BIND_HOST=127.0.0.1
NUXT_CONTROL_TOKEN=

Do not add NUXT_PUBLIC_ to these names. Nuxt exposes public runtime configuration to browser code.

Keep STATION_BIND_HOST on loopback unless you need remote control. For Stream Deck access from another machine, bind to a private VPN interface address, never 0.0.0.0 or a public IP, and set a long random NUXT_CONTROL_TOKEN. The server refuses a non-loopback binding without that token.

2. Put provider calls behind Nuxt server routes

The browser should call your application. Compile & Chill keeps provider credentials in Nuxt runtimeConfig and places provider code under server/api/ and server/utils/.

The relevant section of nuxt.config.ts looks like this:

export default defineNuxtConfig({
  runtimeConfig: {
    elevenLabsApiKey: process.env.ELEVENLABS_API_KEY || '',
    imageGenerationRegion: process.env.BEDROCK_IMAGE_REGION || 'us-west-2',
    imageGenerationModel:
      process.env.BEDROCK_IMAGE_MODEL_ID || 'stability.stable-image-ultra-v1:1',
    stationStorageBucket: process.env.STATION_S3_BUCKET || '',
    stationStorageRegion: process.env.STATION_S3_REGION || 'us-west-2',
    openRouterApiKey: process.env.OPENROUTER_API_KEY || '',
  },
})

This boundary gives you one place to validate requests, clamp paid parameters, redact signed URLs, and translate provider errors into useful HTTP responses.

You can inspect the complete routes in server/api.

3. Generate a scene with Amazon Bedrock

Authenticate with your AWS profile first. This example uses AWS IAM Identity Center:

aws sso login --profile your-profile

Add the profile and model settings to .env:

AWS_PROFILE=your-profile
BEDROCK_IMAGE_REGION=us-west-2
BEDROCK_IMAGE_MODEL_ID=stability.stable-image-ultra-v1:1

The image route validates the station mode, visual style, developer presentation, and optional seed. It then calls generateStationScene() in server/utils/station-generation.ts.

The provider payload is small:

const payload = {
  prompt: buildScenePrompt(mode, direction, {
    visualStyle,
    developer,
    diversitySeed: seed,
  }),
  // Shortened here. The source contains the complete negative prompt.
  negative_prompt: [
    'logos, readable text, watermark, rear view, motion blur, extra fingers',
    visualStyle === 'illustrated'
      ? 'photograph, live action, photorealistic skin, 3D render'
      : 'cartoon, anime, cel shading, flat illustration',
  ].join(', '),
  mode: 'text-to-image',
  aspect_ratio: '16:9',
  output_format: 'png',
  seed,
}

const response = await client.send(
  new InvokeModelCommand({
    modelId: config.imageGenerationModel,
    contentType: 'application/json',
    accept: 'application/json',
    body: JSON.stringify(payload),
  }),
)

The server normalizes the seed before constructing the payload. This matters because Number(undefined) becomes NaN, and JSON serializes NaN as null. Stable Image Ultra expects an integer.

The prompt also ties visual style to output type. Static scenes use a realistic style. Animated scenes use a clearly illustrated 2D style so the source is visibly non-photorealistic. I added that distinction after a provider's person-likeness classifier refused one of the illustrated anchors.

Checkpoint: restart the app, open Visual settings, choose Realistic static, and generate one scene. If the model is unavailable in the configured region, the route returns the provider error and model ID instead of silently switching models.

4. Add looping music with ElevenLabs

The UI sends a 60-second duration, and the server should reject or normalize nonnumeric input before applying its 10-to-60-second bounds. This hardened version avoids sending null to the provider if another client calls the route with an invalid value:

const requestedDuration = Number(input.durationSeconds ?? 60)
const durationSeconds = Number.isFinite(requestedDuration)
  ? Math.min(60, Math.max(10, requestedDuration))
  : 60

const response = await fetch(
  'https://api.elevenlabs.io/v1/music?output_format=mp3_44100_128',
  {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'xi-api-key': config.elevenLabsApiKey,
    },
    body: JSON.stringify({
      prompt: buildMusicPrompt(input.mode, input.direction),
      music_length_ms: durationSeconds * 1000,
      model_id: 'music_v2',
      generation_mode: 'loop',
      force_instrumental: true,
      sign_with_c2pa: true,
    }),
  },
)

generation_mode: 'loop' is one part of making the repeat sound natural. The prompt also asks for no intro pickup, ending cadence, or fade-out. A track written like a normal song sounds broken when it jumps from the ending back to the first beat.

Compile & Chill keeps one generated track per station mode. Switching from Deep Work to Rainy Debug and back reuses the existing track instead of making another paid request.

Checkpoint: add ELEVENLABS_API_KEY to .env, restart the server, and generate one 60-second track. Switch modes and confirm that returning to the original mode reuses its audio.

5. Deploy the private media library

The repository includes an AWS SAM template managed by AWS CloudFormation. Validate and deploy it:

sam validate \
  --template-file infra/compile-and-chill-private-station.yaml \
  --region us-west-2

sam deploy \
  --region us-west-2 \
  --stack-name compile-and-chill-private-station \
  --template-file infra/compile-and-chill-private-station.yaml \
  --no-confirm-changeset \
  --no-fail-on-empty-changeset

Read the media bucket output:

aws cloudformation describe-stacks \
  --region us-west-2 \
  --stack-name compile-and-chill-private-station \
  --query "Stacks[0].Outputs[?OutputKey=='StationMediaBucketName'].OutputValue" \
  --output text

Copy that value into .env:

STATION_S3_BUCKET=YOUR_STACK_OUTPUT
STATION_S3_REGION=us-west-2

The stack creates two versioned buckets. One stores generated station media. The other stores AWS CloudTrail data-event logs encrypted with AWS Key Management Service (AWS KMS). An Amazon CloudWatch alarm watches delete requests against the media bucket.

The application assigns each browser profile a random station ID in an HttpOnly, SameSite cookie. Objects use this layout:

stations/<station-id>/manifest.json
stations/<station-id>/<mode>/scene.png
stations/<station-id>/<mode>/scene.mp4
stations/<station-id>/<mode>/music.mp3

The browser receives same-origin URLs such as /api/library/assets/deepWork/scene. The route reads the matching S3 object into server memory and returns it. The current implementation is a proxy, not a streaming pass-through, so account for memory when increasing the 50 MiB video limit.

The storage implementation is in server/utils/station-library.ts.

Checkpoint: regenerate a scene or track, reload the page in the same browser profile, and confirm that the media returns. Open a private browsing window and confirm that it starts with a separate station.

6. Turn one illustration into a seamless video loop

Animated mode generates a fresh illustrated anchor with Amazon Bedrock, saves it to S3, and creates a 300-second presigned read URL. OpenRouter needs that temporary URL because its video provider must download the input image.

The trick is to submit the same anchor as both frame constraints:

body: JSON.stringify({
  model: modelId,
  duration: 6,
  resolution: '720p',
  aspect_ratio: '16:9',
  generate_audio: false,
  prompt: [
    'Animate this 2D cartoon illustration of a fictional character.',
    'Use a locked-off camera and keep the illustrated composition unchanged.',
    'The provided illustration is both the first and last frame.',
    'Allow only tiny two-hand typing motion and one gentle blink.',
    'No zoom, pan, cut, identity change, new objects, or geometry changes.',
    'Create a silent seamless six-second ambient loop.',
  ].join(' '),
  frame_images: [
    {
      type: 'image_url',
      image_url: { url: sourceUrl },
      frame_type: 'first_frame',
    },
    {
      type: 'image_url',
      image_url: { url: sourceUrl },
      frame_type: 'last_frame',
    },
  ],
})

The model can move away from the anchor, but the matching frame constraints request a return to the same composition at the end. The prompt limits movement to a small typing motion and one blink, with no camera movement, reframing, cuts, new objects, or identity changes.

The app discovers compatible video models at runtime. A candidate must support six seconds, 720p, first_frame, and last_frame. It prefers Seedance 2.0 Fast, then checks a short fallback list.

The fallback policy is intentionally narrow:

HTTP 402 stops because credits are unavailable.
HTTP 429 stops because the account is rate limited.
An input-image moderation refusal may try the next compatible model because no video job was created.
Other failures stop rather than risk submitting and billing a duplicate job.

See the complete policy in server/utils/openrouter-video.ts.

Video generation takes minutes rather than seconds, and provider timing and prices change. Treat the request as a paid background job even if the first version runs inside one long HTTP request.

7. Report real progress during a long request

A spinner cannot tell the user whether a three-minute provider job is moving or stuck. Compile & Chill keeps a process-local job registry with six phases:

creating anchor
preparing source
submitting video
rendering loop
downloading loop
saving privately

The browser creates a job ID, starts the generation request, and polls the Nuxt status endpoint every 750 milliseconds. Nuxt polls the provider every 15 seconds, up to 48 times. These are separate loops.

The registry also rejects a second active job for the same station with HTTP 409. That protects the user from duplicate clicks, but it is not a distributed queue. A process restart loses status, and multiple Nuxt instances would each have their own registry. For a multi-instance deployment, move job state and concurrency control to a shared data store and worker queue.

8. Validate the build

Run the same checks used for the source project:

npm test
npm run typecheck
npm run build

The current repository has 26 passing tests plus a clean type check and production build.

Then test one provider at a time:

Start with no credentials and verify the UI.
Add Amazon Bedrock and generate one static scene.
Add ElevenLabs and generate one track.
Deploy the storage stack and verify reload persistence.
Add OpenRouter last, acknowledge the paid operation, and generate one animated loop.

This order keeps failures small. If the video path fails, you already know that image generation, storage, and browser identity work independently.

Cleanup

The cleanup steps remove data permanently. Download anything you want to keep before continuing. The buckets and KMS key use retention policies, so they can remain after stack deletion and may continue to incur charges.

First, use Delete saved station inside each browser profile whose generated media should be removed. This purges object versions and delete markers under that profile's station prefix.

Before deleting the stack, record the retained resource names:

MEDIA_BUCKET=$(aws cloudformation describe-stacks \
  --region us-west-2 \
  --stack-name compile-and-chill-private-station \
  --query "Stacks[0].Outputs[?OutputKey=='StationMediaBucketName'].OutputValue" \
  --output text)

AUDIT_BUCKET=$(aws cloudformation describe-stacks \
  --region us-west-2 \
  --stack-name compile-and-chill-private-station \
  --query "Stacks[0].Outputs[?OutputKey=='CloudTrailLogBucketName'].OutputValue" \
  --output text)

KMS_KEY_ID=$(aws kms describe-key \
  --region us-west-2 \
  --key-id alias/compile-and-chill-cloudtrail \
  --query KeyMetadata.KeyId \
  --output text)

Delete the non-retained stack resources:

sam delete \
  --stack-name compile-and-chill-private-station \
  --region us-west-2

The media bucket, audit bucket, and KMS key are retained by design. Empty all versions and delete markers from both versioned buckets in the S3 console, then delete the buckets:

aws s3api delete-bucket --bucket "$MEDIA_BUCKET" --region us-west-2
aws s3api delete-bucket --bucket "$AUDIT_BUCKET" --region us-west-2

Schedule the retained KMS key for deletion after confirming that you no longer need the encrypted audit logs:

aws kms schedule-key-deletion \
  --region us-west-2 \
  --key-id "$KMS_KEY_ID" \
  --pending-window-in-days 7

KMS key deletion has a waiting period. After deletion, data encrypted only by that key cannot be recovered.

For local cleanup:

rm -rf node_modules .nuxt .output
rm .env

Finale

This has been a very fun project. Let me know if you try it out!

You can explore every route, prompt, infrastructure resource, and test in the Compile & Chill source code. For another Nuxt project that keeps AI actions behind explicit user approval, read How to Build an AI Agent That Asks Permission First. Leave a comment on what you think! Thank!

How to Build an AI Agent That Asks Permission First (Nuxt + AI SDK 7)

Erik Hanchett — Tue, 18 Aug 2026 18:38:25 +0000

Introduction

I did something stupid. I built a superhero-themed Nuxt app, connected it to an Anthropic model through Amazon Bedrock, and gave it a tool that deletes files from my computer. In fact, if I wasn't careful, it could have deleted all my files!

The first time I tried it, I didn't use any sort of approval mechanism. And as you expected it just deleted things. Then I looked into how my coding agent works, and I learned about tool approvals.

I learned that AI SDK 7 has a tool approval at the model-call level. It works by pausing for an approval, showing an approval window, and then deleting it. I then put Kiro CLI behind the same interface using Agent Client Protocol (ACP).

Watch the full video on YouTube.

Prerequisites

You need:

Node.js 22 or later. AI SDK 7 requires Node.js 22 and uses ECMAScript modules (ESM).
npm 11 or another package manager that works with Nuxt 4.
AWS credentials available through the standard provider chain.
Access to an Amazon Bedrock model in your AWS Region.
The AWS CLI if you want to list the inference profiles available to your account.
An authenticated Kiro CLI installation for the optional ACP section.

Step 1: Create the Nuxt app

Create the project and install the versions used in the recorded demo:

npx nuxi@latest init nuxt-agent-approval
cd nuxt-agent-approval

npm install \
  nuxt@4.5.2 \
  vue@3.5.41 \
  ai@7.0.66 \
  @ai-sdk/vue@4.0.66 \
  @ai-sdk/amazon-bedrock@5.0.57 \
  @aws-sdk/credential-providers@3.1111.0 \
  @nuxt/ui@4.10.0 \
  zod@4.4.3

npm install -D @iconify-json/lucide@1.2.123

// nuxt.config.ts
export default defineNuxtConfig({
  modules: ['@nuxt/ui'],
  css: ['~/assets/css/main.css'],
  runtimeConfig: {
    awsRegion: process.env.AWS_REGION ?? 'us-west-2',
    bedrockModelId: process.env.NUXT_BEDROCK_MODEL_ID
  }
})

Add the two Nuxt UI imports:

/* app/assets/css/main.css */
@import "tailwindcss";
@import "@nuxt/ui";

You can compare your setup with the complete companion project.

Step 2: Keep the file tool inside a fixture directory

The video uses two fixture files, old-draft.md and keep-me.md. Create them before adding the tools:

mkdir -p fixtures
printf '# Old draft\n' > fixtures/old-draft.md
printf '# Keep me\n' > fixtures/keep-me.md

The agent can list or remove files in that directory, but it should not accept a path such as ../../package.json.

Approval decides whether a tool runs. It does not decide what the tool can reach after it starts.

// server/utils/file-tools.ts
import { lstat, readdir, realpath, rm } from 'node:fs/promises'
import { resolve, relative, isAbsolute } from 'node:path'
import { tool } from 'ai'
import * as z from 'zod'

function resolveInsideFixtures(inputPath: string): string {
  const root = resolve(process.cwd(), 'fixtures')
  const target = resolve(root, inputPath)
  const rel = relative(root, target)

  if (rel === '' || rel.startsWith('..') || isAbsolute(rel)) {
    throw createError({
      statusCode: 400,
      statusMessage: `Path escapes the fixtures directory: ${inputPath}`
    })
  }

  return target
}

export const listFiles = tool({
  description: 'List the files in the project fixtures directory.',
  inputSchema: z.object({}),
  execute: async () => {
    const entries = await readdir(resolve(process.cwd(), 'fixtures'), {
      withFileTypes: true
    })
    return { files: entries.filter(entry => entry.isFile()).map(entry => entry.name) }
  }
})

export const deleteFile = tool({
  description: 'Permanently delete one file from the fixtures directory.',
  inputSchema: z.object({ path: z.string() }),
  execute: async ({ path }) => {
    const target = resolveInsideFixtures(path)
    const info = await lstat(target).catch(() => null)

    if (!info?.isFile() || info.isSymbolicLink()) {
      return { deleted: false, path, reason: 'Not a regular file' }
    }

    const root = await realpath(resolve(process.cwd(), 'fixtures'))
    const canonicalTarget = await realpath(target)
    const rel = relative(root, canonicalTarget)

    if (rel === '' || rel.startsWith('..') || isAbsolute(rel)) {
      throw createError({
        statusCode: 400,
        statusMessage: 'File resolves outside fixtures'
      })
    }

    await rm(canonicalTarget)
    return { deleted: true, path }
  }
})

The second check happens after realpath(). That catches a path that looked local before resolution but points outside the fixture directory through a symbolic link.

Step 3: Connect the route to Amazon Bedrock

I used Amazon Bedrock, but you can use provider with AI-SDK

Create the provider in server/utils/bedrock.ts:

import { createAmazonBedrock } from '@ai-sdk/amazon-bedrock'
import { fromNodeProviderChain } from '@aws-sdk/credential-providers'

export function useBedrock() {
  const { awsRegion } = useRuntimeConfig()

  return createAmazonBedrock({
    region: awsRegion,
    credentialProvider: fromNodeProviderChain()
  })
}

fromNodeProviderChain() uses the AWS credentials already available to your local environment, including AWS IAM Identity Center sessions, named profiles, environment variables, and instance roles. You do not need to put a long-lived access key in the Nuxt project.

Do not copy a model ID from this post. Available IDs vary by account and AWS Region. List the active Amazon Bedrock inference profiles for your account:

aws bedrock list-inference-profiles \
  --region us-west-2 \
  --query 'inferenceProfileSummaries[?status==`ACTIVE`].inferenceProfileId'

Set one of the returned profile IDs before starting Nuxt:

export AWS_REGION=us-west-2
read -r -p "Inference profile ID: " NUXT_BEDROCK_MODEL_ID
export NUXT_BEDROCK_MODEL_ID
npm run dev

Now add an unguarded chat route. Starting without approval makes the failure visible:

// server/api/chat.post.ts
import {
  streamText,
  stepCountIs,
  convertToModelMessages,
  toUIMessageStream,
  createUIMessageStreamResponse
} from 'ai'
import type { AmazonBedrockProvider } from '@ai-sdk/amazon-bedrock'

type BedrockModelId = Parameters<AmazonBedrockProvider>[0]

export default defineEventHandler(async event => {
  const { messages } = await readBody(event)
  const { bedrockModelId } = useRuntimeConfig()
  const bedrock = useBedrock()

  const result = streamText({
    model: bedrock(bedrockModelId as BedrockModelId),
    instructions:
      'Manage files in the fixture project. List files before deleting. Never guess a filename.',
    messages: await convertToModelMessages(messages),
    tools: { listFiles, deleteFile },
    stopWhen: stepCountIs(5)
  })

  const stream = toUIMessageStream({ stream: result.stream })
  return createUIMessageStreamResponse({ stream })
})

stopWhen is important. AI SDK 7 stops after one step by default. The model can call deleteFile, receive the result, and then stop before it tells the user what happened. Five steps leave room to list, delete, and summarize while keeping the loop bounded.

At this point, delete old-draft.md removes the file as soon as the model selects the tool. That is what happened in the first minute of the video.

Step 4: Add approval to the delete tool

Add one option to the streamText() call (toolApproval):

const result = streamText({
  model: bedrock(bedrockModelId as BedrockModelId),
  instructions:
    'Manage files in the fixture project. List files before deleting. Never guess a filename.',
  messages: await convertToModelMessages(messages),
  tools: { listFiles, deleteFile },
  stopWhen: stepCountIs(5),
  toolApproval: {
    deleteFile: 'user-approval'
  }
})

The option lives on streamText(), not inside the tool definition. The same deleteFile tool might run unattended in a maintenance job and require a person in a customer-facing chat.

AI SDK 7 supports more than a yes-or-no policy. A policy function can approve a call, deny it without asking, or send it to the user. This example uses the direct user-approval status because every delete should stop.

Step 5: Render the approval request in Nuxt

Nuxt UI's chat documentation follows the same AI SDK message-part model. The recorded app uses useChat() from @ai-sdk/vue and the isToolApprovalPending() helper from Nuxt UI:

<script setup lang="ts">
import {
  DefaultChatTransport,
  getToolName,
  isTextUIPart,
  isToolUIPart,
  lastAssistantMessageIsCompleteWithApprovalResponses
} from 'ai'
import { useChat } from '@ai-sdk/vue'
import { isToolApprovalPending } from '@nuxt/ui/utils/ai'

const input = ref('')

const {
  messages,
  status,
  sendMessage,
  addToolApprovalResponse
} = useChat({
  transport: new DefaultChatTransport({ api: '/api/chat' }),
  sendAutomaticallyWhen: lastAssistantMessageIsCompleteWithApprovalResponses
})

function onSubmit() {
  if (!input.value.trim()) return
  sendMessage({ text: input.value })
  input.value = ''
}
</script>

sendAutomaticallyWhen resumes the interrupted turn after the user answers. Without it, the approval state changes in the browser but the agent does not continue on its own.

Render tool parts and attach the two decisions while approval is pending:

<template>
  <div v-for="message in messages" :key="message.id">
    <template
      v-for="(part, index) in message.parts"
      :key="`${message.id}-${part.type}-${index}`"
    >
      <div v-if="isToolUIPart(part)" class="tool-card">
        <strong>{{ getToolName(part) }}</strong>

        <pre v-if="part.input">{{ part.input }}</pre>

        <div v-if="isToolApprovalPending(part)">
          <button
            type="button"
            @click="addToolApprovalResponse({
              id: part.approval!.id,
              approved: true
            })"
          >
            Do it
          </button>

          <button
            type="button"
            @click="addToolApprovalResponse({
              id: part.approval!.id,
              approved: false,
              reason: 'The user declined this file deletion.'
            })"
          >
            Nope
          </button>
        </div>
      </div>

      <p v-else-if="isTextUIPart(part)">{{ part.text }}</p>
    </template>
  </div>

  <form @submit.prevent="onSubmit">
    <input v-model="input" placeholder="delete old-draft.md">
    <button :disabled="status !== 'ready'">Send</button>
  </form>
</template>

FYI, An approval button is not useful when the person cannot see which path the agent wants to remove.

The denial reason is also useful. approved: false tells the model it cannot run the tool. The reason gives it enough context to explain what happened rather than trying the same call again.

Run the prompt twice. Deny it once and confirm that old-draft.md remains. Reset the fixtures, repeat the prompt, approve it, and confirm that the file disappears. The model received the same request both times.

Step 6: Put Kiro CLI behind the same Nuxt UI

The video switches the backend for the final demo. Instead of sending the prompt directly to an Anthropic model through Amazon Bedrock, the Nuxt app talks to Kiro CLI over Agent Client Protocol.

ACP gives the app a common way to start an agent session, send a prompt, receive tool events, and answer permission requests. Kiro runs as a separate process and keeps its existing agent tools and Model Context Protocol (MCP) integrations. The Nuxt app remains responsible for the interface and the host tools it exposes.

Install the AI SDK harness packages:

npm install \
  @ai-sdk/harness@1.0.73 \
  @ai-sdk/harness-acp@1.0.11

The Kiro route creates a HarnessAgent instead of calling streamText() directly. The createKiroHarness() ACP preset and createUnsafeLocalSandbox() development adapter come from the companion project, so treat this as the route configuration rather than a standalone file:

import { execFileSync } from 'node:child_process'
import { HarnessAgent } from '@ai-sdk/harness/agent'

const kiroExecutable = execFileSync('which', ['kiro-cli'], {
  encoding: 'utf-8'
}).trim()

const agent = new HarnessAgent({
  harness: createKiroHarness({ port: 4100 }),
  sandbox: createUnsafeLocalSandbox({
    ports: [4100],
    hostBins: [
      { harnessId: 'kiro', name: 'kiro-cli', target: kiroExecutable }
    ]
  }),
  permissionMode: 'allow-reads',
  instructions:
    'Manage files in the fixture project. List files before deleting. Never guess a filename.',
  tools: { listFiles, deleteFile },
  toolApproval: {
    deleteFile: 'user-approval'
  }
})

The complete Kiro route and ACP preset include session creation and approval continuation. When a response comes back from the browser, the route gathers pending approval responses and calls continueStream() against the Kiro session.

My recorded run asked more than once before deleting keep-me.md. Kiro confirmed the target, its permission flow asked to run the tool, and the host deleteFile policy asked for the final approval. It was a little repetitive, but it exposed an important boundary. Kiro's built-in permissions and AI SDK's host-tool approval are separate systems.

The local sandbox in this sample is a development adapter. It limits file API paths to a temporary root, but processes still run as the current operating-system user. Replace it with an isolated sandbox provider before exposing a coding agent to untrusted prompts.

Step 7: Keep approval in its lane

Tool approval is a product DX improvement, it isn't security.

If a person approves the wrong path, the tool still removes the wrong path. If the tool can reach the rest of the filesystem, approval does not narrow that access. Keep the path checks from Step 2, apply authorization inside the tool, validate inputs on the server, and use an isolated runtime for agents that can run commands.

The sample app also keeps its recording controls in development mode. The browser can turn approval off for the first demo, but the built app ignores that flag and requires approval. A client-controlled switch that disables confirmation should not ship.

Cleanup

Stop the Nuxt development server. If you deleted either fixture during the demo, recreate both files before your next run:

printf '# Old draft\n' > fixtures/old-draft.md
printf '# Keep me\n' > fixtures/keep-me.md

This tutorial does not provision AWS resources. Amazon Bedrock requests can still incur charges, so stop sending test prompts when you finish.

If you delete the local project directory, its files and any local session state are removed. Copy anything you want to keep before deleting it. AWS credentials loaded through the provider chain remain in their original profile or identity-center cache; this app does not write them into the project.

Finale

I learned a lot by adding this tool approval process. And even though I normally use Strands Agents, the AI SDK 7 worked really well.

Make sure to leave a comment below if you got this far!

References

Nuxt 4.5 SSR Streaming Is Kind Of A Big Deal

Erik Hanchett — Tue, 11 Aug 2026 17:41:30 +0000

Nuxt 4.5 launched last month and it's really neat. One of my most favorite features is the experimental SSR streaming. With one simple change in the Nuxt config I was able to reduce the Largest Contentful Paint (LCP) by over 2 seconds. I simply enabled the experimental SSR streaming, and the first byte arrived in 16 milliseconds.

With out it, the server spent about 2.5 seconds rendering the page. Streaming changed what the browser could display during that wait.

As a part of my testing I also tried out two other features: useLayout() and named views. Let's take a look at all of these now!

This post walks through all three features using Nuxt 4.5.2. Let's take a look!

If you rather watch check out my full video here

Prerequisites

You will need:

Node.js 22 or another version supported by Nuxt 4.5
npm
Basic experience with Nuxt pages, components, and layouts
Chrome or another browser with document-request timing tools
My sample app! https://github.com/ErikCH/nuxt-ssr-streaming

After cloning down the repo, build it and run it in preview.

npm ci
npm run typecheck
npm run build
npm run preview

The demo preview runs on port 3010. The streamed route is /, and /buffered uses the same components with streaming disabled by a route rule.

Feature 1: Experimental SSR streaming

Normal server-side rendering can buffer the document until every server-rendered component finishes. A slow database query or API request can leave the browser waiting even when the page shell is ready.

Nuxt 4.5 added the experimental ssrStreaming option. It uses Vue's web-stream renderer to flush ready HTML while later boundaries continue rendering.

Create a controlled slow component

I used a fixed delay so the delivery difference would be easy to see. The delay runs on the server, and useState serializes the result into the Nuxt payload for hydration.

<script setup lang="ts">
interface SlowResult {
  resolvedAt: string
  serverDurationMs: number
  renderMarker: string
}

const props = withDefaults(
  defineProps<{
    delayMs?: number
  }>(),
  {
    delayMs: 2500,
  },
)

const route = useRoute()
const result = useState<SlowResult>(`slow-panel:${route.path}`, () => ({
  resolvedAt: '',
  serverDurationMs: 0,
  renderMarker: '',
}))

if (import.meta.server) {
  const startedAt = Date.now()
  await new Promise(resolve => setTimeout(resolve, props.delayMs))

  result.value = {
    resolvedAt: new Date().toISOString(),
    serverDurationMs: Date.now() - startedAt,
    renderMarker: Date.now().toString(36).slice(-6).toUpperCase(),
  }
}
</script>

Place the component inside a Vue Suspense boundary. The fallback becomes part of the shell that Nuxt can send before SlowPanel resolves.

<template>
  <main>
    <header>
      <p>Nuxt 4.5 rendering test</p>
      <h1>The shell is ready</h1>
    </header>

    <Suspense>
      <SlowPanel :delay-ms="2500" />

      <template #fallback>
        <article aria-live="polite" aria-busy="true">
          <p>Shell received</p>
          <h2>Waiting for the slow server boundary...</h2>
        </article>
      </template>
    </Suspense>
  </main>
</template>

The fallback needs to be useful. Navigation, page context, and a clear loading state give the visitor something to work with. Sending an empty shell earlier does little for the experience.

Enable streaming in production

The demo enables streaming outside development and keeps /buffered as a control route.

const ssrStreamingEnabled = process.env.NODE_ENV !== 'development'

export default defineNuxtConfig({
  compatibilityDate: '2026-07-01',
  features: {
    devLogs: false,
  },
  experimental: {
    ssrStreaming: ssrStreamingEnabled,
  },
  runtimeConfig: {
    public: {
      ssrStreamingEnabled,
    },
  },
  routeRules: {
    '/buffered': { streaming: false },
  },
})

The /buffered route uses the same slow component, delay, and shell. Its route rule changes the response mode without changing the work performed by the component.

Compare the responses

Open the streamed and buffered routes as full document requests. Disable the browser cache and use a hard reload. Client-side navigation does not create a new SSR document request.

You can also measure the response chunks from a second terminal:

npm run measure

My local production preview produced this result:

streamed: first byte 16 ms, complete 2562 ms, 14 chunks, 5.8 KB
buffered: first byte 2518 ms, complete 2518 ms, 1 chunk, 5.8 KB

Both routes performed the same delayed work and returned the same amount of HTML. The streamed route delivered the response in 14 chunks and gave the browser useful HTML much earlier. The buffered route delivered one chunk after the slow boundary finished.

This was just a test, on a somewhat contrived setup. However, I would try this yourself in your own app and see how the results go. Make sure to try it in development first, before going to production.

Check the production constraints

ssrStreaming is experimental and disabled by default. Nuxt can fall back to buffered rendering for:

Bots and crawlers
Cached routes
Incremental Static Regeneration (ISR)
Stale-while-revalidate (SWR) routes
Redirects
Routes using ssr: false
Prerendered output
Routes with streaming: false

Streaming also changes when the HTTP response becomes committed. After the shell has been flushed, later component code may be too late to change the status, headers, or cookies. Test authentication redirects, cookie writes, cache headers, errors, and middleware before enabling streaming on a production route.

I would start with a content-heavy page that has a useful shell and one isolated slow boundary. Measure the deployed route with its real adapter and route rules. Keep buffering where the application needs to finish response decisions before sending HTML.

Feature 2: Read the resolved layout with `useLayout()`

Nuxt 4.5 added a stable useLayout() composable. It returns a read-only computed ref containing the layout Nuxt resolved for the current route.

<script setup lang="ts">
const layout = useLayout()
</script>

<template>
  <output class="layout-badge">
    <code>useLayout()</code>
    <strong>{{ layout === false ? 'disabled' : layout }}</strong>
  </output>
</template>

The value accounts for page metadata, route-rule layout selection, and the default layout. It also updates during navigation.

In the demo, two child pages select different layouts:

<!-- app/pages/features/overview.vue -->
<script setup lang="ts">
definePageMeta({
  layout: 'default',
})
</script>

<!-- app/pages/features/focus.vue -->
<script setup lang="ts">
definePageMeta({
  layout: 'focus',
})
</script>

The parent page stays mounted while navigation changes the child route. The computed layout updates from default to focus without requiring the parent to inspect route metadata itself.

Reading route.meta.layout can miss layouts selected elsewhere in Nuxt's resolution chain. Use useLayout() when a component needs the layout Nuxt is actually rendering.

Feature 3: Render multiple outlets with named views

Named views let one route render into multiple page outlets. Nuxt 4.5 uses a name@view.vue filename convention for the additional view files.

The demo uses this structure:

app/pages/
  features.vue
  features/
    index.vue
    overview.vue
    overview@sidebar.vue
    focus.vue
    focus@sidebar.vue

The parent page creates a default outlet and a named sidebar outlet:

<template>
  <section aria-label="Named view outlets">
    <article>
      <NuxtPage />
    </article>

    <aside>
      <NuxtPage name="sidebar" />
    </aside>
  </section>
</template>

When you visit /features/overview, overview.vue fills the default outlet and overview@sidebar.vue fills the sidebar. The focus files do the same work for /features/focus. Both outlets belong to one URL, and the parent does not need a manual component map.

Keep route metadata in the default page file. Nuxt ignores definePageMeta in an @sidebar file. If a route has no matching named-view file, that outlet remains empty.

Finale

I am really impressed by the incremental changes in Nuxt 4.5. SSR streaming is something I'll be using on all my future apps. And useLayout and named views are nice DX bonuses.

Leave a comment and let me know which of these features you'll be using next!

Resources

How To learn Web Development in 2026

Erik Hanchett — Mon, 03 Aug 2026 17:19:26 +0000

Learning web development in 2026 is a lot different than it was when I first learned in 2010. Back then, I used Udemy courses, Stack Overflow, and official documentation. I’d spend hours copying and pasting code, only to discover that the blog post I was pulling it from was out of date. It was frustrating, to say the least.

Luckily, learning a new framework in 2026 is a lot easier than it was.

Recently I was at Chain React. It's a React Native conference and for my talk I decided to really deep into the framework and learn it. I started doing the same thing I always did, reading the docs, buying courses etc. Then I realized I could use AI to speed up my learning. This is what I want to teach you today, with a few additional tips along the way.

Want to watch instead, check out my full video on the subject!

(Full disclosure before I start naming tools: I'm a Developer Advocate at AWS, and Kiro is an AWS product. It's the agentic harness I use daily. Everything here works the same in Claude Code, Cursor, or whatever you already have open.)

Start with a goal, not a curriculum

I don't start by learning a framework. I start with something that I want to build for fun.

When I was learning React Native, it was a workout tracker. I wanted to learn a program called 75 Hard, which is 75 days of hitting the same set of daily goals including a diet, an outdoor workout, and a second workout. I wanted to check those off on my phone. That was the goal.

Making sure you have a goal is really important. A todo list app teaches you nothing, because it means almost nothing. A real app forces decisions you have to make, like does it work offline, where does the data live, what happens when permissions get denied. Pick something with a little resistance in it, ideally tied to a hobby so you'll still care as your learning progression continues.

Decide how much you actually need to know

In other words, how much of it do I need to actually learn to achieve my goal?

In today's age, you need to learn the primitives. The basics, and some architecture of how it all works. You do not need to memorize API signatures anymore.

Let's imagine you are learning React. If you're using useState everywhere, understand what it does and why re-renders happen. Whether you can recall the exact argument order from memory is irrelevant, because the model will write it. Same with optional chaining, same with whatever config format the build tool wants this year. Learn the basics of the framework or library you are learning. Let the agent handle the syntax.

Ask three models what they'd build today

Before I learn anything, I want to know what the ecosystem actually looks like right now. So I ask several models the same broad question and compare.

When I was learning React Native, I ran the same prompt through Gemini, Claude, and GPT. Something like this:

Build a mobile application for iOS.

That comes back with Swift, which tells me something. Then:

Build a cross-platform iOS and Android application.

Now I get Flutter or React Native. I'm not asking for code here. I'm reading the consensus from the agent to find out which frameworks and libraries it's recommending, which tells me whether the thing I'm about to learn is the thing I should be learning.

When the models disagree, that's when I dig in further to find out why. I'll usually google around a bit to see if I'm on the right path.

Get a personalized learning path

Finally, I work on a personalized learning path, based on what I know already. Here is an example:

Build me a curriculum to learn React Native. Assume I already
have basic knowledge of React, HTML, CSS, and JavaScript.

The second sentence is where I brought in my own personalization. I know web development, so I wanted to make sure my learning path is tailored to me. Also, I called out React Native, as per the last section, I learned it's the most popular and makes the most sense for me.

Because I told it I already knew web basics, it skips React fundamentals and goes straight to what's different: native components instead of the DOM, StyleSheet instead of the CSS cascade, navigation as a stack instead of URLs, you get the idea. I then get topics with a suggested time frame, and I can work through them at my own pace.

Heads up: model selection matters here more than almost anywhere else. I ran this against Sonnet 4 and Opus 5. Sonnet 4 handed me what was essentially 2023 React Native. Opus 5 gave me current information and a noticeably better curriculum. Every model has a different training cutoff, and a stale curriculum is worse than no curriculum, because you don't know which parts are wrong.

If you're stuck on an older or a local model, run an adversarial review. Have the cheap model draft the learning path, then hand it to a current model and ask what's out of date. Going past two or three models surfaces a surprising amount, and it's also a good idea when you are trying to save tokens.

Also make sure you use some of the tools your harness gives you. Most harnesses have search built in, plus MCP servers and skills. If you're learning React, install the current React skills before you generate anything. Scaffolding tools help here too: create-next-app now drops an AGENTS.md in your project, and that file is a better starting point for your curriculum than the model's memory.

Build it: I do, we do, you do

A learning path is a good start. It's still reading. To move to actual understanding I used an old teaching framework from 1983.

It's called gradual release of responsibility, from a paper by Pearson and Gallagher, and it sits on top of Vygotsky's zone of proximal development. The sequence is I do, we do, you do. The teacher demonstrates, then you work together, then you work alone.

To use this framework today, the the AI becomes the "I." It does, you watch. Then you work together with the AI, and finally you do it yourself. It's really helped me learn. Let's start with ** I do **

I do: let it build, then read it

Let the agent build the whole thing. Just create a simple prompt, and let it do it's thing. Don't type anything. Read the output, look at the file structure, see how it wired things together.

You are not learning yet, and that's fine. This phase is the right one because it gives you an idea what is possible. If you like you could look over the code that was written, but it's not the best way to learn.

We do: spec-driven development

This is where most of the learning actually happened for me.

Spec-driven development means writing structured specifications first, so the agent can build and verify against them. In practice I ask for a spec instead of an app:

Create a spec that helps build a retro workout planner app.

What comes back is a design document, and the design document is the cheat sheet. Mine told me to use Expo Router 57, expo-sqlite, an image picker, and notifications. That's a map of the architecture and the current library choices for a framework I didn't know yet. When I was working like this, I would constantly ask clarifying questions and ask why certain decisions were made. I would even often ask for changes.

Then it generates requirements, usually as user stories. I skip this one when I'm learning. It's more useful when you're shipping to other people.

The implementation plan is the part you need to pay attention to. It's a task list. Instead of letting the agent execute it, I work through the tasks myself, with the design doc open. When I get stuck, I say so:

I tried to install NativeWind 5 and I don't understand what to do here. Can you help?

Then I get help, and I might even read the official documentation anyways. That's the "we do" phase working exactly as designed. I have enough context to attempt it and a patient buddy for the gaps. It's almost like rubber ducking, but with something that can respond.

Keep in mind, if you write a spec and then let the agent implement all of it, you haven't learned much. You can now explain what your app does and still not explain how the framework does it. So I settled on a rule. Spec the what, hand-write the how, at least once per concept. Write the spec for the app, but make sure your writing things yourself (with help if needed).

You do: turn it off

Close the tab. Build something small with no assistance.

Don't skip this step. This is the best way to check your recall and that you really understand everything. I wouldn't write the whole thing from scratch, mind you, but a few pieces just to make sure I understand the underlying concepts.

Two more patterns worth stealing

Let the AI quiz you. Take the learning path you already generated and ask for a quiz on it, then go back and forth. It's a quick way to find out which parts you only think you know.

The stronger version of this flips the direction. Don't ask the model to explain hooks to you. Explain hooks to the model and ask it to grade you. "Here's my understanding of the New Architecture, what did I get wrong?" Use text-to-speach if you can, to make this even quicker.

The other pattern is learning in public, which I was doing long before agents existed. Post what you're learning, on YouTube or Bluesky or a blog. Writing it down for someone else is what exposes the parts you weren't sure on. This post exists because I told a conference I'd stand up and explain React Native, and that deadline taught me more than any course.

Where I've landed

Start with a goal you care about. Use your usual harness on a current model. Have it build you a plan, with search and MCP servers turned on so it isn't working from memory. Learn the primitives and the architecture, skip memorizing the APIs. Then try out something like: having the AI build it, build alongside it, then build alone.

AI didn't replace the learning. It replaced the searching. All those hours of hunting for the right Stack Overflow answer are gone, and I don't miss them. But the part where you sit with something confusing until it stops being confusing? That still has to happen. There's just no tab for it.

How do you learn a new framework these days? Let me know in the comments if you do it differently. Until next time.

7 Kiro Features You're Probably Not Using

Erik Hanchett — Mon, 27 Jul 2026 15:39:49 +0000

Did you know that Kiro doesn't just have a Spec-Driven Development (SDD) flow, but also a bug fix workflow that helps you resolve one issue at a time? That's one of seven features worth knowing about.

If you're completely new to Kiro, it's an agentic harness for the CLI, web, IDE, iOS, and more. It helps teams and individuals do their best work while coding. I've been using it since it launched in July last year, and I keep finding features I didn't know were there.

(Full disclosure: I'm a Developer Advocate at AWS, and Kiro is a part of AWS. I use it every day, and I'll be forthcoming about the parts that are still preview or experimental.)

Heads up: Kiro ships fast. I've flagged the version-sensitive bits of these features inline. Check the docs if something looks different in your build.

1. Stop approving every single command

After talking to a lot of people about Kiro, one of the main pieces of feedback I get is on approving commands. When Kiro asks permission to run a shell command, the default reaction is to hit yes and move on. Then it asks again for the next git command. And the next one.

Press Tab instead in the CLI. This allows you to edit it and put the exact permissions you'd like. For example you can be pickier on the trust tiers:

git pull --rebase     # this exact command
git pull *            # git pull with any arguments
git *                 # anything git
*                     # the entire shell tool

Whatever you pick persists for the session and gets stored as a regex in your agent's allowedCommands.

There's also /tools trust-all, which trusts everything. It's the documented replacement for the old /acceptall, and the security docs are blunt about it: don't use it in production or with sensitive data, and you're responsible for whatever it does.

One version note: on CLI v3 this moves to a permissions.yaml file, so the agent JSON advice above is v2. More on v3 in a minute.

Full details: tool permissions

2. The `#` menu is bigger than `#file` in the IDE

Type # in the IDE chat and you get a list of context providers. #file is the one I use a lot. The full list:

#codebase · #file · #folder · #git diff · #terminal · #problems · #url: · #code: · #repository · #current · #steering: · #docs: · #spec: · #mcp:

You can stack them in a single message. #git diff #problems review my changes is a different request than either one alone.

The one I've been using more is the #terminal. It hands Kiro your recent terminal output and command history, so you stop copying and pasting errors:

#terminal why did this build fail

One thing I find handy is the "#Currently Open files." However, keep in mind that Kiro pulls in your open files and their dependencies automatically without you asking.

Full list: context providers

Also you can't drag a file in the IDE's own explorer to the chat window, however you can copy and past the location of the file and past that into the chat window as a workaround.

3. Pick a workflow instead of freeform chatting

Kiro gives you structured starting points, and it's tempting to just start typing into the chat box instead. Instead you can choose any of these in the IDE.

Spec for a full feature, with requirements, design, and tasks
Plan when you want an implementation plan and zero code changes
Bug Fix to investigate, diagnose, and resolve one problem
Quick Spec when you want Kiro to ask a couple of clarifying questions and then generate the requirements, design, and tasks for you

Bug Fix is the one I'd try first. It writes down current behavior, expected behavior, and unchanged behavior. I like how it doesn't change a bunch of files it shouldn't. It basically tells the agent what it is not allowed to touch.

On a feature spec you also get a choice between requirements-first and tech design-first. If you already know your architecture, pick design-first. There's no reason to answer requirements questions you already have answers to.

4. Skills are slash commands

Kiro activates a skill automatically when your prompt matches the skill's description. That works, but I feel like it doesn't always automatically activate.

You can invoke one directly instead. Skills in .kiro/skills/ or ~/.kiro/skills/ show up as slash commands, so a skill named pr-review becomes:

/pr-review

That loads the entire instruction file, not just the description. Works in the CLI and the IDE.

Powers are a different thing and worth knowing about separately. A power bundles MCP server config with steering and optional hooks, and Kiro loads it only when your task is relevant to it. Powers are keyword-activated, and they're free on every plan.

5. You might be running an old build

Open Help > About and check your version against kiro.dev/downloads.

Kiro's own changelog says auto-updates were paused for IDE 1.0.x and tells you to download the latest release directly from the site. So if your version doesn't match what's on the downloads page, that's why, and no amount of restarting will fix it. Reinstalling keeps your settings, extensions, and sign-in state.

On the CLI:

kiro-cli --version
kiro-cli update
kiro-cli doctor      # install and config problems

And /changelog in the CLI inside a chat session shows the release notes inline, which is a nicer way to find out what shipped than scrolling a webpage.

6. The work doesn't have to run on your laptop

One subscription covers the IDE, the CLI, Kiro on the web, ACP-compatible editors, and automation in CI/CD. Same credit pool.

I really like the web version. You kick off a session, it runs in a cloud sandbox, and it opens the pull request when it's done. Your laptop can be closed. There are also Automations, which are cron-scheduled agent runs that open PRs on their own.

Web is still in preview, gated to Pro and above, and it needs a connected GitHub account. There's an iOS app too, but it's early access via TestFlight, Pro or higher, and it's a surface for starting and reviewing cloud sessions rather than an editor. No Android yet.

7. The experimental stuff is opt-in and worth trying

Three of these are behind a flag or a toggle.

CLI v3. Run kiro-cli --v3 and it runs alongside your existing 2.x setup without touching it. You get the spec agent in the terminal:

kiro-cli --v3
/spec new my-feature

Plus capability-based permissions.yaml, standalone hooks in .kiro/hooks/*.json, and markdown agent configs. See the v3 docs for the full list of features.

Agent Focus in the IDE. Toggle it from the button in the top right. The layout flips: parallel sessions down the left, chat in the middle, specs and diffs in a panel on the right. It's a different job than editing files. You're directing several agents and reviewing what they produce. Settings, powers, MCP management, the terminal, and direct file editing all still live in the normal view, so you'll toggle back and forth.

/goal. Give it an objective and a definition of done, and it loops implement-then-verify until the criteria are met:

/goal Migrate the auth module to the new SDK. Done when all tests pass and there are no TypeScript errors.

This is available in v3 CLI.

Default is five iterations, --max <n> raises it, /goal clear cancels. The docs are right that the definition of done is the part that matters. "All tests pass" works. "Make it better" does not. You can interrupt mid-loop, or nudge it without cancelling using queue steering with Ctrl+S.

A few more worth a mention

While I'm listing CLI commands: /rewind forks the conversation at an earlier turn instead of you fighting a thread that went off the rails, and the original session is preserved. /compact summarizes history to free up context. /tangent (Ctrl+T) lets you run commands on the side (like /btw in Claude). /guide is a docs-grounded agent for "how do I do X in Kiro" questions, and it can write agents, prompts, and steering files into .kiro/ for you.

If Shift+Enter for multi-line input has been annoying you, /settings terminal fixes it and backs up your terminal config first.

Where to go when you're stuck

The Kiro Discord is the main support channel, and there's an active subreddit at r/kiroIDE. Note the name, it's kiroIDE, not r/kiro. Billing lives in your account settings. Bugs and feature requests go to the GitHub repo, and /issue in the CLI opens that workflow for you. If you need to send logs along with a bug report, /logdump zips them up.

Which of these did you not know about? Let me know in the comments. Until next time.

Nuxt vs SvelteKit: What works better?

Erik Hanchett — Wed, 22 Jul 2026 01:13:24 +0000

Nuxt vs SvelteKit. Which one is better?

That is is what I've been testing out this week. I built the same app twice. Once in Nuxt with the version 5 compatibility preview turned on, and once in SvelteKit using its experimental remote functions.

I created a basic task app. Where you can add or remove tasks. I also logged the network requests and timing. The biggest thing I noticed was that the SvelteKit app would make one request, when creating a new task, while the Nuxt app needed two.

That one difference turned out to be the most interesting part of the whole comparison, so let's jump in.

The setup

Both apps are a simple task list backed by an in browser memory store. Both are production builds running locally, and both render the initial task list on the server.

Quick caveat, Nuxt 5 is not released yet. My Nuxt app is stable Nuxt 4.5 with the compatibility flag set:

// nuxt.config.ts
export default defineNuxtConfig({
  compatibilityDate: '2026-07-01',
  future: {
    compatibilityVersion: 5,
  },
})

And SvelteKit's remote functions are still marked experimental in the docs. So this is a comparison of directions, not finished products.

The numbers

When I add a task in the Nuxt app, I get a POST to /api/tasks (about 690 ms) followed by a GET to /api/tasks (about 450 ms) to refresh the list. A little over 1,100 ms total, and the timeline panel reports two browser requests.

When I add a task in the SvelteKit app, I get one request. About 1,100 ms. The server still does both operations, the mutation and the read, but they come back in a single response.

Plain refreshes were nearly identical. 447 ms in Nuxt, 448 ms in SvelteKit. I ran this quite a few times, and if I had to pick, SvelteKit felt slightly faster overall. But the totals were close enough that I wouldn't choose a framework based on them.

Let's talk about how requests work in each.

The Nuxt version: explicit API routes

If you've used Nuxt before, this will feel familiar. I have two handlers in server/api:

// server/api/tasks.get.ts
import { defineEventHandler } from 'h3'
import { readTasks } from '../utils/task-store'

export default defineEventHandler(() => readTasks())

The POST handler validates the title and saves the task. These are normal HTTP endpoints. Anything that speaks HTTP can call them.

On the page, useFetch loads the initial data during SSR, so hydration doesn't fetch it again. When I add a task, I post with $fetch and then call refresh():

const { data: snapshot, refresh } = await useFetch<TaskSnapshot>('/api/tasks', {
  key: 'task-dashboard',
})

async function submitTask() {
  await $fetch('/api/tasks', {
    method: 'POST',
    body: { requestId: crypto.randomUUID(), title },
  })
  await refresh()
}

The code is explicit, and the network tab matches the code exactly. POST first, GET second.

Could I avoid the second request? Sure. The POST could return the updated list and I could patch local state myself. I wrote it this way because invalidate-and-refetch is the workflow most of us reach for, and it's exactly the pattern SvelteKit's remote functions are designed to improve. I also find by adding a GET request we are verifying the exact output after the POST.

The SvelteKit version: remote functions

This is the experimental feature. You turn it on in svelte.config.js:

const config = {
  kit: {
    adapter: adapter(),
    experimental: {
      remoteFunctions: true,
    },
  },
  compilerOptions: {
    experimental: {
      async: true,
    },
  },
}

Then you create a file ending in .remote.ts and export your server functions:

// tasks.remote.ts
import { command, query } from '$app/server'
import { addTask as addTaskToStore, readTasks } from '$lib/server/task-store'
import * as v from 'valibot'

const taskInput = v.object({
  requestId: v.pipe(v.string(), v.trim(), v.minLength(1), v.maxLength(100)),
  title: v.pipe(v.string(), v.trim(), v.minLength(1), v.maxLength(80)),
})

export const getTasks = query(async () => readTasks())

export const addTask = command(taskInput, async ({ requestId, title }) => {
  const result = await addTaskToStore(title, requestId)

  // This runs on the server, and the refreshed query value
  // comes back in the same command response.
  void getTasks().refresh()

  return result
})

The function bodies always run on the server. In the browser, they become typed wrappers around endpoints SvelteKit generates for you. I really enjoy how there is no public endpoint to hit, it's isolated. It's created for the call, which means I can use environment variables and secrets in there without thinking about it.

The void getTasks().refresh() line is the API on the server side to trigger the refresh. After the mutation, SvelteKit refreshes the query on the server and packages the new value into the command's response. That's the single-flight mutation, and it's why the network tab shows one request instead of two.

On the page, I just import and call the functions:

<script lang="ts">
  import { addTask, getTasks } from './tasks.remote'

  const tasks = getTasks()

  async function submitTask(event: SubmitEvent) {
    event.preventDefault()
    await addTask({ requestId: crypto.randomUUID(), title })
  }
</script>

{@render dashboard(await tasks)}

That await tasks at the bottom works almost like a subscription. When the server-side refresh happens, the task list updates automatically. No server routes to worry about.

My first look at this pattern, I thought it was a little complicated. But it clicked pretty fast, and the query-refreshes-inside-the-command idea makes sense once you see it in the network tab. If you've used server actions in Next or TanStack Start, this will feel like family. I'd say I still like TanStack Start's server actions a bit better, but this is close.

Heads up: remote functions have been available since SvelteKit 2.27 and they are still experimental. The API has changed several times over the past few months. If you adopt them early, pin your versions and budget time for migrations.

What does Nuxt 5 offer?

Nuxt 5 doesn't have an answer to remote functions. Most of the confirmed work is in the underlying structure. A new version of Nitro, a new Vite integration, and framework internals. The upgrade guide walks through what to expect, and it's mostly foundation work rather than new application-level APIs.

My verdict

I'm sticking with Nuxt. I love the API routes pattern, I love Vue, and nothing in this demo is a reason to rewrite an existing app. You can return updated data from a mutation today and skip the second request yourself if it matters.

But I do miss server actions. Frameworks like SvelteKit, Next, and TanStack Start all have some version of a typed, non-public server function you can call from a component. I hope Nuxt adds something like it in a future update, beyond the server components they have now.

If you're starting a SvelteKit project and can live with an experimental API, try remote functions first. The single-flight mutation is awesome, and the types crossing the boundary for free is a great developer experience.

Which side are you on: explicit API routes, or remote functions that generate the transport for you? Let me know in the comments if you agree or disagree.

BTW, I used Kiro for all my research for this post and video! Check it out , it's an amazing harness!

How I Used Spec-Driven Development to Build a Game (TanStack Start)

Erik Hanchett — Tue, 14 Jul 2026 22:26:53 +0000

I've been deep in spec-driven development (SDD) lately, and I want to walk through what it actually is, then show you how I used it to build a game for Kiro's first birthday.

If you haven't run into spec-driven development, or SDD, don't worry, I got you. We'll cover what it is, where it helps, where it's overkill, and how I used it to make this game!

Would you like to watch a video instead? Check it out!

What is spec-driven development?

SDD breaks down into three phases, and all of this happens before any code gets written.

First you create a requirements document. Then you have your AI editor turn that into a design document. Then, from the requirements and the design, you generate a list of tasks.

The most important part is that there's a human in the middle at every step. You check the requirements. You check the design. You review and edit the tasks that get created. Nothing gets built until you've signed off on the plan.

This isn't set in stone, though. Sometimes the requirements and design get combined into a single document. Other times you run it in a quick mode where all three happen at once. It depends on what you're trying to do. When I work on big features I create all three documents, when I'm trying to do something quick, like a demo, I might just use some sort of quick or plan mode.

The trade-offs

Like anything else, SDD comes with trade-offs.

The thing I like most is the high first-pass success rate. If you actually do your job up front, writing a real requirements doc and a real design, the end product is a lot more likely to be what you wanted.

It's also easier to review. You're breaking a big, complex feature into smaller steps, so you can check each one instead, and push up multiple smaller PRs. And it helps prevent you from going in the wrong direction. Instead of letting the agent run off in a bunch of directions and finding out way too late, you're checking the code after every step or two.

The downside is the up front planning time. SDD takes more time before you see any code, so it's not meant for every task. For throwaway code or a small issue, it's not needed. On the other hand any features that takes more thought it does really well. You give up a little time at the start, and in return you get a more stable, better working app at the end.

The project: a Kiro birthday game

Let me show you what I built.

It's a rogue-like game where you walk around and explore a bunch of buildings. Each building represents a different point in time for Kiro, because this is part of our Kiro birthday celebration. Kiro is turning one. So one building covers when Kiro went generally available, another is the house we had at re:Invent, and so on. Visit all the houses and you unlock a bonus house/section. I thought it would be a fun way to tell Kiro's history.

Under the hood it's Phaser and TanStack Start. Phaser is the gaming library doing the 2D Final Fantasy style look, and TanStack Start is the web library wrapping it all. There's music in there too, which I'll get to.

How I used SDD to build it

I opened up Kiro and told it to use spec mode. You can do this right in the IDE, and as of v3 of the CLI you can use spec mode there as well. Either way, it creates those three documents: requirements, design, and tasks.

I gave it a prompt describing the game. Something like, I'm creating this 2D video game, Final Fantasy style, here are the different classes and names, here are the different buildings we're going to have. From that it generated the requirements in EARS format, which is the classic structure of a user story plus acceptance criteria. As I mentioned earlier, I double checked it at every stage to make sure the docs it created were correct.

From the requirements it built a design. You can skip this part if you'd rather keep everything in one doc, but I like having it. The design got into the technical details. Phaser as the TypeScript library for the front end, TanStack Start with useEffect all over the place, the high-level structure, the scenes, the boundaries, the game shell.

Then came the task list, with every single task broken out. I told it to build an MVP first, so it took the full list and pulled the four most important tasks to the front. I went in and made sure that ordering made sense, had it implement those first four, looked at the output, and confirmed it held up before moving on.

The tools that made it easier

A few things helped a lot here.

I used a couple of MCP servers. Context7 to grab the Phaser documentation, so the agent wasn't guessing at the API. And the Chrome browser MCP extension, so Kiro could open the app, look at it, and make sure it matched the requirements.

I also ran auto mode. I bounced between models, and while Claude 4.8 is great, it does chew through a lot of credits. Auto mode did really well, especially paired with SDD. That's one of the underrated parts of this approach. When everything is already written down in the spec, you don't need the greatest state-of-the-art model to get what you need. Auto mode was more than enough for most of this.

On top of that I used some skills. The AWS Agent Toolkit, plus the Amplify and serverless skills. I ran /aws-amplify and it helped me get the game hosted on Amplify hosting. For the music I used ElevenLabs. I had a scripts folder wired up to a bunch of services, PixelLab for art, ElevenLabs for audio, even Hugging Face. All of it driven from inside Kiro, with a .env file holding the keys, and it generated the assets for me too.

Wrapping up

That's the basic version of my spec-driven development workflow. It's more planning up front, but for a real feature it pays off.

If you want to try the game, check it out!

Do you use spec-driven development in your day-to-day? I'm curious what your experience has been. Take care, and thanks for reading.

TanStack Start vs Nuxt: One Framework to rule them all?

Erik Hanchett — Tue, 07 Jul 2026 21:38:55 +0000

I love Nuxt and I really like TanStack Start. But which one is better? Or are they about the same?

And if they are about the same, does it do anything my Nuxt setup can't, and is that worth leaving Vue for React? So I decided to build the same app in both frameworks and take a look. Read on below to find out!

If you'd rather watch a video, check out the video on the same topic!

The app

In both frameworks I built a small GitHub user lookup app. You type a username, the profile gets fetched on the server, and the username lands in the URL as a ?user= query param so the result is shareable. Type ErikCH, hit enter, and the card renders. Refresh the page and it's still there. It has the same behaviour so the difference lies in the code.

Difference one: server functions vs server routes

On the Nuxt side we call a server route from useAsyncData. Server routes are the more idiomatic way to use Nuxt to call things on the server.

<!-- app/pages/index.vue -->
<script setup lang="ts">
import { z } from 'zod'
import type { GithubUser } from '~~/server/api/github.get'

definePageMeta({
  props: route => z.object({ user: z.string().default('') }).parse(route.query),
})

const props = defineProps<{ user: string }>()
const router = useRouter()
const input = ref(props.user)

const { data, error } = await useAsyncData(
  'github-user',
  () =>
    props.user
      ? $fetch<GithubUser>('/api/github', { query: { user: props.user } })
      : Promise.resolve(null),
  { watch: [() => props.user] },
)

function lookup() {
  router.push({ query: { user: input.value.trim() } })
}
</script>

The props option on definePageMeta maps the query into a typed page prop and re-runs on client navigation. useAsyncData fetches when there's a username and refetches whenever it changes. The conditional that returns Promise.resolve(null) skips the request on an empty query param, (or when you first load).

The server route does the outbound call:

// server/api/github.get.ts
import { z } from 'zod'

const querySchema = z.object({
  user: z.string().trim().min(1, 'Missing ?user='),
})

export default defineEventHandler(async (event): Promise<GithubUser> => {
  const { user } = await getValidatedQuery(event, querySchema.parse)
  return $fetch<GithubUser>(
    `https://api.github.com/users/${encodeURIComponent(user)}`,
  )
})

getValidatedQuery runs the schema and hands back a typed, validated user. A bad shape, like an array or an empty string, gets a 400 before the handler runs.

TanStack Start takes a different route. There's no separate API endpoint. You write a server function and call it directly from the loader.

// src/routes/index.tsx
import { createServerFn } from '@tanstack/react-start'

const getGithubUser = createServerFn({ method: 'GET' })
  .inputValidator((username: string) => username)
  .handler(async ({ data: username }): Promise<GithubUser> => {
    const res = await fetch(
      `https://api.github.com/users/${encodeURIComponent(username)}`,
    )
    if (!res.ok) throw new Error(`GitHub API error: ${res.status}`)
    return (await res.json()) as GithubUser
  })

One API covers reads and writes. This same createServerFn handles a GET here, and it would handle a POST mutation the same way, called from a loader or straight from a component. The return type flows through to the caller with no manual annotation.

The route wires it up:

const searchSchema = z.object({ user: z.string().catch('') })

export const Route = createFileRoute('/')({
  validateSearch: searchSchema,
  loaderDeps: ({ search: { user } }) => ({ user }),
  loader: async ({ deps: { user } }) => {
    if (!user) return { user: null, error: null }
    return { user: await getGithubUser({ data: user }), error: null }
  },
  component: Home,
})

validateSearch defines the query, loaderDeps narrows it to just what the loader needs, and the loader runs on navigation, a lot like script setup running when a Nuxt page loads.

Between the two, I really like TanStack and it's server functions. I don't have to worry about another end point being exposed to the internet, and it's simple to use. Though both work for a lot of different scenarios.

Server components in both

Both frameworks also let you skip the client entirely with server components, and both still label the feature experimental.

Nuxt calls them islands. You flip one flag in nuxt.config.ts:

export default defineNuxtConfig({
  experimental: {
    componentIslands: true,
  },
})

Then a component named with a .server.vue suffix renders only on the server. It can call useFetch directly, and no client-side JavaScript ships for it. Basically you embed the server component in a client component and that's it.

<!-- app/components/GithubUserCard.server.vue -->
<script setup lang="ts">
import type { GithubUser } from '~~/server/api/github.get'

const props = defineProps<{ user: string }>()

const { data, error } = await useFetch<GithubUser>('/api/github', {
  query: { user: props.user },
})
</script>

The card fetches on the server and streams its HTML into the page. When ?user= changes, Nuxt refetches the island in place. The GitHub response never lands in the browser bundle, which is nice to help reduce bundle size.

TanStack Start added server components too, back in April. They're also experimental, and from the docs they look pretty different from the Next.js version people know, built around a readable-stream API. I tried it and found it more complicated than the Nuxt island, so for this app I stayed on the server function.

Of everything here, the server function is still my favorite. Server routes earn their place when something outside your app needs to call in, like a webhook, or some sort of callback. For the rest, the function felt better and cleaner.

Typed search params

This is where TanStack Start made me a little jealous.

Because validateSearch puts the query schema on the route itself, the user param is typed everywhere it shows up. Not only in the component, but in navigation and links.

// Typed against the route's search schema:
navigate({ search: (prev) => ({ ...prev, user: input.trim() }) })

<Link to="/" search={{ user: 'ErikCH' }}>Look up</Link>

Pass a key that isn't in the schema and you get a red squiggle before you save. Delete the target on a <Link> and the editor lists the real routes, because the routes are typed as well. I could see me using this all over, and if you're using an agent to help code, this will help catch the errors even quicker.

Nuxt gets you close, with two caveats. Turn on experimental.typedPages and your <NuxtLink> routes are typed, so that half matches. With the props plus Zod pattern above, the user value reaching your component is typed and validated too. What Nuxt doesn't give you yet is the query itself typed on the link. You can type the prop, but not the ?user= on a <NuxtLink>.

If you are on the Nuxt team, does anyone know a workaround? Leave a comment? I'd love a typed-query-params story on the router in Nuxt.

What they actually share

Interesting enough, both of these frameworks share a lot. Both build on Vite, so both dev servers start are super fast. Both run on Nitro for the server layer, which adds a lot of flexibility when deploying to different places. Overall in that sense they are very similar.

One practical thing to weigh. As of this recording TanStack Start is still a Release Candidate (RC), so expect a few rough edges and bugs. Nuxt is on 4.4.x, production-hardened, with a modules ecosystem for images, i18n, SEO, and a lot that TanStack Start doesn't have yet.

The verdict

So, should a Nuxt developer switch? For me, no, at least not today. I'm staying on Nuxt. I like Vue, the framework is mature, and TanStack features are nice, but not enough for me to move over (specially since it's still React).

If you're already a React developer, or starting something new in React, TanStack Start is genuinely fun and I'd reach for it. React fans will feel at home in TanStack Start, Vue fans in Nuxt. I'll keep an eye on TanStack Start and pull it out for the odd project every now and then.

One last note. I did all the research for the video and this post in Kiro, an agent that works on the IDE, CLI and Web.

If you've run both, tell me which way you'd go in the comments.

DEV Community: Erik Hanchett

Jev 101: How I'm Using It Today in My Apps

What a request actually looks like

Three question types

App one: gating a pull request

OpenRouter versus calling TypeSafe directly

App two: AWS workload

Schema validity

What other people are doing with it

Would I use it

Links

Frontend Isn't Dead. But the Job Title Is Changing

Job posting show an interesting story

Why

The skills moved to meta frameworks

So what to do?

Conclusion

Sources

Would You Choose a Library Because AI Writes It Better?

Put expected failures in the type system with Effect

Put visual states behind a typed API with StyleX

Decide who your stack is optimized for

Finale

10 MCP Servers Worth Adding to Your AI Coding Workflow in 2026

Introduction

Prerequisites

Steps: the 10 MCP servers worth considering

1. Context7

2. Chrome DevTools MCP

3. Playwright MCP

4. GitHub MCP Server

5. Serena

6. Supabase MCP

7. AWS MCP Server

8. Vercel MCP

9. Cloudflare API MCP

10. Excalidraw MCP

What about Canva and Figma?

Three popular names I left off

Puppeteer MCP

Memory reference server

TanStack Intent

Finale

Build a Full-Stack Music Station with OpenRouter, Amazon Bedrock, and Nuxt

Prerequisites

Steps

1. Run the station without credentials

2. Put provider calls behind Nuxt server routes

3. Generate a scene with Amazon Bedrock

4. Add looping music with ElevenLabs

5. Deploy the private media library

6. Turn one illustration into a seamless video loop

7. Report real progress during a long request

8. Validate the build

Cleanup

Finale

How to Build an AI Agent That Asks Permission First (Nuxt + AI SDK 7)

Introduction

Prerequisites

Step 1: Create the Nuxt app

Step 2: Keep the file tool inside a fixture directory

Step 3: Connect the route to Amazon Bedrock

Step 4: Add approval to the delete tool

Step 5: Render the approval request in Nuxt

Step 6: Put Kiro CLI behind the same Nuxt UI

Step 7: Keep approval in its lane

Cleanup

Finale

References

Nuxt 4.5 SSR Streaming Is Kind Of A Big Deal

Prerequisites

Feature 1: Experimental SSR streaming

Create a controlled slow component

Enable streaming in production

Compare the responses

Check the production constraints

Feature 2: Read the resolved layout with useLayout()

Feature 3: Render multiple outlets with named views

Finale

Resources

Feature 2: Read the resolved layout with `useLayout()`

2. The `#` menu is bigger than `#file` in the IDE