DEV Community: Erik Hanchett

Nuxt CLI v4 Is Great for AI Coding Agents

Erik Hanchett — Wed, 04 Nov 2026 18:59:04 +0000

Have you ever had a dev server running, and then asked your coding agent to test something in that app? It starts its own server on port 3001. Then it restarts that one, and you end up with another on 3002. Pretty soon you've lost track of what's running on which port and what you need to stop...

Nuxt CLI v4 shipped alongside Nuxt 4.6 in early October, and a few of its new features fix that exact problem. The Nuxt team pitched this release as a speed and dev experience update. Nuxt's own numbers put the CLI install at 3.5 MB (down from 13.1 MB) and first paint for nuxt dev at 50 ms (down from 330 ms). However, what I'm really interested in is some of the agentic features.

I tried them on a small Nuxt 4.6.4 todo app. Here's the video if you'd rather watch:

Prerequisites

Node.js 22.21+, 24.11+, or 26+. CLI v4 won't run on older versions.
A Nuxt project on 4.6 or later. CLI v4 is a dependency of nuxt, so upgrading Nuxt gets you the new CLI. I tested nuxt 4.6.4 with @nuxt/cli 4.0.3.
Optional, a coding agent that can run shell commands.

1. Meet the new nuxt dev

Run npm run dev and the first thing you'll notice is the panel pinned to the bottom of your terminal. It shows your Nuxt version, the local URL, a request counter, and a row of single-key shortcuts.

The new nuxt dev panel. Each letter at the bottom is a shortcut.

r restarts the server, o opens it in the browser, i shows info about your setup, and n lists every request with its status and timing. Press p for all your pages and server routes. If you'd rather have plain log output, nuxt dev --no-tui turns the panel off.

2. Check the lock file

When nuxt dev starts, it writes .nuxt/nuxt.lock. When you stop the server, the file goes away. Here's mine:

.nuxt/nuxt.lock has everything an agent needs to find the running server.

The PID, port, and URL tell an agent that a server is already up and where to find it. It doesn't have to probe ports or guess at localhost:3000.

The interactive field records whether the server was started from an interactive terminal. Nuxt uses it to decide what happens when a second nuxt dev shows up. In my testing, a server started from a real terminal wouldn't hand itself over to a non-interactive nuxt dev (the kind an agent runs). The agent gets a message pointing it at --takeover instead. A server that was started non-interactively gets taken over on the same port, so an agent that restarts its own server doesn't leave the old one running.

3. Run nuxt dev a second time

If you run npm run dev again while a server is up, Nuxt stops and asks what you want:

Taking over stops the running server. Start anyway gives you a second one.

Take over stops the running server and starts yours on the same port. That's the --takeover flag. Start anyway runs a second server, which you can also force with NUXT_IGNORE_LOCK=1. Nuxt calls that unsupported.

The CLI already warns an agent about all of this, but I still wanted the rules written down. So I added a steering file at .kiro/steering/nuxt-dev-server.md. If you use a different agent, put the same thing in AGENTS.md.

---
inclusion: always
---

# Nuxt dev server rules

This project uses Nuxt 4.6 with Nuxt CLI v4.

- Never start a second `nuxt dev`. A dev server is usually already running. Check `.nuxt/nuxt.lock` for its URL.
- Never pass `--takeover` or set `NUXT_IGNORE_LOCK=1` unless I ask.
- To test API routes, use `npx nuxt curl <path>` (add `-X`, `-d`, `-i` as needed). It finds the running server without a port.
- To run Nitro tasks, use `npx nuxt task list` and `npx nuxt task run <name> --payload.<key>=<value>`.
- Before using a Nuxt API you are unsure about, run `npx nuxt docs "<query>"` to read the docs for the installed version.

4. Test routes with nuxt curl

If the agent can't start its own server, it still needs a way to test things. That's what nuxt curl is for.

npx nuxt curl /api/todos

No host, no port. nuxt curl reads the lock file.

You pass a path, not a URL. nuxt curl reads the lock file, finds the running server, and pretty-prints the JSON it gets back. It takes the usual curl flags too, so a POST looks like this:

npx nuxt curl /api/todos -X POST -d '{"title":"Added by nuxt curl"}'

Add -i to see the response headers. If no server is running, it tells you to start one with nuxt dev or pass an absolute URL.

5. Run Nitro tasks with nuxt task

The other command I liked is nuxt task, which runs Nitro tasks against the running server. Tasks are still experimental in Nitro, so turn them on in nuxt.config.ts first:

export default defineNuxtConfig({
  nitro: {
    experimental: { tasks: true },
  },
})

My app has a seed task in server/tasks/db/seed.ts that resets the in-memory todos:

export default defineTask({
  meta: {
    name: 'db:seed',
    description: 'Replace the in-memory todos with N seeded todos',
  },
  run({ payload }) {
    const count = Math.min(Math.max(Number(payload?.count) || 5, 1), 100)
    const todos = resetTodos(count)
    return { result: `Seeded ${todos.length} todos` }
  },
})

Then list and run it from the terminal:

npx nuxt task list
npx nuxt task run db:seed

I forgot the run subcommand the first time. The help output got me there.

You can see I typed npx nuxt task db:seed first and got an error. It needs run. Pass a payload with --payload.count=10 and you get 10 todos instead of the default 5.

6. Hand errors to your agent

I really like this the most, because I run into this all the time! In my example my app has a /profile page that's broken on purpose:

<script setup lang="ts">
const user = { name: 'Erik', profile: null as null | { handle: string } }
const handle = user.profile!.handle.toUpperCase()
</script>

Load it and Nuxt shows the new error overlay. You get the error, the exact line in profile.vue, a toggle between source and compiled code, and a call stack with the 9 framework frames hidden by default.

The Copy error menu has an option written for agents.

The new part is the Copy error menu. Copy as Markdown and Copy structured JSON do what they sound like. Copy prompt for an agent wraps the error, source location, Node version, and runtime details in instructions to diagnose the error, trace the root cause, and explain the failure.

I pasted that prompt into Kiro, running Claude Opus 5.5, and let it go. Because of the steering file, it didn't start a server. It ran npx nuxt curl /profile to confirm the 500, changed the non-null assertion to optional chaining and added a v-if so the template skips the missing handle, then ran nuxt curl again to confirm a 200.

Kiro checked its own fix with nuxt curl against my running server.

The whole thing took about 36 seconds and one credit.

Wrap up

I'm really liking this new version of Nuxt CLI! I'd like to see more frameworks do this. Have you had an agent take over your dev server, or start five of them? Let me know in the comments.

Vite+ 1.0 Is Out. You Don't Need ESLint or Prettier Anymore

Erik Hanchett — Wed, 28 Oct 2026 14:48:04 +0000

Do you still need ESLint and Prettier? The team behind Vite+ says no. Vite+ 1.0 shipped on September 28, and it puts Vite, Vitest, linting, formatting, Git hooks, and Node.js version management behind one CLI called vp and one vite.config.ts.

I wrote about Vite+ back in March when it was still in alpha. It's grown up a lot since then. It's MIT licensed, it's stable, and it's close to 2 million weekly downloads. So I took a small Vue app that uses the usual pile of tools and migrated it to see how much of it Vite+ could swallow.

If you'd rather watch, here's the video:

(Full disclosure: I'm a Developer Advocate at AWS, and Kiro is an AWS product. I use it to finish the migration below, but Claude Code or Codex would do the same job.)

What Vite+ replaces

Vite+ comes from VoidZero, the team behind Vite, Vitest, Rolldown, and Oxc. It isn't a new framework and it doesn't replace Vite. It ties a set of tools together and tests them as one stack, so a single vite-plus dependency takes the place of packages like eslint, prettier, vitest, tsup, and turbo.

The commands map to those tools:

vp check formats, lints, and type checks in one pass with Oxfmt and Oxlint
vp test runs Vitest
vp dev and vp build run Vite 8 with Rolldown
vp env manages your Node.js version
vp migrate moves an existing project over

The Oxc tools are written in Rust. VoidZero says Oxlint runs 50x to 100x faster than ESLint and Oxfmt is up to 30x faster than Prettier. I didn't benchmark those claims, but I'll share the times I saw later.

Prerequisites

macOS, Linux, or Windows. I'm on Windows Subsystem for Linux (WSL) with Ubuntu 24.04.
An existing Vite project. Mine is a Vue 3 app, but React and other frameworks work too.
A clean Git working tree. vp migrate edits a lot of files, so commit first.
Optional, a coding agent to clean up whatever the migration misses.

The project before Vite+

My test app is a vibe-coded park planner where you save trips and the parks you want to visit. It started out with a pretty typical setup. ESLint for linting, Prettier for formatting, vue-tsc for type checks, Husky and lint-staged for the pre-commit hook, pnpm as the package manager, and separate vite.config.ts and vitest.config.ts files.

That's a lot of config to keep in sync. Here's the scripts block from package.json:

"scripts": {
  "dev": "vite",
  "build": "run-p type-check \"build-only {@}\" --",
  "preview": "vite preview",
  "test:unit": "vitest",
  "build-only": "vite build",
  "type-check": "vue-tsc --build",
  "lint": "eslint . --fix --cache",
  "lint:check": "eslint .",
  "format": "prettier --write src/",
  "format:check": "prettier --check src/",
  "prepare": "husky"
}

Every one of those tools has its own release cadence and its own upgrade guide. I also use NVM to switch Node versions, since I jump between a lot of projects for videos.

1. Install Vite+

On macOS or Linux, run the install script from viteplus.dev:

curl -fsSL https://vite.plus | bash

On Windows, use PowerShell instead:

irm https://vite.plus/ps1 | iex

The installer asks if you want Vite+ to manage Node.js for you. I said no to this during the alpha because it fought with my other tools. This time I took the default and said yes. After that, open a new shell (or source your .zshrc) so vp is on your path.

2. Run vp migrate

From the project root:

vp migrate

It walks you through a short list of questions before it changes anything. Do you want pre-commit hooks for formatting and linting? Which agent instructions file should it write? Which editor config? Then it asks whether to migrate ESLint rules to Oxlint (it uses @oxlint/migrate for this) and Prettier to Oxfmt.

vp migrate asks before it converts your ESLint and Prettier configs.

I said yes to the hooks, picked AGENTS.md (Kiro reads it), chose VS Code since the Kiro IDE is built on it, and let it migrate Prettier, ESLint, and the TypeScript shims.

When it finished, I ran the check:

vp check
vp check --fix

vp check found some formatting issues, and --fix cleaned up most of them. A few things were left over. My ESLint rules were now in vite.config.ts under a lint block, and eslint.config.ts was gone. But vitest.config.ts was still around, and there was one lint error it couldn't fix on its own.

VoidZero says up front that larger projects might need a follow-up after vp migrate, so I wasn't surprised.

3. Let your agent finish the migration

Instead of fixing those by hand, I asked Kiro, running Claude Opus 5.5:

I just used Vite+ to migrate this project. Can you complete the migration for Vitest and this error?

If you have Kiro, Claude Code, or Codex open already, I don't see a reason to do this part manually. The AGENTS.md file that vp migrate writes explains the vp commands, so the agent doesn't have to guess. VoidZero also publishes a migration prompt for coding agents, linked from the 1.0 announcement.

It finished in under a minute. It moved the test block from vitest.config.ts into vite.config.ts and deleted the old file. It removed vitest.config.* from the include list in tsconfig.node.json. The lint error was the typescript/no-empty-object-type rule in env.d.ts. It fixed it by changing DefineComponent<{}, {}, unknown> to DefineComponent<object, object, unknown>.

Then I ran the check again:

Formatting, linting, and type checks in one command.

All 39 files were formatted correctly in 731ms, and it found no warnings, lint errors, or type errors in 27 files in 782ms. All 16 tests passed with vp test, and the dev server still ran after a restart.

4. Replace Husky with Vite+ hooks

package.json still had "prepare": "husky", so I asked Kiro to move that over too. Vite+ has its own hooks now. vp hooks sets up Git hooks, and vp staged runs your checks on staged files only.

Kiro removed the .husky/ folder, added a staged block to vite.config.ts, and ran vp hooks enable. The hook script lives in .vite-hooks/pre-commit now, and you commit it with the rest of the project.

It also flagged something I would have missed. Husky sets core.hooksPath to .husky/ in your local Git config. Anyone with an existing clone still has that setting, so the new hooks won't install for them until they run this once:

git config --unset core.hooksPath && vp hooks enable

Put that in your PR description if you're migrating a team project.

What's left

After all that, one vite.config.ts holds the linting, formatting, testing, and staged-file config:

Run vp toolchain to see exactly what you're getting. Mine showed Vite 8.3.5, Rolldown 1.2.15, Vitest 5.0.5, Oxlint 1.89.0, Oxfmt 0.74.0, and tsdown 0.23.1, all pinned by the one vite-plus package. That's the upgrade story I like. You bump one version, and VoidZero has already tested those tools together.

For Node, vp env current shows the Node.js and pnpm versions the project resolves to. If something looks off, vp env doctor explains why it picked them.

Rolling it back

This is why you commit before running vp migrate. If it doesn't work out, go back to that commit, delete the new files like AGENTS.md and .vite-hooks/, and reinstall your dependencies. If you let Vite+ manage Node.js, you can switch back to NVM in your shell config.

Wrap up

The migration was pretty painless. vp migrate did most of the work, and the agent cleaned up the Vitest config, one lint error, and the Husky hooks in a couple of minutes. I'm going to start using Vite+ on most of my projects, and I'm happy to drop NVM.

It isn't feature complete. Remote caching, vp release, and vp docs are still on the roadmap. If you're migrating something in production, read the migration guide on viteplus.dev first.

Are you switching? Let me know in the comments, especially if you've tried it on a big monorepo.

2 Agent Skills Every Frontend Developer Should Try

Erik Hanchett — Tue, 20 Oct 2026 18:15:41 +0000

I love to try out new agent skills. Anything that can help me be more productive I'm all for. Today I found two new ones I want to share with you.

First one is Impeccable. Impeccable took a plain, AI-built website and gave it a design. It wasn't bad at all! Diagram Design took that same site and drew a diagram of how it works! Both install with one command, and both work with basically any coding harness. I used Kiro in my demos but you can use whatever you like.

I made a video walking through both if you'd rather watch:

Prerequisites

An agent that supports Agent Skills. I use Kiro, but Claude Code, Cursor, and Codex work too.
Node.js, so you can run npx.
A frontend project to try them on. Mine is a small website about cats.

Finding skills

I found both skills on Skill Leaderboard, which ranks skill repos by GitHub stars. You can filter by compatible agent, so I set it to Kiro. Skills are like recipes that work across most coding harnesses, so you'll usually be fine without the filter. Some repos are easier to install in one agent than another, though, and the filter saves you from finding that out the hard way.

Stars measure popularity. I cared more about what fits my own projects, so I picked the two that match what I build most, which is websites.

Before you install anything, read the SKILL.md and any scripts it pulls in. A skill is instructions and scripts that run with your agent's permissions, so check it the same way you'd check an npm package.

1. Impeccable

Impeccable is a design skill that started from Anthropic's frontend-design skill and builds on top of it. It has UX planning, a set of design commands like critique, polish, and audit, and it asks you a lot of questions.

To test it, I had Claude Opus 5.5 vibe code a site called the Great Cat Color Census. You spot a cat in the wild, click "Spotted one," and the counts and leaderboard update. Out of the box it came with a blocky card style and some hover animations. It looked okay. I don't think it looked bad, but it was pretty generic.

The default design Claude Opus 5.5 came up with.

Install it from your project root:

npx impeccable install

Then run init inside your agent:

/impeccable init

Init looks through the project, asks about anything it can't work out on its own, and writes a PRODUCT.md with what it learned. After that I asked it to make the site much nicer using its styles. It came back with five or six design directions. I picked the sticker one.

The sticker direction from Impeccable. Same features, new design.

It has basically the same features as before, and you can still summon a random cat. It looks a lot more polished, with extra animation and cats that look like peel-off stickers. The font gives it a Cat in the Hat feel. I don't have a very particular taste for frontend design, and I still like this version better. If you're a designer, tell me in the comments whether you agree.

A good way to use Impeccable is to have it build several of its directions on separate Git branches. Then you can run each one and compare them side by side before you commit to a look.

2. Diagram Design

Diagram Design draws diagrams as one self-contained HTML and SVG file. It supports 45 diagram types, from architecture diagrams and flow charts to radar charts and Venn diagrams. The screenshots in the repo don't do it much justice.

Install it with the skills CLI:

npx skills add cathrynlavery/diagram-design

I asked it for a diagram of the same cat site and didn't say what to diagram. There's no backend, so I wasn't expecting much. It picked the visitor flow. A visitor clicks, an action runs change() or reset(), the counts update, and the derived stats feed the left and right pages. It also shows the save and load path to localStorage, and it even carried over the pink styling from the site.

The diagram Diagram Design made from the cat site, open in Kiro.

It's a simple diagram, but I like the style, and I can see myself using it on my next project. It's also handy when you open a code base with little documentation. Ask it for a few diagrams before you start reading the code.

The rest of the list

I haven't spent much time with the other popular skills yet. These are my notes so far.

Ponytail gives your agent the personality of the laziest senior dev in the room. In its README, you show him fifty lines, and he says nothing and replaces them with one. The goal is less code and fewer tokens. In Kiro it loads as an always-on ruleset, so you don't get its slash commands.

Caveman makes the agent answer tersely to cut token usage. I haven't seen much savings myself. Someone in a Reddit thread on the top Kiro skill repos said it raised their token usage, even though the research the repo cites says otherwise.

Addy Osmani's agent skills add a spec, plan, build, and test workflow to your agent. Kiro has specs built in, but if your tool doesn't, this or Superpowers is how I'd add spec-driven development.

I haven't tried UI UX Pro Max or Graphify yet, even though they're near the top of the list.

If you build on AWS, look at the Agent Toolkit for AWS. It's our set of skills and MCP servers for working with AWS from your agent, and it's free on GitHub.

Wrap up

If you build websites, Impeccable is the one I'd install first. Diagram Design is right behind it, especially when you're new to a code base.

I'm thinking about testing whether Ponytail and Caveman save tokens in Kiro. Leave a comment if you want to see that, and tell me which skills you're using.

Is This How Frontend Developers Work Now? My 2026 Coding Setup

Erik Hanchett — Wed, 14 Oct 2026 18:09:55 +0000

Software development is moving fast! The same setup I had six weeks ago, is not the same I have now. In fact, I've been doing software development on my phone!

Just last week I was on vacation at Yellowstone, and I built an app from my phone. I chatted with an agent, it pushed the code to GitHub, and I reviewed the PRs. It was wild!

This post walks through the setup that makes that work. It runs on a server in my house, and I can reach it from anywhere.

Full disclosure, I'm a developer advocate at AWS, and a couple of the tools here are Kiro tools.

The box: a TrueNAS home lab

Years ago I bought an old Intel Xeon server and loaded it with hard drives. It's been my home lab ever since, running TrueNAS. For this setup I created a new Ubuntu VM on it called Kiro Crew and do all my coding there.

I went with Ubuntu 24.04 for the long-term support. 26 was an option, but 24 does everything I need.

You don't need a TrueNAS server for this. I've seen people buy a Mac mini or reuse an old machine, and an EC2 instance or any cloud VM works too. I like keeping it local so everything sits on my own network.

What I installed

After the VM was up, I SSH'd in and installed four things.

Kiro CLI. Any coding harness that runs on a remote server and lets you authenticate there will work. Most of them do now.
Kiro Crew. This is the agent I actually talk to. It works like a personal assistant for developers, with sessions, artifacts, memories, skills, and scheduled tasks. OpenClaw, Pi, and OpenCode are other options people run on remote servers.
The GitHub CLI, so the agent can push code and open PRs.
Tailscale, so I can reach the server from anywhere.

Connecting from my phone with Tailscale

Tailscale puts the server, my laptop, and my phone on the same private network. Wherever I am, I open Tailscale on my phone, SSH into the box with a mobile SSH app, and port forward the Kiro Crew dashboard. I use port 5477 for mine.

The Kiro Crew docs cover remote setup, and the remote and mobile guide goes through SSH tunnels and phone access step by step. You could use something like CloudFlare tunnels for this as well.

Connecting from my laptop with SSH port forwarding

From my laptop it's a single SSH command with local port forwarding:

ssh -L 5477:localhost:5477 YOUR_USER@YOUR_SERVER

Then I open a new connection window and point it at that port. (I also installed Kiro Crew locally on my Mac Laptop, so I can connect to Kiro Crew locally or to a remote instance)

For security, Kiro Crew wants a token before it lets you in. On the server, run:

kirocrew token

It prints a link with a token in it. Open that, and you're talking to your Crew instance.

Working in Kiro Crew

Sessions live along the side of the dashboard. When I start a new one, I usually turn on trust mode so the agent stops asking for approval after every step. That isn't a good idea for everything. For the personal projects I'm building, I'm comfortable with it.

Then I tell it what to do. In the video I had it pull down a repo I already had. As we go back and forth, it sends me screenshots of what it's building, and it can spin up a dev server so I can look at the running app.

By default it put that project in a scratch folder. Normally I pick the working folder I want before I start. The artifacts tab collects the screenshots and files from all my other projects too, so I can check on things I'm not actively working on.

Memories and skills

Memories are new in Kiro Crew. I told it to always use Vue.js, because I'm a huge Vue fan. I also installed a set of skills, so every new project starts with the same defaults.

Reviewing stacked PRs on GitHub

I always tell the agent to push to GitHub. When I want to be careful, I ask for a stacked PR.

GitHub's stacked PR interface works well with coding agents. It breaks a large update into smaller layers, and you review each one on its own.

For a fun project I'll accept the whole stack. For anything else I go through it layer by layer, make changes, and go back to Kiro Crew with something like "please update the PR, this code isn't what I want." Then we go back and forth until it's right.

The next thing I'd add is CodeRabbit, which reviews PRs automatically before you merge. I don't have it on this project yet.

Building from my phone on vacation

When I was at Yellowstone National Park last week, I wanted to try an ASCII library I'd seen on Hacker News. I asked Kiro Crew to build an app with it, and it created everything.

I did all of it from my phone. Tailscale got me onto my network, I chatted with the agent, it pushed to GitHub, and I checked the PRs. It worked really well.

I can also give it one prompt, turn on trust mode, walk away, and come back half an hour later to see everything it's done.

Models and effort levels

I switch between Claude Opus 5.5 and GPT 5.6 Sol. Opus 5.5 works better for me and what I'm building, so that's my default.

I've also been testing different effort levels, including high. I don't have a clear answer there yet, so your mileage may vary.

Specs and parallel sessions

When I want to be very specific, I use spec-driven development mode. Kiro Crew has a spec builder built in. (You can enable it in the "Discover" apps section)

Most of the time, though, I open three or four sessions and let them run in the background while I do other things.

Scheduled tasks and Discord

I'm trying to do more speaking, so I set up a weekly CFP finder. It runs on a schedule and sends me a message with what it found.

Kiro Crew is also connected to my own Discord channel and posts there. So I can either use Tailscale and port forwarding to open Crew on my phone, or I just open Discord and read the messages as they come in.

What does your setup look like?

This is how I'm building apps right now. A server at home runs the agent, my phone and laptop connect to it, and code reaches me as stacked PRs I can review.

Is this what your future looks like? Have you been running agents remotely, or is everything still happening in your editor? Let me know in the comments.

Are Frontend Developers Wasting Tokens? 5 Ways to Cut AI Coding Costs

Erik Hanchett — Thu, 08 Oct 2026 03:27:41 +0000

When you have an AI agent open all day, it's really easy to burn through a lot of tokens quickly. And for a while that's how everyone was using our agentic harnesses. Unfortunately, the costs add up quick.

So token maxing is dead. Whether your coding harness bills by tokens or by credits, it adds up. Let me show you a few ways to help lower you token costs! I'm using Kiro in my examples, but you can use whatever you'd like.

A lot of this builds on Laura Salinas's article Pushing Kiro's Free Tier to Its Limits. She built a project on Kiro's free tier and tracked where her credits went. It's worth a read.

I also made a video covering all five. Check it out if you'd rather watch:

(Full disclosure: I'm a Developer Advocate at AWS, and Kiro is owned by AWS. It's what I use in the video, so the examples below use it.)

1. Use a cheaper model for simple tasks

This one's a little obvious, but you shouldn't use the same frontier model for everything. Fixing a quick bug or renaming a prop shouldn't need the latest and greatest model.

In Kiro, the model picker shows a credit multiplier for each model, and everything is relative to Auto at 1.0x. The open weight models sit at the cheap end. Qwen3 Coder Next is 0.05x, MiniMax M2.1 is 0.15x, and DeepSeek 3.2 is 0.25x. Opus 5.5, a frontier model, is 2.0x, and a few models go higher than that.

The models docs spell out what that means. A task that costs 10 credits on Auto would cost 20 on Opus 5.5, 4 on Haiku 4.5, and 0.5 on Qwen3 Coder Next. That's a 40x spread for the same task.

If your model supports it, you can also turn down the reasoning effort. The docs say lower effort levels give faster, shorter responses and use fewer credits.

Heads up: Multipliers change as new models show up, so check the models page before you settle on one. Two models with the same multiplier can still use different amounts of credits on the same task, since token counts and thinking depth vary.

Keep spec-driven development in mind here. I'll come back to it in tip 3, because that's where mixing models comes in.

2. Put token rules in your steering file

Steering files are markdown files in .kiro/steering/ that Kiro loads as persistent context, so you don't have to repeat yourself every session. Here are a few token rules I have in mine. You can write them exactly like this, and Kiro will try to follow them:

---
inclusion: always
---

# Token rules

- Don't create unnecessary files.
- Don't create tests unless I ask you to.
- Try to save on token usage.

Save that as .kiro/steering/token-rules.md. inclusion: always is the default mode, so it loads into every interaction. The front matter has to be the very first thing in the file, with no blank lines above it. With these rules in place, I know I'm not getting a bunch of files or tests I never asked for.

Laura ran into exactly this in her build. With no steering file, DeepSeek generated validation files and summary markdowns she didn't need, and those cost credits. Her suggested steering rules include "Don't create summary markdown files" and "Use minimal code, no boilerplate."

Always-on steering rides along with every request too, so keep that file short. Anything framework-specific can use fileMatch, which only loads the file when you're working with matching files:

---
inclusion: fileMatch
fileMatchPattern: "components/**/*.tsx"
---

# React component rules

- Use function components and hooks.
- Type props with an interface in the same file.

There are two more modes. manual loads a file only when you reference it with #file-name in chat, and auto loads it when your request matches its description. The steering docs cover all four.

3. Use spec-driven development with two models

If you're building a feature that takes some forethought, and not just a quick bug fix, spec-driven development is the way to go. A Kiro spec moves through three phases (requirements, design, and tasks) and writes requirements.md, design.md, and tasks.md into .kiro/specs/.

The requirements and design phases are where the hard thinking happens, so that's where a stronger model earns its multiplier. Once you have a solid requirements and design document, you don't need the latest frontier model for the implementation phase. The cheaper models do pretty well working through a clear task list. You may want to try it out.

To make the switch, change the model picker before you start running tasks. The models docs say your selection applies to all later messages in the conversation. Tasks can run one at a time or all at once, so you can check the cheaper model's work on the first task before you let it run the rest.

More on the phases is in the specs docs.

4. Let ESLint, Prettier, and hooks do the deterministic work

If a job has a deterministic answer, don't pay a large language model to work it out. Formatting and lint fixes are that kind of job. Prettier gives you the same output every time, and so does eslint --fix. When you ask the agent to do it, you pay for it to read the file, reason about it, and write a diff a tool would have made instantly.

Laura's article makes the same point. She suggests hooks that auto-lint or auto-format on save, so you never spend credits asking the agent to fix style.

Start with scripts in package.json. This also includes a lint-staged block for the commit hook further down:

{
  "scripts": {
    "lint": "eslint .",
    "lint:fix": "eslint . --fix",
    "format": "prettier --write ."
  },
  "lint-staged": {
    "*.{js,jsx,ts,tsx,vue}": ["eslint --fix", "prettier --write"]
  }
}

I have a hook that runs Prettier or my Husky rule every time I'm done doing something, so I'm not wasting tokens on it. In Kiro, hooks are JSON files in .kiro/hooks/. This one lint-fixes and formats when the agent finishes its turn:

{
  "version": "v1",
  "hooks": [
    {
      "name": "Lint and format when the agent finishes",
      "trigger": "Stop",
      "action": {
        "type": "command",
        "command": "npm run lint:fix && npm run format"
      }
    }
  ]
}

Save it as .kiro/hooks/format-on-stop.json. The Stop trigger fires when the agent completes its turn, and a command action runs a shell command in your project root. The hook actions docs say shell command actions don't consume credits, while agent prompt actions do because they start a new agent loop. So for formatting, pick command.

If you'd rather run on every save, the hooks docs show a PostFileSave trigger with a matcher, something like "matcher": "\\.(ts|tsx|vue)$". File triggers only fire on changes the agent makes, not on your own edits.

For commits, Husky plus lint-staged runs the same tools on staged files.

npm install --save-dev husky lint-staged
npx husky init
echo "npx lint-staged" > .husky/pre-commit

husky init creates .husky/pre-commit and adds a prepare script to package.json. The echo line swaps the default npm test for npx lint-staged, which reads the config from the package.json above.

5. Watch your context window

The last tip is to double check your context usage. In Kiro, the context usage meter in the chat panel shows how close you are to the model's limit.

This matters because on every turn, every time you go back and forth with the model, the previous chat history gets sent again. The longer the session, the more context each message carries.

MCP servers add to this, since their tool definitions take up context too. The Kiro Powers docs put a number on it. Five connected MCP servers can mean 100+ tool definitions and 50,000+ tokens, about 40% of your context window, before your first prompt. Different harnesses may handle this differently, some use search tools to help prevent context bloat with MCP servers Kiro Powers, for example, only load their tools when your conversation mentions something relevant. Your mileage may vary, so turn off MCP servers you aren't using for the project in front of you.

Then start a new session when you move on to a new task. History from the last task doesn't help with the next one, and it gets sent along on every turn. In Claude Code, /clear does this. It starts a new session and keeps the previous one so you can resume it later. Kiro also compacts long sessions automatically, but a fresh session for unrelated work keeps things small from the start.

Wrap up

Thanks again to Laura Salinas for Pushing Kiro's Free Tier to Its Limits. It has more tips I didn't cover here, like writing a specific first prompt and pointing the agent at files with #File. The video version is up top if you want to see these in action.

Let me know in the comments if I missed one.

Are Frontend Developers Cooked? Is Frontend design safe?

Erik Hanchett — Wed, 30 Sep 2026 20:38:21 +0000

I recently put out a video arguing that frontend development is changing. I don't think the work is going away. The frontend developer title is what's changing, and a lot of us are turning into full stack developers.

The comments had opinions, so I recorded a follow-up.

Pick a stack and get really good at it

One comment that I found really interesting was from a 62 year old developer with almost 30 years in the field. In the comment he described how Claude handles about half his workload now. His advice was to pick a couple of good frontend frameworks like Vue or Angular, pair them with a solid backend like C#, and become an absolute master at them.

I agree with him, and this was something I've always said. It's always good to be at least a specialist in one category. I use Kiro as my agent harness for most of my apps now, and I still want deep knowledge of the stack underneath. That way I can really understand what's happening and help steer the agent when things go wrong. The agents are good. They aren't good enough that I'd stop checking their work.

Is frontend design the safer part of web dev?

This comment is where the title comes from. CRUD apps are the easy wins for LLMs, the argument goes, and attractive, non-generic UI with great UX is where they still struggle.

I sort of agree. With the older Anthropic models you could tell someone one-shotted a design at a glance. It had that very generic Tailwind template look. However, with every new model it's becoming harder and harder to tell. People who aren't looking at this stuff every day mostly think the designs look fine.

I didn't talk much about taste in my last video, but it is important. Looking at a screen and knowing whether the UX works, catching an accessibility problem, noticing that a flow is going to bog users down. That judgment still comes from people with experience. Still, LLMs are getting closer all the time.

I rebuilt Winamp with an AI agent

To test this I picked something with a lot of small UI pieces. I had Kiro Crew recreate the old Winamp MP3 player, and it came back as ErikAmp.

I was really impressed with everything it did with the UI. An equalizer with a row of sliders, a scrolling playlist, play, pause, stop, next and previous, shuffle, repeat, balance, volume. Getting every one of those working by hand would take me a couple of days, maybe less if I did nothing else. The agent basically one-shot it last Saturday. I had it fix a few bugs afterward, and it wrote a whole test suite along the way.

The source code is really simple. I never asked for Vue or React, so it skipped frameworks entirely. It's an index.html, some CSS, a handful of JavaScript files, and a bit of Python.

You could argue that this design was already made, but still. I had it create three brand new themes, and it looks great.

Where it starts to look like AI

The second app I showed is a 5K coach I built to get myself in shape for a race. It tells me what to do each day.

This is about as close as I get to the default Anthropic look. Dark cards, rounded corners, pill badges. It isn't flashy and I wouldn't call it amazing. For my own training plan it's fine, and it took a few minutes with my agent. Building it by hand would have eaten a lot more of my time.

So are we cooked?

I don't think so. Building a frontend is the easiest it has ever been, and I got two working apps out of an agent with very little effort. Deciding whether those apps are any good is still the developer's job, and that takes knowing your stack and having some taste.

I'm also figuring out what to cover next. Do you want more AI workflow content, or more classic Vue and fundamentals tutorials? Tell me in the comments, and tell me where you think frontend is headed.

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

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

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

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

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

Here is what I built with it!

What a request actually looks like

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

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

What comes back is shaped like the questions you asked:

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

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

Three question types

Jev has three primitives.

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

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

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

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

App one: gating a pull request

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

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

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

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

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

OpenRouter versus calling TypeSafe directly

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

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

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

App two: AWS workload

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

Here is what it does:

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

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

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

Schema validity

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

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

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

What other people are doing with it

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

The possibilities are endless.

Would I use it

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

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

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

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

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

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

If you rather watch, check out this video:

Job posting show an interesting story

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

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

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

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

Why

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

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

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

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

The skills moved to meta frameworks

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

So what to do?

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

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

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

Conclusion

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

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

Sources

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

Would You Choose a Library Because AI Writes It Better?

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

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

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

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

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

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

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

Put expected failures in the type system with Effect

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

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

import { Data, Effect } from 'effect'

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

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

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

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

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

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

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

    return profile
  })

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

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

The UI then handles each tag in one place:

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

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

Here is the feedback loop:

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

The compiler is catching the errors first.

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

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

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

Put visual states behind a typed API with StyleX

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

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

The component composes those states explicitly:

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

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

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

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

Decide who your stack is optimized for

I used to choose libraries based on the following:

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

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

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

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

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

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

Finale

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

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

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

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

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

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

Introduction

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

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

I also picked them based on these four signals:

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

Here is the video version of the list:

Prerequisites

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

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

Steps: the 10 MCP servers worth considering

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

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

1. Context7

Project: upstash/context7

Package: @upstash/context7-mcp

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

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

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

2. Chrome DevTools MCP

Project: ChromeDevTools/chrome-devtools-mcp

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

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

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

3. Playwright MCP

Project: microsoft/playwright-mcp

Package: @playwright/mcp

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

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

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

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

4. GitHub MCP Server

Project: github/github-mcp-server

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

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

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

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

5. Serena

Project: oraios/serena

Package: serena-agent

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

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

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

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

6. Supabase MCP

Project: supabase/mcp

Package: @supabase/mcp-server-supabase

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

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

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

7. AWS MCP Server

Documentation: AWS MCP Server

Toolkit: aws/agent-toolkit-for-aws

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

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

Check it out!

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

8. Vercel MCP

Documentation: Vercel MCP

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

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

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

9. Cloudflare API MCP

Project: cloudflare/mcp

Catalog: Cloudflare MCP servers

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

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

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

10. Excalidraw MCP

Project: excalidraw/excalidraw-mcp

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

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

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

What about Canva and Figma?

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

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

If you need design, check both of them out!

Three popular names I left off

Here are a few other MCP servers I left out.

Puppeteer MCP

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

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

Memory reference server

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

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

TanStack Intent

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

The distinction matters:

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

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

Finale

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

Today my starter stack looks like this:

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

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

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

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

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

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

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

I also added a Stream Deck API interface!

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

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

Watch the full video on YouTube.

Prerequisites

You need the following tools for the complete build:

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

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

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

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

Steps

1. Run the station without credentials

Pull down the repo and get started!

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

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

The environment file separates each feature:

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

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

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

2. Put provider calls behind Nuxt server routes

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

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

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

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

You can inspect the complete routes in server/api.

3. Generate a scene with Amazon Bedrock

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

aws sso login --profile your-profile

Add the profile and model settings to .env:

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

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

The provider payload is small:

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

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

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

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

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

4. Add looping music with ElevenLabs

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

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

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

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

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

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

5. Deploy the private media library

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

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

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

Read the media bucket output:

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

Copy that value into .env:

STATION_S3_BUCKET=YOUR_STACK_OUTPUT
STATION_S3_REGION=us-west-2

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

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

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

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

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

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

6. Turn one illustration into a seamless video loop

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

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

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

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

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

The fallback policy is intentionally narrow:

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

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

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

7. Report real progress during a long request

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

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

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

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

8. Validate the build

Run the same checks used for the source project:

npm test
npm run typecheck
npm run build

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

Then test one provider at a time:

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

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

Cleanup

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

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

Before deleting the stack, record the retained resource names:

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

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

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

Delete the non-retained stack resources:

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

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

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

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

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

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

For local cleanup:

rm -rf node_modules .nuxt .output
rm .env

Finale

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

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

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

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

Introduction

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

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

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

Watch the full video on YouTube.

Prerequisites

You need:

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

Step 1: Create the Nuxt app

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

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

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

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

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

Add the two Nuxt UI imports:

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

You can compare your setup with the complete companion project.

Step 2: Keep the file tool inside a fixture directory

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

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

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

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

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

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

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

  return target
}

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

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

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

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

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

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

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

Step 3: Connect the route to Amazon Bedrock

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

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

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

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

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

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

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

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

Set one of the returned profile IDs before starting Nuxt:

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

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

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

type BedrockModelId = Parameters<AmazonBedrockProvider>[0]

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

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

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

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

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

Step 4: Add approval to the delete tool

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

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

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

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

Step 5: Render the approval request in Nuxt

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

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

const input = ref('')

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

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

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

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

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

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

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

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

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

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

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

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

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

Step 6: Put Kiro CLI behind the same Nuxt UI

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

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

Install the AI SDK harness packages:

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

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

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

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

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

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

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

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

Step 7: Keep approval in its lane

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

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

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

Cleanup

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

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

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

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

Finale

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

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

DEV Community: Erik Hanchett

Nuxt CLI v4 Is Great for AI Coding Agents

Prerequisites

1. Meet the new nuxt dev

2. Check the lock file

3. Run nuxt dev a second time

4. Test routes with nuxt curl

5. Run Nitro tasks with nuxt task

6. Hand errors to your agent

Wrap up

Links

Vite+ 1.0 Is Out. You Don't Need ESLint or Prettier Anymore

What Vite+ replaces

Prerequisites

The project before Vite+

1. Install Vite+

2. Run vp migrate

3. Let your agent finish the migration

4. Replace Husky with Vite+ hooks

What's left

Rolling it back

Wrap up

Links

2 Agent Skills Every Frontend Developer Should Try

Prerequisites

Finding skills

1. Impeccable

2. Diagram Design

The rest of the list

Wrap up

Is This How Frontend Developers Work Now? My 2026 Coding Setup

The box: a TrueNAS home lab

What I installed

Connecting from my phone with Tailscale

Connecting from my laptop with SSH port forwarding

Working in Kiro Crew

Memories and skills

Reviewing stacked PRs on GitHub

Building from my phone on vacation

Models and effort levels

Specs and parallel sessions

Scheduled tasks and Discord

What does your setup look like?

Are Frontend Developers Wasting Tokens? 5 Ways to Cut AI Coding Costs

1. Use a cheaper model for simple tasks

2. Put token rules in your steering file

3. Use spec-driven development with two models

4. Let ESLint, Prettier, and hooks do the deterministic work

5. Watch your context window

Wrap up

Are Frontend Developers Cooked? Is Frontend design safe?

Pick a stack and get really good at it

Is frontend design the safer part of web dev?

I rebuilt Winamp with an AI agent

Where it starts to look like AI

So are we cooked?

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

What a request actually looks like

Three question types

App one: gating a pull request

OpenRouter versus calling TypeSafe directly

App two: AWS workload

Schema validity

What other people are doing with it

Would I use it

Links

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

Job posting show an interesting story

Why

The skills moved to meta frameworks

So what to do?

Conclusion

Sources

Would You Choose a Library Because AI Writes It Better?

Put expected failures in the type system with Effect

Put visual states behind a typed API with StyleX

Decide who your stack is optimized for

Finale

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

Introduction