DEV Community: Erik Hanchett

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.

Loop Engineering: Do Frontend and Fullstack Devs Actually Need It?

Erik Hanchett — Tue, 30 Jun 2026 17:59:18 +0000

Introduction

I keep hearing the term loop engineering. It's all over my feed, every AI newsletter, half the dev videos I open. So I had the same question you probably have. Is this actually important, and do I need to learn it as a frontend or fullstack developer?

I spent some time with it and made a video breaking down what it is and where it fits. This post is the written version, with a practical example you can copy.

What loop engineering actually is

Here's how I think about it. You give your coding agent a goal, and it runs over itself again and again, almost recursively, until that goal is met.

You can also frame it as four parts. You give the agent a trigger or a system prompt with a clear ending state. It acts on that trigger. It observes to check whether the work is actually done. If it hits the stop condition, it stops. If it doesn't, it goes around again.

That's basically it. The idea is that you are defining a goal and a stop condition, then letting the agent close the gap on its own.

It's the agentic loop you already know

If you've built anything with agents, this should feel familiar. It's the classic agentic loop. You give an agent a set of tools, and it uses those tools with its own reasoning to reach an answer.

Say I want to research the latest tech trends. I give the agent a tool to search Google and a tool to search Reddit. On the first pass it searches Google and pulls what it finds. That isn't enough, so it loops again and pulls from Reddit. Then it combines both and hands the answer back to me.

You've seen the same thing in a chatbot. Ask it for the weather and it might call a few tools, look at the context of your question, and come back with what you asked for. Loop engineering is that pattern, pointed at your actual work.

A practical example: fixing a PR on a loop

Let me show you where this earns its place day to day.

I had a pull request that I pushed up using Kiro Web. It connected straight to my GitHub repo, I gave it an action, and it opened the PR for me. You can do this with Claude Code, Cursor, and other agents too.

Then I noticed some tests were failing in my CI/CD pipeline. My GitHub Actions were red. So I gave it one prompt:

Fix all issues on the PR. Keep going until it's all fixed.

That last sentence is the stop condition. Kiro went to work in the background, running again and again, fixing the failures and looping until everything passed. I didn't babysit it through each round.

Tests are a great place to start with this, because the pass or fail signal gives the loop a clear way to check its own work.

Automations are the other big use case

The other place loops shine is on a schedule. Addy Osmani wrote a great article on loop engineering where he points out that automations running on a schedule, doing discovery and triage on their own, are a strong fit for this.

If you can find work that a cron job or a scheduled tool can kick off every day, that's a candidate. A couple of examples:

At the end of every day, run all the tests, and if anything is broken, let the agent fix it. Or keep your documentation current. The loop checks the docs against the latest code and keeps going until they match.

If you use Claude Code, there's a /loop command and a /goal command worth knowing. They let you set up in-session scheduled work, and /goal lets you set a persistent, verifiable objective instead of a single one-off task. You can do the same thing in Kiro and other tools, you just have to be more explicit and write your own system prompts to drive it.

My take

Now the part where I push back a little.

Don't tear up your whole workflow to jam loops in everywhere. There are real spots where they make sense, especially when your agent supports them and you've found an automation worth setting up. But I still think spec-driven development and plain back-and-forth vibe coding will solve most of your problems day to day. Loops are a tool to reach for in the right moment, not a religion.

If you want to go deeper, three people shaped how I think about this. Kent C. Dodds made an excellent video on what he's discovered and how he works this way. Theo did a great one too. And Addy Osmani's article on loop engineering is worth your time.

So I'll ask you what I asked at the end of the video. On your next project, are you going to try loop engineering? Or is it just hype? Let me know.

Resources:

3 Tools That Make AI Suck Less at Coding

Erik Hanchett — Mon, 22 Jun 2026 00:47:45 +0000

I've completely updated my workflow, and I use AI coding agents for everything. Writing code, testing, and just helping me be more productive. However, AI isn't perfect and often after a long back-and-forth session I'll have working code, but it will have a few code smells. Duplicated code, dead-end code, lengthy functions are common. One way to fix that is to add all these problems to an AGENTS.md file and that works. But that's not always possible, depending on the codebase and team I'm working with.

To that end, I went looking for tools that could help me detect and fix these issues. And so after some research I found three tools that could work almost as a pipeline. One finds these issues, one reviews the changes before they ever reach a pull request, and one helps me evaluate my agents. I use Kiro for most of my day to day, so I wired all of these into that loop, but they run with whatever agent you already have.

If you'd rather watch than read, here's the full walkthrough:

This post covers:

Finding dead code and duplication with Fallow
Reviewing the AI's diff with CodeRabbit before you open a PR
Measuring whether the output improves with Kiln

Prerequisites

Node.js 20 or newer, so you have npx
A JavaScript or TypeScript project, ideally one with some AI-generated code in it
A coding agent like Kiro, Claude Code, or Cursor for the review-loop parts
Git, for the diff-based workflows

Find the mess: Fallow

The first problem I've seen often is that AI can generate a mess of code. It will duplicate a block, leave an orphaned file behind, and grow a function to a thousand lines without ever flagging it, because each individual edit looked reasonable in isolation. You need a tool that reads the whole codebase at once.

Fallow is the one I reached for. It's static codebase intelligence for JS and TS, and it works a lot like ESLint, except it's built around these common AI code issues. You can run it with:

npx fallow

That gives you a full report. The sections I care about most are dead code, duplication, and complexity. Dead code finds files that aren't reachable from any entry point, exports nothing imports, and dependencies you've stopped using. When I ran this on my vibe-coded chess app (see video) it found dozens of these problems Duplication shows you the exact line ranges that got copied between two places. Complexity scores each function on how branchy and how hard to test it is, then ranks your worst offenders so you know where to start.

There's a fix command for most things:

npx fallow fix

If you'd rather have an agent fix it you can use a JSON output and the skill. Run it with --json and you get structured findings an agent can read and act on. Fallow also ships an agent skill you can install:

npx skills add fallow-rs/fallow

Once that's in place, I can tell Kiro to build a feature and then run Fallow on its own work to clean up after itself. It catches the duplicate block it just wrote and removes it before I even see it. You can also drop fallow audit into CI so it compares your branch against main and only flags what your change introduced.

Bonus: Knip

If Fallow is more than you need, Knip does the dead-code half on its own and has been around longer. It finds unused files, dependencies, and exports in JS and TS projects in one command:

npx knip

I've found knip to be a little slower then Fallow. YMMV.

Review the diff: CodeRabbit

Finding dead code is great, but what about reviews?

CodeRabbit puts a review step back in. It's AI code review that runs on your diff, and the version I like runs locally from the CLI so it happens before the PR exists. Install it with one line:

curl -fsSL https://cli.coderabbit.ai/install.sh | sh

Then point it at your uncommitted changes:

coderabbit review --plain

It reads the diff and comes back with specific findings. It also hands you a fix prompt you can paste straight back into your agent, so the loop closes quickly.

Jack Herrington made the point in his video that lower-end models get noticeably more useful once CodeRabbit is in the loop, because the review catches what the cheaper model missed. That makes sense to me. The agent writes, CodeRabbit reviews, the agent fixes.

Measure the improvement: Kiln

The first two tools clean up individual changes. This last one answers a bigger question. When I tweak a prompt, swap a model, or add a skill, is my agent's output actually better, or does it just feel better because the last three runs went well?

Kiln is the tool I use to stop guessing. It's built for creating and evaluating AI systems, so you set up datasets, run evals, and compare results across changes.

For my use case, I connected it to some output a LLM was producing. I ran an eval on it to make sure it was as I expected. When I added the Fallow skill, I could iterate on the system prompt and strings. It's the same instinct behind writing tests for your code, pointed at the thing generating the code.

This is the least flashy of the three and the one I'd skip first if you're in a hurry. But if you're serious about tuning a workflow you'll use every day, measuring beats vibes every time.

How to pick

You don't have to use all three, so here are some good guide lines for each:

If your agent leaves dead code and duplication everywhere, start with Fallow, or Knip if you want something smaller.
If you need more code reviews, add CodeRabbit and let it review before you do.
If you're tuning prompts, models, or skills and want proof you're improving, set up Kiln.

Keep in mind these tools don't replace knowing what good code looks like. They raise the floor on what your AI ships so the version that lands in your editor is closer to something you'd have written yourself. That's extremely important. AI made writing code fast, and it made reviewing code the bottleneck. These three move that bottleneck.

Conclusion

AI compresses how long it takes to generate code and stretches how long it takes to trust it. Fallow and Knip find the mess it leaves behind, CodeRabbit reviews the change before it slips past you, and Kiln tells you whether any of your tuning is working.

If you want to see these running inside a real agent loop, I walk through all of them in the companion video.

Resources:

The most popular AI coding skills right now

Erik Hanchett — Mon, 15 Jun 2026 17:04:07 +0000

Introduction

It's crazy to me that some GitHub repos, that were just created in the last year, have more stars then some of the most popular programming frameworks out there. At the time of writing, Superpowers, is around 226,000, ahead of the Vue repo and way ahead of Next.js. A separate repo based on Andrej Karpathy's coding advice has 174,000. And they aren't even code. They're folders of markdown files that tell your AI coding agent how to write software better.

In other words these are agent skills, and they've blown up over the past year into one of the most-starred new categories of developer tooling. The format started at Anthropic, a SKILL.md file with a short description and a set of instructions, and now it works in Claude Code, Kiro and all your other favorite coding agents.

This post is a tour of some of the skills I find most interesting that people are using everyday. I'll be in Kiro for most of this, but these run in whatever agent you already have, with install paths that vary per agent.

This post covers:

What an agent skill actually is
The big workflow skills (Superpowers, Karpathy, Matt Pocock, GStack, GSD)
Framework skills and the "ships with your package" model
The Agent Toolkit for AWS
How to pick one and try it safely

If you like, you can watch a full video on the subject instead! Also if nothing else, please check out the Agent Toolkit for AWS! More information below. Full disclosure, I'm a developer advocate for AWS

What is an agent skill?

A skill is a directory with a SKILL.md file inside it. The file has a name, a one-line description, and instructions. These instructions include which steps to follow, which APIs to call, which mistakes to avoid and how to check the result.

Skills should only run when needed. Your agent reads the short description, decides if the skill is relevant to what you asked, and only then loads the full instructions. Reference files load on demand after that. So you can have fifty skills installed and your context window stays clean, because the agent pulls in the two it needs and ignores the rest. In practice, I've found I still need to manually tell my agent to run the skills by using the / command and the skill name. YMMV

The big workflow skills

Most of the popular general-purpose skills are trying to fix the problem agents often have, going in the wrong direction. Agents when left alone often rush in, touch too many files, and they skip planning. These five take different approaches to slowing it down.

Superpowers (obra/superpowers)

Superpowers is the most-starred of the bunch and the most opinionated. It is a full development methodology that triggers automatically. It really reminds me of a super powered Spec-Driven Development (SDD) workflow.

The moment the agent sees you are building something, it stops and asks what you are actually trying to do. It works a spec out of the conversation, shows it to you (optionally in a web browser), and only after you sign off does it write an implementation plan. Then it hands the plan to subagents that build and review each other's work. Be aware, this can eat up a lot of tokens.

It is available through the official Claude plugin marketplace, plus Codex, Cursor, Gemini CLI, and a handful of others. You can also get it working with Kiro by from Skills.sh. Though, I'd probably skip it if you're using Kiro, since most of the SDD is already there in Kiro.

If you want one system that owns the whole loop from idea to reviewed code, this is the one to reach for. In Claude Code, install it from the official plugin marketplace:

/plugin install superpowers@claude-plugins-official

The Karpathy guidelines (multica-ai/andrej-karpathy-skills)

This one is almost the opposite. It is a short file of behavioral rules, now at 174,000 stars. Andrej Karpathy did not write it, despite the name, which I find really funny. It is a community-built file derived from a January post where Karpathy listed the ways LLM coding agents tend to fail, and the repo later moved to the multica-ai org.

The rules come down to four simple ideas. Think before coding, keep it simple, make surgical changes, and stay focused on the goal. If Superpowers feels like too much process for you, this is the low-commitment starting point. It is a single CLAUDE.md (or AGENTS.md, or you can use it as a Skill), so the simplest install is to drop it into your project:

curl -o CLAUDE.md https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md

Personally, I'm not sure if this is worth it in my own testing. However, it's easy enough to add it to your own CLAUDE.md or AGENTS.md so give it a shot though and make your own opinion.

Matt Pocock's skills (mattpocock/skills)

Matt Pocock's collection sits in the middle and takes a deliberate stance against the all-in-one systems. In fact, he's often said he doesn't like SDD, and thinks it's too cumbersome. His framing is that approaches which own your entire process also take away your control and make bugs in that process hard to fix. So his skills are small, composable, and easy to adapt. You install the ones you want with the Vercel skills CLI:

npx skills@latest add mattpocock/skills

His most popular one, and the one I like the most, is the grill-me, which makes the agent interview you about what you are building before it writes anything. There is a more powerful version, grill-with-docs, that does the same interview and also builds a shared-language document for your project. The repo's pitch is that this shared-language document pays off across sessions. There is also tdd for a red-green-refactor loop, diagnose for debugging, and improve-codebase-architecture for rescuing a project that has turned into spaghetti.

Another skill called caveman helps reduce token costs. I find the caveman and grill-me skills the most useful. Though, I find grill-me a little annoying after a while, when I just want to get something done.

GStack (garrytan/gstack)

GStack is Garry Tan's Claude Code setup, and at nearly 110,000 stars it is one of the most popular skill collections out there. Instead of one mode that handles everything, it gives the agent distinct roles, each behind its own slash command. It has product vision, designer, engineering manager, release manager, doc engineer, QA, and post-launch retrospective. It is the same genre as Superpowers, a full workflow, but organized around the roles on a software team rather than a sequence of phases. If you think in terms of "who would handle this part," GStack maps to that mental model nicely. It installs with a clone and a setup script (pass --host kiro, --host cursor, and so on for other agents):

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

It also works with Kiro nicely.

GSD Core (open-gsd/gsd-core)

GSD Core (Git. Ship. Done.) is a spec-driven system that pitches itself as a fix for context rot, the slow drop in quality as your context window fills up during a long session. It breaks work into atomic plans that run in fresh context windows, keeping the main session light while subagents do the heavy lifting. It targets more than a dozen agents. The project moved from the old gsd-build org to its current home at open-gsd/gsd-core, and the installer prompts for your runtime:

npx @opengsd/gsd-core@latest

While using this, I found that it burned through tokens fast. It also takes over your whole workflow, that I disliked. Still, it's worth trying out to see if it works well for your own personal projects.

Framework skills and the "ships with your package" model

The skills above are framework-agnostic. The more interesting development for frontend folks is skills that know your specific stack.

The Vue community moved early here. vuejs-ai/skills is a community Vue 3 skills project (the README notes the author may propose transferring it to the Vue org), and its vue-best-practices skill is a structured workflow covering the Composition API, reactivity, and the patterns you want a model to follow. Anthony Fu's collection covers Vue, Vite, Nuxt, Pinia, VueUse, and Vitest. Both install through the same CLI:

npx skills add vuejs-ai/skills
npx skills add antfu/skills --skill='*'

The newer idea is shipping skills inside the package itself. Three things are worth knowing:

skilld generates version-aware skills from the npm dependencies you already have, pulling from docs, release notes, and GitHub issues. It solves the problem where a model's training cutoff means it writes last year's version of your library.
TanStack Intent (@tanstack/intent) flips that around for maintainers. It lets library authors generate and ship SKILL.md files inside their npm package, versioned with each release, so the skill updates when the library does. It launched recently and ties straight into the TanStack ecosystem.
The Vercel skills CLI is the npx skills tool that installs any of this across 70-plus agents. If you use Kiro, it loads skills from .kiro/skills/ automatically with no config, which makes it an easy way to try things on camera or in a real project.

Here is each of those three:

# Generate version-aware skills from your installed npm dependencies
npx -y skilld

# Library maintainers: scaffold SKILL.md files inside your own package
npx @tanstack/intent scaffold

# The universal installer used throughout this post — pattern is `npx skills add <owner/repo>`
npx skills add vercel-labs/skills

The Agent Toolkit for AWS

AWS ships skills too, in the same open format, so they run in Kiro, Claude Code, Cursor, and Codex.

The Agent Toolkit for AWS was announced in May 2026 and is the officially supported way to bring AWS expertise into your agent. It pairs plugins for Claude Code and Codex with a curated collection of skills and the AWS MCP Server, which reached general availability on May 6, 2026. The toolkit covers areas like deployment, serverless, and database work. Setup is per-agent. In Kiro you add the AWS MCP Server through your MCP config and then pull in skills with npx skills:

# Install AWS-curated skills via the universal CLI
npx skills add aws/agent-toolkit-for-aws/skills

If you are building on AWS, you should download this. Even if you are not using AWS I would download it for the future. Because with this the agent loads service-specific guidance instead of guessing at an API it half-remembers from training.

How to pick one and try it safely

Personally, I would use Matt Pococks skills and try out one of the other larger skill workflows like Superpowers. See if it works for you. Then pair it with a framework specific skills as well.

Last thing, and it matters. A skill is instructions you are dropping into your agent's context, so treat it the way you treat an npm dependency. Read the SKILL.md before you install it. A repo with 100,000 stars is popular, but stars are a popularity signal, not a quality review. Skim the file, see what it tells your agent to do, and keep the ones that match how you actually work.

Conclusion

Agent skills went from a quiet Anthropic format to repos with more stars than the frameworks we build on, and it makes sense why. They take the patterns a good engineer carries in their head and hand them to the model at the start of every task. The big workflow skills give you structure while the framework skills give you correctness, and the AWS plugins give you service-specific knowledge you would otherwise paste in by hand.

My advice: install one, read what it actually tells the agent, and see if the output matches how you'd have built it yourself. That's the real test, and it's the one only you can run. If you want to see these in action, I walk through them in the companion video.

DEV Community: Erik Hanchett

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

How To learn Web Development in 2026

Start with a goal, not a curriculum

Decide how much you actually need to know

Ask three models what they'd build today

Get a personalized learning path

Build it: I do, we do, you do

I do: let it build, then read it

We do: spec-driven development

You do: turn it off

Two more patterns worth stealing

Where I've landed

7 Kiro Features You're Probably Not Using

1. Stop approving every single command

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

3. Pick a workflow instead of freeform chatting

4. Skills are slash commands

5. You might be running an old build

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

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

A few more worth a mention

Where to go when you're stuck

Nuxt vs SvelteKit: What works better?

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

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