DEV Community: Erik Hanchett

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!

References

Nuxt 4.5 SSR Streaming Is Kind Of A Big Deal

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

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

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

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

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

If you rather watch check out my full video here

Prerequisites

You will need:

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

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

npm ci
npm run typecheck
npm run build
npm run preview

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

Feature 1: Experimental SSR streaming

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

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

Create a controlled slow component

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

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

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

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

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

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

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

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

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

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

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

Enable streaming in production

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

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

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

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

Compare the responses

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

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

npm run measure

My local production preview produced this result:

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

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

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

Check the production constraints

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

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

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

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

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

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

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

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

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

In the demo, two child pages select different layouts:

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

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

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

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

Feature 3: Render multiple outlets with named views

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

The demo uses this structure:

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

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

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

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

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

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

Finale

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

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

Resources

How To learn Web Development in 2026

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

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

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

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

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

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

Start with a goal, not a curriculum

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

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

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

Decide how much you actually need to know

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

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

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

Ask three models what they'd build today

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

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

Build a mobile application for iOS.

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

Build a cross-platform iOS and Android application.

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

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

Get a personalized learning path

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

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

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

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

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

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

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

Build it: I do, we do, you do

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

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

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

I do: let it build, then read it

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

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

We do: spec-driven development

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

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

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

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

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

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

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

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

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

You do: turn it off

Close the tab. Build something small with no assistance.

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

Two more patterns worth stealing

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

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

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

Where I've landed

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

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

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

7 Kiro Features You're Probably Not Using

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

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

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

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

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

1. Stop approving every single command

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

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

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

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

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

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

Full details: tool permissions

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

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

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

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

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

#terminal why did this build fail

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

Full list: context providers

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

3. Pick a workflow instead of freeform chatting

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

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

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

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

4. Skills are slash commands

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

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

/pr-review

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

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

5. You might be running an old build

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

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

On the CLI:

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

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

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

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

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

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

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

Three of these are behind a flag or a toggle.

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

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

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

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

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

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

This is available in v3 CLI.

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

A few more worth a mention

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

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

Where to go when you're stuck

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

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

DEV Community: Erik Hanchett

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

Prerequisites

Steps: the 10 MCP servers worth considering

1. Context7

2. Chrome DevTools MCP

3. Playwright MCP

4. GitHub MCP Server

5. Serena

6. Supabase MCP

7. AWS MCP Server

8. Vercel MCP

9. Cloudflare API MCP

10. Excalidraw MCP

What about Canva and Figma?

Three popular names I left off

Puppeteer MCP

Memory reference server

TanStack Intent

Finale

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

Prerequisites

Steps

1. Run the station without credentials

2. Put provider calls behind Nuxt server routes

3. Generate a scene with Amazon Bedrock

4. Add looping music with ElevenLabs

5. Deploy the private media library

6. Turn one illustration into a seamless video loop

7. Report real progress during a long request

8. Validate the build

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

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