DEV Community: Erik Hanchett

Nuxt vs SvelteKit: What works better?

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

Nuxt vs SvelteKit. Which one is better?

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

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

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

The setup

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

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

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

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

The numbers

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

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

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

Let's talk about how requests work in each.

The Nuxt version: explicit API routes

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

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

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

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

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

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

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

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

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

The SvelteKit version: remote functions

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

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

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

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

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

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

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

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

  return result
})

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

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

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

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

  const tasks = getTasks()

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

{@render dashboard(await tasks)}

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

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

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

What does Nuxt 5 offer?

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

My verdict

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

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

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

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

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

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

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

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

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

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

What is spec-driven development?

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

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

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

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

The trade-offs

Like anything else, SDD comes with trade-offs.

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

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

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

The project: a Kiro birthday game

Let me show you what I built.

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

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

How I used SDD to build it

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

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

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

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

The tools that made it easier

A few things helped a lot here.

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

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

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

Wrapping up

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

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

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

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

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

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

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

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

The app

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

Difference one: server functions vs server routes

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

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

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

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

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

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

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

The server route does the outbound call:

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

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

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

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

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

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

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

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

The route wires it up:

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

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

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

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

Server components in both

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

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

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

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

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

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

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

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

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

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

Typed search params

This is where TanStack Start made me a little jealous.

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

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

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

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

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

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

What they actually share

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

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

The verdict

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

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

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

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

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

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

Introduction

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

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

What loop engineering actually is

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

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

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

It's the agentic loop you already know

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

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

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

A practical example: fixing a PR on a loop

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

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

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

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

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

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

Automations are the other big use case

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

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

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

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

My take

Now the part where I push back a little.

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

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

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

Resources:

3 Tools That Make AI Suck Less at Coding

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

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

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

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

This post covers:

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

Prerequisites

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

Find the mess: Fallow

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

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

npx fallow

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

There's a fix command for most things:

npx fallow fix

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

npx skills add fallow-rs/fallow

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

Bonus: Knip

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

npx knip

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

Review the diff: CodeRabbit

Finding dead code is great, but what about reviews?

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

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

Then point it at your uncommitted changes:

coderabbit review --plain

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

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

Measure the improvement: Kiln

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

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

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

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

How to pick

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

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

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

Conclusion

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

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

Resources:

The most popular AI coding skills right now

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

Introduction

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

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

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

This post covers:

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

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

What is an agent skill?

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

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

The big workflow skills

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

Superpowers (obra/superpowers)

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

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

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

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

/plugin install superpowers@claude-plugins-official

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

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

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

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

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

Matt Pocock's skills (mattpocock/skills)

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

npx skills@latest add mattpocock/skills

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

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

GStack (garrytan/gstack)

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

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

It also works with Kiro nicely.

GSD Core (open-gsd/gsd-core)

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

npx @opengsd/gsd-core@latest

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

Framework skills and the "ships with your package" model

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

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

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

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

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

Here is each of those three:

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

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

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

The Agent Toolkit for AWS

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

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

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

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

How to pick one and try it safely

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

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

Conclusion

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

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

TanStack Start Is Kind of a Big Deal

Erik Hanchett — Mon, 08 Jun 2026 17:06:43 +0000

Introduction

People keep telling me TanStack Start is kind of a big deal, and I wanted to know if that holds up or not. I've been spending a lot of time at conferences lately, and TanStack Start comes up quite often in conversation. The community is split if server components is the right answer. TanStack Start has gone the opposite direction with it's clean client-side first components approach, with lot so ways to call server-side code, even in the same component.

I'm a Vue and Nuxt person most days, so I'm not here to dunk on anyone's framework. What I want to figure out is simpler: are there specific things TanStack Start does that Next.js and Nuxt don't, and are they good enough to switch for?

After some research I have come up with three things I really like about TanStack Start. These things alone aren't probably enough for me to switch, but I'm getting close.

If you'd like to watch a video instead, check this out!

Prerequisites

Node.js 22+
Comfort with React and TypeScript
You do not need any Next.js or TanStack experience

What we're building

A GitHub user lookup. You type a username, the app fetches that user from the GitHub API on the server, and renders their profile. It's a perfect app to show these three features.

You can find the full code in the demo repo. Let's start by creating the app.

Step 1: Create the app

TanStack has a CLI, so scaffolding is one command:

npx @tanstack/cli@latest create my-app --framework React

It asks about a package manager and a few add-ons, then sets up a project on Vite with file-based routing. Run it:

cd my-app
npm install
npm run dev

The dev server was ready in under a second on my machine. That Vite-powered startup is really nice, and it's the same Vite speed I covered in my earlier Vite videos.

The structure is small:

src/
├── routes/
│   ├── __root.tsx      # the document shell
│   └── index.tsx       # the home route
├── router.tsx          # router config
└── routeTree.gen.ts    # auto-generated, don't edit

Now the three features.

Feature 1: One server function for reads and writes

Let me be fair up front, Next.js can also call server code directly. Next has React Server Functions, and in mutation contexts those are Server Actions. You mark a function with "use server" and call it from a component, no API route required. Nuxt has its own version with server/api routes plus useFetch, which gives you typed responses too. So "call a function on the server" is not unique.

However, the difference is the constraint. Next.js Server Actions run as POST requests and are built for mutations. The Next docs themselves steer you to Server Components or Route Handlers for reading data. You can call a Server Action from a client component to read, but it still goes over POST and isn't the idiomatic, cacheable GET path.

TanStack Start doesn't split it this way. One primitive, createServerFn, handles both a GET read and a POST mutation, and you call it the same way from anywhere.

import { createServerFn } from '@tanstack/react-start'

interface GithubUser {
  login: string
  name: string | null
  avatar_url: string
  html_url: string
  bio: string | null
  public_repos: number
  followers: number
  following: number
}

const getGithubUser = createServerFn({ method: 'GET' })
  .inputValidator((username: string) => username)
  .handler(async ({ data: username }): Promise<GithubUser> => {
    const res = await fetch(`https://api.github.com/users/${username}`, {
      headers: {
        Accept: 'application/vnd.github+json',
        // a token here stays on the server, never ships to the client:
        // Authorization: `Bearer ${process.env.GITHUB_TOKEN}`,
      },
    })
    if (!res.ok) throw new Error(`User "${username}" not found`)
    return (await res.json()) as GithubUser
  })

That .handler runs only on the server, so a token never reaches the browser. I set method: 'GET' because this is a read, and I call it straight from my route loader like a normal async function. There is no route handler, or RSC boundary to think about and no endpoint string to keep in sync. (This snippet is trimmed for clarity. The version in the repo adds encodeURIComponent on the input and separate handling for 404 and 403 rate-limit responses.)

You can watch this happen in the browser too. Open the network tab, run a lookup, and you won't see a request to api.github.com anywhere. The only call is the one to my own server. The GitHub fetch is happening server-side, which is exactly where I want it, and any token isn't leaked.

I really like how types work here. I annotate the handler's return as GithubUser once, and that type flows through the loader and into the component without me re-typing it at each call, and that holds whether it's a GET or a POST. Rename a field in the interface and every call that still reads the old property lights up red. (One caveat, that's compile-time propagation, not runtime validation. I cast the GitHub response with as GithubUser, so if you want to prove the external JSON actually matches, you'd add a runtime schema check.) You can get there with a route handler too, with shared types or a schema validator. The difference is that TanStack infers the chain for you by default instead of asking you to wire it up.

Feature 2: Search params that are actually typed

This is the one where TanStack genuinely has an advantage as of today. Next.js gives you generic string and string-array search params, not route-local schema validation. useSearchParams hands you a read-only URLSearchParams, and while typedRoutes plus the PageProps helper have improved path, navigation, and page-prop typing, none of that validates or transforms the values inside the query string the way TanStack Router does. You can get there in Next with Zod, nuqs, or next-typesafe-url, but it's something you add on. Nuxt can validate a route with definePageMeta's validate function, which can return false or a Partial<NuxtError> to reject a route, but it doesn't turn route.query into a typed, validated query object for your component.

TanStack Router treats search params as validated route state out of the box:

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

I validate ?user= once. After that, Route.useSearch() gives me { user: string }, fully typed, anywhere in the component. The loader reads that param and runs the server function, so loading the page with ?user=ErikCH in the URL loads the profile directly, with no extra client wiring. The lookup is shareable and survives a refresh, and I never wrote client state to make that happen. You can plug in Zod if you want richer schemas.

Feature 3: Type safety that runs end to end by default

Typed navigation by itself isn't unique, and I want to be straight about that. Next.js has typedRoutes for statically typed links, and Nuxt has typed navigation built in through experimental.typedPages, plus the nuxt-typed-router module for more. So all three can stop you from typoing a route.

The difference is how far the chain reaches and how much setup it takes. Next's typedRoutes types the path, not the search param values. Nuxt's typed pages are opt-in and cover routes and params. In TanStack it's on by default, and the same type system covers your route params, your search params, and your loader data in one connected chain.

const navigate = useNavigate({ from: Route.fullPath })

function lookup(e: React.FormEvent) {
  e.preventDefault()
  navigate({ search: { user: input.trim() } })  // typed: { user: string }
}

If I pass a search param that doesn't exist, or the wrong type, the type checker flags it. Vite itself transpiles TypeScript without type checking, so this is tsc --noEmit (I keep it in a typecheck script and run it in CI) or your editor catching it inline. And because the loader's return type flows into Route.useLoaderData(), the data I render is typed by the same chain that typed the navigation. That whole path, from the server function return through the loader, the search params, and the link, is one thing instead of three features you wire up separately.

Adding in AI

I lean on AI coding assistants like Kiro for a lot of my code, and TanStack Start is new enough that the models don't have great knowledge on it. When I asked for a server function, I'd sometimes get an older API shape back, because the training data is behind.

TanStack ships a fix for exactly this, and it's the last thing I showed in the video. There's a package called TanStack Intent that wires your coding agent into current TanStack patterns. You install it like this:

npx @tanstack/intent@latest install

That creates or updates your agent config, defaulting to AGENTS.md (it can target others like CLAUDE.md or .cursorrules too), with skill-loading instructions. Your agent reads it, sees which TanStack skills are available, and pulls the current docs for whatever it's working on instead of guessing from stale training data.

So I opened Kiro CLI, which picks up that AGENTS.md on its own, and gave it this:

Please review my existing repository against the newly loaded TanStack Intent rules. Check my implementation for anti-patterns, missing edge cases, or deprecated syntax.

It worked through the skills and came back with a list, a couple of verbatimModuleSyntax notes, some dev-tools setup for TanStack Start, a shell component thing. One last thing, I wasn't pinning the latest version tags in my package.json. Though not really required all the time, I did like how it was looking at the package.json file in general.

The second guardrail is the type safety from earlier. When the AI guessed an old createServerFn shape, tsc and my editor flagged it right away. I didn't have to catch it in review. The types caught it for me.

This is the same point I made in my Vue in the Age of AI video. AI writes more of our code now, so the frameworks that verify the AI's work for you are worth more than they used to be.

Cleanup

Nothing to tear down for local development. Stop the dev server with Ctrl+C. If you deployed, TanStack Start uses Nitro under the hood, so you can remove whatever Node target you set up. Those hosting resources can incur charges, so tear them down if you were only testing.

Conclusion

So is it kind of a big deal? I'd put it this way. If you want explicit control, fast Vite builds, and type safety that runs from the server function through search params to your links, TanStack Start is genuinely the most compelling React framework I've tried in a while. The server functions and typed search params alone are just really nice to have.

It's not for everyone yet. The ecosystem is smaller than Next.js, there are fewer plugins and it's young. The TanStack CLI is still marked alpha, there are fewer production references to learn from, and the deployment and debugging knowledge isn't as standardized as Next.js. If you need the hiring pool and the deployment story Next.js has, that's a real reason to wait.

But "the default React framework is finally in question" is true for the first time in years, and after building with it, I get why people are switching. If you're a Nuxt person like me, the typed search params and server functions will feel like the things you wish you had without reaching for extra modules.

Resources:

Mastering the Latest TypeScript: What's New in 6.0 (and a Peek at 7)

Erik Hanchett — Thu, 04 Jun 2026 17:01:27 +0000

TypeScript 6.0 has been out for a few months now, and it's a bit of an unusual release. It's the last compiler that will be written in TypeScript and JavaScript. Later this year, TypeScript 7 arrives with the compiler rewritten in Go. Microsoft has seen roughly 10x speed improvements on large codebases. That makes 6.0 the bridge release.

The good news is that the features I want to show you aren't going anywhere. Everything here is forward compatible with TypeScript 7. They're also just genuinely nice to use. I'll walk through five additions worth adopting today, show the tsconfig.json changes that add them, and finish with what the Go rewrite means for you.

If you'd rather watch than read, the full video is here.

Prerequisites

Node.js 20 or newer
TypeScript 6.0 (npm install -D typescript@6)
A code editor with TypeScript support (I'm using Kiro)
Basic familiarity with tsconfig.json

1. Native Temporal date and time types

The built-in JavaScript Date API isn't that great. Months are zero-indexed, time zone handling is painful, and most of us reach for an API library to help. TypeScript 6 ships type support for Temporal, the TC39 date/time API, so you get a modern API with no extra dependency.

Creating a date is readable now. You pass the year, month, and day as named fields instead of memorizing argument order.

const launch = Temporal.PlainDate.from({ year: 2026, month: 9, day: 1 });

// Arithmetic that reads the way you think about it
const twoWeeksLater = launch.add({ weeks: 2 });
const aMonthEarlier = launch.subtract({ months: 1 });

Time zones are really neat to use. You can format the same instant across several zones without juggling offsets by hand.

const now = Temporal.Now.zonedDateTimeISO("America/Los_Angeles");

const zones = ["America/Los_Angeles", "America/New_York", "Europe/London", "Asia/Tokyo"];
for (const zone of zones) {
  const local = now.withTimeZone(zone);
  console.log(zone, local.toLocaleString());
}

And duration math, the thing that usually sends you to a library, is built in.

const today = Temporal.Now.plainDateISO();
const target = Temporal.PlainDate.from("2026-09-01");
const diff = today.until(target, { largestUnit: "day" });

console.log(`${diff.days} days until launch`);

You get all this without a date library, and you avoid the off-by-one month bugs that Date gives you. This is the feature I expect people to adopt first.

2. Map.getOrInsert() and getOrInsertComputed()

If you work with Map, you know the check-then-set code you have to write. You want to insert a value only if the key isn't already there, so you write something like this.

const cache = new Map<string, number>();

if (!cache.has("a")) {
  cache.set("a", 1);
}
const value = cache.get("a")!; // non-null assertion because get() can return undefined

Two things bother me there. The if guard is boilerplate, and the ! non-null assertion exists only because get() is typed to possibly return undefined. TypeScript 6 adds Map.getOrInsert(), which adds all of that into one call.

const cache = new Map<string, number>();

const value = cache.getOrInsert("a", 1); // returns 1, inserts if missing
cache.getOrInsert("a", 99);              // key exists, so this is ignored
console.log(cache.get("a")); // still 1

It checks for the key, returns the existing value if present, and inserts only when the key is missing. You don't overwrite anything, and the guard and the assertion both go away.

There's a companion method, getOrInsertComputed(), that takes a factory function instead of a value. The function only runs when the key is actually missing.

const cache = new Map<string, number>();

cache.getOrInsertComputed("a", () => {
  console.log("computing a");
  return 1;
}); // logs "computing a", inserts 1

cache.getOrInsertComputed("a", () => {
  console.log("this never runs");
  return 2;
}); // key already exists, so the factory is skipped entirely

That second factory never executes. If your value is expensive to produce, a database call, a heavy calculation, parsing something large, getOrInsertComputed() skips the work entirely when the key already exists. getOrInsert() evaluates its argument no matter what, so reach for the computed version when the value isn't cheap.

3. RegExp.escape() for safe dynamic regex

Building a regular expression from user input is a classic problem that we all run into. Say you take a version string and try to match it.

const userInput = "1.0";
const pattern = new RegExp(userInput, "g");

const text = "version 1.0 and build 1x0 are different";
console.log(text.match(pattern)); // matches BOTH "1.0" and "1x0"

That matches more than you wanted. The . in the input is a regex wildcard, so it matches any character, including the x in 1x0. TypeScript 6 adds RegExp.escape(), which escapes special characters in a string so it's treated literally.

const userInput = "1.0";
const pattern = new RegExp(RegExp.escape(userInput), "g");

const text = "version 1.0 and build 1x0 are different";
console.log(text.match(pattern)); // matches only "1.0"

Now the dot is a literal dot, and you match exactly what you meant. Any time you build a regex from a value you didn't write yourself, wrap it in RegExp.escape().

4. The `#` subpath imports (and the tsconfig that powers them)

Deep relative imports like ../../../utils/format are hard to read and break when you move files. The common fix is a path alias with @, but that can collide with real npm packages, since plenty of scoped packages start with @. TypeScript 6 leans into Node's subpath imports, which use a # prefix that can't be confused with a package name.

Setup happens in two files. First, tsconfig.json needs a module resolution mode that understands subpath imports.

{
  "compilerOptions": {
    "module": "esnext",
    "moduleResolution": "bundler"
  }
}

If you're not using a bundler, the Node-native equivalent works too.

{
  "compilerOptions": {
    "module": "nodenext",
    "moduleResolution": "nodenext"
  }
}

Then you declare the actual mapping in package.json under imports.

{
  "imports": {
    "#utils/*": "./src/utils/*.js",
    "#components/*": "./src/components/*.js"
  }
}

Now your imports are clean.

import { formatDate } from "#utils/format";
import { Button } from "#components/Button";

Without one of those module resolution settings, the # imports won't resolve, so the tsconfig change is the part that actually unlocks the feature. If you watched my earlier video on tsconfig paths, this is the modern, standardized version of that same idea.

5. Smarter generic inference

This one removes annotations you used to have to write by hand. Take a generic interface like this.

interface CreatePair<T> {
  config: { value: T };
  consume: (value: T) => void;
}

Before TypeScript 6, you usually had to pin the generic explicitly when you used it.

const pair: CreatePair<number> = {
  config: { value: 42 },
  consume: (value) => console.log(value),
};

TypeScript 6 infers T from the value you provide, so the annotation becomes optional.

const pair = {
  config: { value: 42 },        // T inferred as number
  consume: (value: number) => console.log(value),
};

Because the compiler reads 42 and figures out the type, you write less and still get full type safety and autocomplete everywhere. It's a small change you'll feel constantly in real code.

tsconfig.json changes worth making now

Beyond the subpath imports config above, TypeScript 6 shifts a few defaults in a direction that TypeScript 7 will push as well. A few minutes auditing your config today saves friction later.

strict now defaults to true. If you've explicitly set strict: false, you're working against where the language is heading. This is a good moment to enable it or write down why you're opting out.
verbatimModuleSyntax: true is encouraged and replaces the older importsNotUsedAsValues. It forces explicit import type for type-only imports, which keeps your emitted output predictable.
baseUrl is no longer required for paths to work. If you only kept baseUrl around to enable path aliases, you can drop it.
moduleResolution: "node" is on its way out. If you're still on the legacy resolver, 6.0 is the time to move to nodenext or bundler.

What's coming in TypeScript 7

TypeScript 7 is the headline behind all of this. The compiler is being rewritten in Go (the project codename is Corsa), and the speed gains look impressive. The Go compiler parallelizes across CPU cores, so the bigger your codebase, the more you benefit.

Wrapping up

TypeScript 6 isn't a flashy release, and that's the point. Temporal, the new Map methods, RegExp.escape(), subpath imports, and smarter inference all make day-to-day code a little cleaner, and none of it gets in your way when you move to 7. The single most valuable thing you can do today is adopt these APIs and audit your tsconfig.json so the Go-compiler upgrade is a non-event.

I also built an experimental skill that helps you upgrade older TypeScript projects to 6.0. If you use Kiro, Claude Code, or another agentic editor, give it a try on a TypeScript 5 project and let me know how it goes. The link is in the video description.

Watch the full walkthrough on YouTube, and drop a comment if you've started using any of these in your own projects.

Your Default Vite Config Is Not Enough (New with Vite 8)

Erik Hanchett — Mon, 25 May 2026 17:14:13 +0000

Introduction

Last week I was at Vueconf US. It's one of my favorite conferences and I try to go every year. This year Evan You gave a talk on the future of Vue and tooling. Halfway through he started talking about Vite and some of the new features of Vite 8 that just came out. I was amazed at how far Vite has come and the millions of downloads a month it's getting. What I found especially interesting was how few people really knew about these features. Evan asked the audience by a show of hands who had tried out Vite 8, and only a few people raised their hands! So when I got home I decided to write this blog post and create a video on some configurations you must try out with Vite, including some new features that just came out with Vite 8.

If you haven't heard yet, Vite 8 shipped in March 2026 with the most significant architectural change since Vite 2. One of the most significant is the Rust-based bundler called Rolldown that delivers 10-30x faster builds. If you've been using Vite with zero config, that's fine. The defaults are great. However, there are a handful of options that, once you know them, you'll reach for in every project.

This post covers 8 config options that you should know. Two are new in Vite 8, and six have been around but you probably have not heard of them. All of them go in your vite.config.ts.

I put this post together using Kiro, an AI-powered IDE. The forwardConsole option in section 1 is something Kiro benefits from directly.

I also made a video covering all of these with a live demo. Check it out if you prefer watching over reading:

Prerequisites

Node.js 20.19+ or 22.12+ (required by Vite 8)
A Vite project (any framework)

To upgrade to Vite 8:

npm install vite@latest

Steps

1. server.forwardConsole

New in Vite 8. When you enable this, browser console errors and warnings show up in your Vite terminal instead of only in DevTools.

export default defineConfig({
  server: {
    forwardConsole: true,
  },
})

It's useful when you're working with AI coding agents that can't see the browser, or when you just want to keep your eyes on the terminal instead of switching to DevTools. Vite auto-enables it when it detects an AI coding agent via @vercel/detect-agent. Otherwise it defaults to false.

You can get more granular with it too:

server: {
  forwardConsole: {
    unhandledErrors: true,
    logLevels: ['warn', 'error'],
  },
}

The output includes source-mapped stack traces, so you see the original TypeScript line numbers, not the compiled output.

2. resolve.tsconfigPaths

Also new in Vite 8. Before this you had to install the vite-tsconfig-paths plugin to use TypeScript path aliases. Now it's built in and works in both the dev server and build.

export default defineConfig({
  resolve: {
    tsconfigPaths: true,
  },
})

One setup mistake I see a lot: make sure paths is inside compilerOptions, not at the top level of the JSON. Easy to get wrong when editing by hand:

// wrong — paths at top level, ignored by Vite
{
  "files": [],
  "paths": { "@/*": ["./src/*"] },
  "references": [{ "path": "./tsconfig.app.json" }]
}

// correct — paths inside compilerOptions
{
  "files": [],
  "references": [{ "path": "./tsconfig.app.json" }],
  "compilerOptions": {
    "paths": {
      "@/*": ["./src/*"],
      "@components/*": ["./src/components/*"]
    }
  }
}

There's a small performance cost, so it's opt-in rather than the default. The TypeScript team also notes that paths is intended to inform TypeScript about mappings handled by other tools, not to change emit behavior. Still, I think it's well worth trying out.

resolve.alias vs resolve.tsconfigPaths: which should you use?

	`resolve.alias`	`resolve.tsconfigPaths`
Config location	`vite.config.ts`	`tsconfig.json`
Works with plain JS	✅	❌
Single source of truth	❌	✅
Requires Vite 8	❌	✅ (built-in)
Performance cost	None	Small

Use tsconfigPaths if you want one place to define aliases and you're already on TypeScript. Use alias for plain JS projects, monorepos, or when you want aliases independent of TypeScript's config.

3. server.proxy

I don't see a lot of developers using this one. The proxy isn't really about fixing CORS. It's about making your dev environment behave like production.

In production, your frontend and API are usually on the same domain. They might have the same origin, so CORS is not needed. For example, in dev, your frontend may be on localhost:5173 and your backend on localhost:8080. If you have different ports, and different origins, tne you'll get a CORS error. The proxy closes helps fix this.

export default defineConfig({
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api/, ''),
      },
    },
  },
})

Any request to /api/* gets forwarded to http://localhost:8080/*. The browser only ever sees localhost:5173, so no cross-origin request and no CORS error.

A few other reasons to reach for it:

Working against a teammate's service or a third-party API that hasn't added localhost to their CORS config? You can't change their server, but you can proxy through Vite.
Adding Access-Control-Allow-Origin: localhost:5173 to your backend is a dev concern leaking into prod config. The proxy keeps that out entirely.
You can inject auth headers for external services in the proxy configure callback, keeping them out of the browser bundle. This is dev-only though. For production, handle auth server-side.

changeOrigin: true makes the request appear to come from the target host, which some backends require. rewrite strips the /api prefix before forwarding.

4. server.hmr.overlay

By default, Vite shows a full-screen red overlay when there's a server error. Runtime errors, HMR failures, and transform errors all trigger it. If you find it disruptive while editing, you can turn it off.

export default defineConfig({
  server: {
    hmr: {
      overlay: false,
    },
  },
})

Errors still appear in the terminal and browser console. Turn it off when you're doing UI-heavy work and the overlay keeps blocking the component you're editing. I've been turning the overlay off a lot when I work. It's been so much nicer. Leave it on if you like the overlay.

5. resolve.alias

While I prefer the tsconfigpaths, sometimes you have to use resolve.alias instead. It is the explicit way to set up import shortcuts without touching tsconfig at all. It's great for JS projects, monorepos, or when you want aliases that aren't tied to TypeScript's path resolution.

export default defineConfig({
  resolve: {
    alias: {
      '@': path.resolve(__dirname, 'src'),
      '@components': path.resolve(__dirname, 'src/components'),
      '@utils': path.resolve(__dirname, 'src/utils'),
    },
  },
})

Use path.resolve (or fileURLToPath with ESM) to get a proper absolute path. Passing a bare string like '/src' resolves to the filesystem root on most systems, not your project root.

6. server.open

I've been really liking this option. Yes it's small but once you turn it on, you'll never turn it off (at least most of the time). Set server.open: true and Vite opens your browser automatically when the dev server starts.

export default defineConfig({
  server: {
    open: true,
  },
})

You can also pass a path string to land on a specific route:

server: {
  open: '/dashboard',
}

Pairs well with conditional config (see the Bonus section) so you can set open only when running vite dev, not during build.

7. build.sourcemap

By default, Vite doesn't generate sourcemaps for production builds, so errors in production point at minified output. Turn this on and stack traces point at your actual source files.

FYI: Source maps are turned on for dev builds, so don't accidentaly turn this on by accident and leak your source code in production!

export default defineConfig({
  build: {
    sourcemap: true,
  },
})

Run npm run build then npm run preview (preview runs vite preview). Open DevTools, go to Sources, and you'll see your actual .vue and .ts files. Click any line in a stack trace and it jumps to the original source. This is perfect for debugging and adding in break points.

Three modes are available:

build: {
  sourcemap: true,      // separate .map files alongside the bundle
  sourcemap: 'inline',  // sourcemap embedded directly in the JS file
  sourcemap: 'hidden',  // .map files generated, no reference in the bundle
}

'hidden' is useful if you're uploading sourcemaps to an error monitoring service like Sentry. They can decode your stack traces server-side without the browser ever loading the maps. One thing to know: 'hidden' only removes the //# sourceMappingURL= comment from the bundle. The .map files are still generated and will be deployed alongside your JS unless you explicitly exclude them. If you want them truly private, add a step to strip *.map files before uploading. Otherwise your source maps might leak to production!

8. envPrefix

Occasionally I look for this one, it's useful when I'm migrating code and the prefixs are different. By default, Vite only exposes env variables prefixed with VITE_ to your client code. Everything else in your .env file stays server-side. envPrefix lets you change that prefix.

export default defineConfig({
  envPrefix: 'PUBLIC_',
})

With this set, your .env file might look like:

PUBLIC_API_URL=https://api.example.com
PUBLIC_APP_NAME=My App
SECRET_DB_PASSWORD=supersecret

And in your components:

import.meta.env.PUBLIC_API_URL   // "https://api.example.com"
import.meta.env.PUBLIC_APP_NAME  // "My App"
import.meta.env.SECRET_DB_PASSWORD // undefined, never sent to the browser

Only variables matching your prefix make it into the bundle. Everything else is stripped at build time, even if it's in the same .env file.

If you're migrating from Create React App (REACT_APP_) or Next.js (NEXT_PUBLIC_), you can match your existing naming convention instead of renaming every variable. You can also pass an array to expose multiple prefixes:

envPrefix: ['PUBLIC_', 'APP_']

Bonus: conditional config and define

This bonus is more for the advanced users out there! If you are let me know in the comments! You can pass a function to defineConfig instead of an object. It receives command ('serve' or 'build') and mode ('development' or 'production'), so you can change config based on context:

export default defineConfig(({ command, mode }) => ({
  server: {
    open: command === 'serve',
  },
  build: {
    sourcemap: mode !== 'production',
  },
}))

define bakes global constants into the build at compile time. Values are inlined directly into the output, so there's no runtime cost:

define: {
  __APP_VERSION__: JSON.stringify('1.0.0'),
  __BUILD_DATE__: JSON.stringify(new Date().toISOString()),
}

Add type declarations to vite-env.d.ts so TypeScript knows about them:

declare const __APP_VERSION__: string
declare const __BUILD_DATE__: string

Cleanup

Most of these are config-only changes. A few touch other files: tsconfigPaths requires paths in your tsconfig.json, envPrefix pairs with a .env file, and define needs type declarations in vite-env.d.ts. To revert any option, remove it from vite.config.ts and Vite falls back to its defaults.

Frequently Asked Questions

Why aren't my TypeScript path aliases working in Vite?
Make sure paths is inside compilerOptions in your tsconfig.json, not at the top level. Vite 8's built-in resolve.tsconfigPaths: true reads from compilerOptions.paths only. A top-level paths key is silently ignored.

What's the difference between resolve.alias and resolve.tsconfigPaths in Vite?
resolve.alias is defined directly in vite.config.ts and works for any project including plain JavaScript. resolve.tsconfigPaths reads aliases from your tsconfig.json and requires TypeScript. Use tsconfigPaths if you want a single source of truth; use alias for JS projects or monorepos.

Does Vite's server.proxy fix CORS errors?
Yes, but the real purpose is making dev match production. The proxy routes requests through the Vite dev server so the browser never makes a cross-origin request. No CORS header needed on your backend. It's cleaner than adding Access-Control-Allow-Origin: localhost:5173 to your server config.

Are Vite production sourcemaps safe to deploy?
sourcemap: 'hidden' generates .map files without referencing them in the bundle, so browsers won't load them. You can upload them to Sentry or similar for private stack trace decoding. Note: the .map files are still built and will be deployed unless you add a step to strip *.map files before uploading.

What env variables does Vite expose to the browser?
Only variables prefixed with VITE_ by default (or your custom envPrefix). Everything else in .env is stripped at build time and never sent to the browser. That includes secrets like database passwords or API keys that don't have the prefix.

Does server.forwardConsole work with all frameworks?
Yes, it's a Vite dev server feature, not framework-specific. It works with Vue, React, Svelte, and any other Vite-based setup. Vite auto-enables it when it detects an AI coding agent via @vercel/detect-agent; otherwise it defaults to false.

Conclusion

forwardConsole and tsconfigPaths are both opt-in and default to false. The others (proxy, hmr.overlay, resolve.alias, server.open, build.sourcemap, envPrefix) have been around for a while but are easy to miss if you've never needed them.

The full demo project is available at https://github.com/ErikCH/vite-config-tips.

Here is me speaking at VueConf this year!

Written by Erik Hanchett, AWS Developer Advocate. He covers frontend development, AWS, and AI/agents at programwitherik.com.

5 Things to Do After Installing OpenClaw (Before You Break It)

Erik Hanchett — Mon, 11 May 2026 18:51:25 +0000

I've been running OpenClaw for a while now and I think it's pretty awesome.

If you haven't heard of it, OpenClaw is a self-hosted AI agent that runs on your own hardware: a spare laptop, a Mac Mini, or a VPS. At AWS we have Amazon Lightsail which is a great option for running OpenClaw on a dedicated instance. (Full disclosure: I'm a Developer Advocate for AWS, so I'll be recommending AWS services where relevant. Feel free to use whatever VPS provider you'd like.) It's not a chatbot you open in a browser tab. It's always on. It connects to your messaging apps (Telegram, Discord, WhatsApp), reads your files, runs scheduled tasks, and takes action on your behalf. By default, a heartbeat runs every 30 minutes, it checks for instructions in HEARTBEAT.md and acts proactively. You can customize the interval or disable it entirely, but it's on out of the box.

The whole thing is built around plain-text markdown files. Your agent's personality lives in SOUL.md. Its long-term memory lives in MEMORY.md. Its knowledge of you lives in USER.md. These files are your agent.

The default install is not entirely production ready. Your gateway might be exposed to the public internet. Your default model might be eating your API budget. And without a few key configuration steps, your agent has no idea who you are or what it's allowed to do.

These are the five things that I would do after you install OpenClaw.

FYI: OpenClaw moves fast — updates ship 2–3 times a week and the UI changes regularly. The steps here are based on v2026.5.x. If something looks different in your version, check the official docs first. And as always, be careful giving any agent access to your files, accounts, and messaging apps. Start with read-only tasks and expand permissions as you build trust.

Opening the Dashboard
1. Lock Down Your Gateway
2. Switch to a Cheaper Model
3. Write Your SOUL.md With Boundaries
4. Seed Your Memory Files
5. Back Up Your Workspace and Use /new
Resources

Prerequisites

OpenClaw installed and running
Access to your API provider dashboard (Anthropic, OpenAI, or similar)

Opening the Dashboard

The dashboard runs at http://127.0.0.1:18789 by default. The easiest way to open it with your token already attached is to run this from the terminal on the machine where OpenClaw is installed:

openclaw dashboard

This opens the dashboard in your browser with a clean URL. If it asks for a token, run this to get it:

openclaw config get gateway.auth.token

Then paste it into the dashboard login prompt. See the dashboard docs for more detail.

If you've already logged in before, just go straight to http://127.0.0.1:18789. Your browser should have the session cached.

Steps

1. Lock Down Your Gateway

Good news: the default install gets this right. Bind mode is loopback and auth mode is token out of the box. If you installed via the quick-start script, verify this. Some install paths skip token setup during onboarding.

The reason this is still Step 1 is that it's easy to accidentally break, and most people never verify it.

Go to Settings → Infrastructure and confirm these two settings.

Gateway Bind Mode: should be loopback for a local setup. This controls who can reach the port at all — loopback means only 127.0.0.1, so nothing outside the machine can connect regardless of auth settings. lan binds to all network interfaces, which is fine on a home machine where your interfaces are private. On a VPS where the network interface has a public IP, lan puts the port on the internet. That's where the real exposure happens. If you need remote access, use tailnet (Tailscale) rather than lan — it keeps the port off the public internet.

Gateway Auth Mode: should be token. This controls what happens once someone reaches the port. If it's none, anyone who can reach the port connects with no credentials at all. On loopback that's low risk. On a public bind it's a disaster. There are thousands of OpenClaw instances exposed on the public internet right now, most of them are the result of changing bind mode without realizing what that exposes.

While you're here, check two more things:

Insecure Control UI Auth Toggle: may be enabled from your initial setup. Turn it off. When on (allowInsecureAuth: true), it lets localhost Control UI sessions bypass device identity checks in non-secure HTTP contexts, it's a compatibility workaround that shouldn't be left on in normal use. The security audit will flag it if it's enabled.
Control UI Allowed Origins: should list your specific origins (e.g., http://localhost:18789). Never set this to *.

To verify from the command line:

openclaw config get gateway.auth.mode
# should print: token

openclaw config get gateway.bind
# should print: loopback

If either prints something different, fix it in the dashboard before moving on.

Run the security audit. OpenClaw has a built-in security audit command. Run it now:

openclaw security audit

For a more thorough check that includes live probes:

openclaw security audit --deep

If it flags issues, --fix applies the safe defaults automatically:

openclaw security audit --fix

Then tell your agent to keep checking:

Read https://docs.openclaw.ai/gateway/security, run `openclaw security audit --deep`,
and send me a summary of any findings. Then schedule yourself to repeat this twice a day.

Pin your version. OpenClaw ships updates 2–3 times a week and some of them break things. The community built a tracker: isitstable.com/openclaw. Check it before you update, then install the recommended stable release:

openclaw update --tag <stable-version>

This handles the doctor check and gateway restart automatically. If you need to roll back to an older version, the manual fallback is npm i -g openclaw@<version> followed by openclaw doctor and openclaw gateway restart.

When you're ready to update, check the tracker, read the changelog, then update during a quiet period.

2. Switch to a Cheaper Model

Someone in the community went from $47/week to $6/week with two changes. It's one of the most upvoted posts in r/openclaw. That's the whole story for this step.

The default model on most OpenClaw installs is whatever was set during onboarding, often a top-tier model like GPT-5 or Opus. That's great for setup, you want the best reasoning when configuring your workspace files and personality. For daily use it works fine too, but it gets expensive fast. Your agent is checking calendars, drafting short replies, and running heartbeat tasks every 30 minutes. None of that needs frontier-model reasoning, and you're paying frontier-model prices for all of it.

Here's a breakdown of what the community recommends based on your budget and hardware:

If you want the best results and don't want to think about cost, Opus with Sonnet as fallback is the standard recommendation. Just be warned. It's expensive.

The cheapest option: use your ChatGPT Plus subscription. If you're already paying $20/month for ChatGPT Plus, you can connect OpenClaw to it via OpenAI Codex OAuth. That means you're using your existing subscription instead of paying separately per token. OpenAI explicitly supports this for third-party tools like OpenClaw. To set it up:

openclaw onboard --auth-choice openai-codex

Or if you're already past onboarding:

openclaw models auth login --provider openai-codex

This opens an OAuth flow to sign in with your ChatGPT account. Once connected, set your model to openai/gpt-5.5 and OpenClaw automatically uses the Codex subscription runtime. Usage limits apply. Check OpenAI's plan comparison for current details on what Plus vs Pro covers.

Note: Anthropic does allow Claude subscription auth (Claude Pro or Max) via Claude CLI reuse — run openclaw models auth login --provider anthropic --method cli --set-default. For production use, an API key is more reliable.

If you want to keep bills low without going local, Minimax M2.7 via API is worth knowing about. It's not as capable as Opus or Sonnet but it's significantly cheaper and the community rates it as surprisingly good for most daily tasks.

If your machine has 32GB+ RAM, local models become viable and can bring your API costs close to zero for routine work. A common setup: Opus or Sonnet for planning and complex reasoning, then a local model like Qwen Coder (8B parameter, free to run) for the actual code generation. On Apple Silicon (Mac Mini, MacBook Pro) the unified memory means RAM alone is enough for good performance on smaller models. On a PC or Linux box, a dedicated GPU makes a big difference, without one, local models run on CPU and can be slow enough to be frustrating for interactive use.

Where to change it: First, make sure your API key is set. The cleanest way is to add it to ~/.openclaw/.env:

# ~/.openclaw/.env
ANTHROPIC_API_KEY=sk-ant-...
OPENAI_API_KEY=sk-...

OpenClaw picks this up automatically at startup. Make sure this file isn't committed to a public repo, it contains your credentials.

Then go to Settings → AI & Agents → Models tab and edit the Model JSON field directly:

{
  "primary": "anthropic/claude-sonnet-4-5",
  "fallback": "anthropic/claude-haiku-4-5"
}

The fallback kicks in if the primary is rate-limited or unavailable. Hit Save → Apply.

The SOUL.md trick: The second change that made the $47→$6 difference was adding one line to SOUL.md:

Only use a more powerful model when I explicitly ask for deep analysis.

This lets the agent self-route. Routine tasks stay cheap. You ask for "deep analysis" when you actually need it.

Check your costs: Go to Control → Usage in the sidebar. It shows total tokens, cost, and a breakdown by model. Check it daily in your first week until you understand your baseline. Keep an eye on the cache hit rate, a high rate means you're not paying full price for repeated context, since cached tokens cost significantly less than fresh input tokens.

3. Write Your SOUL.md With Boundaries

SOUL.md is the character sheet for your agent. It defines personality, voice, temperament, and what it's allowed to do. Most people fill it in during onboarding with vague answers and never touch it again. That's a mistake.

The file lives in your OpenClaw workspace alongside a handful of other markdown files: AGENTS.md, MEMORY.md, USER.md, IDENTITY.md. Together these plain-text files are your agent. If you ever migrate to new hardware, these files are what you bring with you.

Go to Agent in the sidebar and click the SOUL button, under Files. The default template is already there and it's actually pretty good. What it doesn't have is your specific boundaries. Add these at the bottom:

## Identity
You are [name]. You are a collaborator, not an assistant.
Push back when I'm wrong. Challenge ideas during brainstorms.
When I'm heads-down, keep it crisp.

## Defaults
Only use a more powerful model when I explicitly ask for deep analysis.
For routine tasks, use the cheapest capable model.

## Boundaries
Never delete files without explicit confirmation.
Never send messages on my behalf without showing me the draft first.
Never make purchases or API calls that cost money without asking.
If a task fails twice with the same error, stop and report. Do not retry.

That last section is easy to skip. Without explicit boundaries, your agent will make reasonable-sounding decisions that you didn't actually authorize.

The aggressive note-taker trick: Add this to both SOUL.md and AGENTS.md:

You are an aggressive note-taker. After every significant session,
write key decisions, preferences, and facts into your daily log.

SOUL.md gets it so the behavior is part of the agent's core identity. AGENTS.md gets it so it's enforced as an operating rule. Together they make it stick. Without both, the agent may follow the instruction in some sessions but not others. This is the single biggest thing you can do to prevent memory degradation over time.

4. Seed Your Memory Files

The biggest complaint from people who've been using OpenClaw for a few weeks is that it starts forgetting things. The experience gets less magical and more frustrating as you keep re-explaining context it should already know.

This is a known problem in the community and it's not fully solved. But it's manageable if you set things up right from the start.

Seed MEMORY.md before your first real session. Go to Agent in the sidebar, then click the MEMORY button. On a fresh install it shows as "MISSING". Clicking it opens an empty editor and saving creates the file.

MEMORY.md is for curated, distilled facts the agent needs to remember across every session: standing rules, key decisions, strong preferences. It gets injected into the context window on every turn, so keep it lean. This is not a journal or a log:

# Memory

## Preferences
- Communication style: direct and concise, skip filler phrases
- Response length: brief by default, thorough when I ask for detail
- Don't ask clarifying questions for simple tasks. Just do it.

## Standing Rules
- Always show me a draft before sending anything externally (email, messages, posts)
- Ask before making calendar changes or bookings
- If a task fails twice with the same error, stop and report. Don't keep retrying.
- Never modify config files without telling me what you're changing and why

## Key Context
- Main tools I use: [e.g. VS Code, GitHub, Notion, Slack]
- Current focus: [e.g. shipping a feature, writing content, job search]
- Things I'm working on this month: [1-3 active projects]

Keep MEMORY.md short. If it gets too long, OpenClaw truncates it when injecting into context, which means the stuff at the bottom silently disappears. Detailed notes belong in memory/YYYY-MM-DD.md daily logs, not here.

USER.md is different. Click the USER button on the same page. This is the agent's profile of you as a person: your background, role, working style, what you care about. The agent builds this over time, but seeding it upfront saves weeks of it figuring things out:

# User Profile

## Who I Am
- Name: [your name]
- Role: [what you do, e.g. "frontend engineer at a fintech startup"]
- Location / timezone: [city, UTC offset]
- Working hours: [e.g. 9am–6pm weekdays]

## How I Work
- I prefer [async / real-time] communication
- I get annoyed when: [e.g. things are over-explained, asked obvious questions]
- I work best when: [e.g. given context upfront, shown options not just answers]

## What I'm Trying to Do With OpenClaw
- [e.g. automate my morning briefing, manage email triage, track projects]
- My biggest time sink right now: [what you want help with most]

The short version: USER.md is who you are. MEMORY.md is what the agent must remember. AGENTS.md is the agent's operating procedure: how it behaves, what it does on startup, routing rules. All three get injected into every session, so they all matter.

Enable Dreaming. Go to your OpenClaw dashboard, find the Dreaming tab, and toggle it on. This is a beta feature with two phases: a shallow phase that writes session summaries to DREAMS.md, and a deep phase that promotes the strongest memories into MEMORY.md as permanent long-term storage. If you enable it and don't see things showing up in MEMORY.md right away, that's normal. Only the deep phase promotes to permanent memory, and it runs on its own schedule. Without Dreaming, session logs accumulate but never get distilled into anything the agent reliably recalls.

5. Back Up Your Workspace and Use /new

How sessions actually work. Every message you send in a session gets included in every future API call in that session. After a few hours of chatting, you're sending thousands of tokens of old conversation with every new message. It costs money, and it makes your agent slower and more confused as the context gets cluttered.

OpenClaw handles this in two ways.

Compaction happens automatically when the context window fills up. It summarizes older conversation history into a condensed entry to free up space. You can also trigger it manually with /compact before a long task, or guide what it focuses on:

/compact Focus on the deployment task

/new starts a completely fresh session. Your agent keeps everything: SOUL.md, MEMORY.md, USER.md, all your workspace files. You're just clearing the conversation buffer. Use it when you're switching topics or starting a new task. Many people in the community report meaningful cost savings just from using /new regularly. Most people don't know it exists.

Also learn /btw. It fires off a side question without touching your main session context. Great for quick lookups mid-task without opening a whole new session.

The key rule: anything important needs to be written to files, not just said in chat. Session memory dies on compaction. If you told your agent something three days ago in conversation, it may not remember it. If it's in MEMORY.md, it will.

Back up your workspace files. Your agent's entire state (personality, memory, projects, tools) lives in markdown files in the OpenClaw workspace directory. If something goes wrong (and eventually something will), you want to be able to roll back. Make sure to use a private repo. Just ask your agent:

Help me put my OpenClaw workspace files onto a private GitHub repo
and commit changes automatically after each session.

This takes about ten minutes and has saved people from complete resets when their agent went off the rails or a config change broke something.

Check Control → Usage daily in your first week. The usage panel shows total tokens, cost, and a breakdown by model. You're looking for two things: your baseline daily cost, and your cache hit rate. A high cache hit rate means you're not paying full price for repeated context. That's healthy. If costs are higher than expected, check whether your context profile is set too large under Settings → AI & Agents → Agent Defaults → Bootstrap Max Chars.

After the first week you'll have a sense of what normal looks like. Set a budget alert at 2x your daily baseline so you get notified if something starts running away. A misconfigured heartbeat task or a loop in an automation can burn through tokens fast without any visible output.

Resources

🚀 Try Amazon Lightsail — run OpenClaw on a dedicated VPS
OpenClaw docs
OpenClaw security audit docs
ClawHub skills marketplace
Is it stable? — check before you update
Tina's OpenClaw setup guide — the video that inspired a lot of this post

Conclusion

These five steps take a bit of time to do right. The config changes (gateway, model, SOUL.md) take about 30 minutes. Getting your memory files properly seeded and GitHub backup set up will take a bit longer, but it's worth doing before your first real session.

Let me know in the comments if I missed anything. I'm still learning this thing too.

Build Your Own AI Butler - A Scheduled Agent That Runs Itself!

Erik Hanchett — Wed, 06 May 2026 16:00:47 +0000

I want an AI agent that works for me. I want it to search up the latest news, and I want it to deliver it to me in a daily message. I want to chat with it, and get advice. I want to expand its capabilities in the future. And most importantly I want to control it. Basically, I want Jarvis.

Yes Jarvis, the fictional AI character in the Marvel Cinematic Universe (MCU), serving as Tony Stark's butler. I've never had my own agentic butler, and now that I think about it who wouldn't? 😆 A few years ago I would have told you this would have never happened. But today with the rise of agents the future is here.

Well sort of... we are getting closer than ever though!

To take on this task one of the most obvious routes was to use something like OpenClaw. Except, OpenClaw is too new, and a little too much for what I needed, so like any good engineer I decided to roll my own. OpenClaw is an open-source, autonomous AI agent that runs locally on a your machine or VPS to automate tasks.

Recently Amazon Bedrock AgentCore released its managed harness in preview. You define the agent in a config file and a system prompt, and then deploy it. That was it! From my research it looked very straightforward to get up and running, and it could save me a lot of time in the long run. So I decided to take the journey to create my very own Jarvis.

If you want the conceptual breakdown of what a harness actually is in more detail, my friend Morgan's post on dev.to covers that well. This post is the hands-on build.

After several hours of tinkering and research I created "The Pulse." It opens Hacker News in a real browser, grabs Reddit posts via RSS, saves everything to persistent storage, and every 6 hours writes a trending stories digest. It messages me every day, or I can message it anytime and ask what's happening in AI. It reads from the data it's been collecting all day.

If you're more like me and love videos, check out the full video below on how to get started. I'm also including the source code so you can try it yourself. Otherwise continue on and learn all about how to get started! Feel free to let me know how it goes.

Full code:

aws-samples / sample-AgentCore-Managed-Harness-News

AgentCore Managed Harness News Sample — The Pulse

A sample AgentCore managed harness project that runs a scheduled news digest agent ("The Pulse") on Amazon Bedrock AgentCore and posts the results to Telegram.

The agent is scheduled with EventBridge Scheduler, invoked via a Lambda trigger, and uses AgentCore Memory to retain context across runs. It's a realistic end-to-end example of building a recurring, long-running agent on AWS.

What's in here

AgentCore-News-Sample/
├── agentcore/
│   ├── agentcore.json          # Project config (runtimes, memories, etc.)
│   ├── aws-targets.json        # AWS account + region to deploy into
│   ├── cdk/                    # CDK infrastructure (@aws/agentcore-cdk)
│   │   ├── bin/cdk.ts          # CDK entry — synthesizes both stacks
│   │   ├── lib/cdk-stack.ts    # AgentCore stack (agent, memory, roles)
│   │   ├── lib/scheduler-stack.ts  # Scheduler + Lambda trigger
│   │   └── lambda/pulse-trigger/   # Lambda that invokes the harness
│   └── .llm-context/           # Type definitions for AI coding assistants

…

View on GitHub

AgentCore Harness is in preview. The CLI, pricing, and some APIs may change. Check the AgentCore docs for the latest.

Table of Contents

What We're Building
Why Not Just Use Lambda?
Prerequisites
Create the Harness Project
Configure the Agent
Deploy
Test the Hourly Collection
Test the Summary Digest
Ask It Questions
Pull Data Out Without Burning Tokens
Schedule It With EventBridge and Lambda
Troubleshooting
Cost Estimate
Cleanup
What's Next

What We're Building

Don't worry if this diagram looks intimidating! The most complicated part is just getting the EventBridge connected with the correct IAM roles to the harness and dealing with the infrastructure code if you're new to that. Let's break down the flow here.

EventBridge fires every hour and triggers a Lambda. EventBridge is AWS's scheduler service, think of it like a cron job in the cloud. The Lambda makes one API call to the harness. Inside the harness, the agent runs in its own microVM, which is basically a lightweight virtual machine that spins up just for your session with its own CPU, memory, and filesystem. The agent opens a browser, scrapes HN, fetches Reddit RSS, and saves a snapshot. Every 6th run it reads all the snapshots, finds trends, and writes a digest. And because the session ID stays the same across runs, all that data accumulates on /mnt/data. You can also just talk to it anytime through the CLI and ask what's trending.

Why Not Just Use Lambda?

Before we get into the details, one question you may be thinking is couldn't we do all this with just a Lambda, some Strands Agents code, an LLM, and a dream? For a simple one-shot task, you are probably right. But this agent needs a few things Lambda can't give you, which makes this approach well worth it.

First, the agent opens a real browser to scrape Hacker News. Lambda can't spin up a managed browser session. You'd need Fargate plus Playwright, and now you're managing containers. I love containers, but let's skip it for this scenario.

Second, it saves hourly snapshots to /mnt/data/runs/ and reads them back 6 hours later. Lambda's /tmp gets wiped after every invocation. You'd need S3 plus custom read/write logic for every file operation. That's a lot of work for what should be "save a file."

Third, the 6-hour summary run reads all the accumulated data, compares scores across snapshots, identifies trends, and writes a digest. That can take a while. Lambda maxes out at 15 minutes. The harness defaults to a 1-hour timeout per invocation (I set mine to 30 minutes since that's plenty), and the microVM itself can stay alive for up to 8 hours across multiple invocations.

And then there's memory. AgentCore Memory is a built-in service that stores facts, preferences, and conversation summaries across sessions. So "What did I ask about yesterday?" works because the memory carries context forward. In Lambda, you'd need DynamoDB plus a custom integration.

Could you build all of this with Lambda plus S3 plus Fargate plus DynamoDB plus Step Functions? Sure. That's five services instead of one. That's four too many for this tutorial.

Prerequisites

Node.js 20+
AWS credentials configured in a preview region (us-west-2, us-east-1, eu-central-1, or ap-southeast-2)
CDK bootstrapped in your account (cdk bootstrap). CDK is the AWS Cloud Development Kit. It lets you define infrastructure in TypeScript instead of clicking through the console. If you haven't used it before, npm install -g aws-cdk and then cdk bootstrap in your account.
The AgentCore CLI:

npm install -g @aws/agentcore@preview

Bedrock model access for Claude Sonnet 4.6 in your region. As of late 2025, Bedrock gives you automatic access to all serverless models in your region without needing to enable them individually. If your organization uses IAM policies or SCPs to restrict model access, make sure Sonnet isn't blocked. You can verify by opening the Bedrock console and trying the model in the playground.

Create the Harness Project

This is where the fun begins. We'll create our very first managed harness.

agentcore create \
  --name thepulse \
  --model-provider bedrock \
  --session-storage-mount-path /mnt/data

cd thepulse

That one command scaffolds the whole project. Harness config, memory, session storage, CDK app, IAM role. The --session-storage-mount-path flag wires up persistent storage so the platform creates a /mnt/data mount point for you. You don't have to worry about a Dockerfile, or container to manage.

Now add the browser tool. AgentCore Browser is a managed headless Chrome instance that the harness can spin up on demand. Your agent can navigate pages, click elements, extract content, basically anything you'd do with Playwright but without managing the browser infrastructure yourself.

agentcore add tool --harness thepulse --type agentcore_browser --name browser

Here's what you end up with:

thepulse/
├── agentcore/
│   ├── agentcore.json          # Project-level resource config
│   ├── aws-targets.json        # Deployment targets (account, region)
│   ├── .env.local              # Local dev config (gitignored)
│   └── cdk/                    # CDK TypeScript app
├── app/
│   └── thepulse/
│       ├── harness.json        # Agent config
│       └── system-prompt.md    # Agent instructions

Configure the Agent

Our AgentCore CLI already set up the model, memory, and session storage. You just need to tweak the execution limits and write the system prompt.

Edit app/thepulse/harness.json:

{
  "name": "thepulse",
  "model": {
    "provider": "bedrock",
    "modelId": "global.anthropic.claude-sonnet-4-6"
  },
  "tools": [
    {
      "type": "agentcore_browser",
      "name": "browser"
    }
  ],
  "skills": [],
  "memory": { "name": "thepulseMemory" },
  "sessionStoragePath": "/mnt/data",
  "maxIterations": 75,
  "timeoutSeconds": 1800
}

A few things worth mentioning here.

I set maxIterations to 75 because browser interactions are chatty. That eats through iterations fast, and 75 gives room for the full HN browser scrape plus Reddit RSS plus file operations without the agent hitting the ceiling.

timeoutSeconds is 1800 (30 minutes). Browser sessions take time, and the summary run reads a lot of data. I didn't hit too many timeouts when testing, but this was a just-in-case update.

This next setting is really useful. The platform creates the /mnt/data mount point automatically when you set sessionStoragePath. This mount point will be shared per session, no matter if the session times out.

Now edit app/thepulse/system-prompt.md. The CLI created this file with a default prompt. Replace it:

You are The Pulse, an AI research agent that monitors Hacker News
and Reddit for AI/ML stories.

You have two modes:

### HOURLY COLLECTION
When the prompt says "hourly run":

**Hacker News (browser):**
1. Use the browser tool to open https://news.ycombinator.com
2. Extract the top 30 stories: title, score, comment count, URL
3. Close the browser session when done

**Reddit (RSS — do NOT use the browser):**
Reddit blocks automated browser access (403). Use the RSS feed instead:
1. Shell: `curl -s -A 'ThePulse/1.0'
   'https://www.reddit.com/r/MachineLearning/.rss'`
2. Parse the XML to extract post titles, URLs, authors, and dates
3. Note: RSS does not include upvote scores. That's expected.
4. Also try r/artificial: `curl -s -A 'ThePulse/1.0'
   'https://www.reddit.com/r/artificial/.rss'`

**Save the snapshot:**
1. Combine HN and Reddit data into a single JSON file
2. Save to /mnt/data/runs/YYYY-MM-DD-HH.json
3. If a previous hour's snapshot exists (check /mnt/data/runs/),
   compare and flag:
   - Stories that appeared in both snapshots (persistent)
   - HN stories with rising scores

### SUMMARY DIGEST
When the prompt says "generate summary":
1. Read all snapshots from /mnt/data/runs/ for the last 6 hours
2. Identify stories that appeared in multiple snapshots
   (persistent presence = trending)
3. Identify stories with rising scores across snapshots
4. Deduplicate and rank by persistence, score growth, and
   comment activity
5. Write a markdown digest to
   /mnt/data/digests/YYYY-MM-DD-{morning|afternoon|evening|night}.md
6. Include the top 10 trending stories with: title, source
   (HN/Reddit), peak score, trend direction, URL

### INTERACTIVE
When a user asks a question:
- Read from /mnt/data/runs/ and /mnt/data/digests/ to answer
- Use memory for conversational context

## Important
- /mnt/data is persistent session storage. Use the same session ID
  across runs so data accumulates.
- Always create directories before writing:
  `mkdir -p /mnt/data/runs /mnt/data/digests`

I put the collection to be hourly and the snapshots to run every six hours. Retrospectively, this is a lot of data, and I could certainly have expanded that. I'd say collecting twice a day and having a snapshot created once a day would be fine as well. Feel free to tweak this prompt to your liking.

One gotcha I'd like to pass on is that Reddit doesn't like agents scraping its data. The agent kept trying to open Reddit in the browser, getting 403'd, and burning 5-6 iterations before giving up. I sat there watching it retry over and over thinking "please just stop." The RSS feed at reddit.com/r/MachineLearning/.rss works every time. Putting it explicitly in the system prompt saves you from that pain.

Deploy

agentcore deploy

One command. It provisions the harness, memory, IAM role, session storage, and the underlying microVM infrastructure. This takes about 3-5 minutes because it's also spinning up AgentCore Memory and running CDK for the IAM roles.

You can verify what got created:

agentcore status --json

Test the Hourly Collection

To test this out you'll need a stable session ID so /mnt/data accumulates across runs, as I mentioned earlier. The session ID needs to be at least 33 characters (a UUID is 36, so that works). This is important because the same session ID means the same filesystem. That's how data builds up over time.

SESSION_ID="thepulse-$(uuidgen)"
echo $SESSION_ID  # Save this. You'll reuse it for every run.

agentcore invoke --harness thepulse \
  --session-id "$SESSION_ID" \
  --actor-id scheduler \
  "Hourly run. Collect AI/ML stories from Hacker News and Reddit. Save the snapshot."

The agent will open a managed Chrome browser, navigate to news.ycombinator.com, extract stories, fetch Reddit via RSS, and save everything to /mnt/data/runs/.

Verify it worked:

agentcore invoke --exec --harness thepulse \
  --session-id "$SESSION_ID" \
  "ls -la /mnt/data/runs/"

That --exec flag is one of my favorite things about the harness. It runs a shell command directly on the microVM. It's not connecting to any LLM so no tokens are used. You can use it to poke around the filesystem anytime without spending money.

Test the Summary Digest

Run the collection a couple times (or wait a few hours), then:

agentcore invoke --harness thepulse \
  --session-id "$SESSION_ID" \
  --actor-id scheduler \
  "Generate summary. Read all snapshots from the last 6 hours and write a trending stories digest."

The agent reads all the hourly snapshots, identifies stories that appeared multiple times (trending), flags rising scores, and writes a markdown digest.

Ask It Questions

agentcore invoke --harness thepulse \
  --session-id "$SESSION_ID" \
  --actor-id demo-user \
  "What's trending in AI right now?"

The agent reads from /mnt/data/runs/ and /mnt/data/digests/ to answer with real data. Not hallucinated summaries, actual scores and URLs from the snapshots it collected. I really liked this part. The agent isn't guessing. It's reading files it wrote earlier that day.

Schedule It With EventBridge and Lambda

The agentcore create command already scaffolded a CDK app at agentcore/cdk/. We'll add a Lambda trigger and an EventBridge schedule to that existing project. EventBridge Scheduler is the AWS service that fires events on a cron schedule. We'll have it invoke a Lambda every hour, and that Lambda calls the harness. One agentcore deploy handles the harness, one cdk deploy handles the scheduler. I like keeping these separate because you iterate on the agent config way more often than the scheduling infrastructure.

Set Up the Lambda

mkdir -p agentcore/cdk/lambda/pulse-trigger
cd agentcore/cdk/lambda/pulse-trigger
npm init -y
npm install @aws-sdk/client-bedrock-agentcore @aws-sdk/client-secrets-manager
npm install -D typescript @types/node esbuild
cd ../../../..

Create agentcore/cdk/lambda/pulse-trigger/index.ts:

import {
  BedrockAgentCoreClient,
  InvokeHarnessCommand,
} from "@aws-sdk/client-bedrock-agentcore";
import {
  SecretsManagerClient,
  GetSecretValueCommand,
} from "@aws-sdk/client-secrets-manager";

interface TelegramSecret {
  botToken: string;
  defaultChatId: string;
}

const agentCore = new BedrockAgentCoreClient({ region: process.env.AWS_REGION });
const secrets = new SecretsManagerClient({ region: process.env.AWS_REGION });

// Cache the secret across warm invocations
let cachedSecret: { value: TelegramSecret; expiry: number } | null = null;
const SECRET_TTL_MS = 5 * 60 * 1000; // 5 minutes

async function getSecret(): Promise<TelegramSecret> {
  if (cachedSecret && Date.now() < cachedSecret.expiry) {
    return cachedSecret.value;
  }
  const secretArn = process.env.TELEGRAM_SECRET_ARN;
  if (!secretArn) throw new Error("Missing TELEGRAM_SECRET_ARN env var");

  const res = await secrets.send(
    new GetSecretValueCommand({ SecretId: secretArn })
  );
  const value: TelegramSecret = JSON.parse(res.SecretString!);
  cachedSecret = { value, expiry: Date.now() + SECRET_TTL_MS };
  return value;
}

async function sendToTelegram(
  botToken: string, chatId: string, text: string
) {
  // Telegram's message limit is 4096 chars. Split if needed.
  const chunks = text.match(/[\s\S]{1,4000}/g) || [];
  for (const chunk of chunks) {
    const res = await fetch(
      `https://api.telegram.org/bot${botToken}/sendMessage`,
      {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({
          chat_id: chatId,
          text: chunk,
          parse_mode: "Markdown",
        }),
      }
    );
    if (!res.ok) {
      console.error("Telegram send failed:", await res.text());
    }
  }
}

export const handler = async () => {
  const hour = new Date().getUTCHours();
  const sessionId = process.env.STABLE_SESSION_ID!;
  const harnessArn = process.env.HARNESS_ARN!;

  const isSummaryRun = hour % 6 === 0;

  const prompt = isSummaryRun
    ? "Generate summary. Read all snapshots from the last 6 hours and write a trending stories digest."
    : "Hourly run. Collect AI/ML stories from Hacker News and Reddit. Save the snapshot.";

  const command = new InvokeHarnessCommand({
    harnessArn,
    runtimeSessionId: sessionId,
    actorId: "scheduler",
    messages: [{ role: "user", content: [{ text: prompt }] }],
  });

  const response = await agentCore.send(command);

  // Collect the full response text from the stream
  let responseText = "";
  let chunkCount = 0;
  if (response.stream) {
    for await (const event of response.stream) {
      chunkCount++;
      if ("contentBlockDelta" in event) {
        const delta = (event as any).contentBlockDelta?.delta;
        if (delta && "text" in delta) {
          responseText += delta.text;
          process.stdout.write(delta.text);
        }
      }
    }
  }

  console.log(
    `\n[pulse-trigger] Stream complete — ${chunkCount} chunks`
  );

  // On summary runs, send the digest to Telegram
  if (isSummaryRun && responseText) {
    const { botToken, defaultChatId } = await getSecret();
    await sendToTelegram(botToken, defaultChatId, responseText);
  }

  return {
    statusCode: 200,
    hour,
    type: isSummaryRun ? "summary" : "collection",
    digestSent: isSummaryRun,
  };
};

Let's break down what's happening here.

The Lambda passes a stable session ID (from an environment variable) so every hourly run writes to the same /mnt/data. It collects the full response text from the stream and logs it to CloudWatch. On summary runs, it sends the digest to Telegram using a bot token stored in Secrets Manager. Secrets Manager is the AWS service for storing sensitive values like API keys and tokens. You don't want a bot token sitting in an environment variable where anyone with console access can see it. The sendToTelegram function handles Telegram's 4096 character limit by chunking the text. I found the CloudWatch logging really helpful for debugging early on when the agent would occasionally get stuck in a browser loop.

Add the Scheduler Stack

Create agentcore/cdk/lib/scheduler-stack.ts. This is a CDK stack, which is basically a unit of deployment. Everything in this file gets deployed together as one CloudFormation stack.

import {
  Stack, StackProps, Duration, TimeZone, CfnOutput,
} from "aws-cdk-lib";
import { NodejsFunction } from "aws-cdk-lib/aws-lambda-nodejs";
import { Runtime } from "aws-cdk-lib/aws-lambda";
import { Secret } from "aws-cdk-lib/aws-secretsmanager";
import * as iam from "aws-cdk-lib/aws-iam";
import * as scheduler from "aws-cdk-lib/aws-scheduler";
import * as targets from "aws-cdk-lib/aws-scheduler-targets";
import { Construct } from "constructs";
import * as path from "path";

export interface PulseSchedulerStackProps extends StackProps {
  agentRuntimeArn: string;
  harnessArn: string;
  stableSessionId: string;
  telegramSecretArn: string;
}

export class PulseSchedulerStack extends Stack {
  constructor(
    scope: Construct, id: string, props: PulseSchedulerStackProps
  ) {
    super(scope, id, props);

    const telegramSecret = Secret.fromSecretCompleteArn(
      this, "TelegramSecret", props.telegramSecretArn
    );

    const triggerFn = new NodejsFunction(this, "PulseTrigger", {
      runtime: Runtime.NODEJS_22_X,
      entry: path.join(
        __dirname, "../../lambda/pulse-trigger/index.ts"
      ),
      handler: "handler",
      timeout: Duration.minutes(15),
      memorySize: 256,
      environment: {
        HARNESS_ARN: props.harnessArn,
        STABLE_SESSION_ID: props.stableSessionId,
        TELEGRAM_SECRET_ARN: props.telegramSecretArn,
      },
      bundling: {
        externalModules: [],
      },
    });

    triggerFn.addToRolePolicy(
      new iam.PolicyStatement({
        actions: [
          "bedrock-agentcore:InvokeHarness",
          "bedrock-agentcore:InvokeAgentRuntime",
        ],
        resources: [
          props.harnessArn,
          props.agentRuntimeArn,
        ],
      })
    );

    // Read access to the Telegram bot token secret
    telegramSecret.grantRead(triggerFn);

    new scheduler.Schedule(this, "HourlySchedule", {
      schedule: scheduler.ScheduleExpression.cron({
        minute: "0",
        hour: "*",
        timeZone: TimeZone.of("UTC"),
      }),
      target: new targets.LambdaInvoke(triggerFn, {}),
      description: "The Pulse — hourly AI/ML news collection",
    });

    new CfnOutput(this, "TriggerFunctionName", {
      value: triggerFn.functionName,
    });
  }
}

The telegramSecret.grantRead(triggerFn) line gives the Lambda permission to read the bot token from Secrets Manager. The bot token lives there instead of in environment variables so it doesn't show up in CloudFormation outputs or the Lambda console.

Wire it into agentcore/cdk/bin/cdk.ts:

import { PulseSchedulerStack } from "../lib/scheduler-stack";

// ... existing AgentCore stack code ...

new PulseSchedulerStack(app, "ThePulseScheduler", {
  harnessArn: "REPLACE_WITH_YOUR_HARNESS_ARN",
  agentRuntimeArn: "REPLACE_WITH_YOUR_RUNTIME_ARN",
  stableSessionId: "REPLACE_WITH_YOUR_SESSION_ID",
  telegramSecretArn: "REPLACE_WITH_YOUR_SECRET_ARN",
  env: {
    account: targets[0].account,
    region: targets[0].region,
  },
});

I'm showing placeholders here to make it clear what goes where. You can get your harness ARN and runtime ARN with agentcore status --json, and use the same session ID you've been testing with. The Telegram secret ARN comes from Secrets Manager (store your bot token and chat ID as a JSON object with botToken and defaultChatId keys).

That said, you shouldn't hardcode ARNs and secrets into source files you commit to git. The actual repo resolves the harness ARN and runtime ARN automatically from the deployed state file that agentcore deploy creates, and reads the Telegram secret ARN and session ID from environment variables. That way nothing sensitive ends up in version control. Check the cdk.ts in the repo for the full implementation.

Deploy and Test

# Install esbuild in the CDK project (needed for NodejsFunction)
cd agentcore/cdk && npm install esbuild --save-dev && cd ../..

# Deploy the harness
agentcore deploy

# Deploy the scheduler stack
cd agentcore/cdk && npm run build && npx cdk deploy ThePulseScheduler && cd ../..

Test the Lambda directly:

aws lambda invoke \
  --function-name $(aws cloudformation describe-stacks \
    --stack-name ThePulseScheduler \
    --query 'Stacks[0].Outputs[?OutputKey==`TriggerFunctionName`].OutputValue' \
    --output text) \
  --region us-west-2 \
  --cli-read-timeout 900 \
  /tmp/lambda-response.json

cat /tmp/lambda-response.json

The --cli-read-timeout 900 is important. The harness invocation takes a few minutes (the agent is browsing HN, fetching RSS, saving data), and the AWS CLI's default timeout is 60 seconds. Without it, you'll get a Read timeout error even though the Lambda is still running fine. Don't make this mistake like I did.

You should see {"statusCode":200,"hour":...,"type":"collection"}.

Troubleshooting

A few things I hit while building this. Hopefully they save you some time.

npm ci fails during CDK synth. If you use nodeModules in the bundling config instead of externalModules: [], CDK copies your package-lock.json into a temp directory and runs npm ci. If the lock file is even slightly out of sync with package.json, it fails. I went back and forth on this for a while before landing on the externalModules: [] approach that bundles everything with esbuild and skips npm ci entirely.

AccessDeniedException on ConverseStream. This one got me. Bedrock now gives automatic access to all models in your region, so the old "Model Access" page is gone. But if your organization uses IAM (Identity and Access Management) policies or SCPs (Service Control Policies) to restrict which models can be invoked, you'll get this error. Check with your admin to make sure the model isn't blocked by a deny policy. I hit this when I tried to use Haiku for cheaper collection runs in an account that had an SCP limiting models to Sonnet only. The error message doesn't make it obvious that it's a permissions issue.

Lambda times out but the agent is still running. The Lambda timeout (15 min max) and the harness timeout (30 min) are separate. If the agent takes longer than the Lambda allows, the Lambda dies but the harness session keeps running in the background. Check CloudWatch logs for the Lambda, and use agentcore logs --harness thepulse --since 1h for the harness side.

Reddit returns 403 in the browser. Reddit blocks automated browser access. The system prompt tells the agent to use RSS instead, but if you're iterating on the prompt and forget to include that instruction, the agent will waste iterations trying to open Reddit in the browser. Ask me how I know.

Cost Estimate

The main cost here is Bedrock model usage. Each hourly collection run uses around 10-15K tokens (browser interactions are chatty), and summary runs use more since they read all the accumulated data. Lambda and EventBridge are basically free at this scale.

You can cut costs by enabling a cheaper model like Haiku in the Bedrock console and passing a model override for collection runs. Keep Sonnet for the summary runs that need more reasoning. The harness supports per-invocation model overrides so you don't need to redeploy. You can also just reduce the number of times it collects data.

AgentCore Runtime and Browser have no separate charge during preview.

Check the Bedrock pricing page for current model token costs and the AgentCore pricing page for runtime and browser session rates.

Cleanup

Make sure you always clean up your stacks after trying out tutorials!

# Delete the scheduler stack
cd agentcore/cdk && npx cdk destroy ThePulseScheduler && cd ../..

# Delete the harness and all AgentCore resources
agentcore destroy

The agentcore destroy command removes the harness, memory, IAM role, and session storage. The CDK destroy removes the Lambda, EventBridge schedule, and any IAM roles CDK created.

What's Next

This is a starting point. I have thoughts on a few directions I could take my very own Jarvis 😊.

Right now the Telegram integration is outbound only. I want to add two-way chat so I can message the bot and ask questions (without just using the command line). That means an API Gateway webhook and a second Lambda that invokes the harness in interactive mode. The agent reads from /mnt/data to answer with real data.

More sources would be easy to add. The system prompt is just markdown. Add instructions for other news sources that a browser can reach. The nice thing is it would just take a prompt update and a new run of agentcore deploy.

I also want to try switching models per run. Enable Haiku in the Bedrock console and pass --model-id on collection runs for cheaper hourly scrapes. Keep Sonnet for the summary runs that need more reasoning. The harness supports this per-invocation without a redeploy.

And eventually, a dashboard. Have the agent generate an HTML page from the accumulated data and sync it to S3. Use --exec to run aws s3 sync from the microVM.

After building this, I'm convinced the harness approach works really well for simpler use cases like my personal news Jarvis. If your agent needs persistent state, scheduled runs, and a browser, this is way less infrastructure than stitching it together yourself. If you just need a one-shot agent that answers a question, stick with Lambda. And of course if you need maximum flexibility, using AgentCore runtime is your best bet!

Let me know in the comments what you think! Thanks!

Resources

Stop Reaching for Python: Strands Agents TypeScript SDK Just Hit 1.0

Erik Hanchett — Mon, 04 May 2026 20:11:08 +0000

A lot of production codebases are TypeScript. A lot of agent frameworks are Python. If yours is both, you either rewrite your stack or build a bridge between two languages. Strands Agents just shipped 1.0 of the TypeScript SDK, so now you don't have to. It's the full framework, native TypeScript types and all. And it does things Python can't, like running agents in the browser.

The Python SDK has been in production since May 2025. This is the same model-driven approach, now with full TypeScript types and Zod-validated tools.

Full disclosure, I'm a Developer Advocate for AWS. Strands is an open source project from AWS. I've been building with the Python SDK for months, so I was curious how the TypeScript version compares. So far, it's been great.

In this post we'll cover:

Getting a basic agent running
Defining type-safe tools with Zod
Connecting MCP servers
Streaming responses
Running agents in the browser
Multi-agent patterns: agent-as-tool, Graph, and Swarm

Get Started

Install the SDK:

npm install @strands-agents/sdk

Here's how it works.

Two Lines to a Working Agent

The API is small on purpose. Create an agent, then invoke.

import { Agent } from '@strands-agents/sdk'

const agent = new Agent({ systemPrompt: 'You are a helpful assistant.' })
const result = await agent.invoke('What makes TypeScript great for building agents?')

console.log(result.lastMessage)

Bedrock is the default model provider. If you want OpenAI, Anthropic, Google, or anything that works with the Vercel AI SDK, you swap one import:

import { Agent } from '@strands-agents/sdk'
import { OpenAIModel } from '@strands-agents/sdk/models/openai'

const model = new OpenAIModel({ api: 'chat', modelId: 'gpt-5.4' })
const agent = new Agent({ model, systemPrompt: 'You are a helpful assistant.' })

You just swap the model import. The agent, tools, and invocation pattern don't change at all.

Zod Tools

TypeScript is a good fit here because you're defining the contract between your agent and your tools at the type level. You define a tool with a Zod schema and get runtime validation plus full type inference at compile time. The model can't pass garbage to your tool without Zod catching it, and your editor knows the exact shape of every input before you even run anything.

Here's a GitHub lookup tool in about 30 lines:

import { Agent, tool } from '@strands-agents/sdk'
import { z } from 'zod'

const githubRepo = tool({
  name: 'get_github_repo',
  description: 'Get info about a GitHub repository.',
  inputSchema: z.object({
    owner: z.string().describe('Repository owner'),
    repo: z.string().describe('Repository name'),
  }),
  callback: async (input) => {
    const res = await fetch(`https://api.github.com` + `/repos/${input.owner}/${input.repo}`)
    const data = await res.json()
    return `${data.full_name} — ⭐ ${data.stargazers_count} stars`
  },
})

const agent = new Agent({
  tools: [githubRepo],
  systemPrompt: 'You are a developer assistant.',
})

The input parameter in that callback is fully typed. Your editor knows input.owner is a string. No any, no type casting.

The SDK also ships with built-in tools for bash, file editing, HTTP requests, and notebooks. Your agent can read files, hit APIs, and run shell commands without writing any tool code:

import { Agent } from '@strands-agents/sdk'
import { bash } from '@strands-agents/sdk/vended-tools/bash'
import { fileEditor } from '@strands-agents/sdk/vended-tools/file-editor'
import { httpRequest } from '@strands-agents/sdk/vended-tools/http-request'
import { notebook } from '@strands-agents/sdk/vended-tools/notebook'

const agent = new Agent({
  tools: [bash, fileEditor, httpRequest, notebook],
  systemPrompt: 'You are a helpful coding assistant.',
})

MCP

If you're already using MCP servers, they plug right in. I tested this with the filesystem MCP server and it worked well.

import { Agent, McpClient } from '@strands-agents/sdk'
import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js'

const mcp = new McpClient({
  transport: new StdioClientTransport({
    command: 'npx',
    args: ['-y', '@modelcontextprotocol/server-filesystem', process.cwd()],
  }),
})

const agent = new Agent({ tools: [mcp] })

Any MCP-compatible server works the same way. One McpClient import and you're done. I've used this with the filesystem server, a Postgres server, and a few custom ones, and the setup is identical every time.

Streaming

Async iterators let you generate chunks and stream them back to the user.

const agent = new Agent({ systemPrompt: 'You are a creative storyteller.', printer: false })

for await (const event of agent.stream('Tell me a short story about a brave toaster.')) {
  if (
    event.type === 'modelStreamUpdateEvent' &&
    event.event.type === 'modelContentBlockDeltaEvent' &&
    event.event.delta.type === 'textDelta'
  ) {
    process.stdout.write(event.event.delta.text)
  }
}

The event type checking is verbose. You're narrowing through three nested types to get to the actual text delta. That's just how TypeScript streaming works when the event union is this wide. Once you have the pattern, you copy it.

It Runs in the Browser

You can run agents in the browser. Most people don't think about this because the Python SDK can't do it natively.

There's a demo in the strands-agents/sdk-typescript repo where you chat with an agent and it builds a live HTML canvas in real time. The agent runs entirely client-side.

That opens up things that weren't possible before: local-first tools where the agent runs on the user's machine, interactive assistants embedded in your app without a server round-trip, or even running the model locally if you want to skip the round-trip entirely.

I cloned the demo and had it running in a few minutes.

git clone https://github.com/strands-agents/sdk-typescript.git
cd sdk-typescript/strands-ts/examples/browser-agent
npm install && npm run dev

Multi-Agent Patterns

The SDK ships with three ways to combine agents: agent-as-tool, Graph, and Swarm. Each one fits a different problem.

Agent-as-tool

This is the one you'll reach for most. Pass a sub-agent directly into another agent's tools array and it gets wrapped automatically. The outer agent decides when to call it, just like any other tool.

Think of a writer agent that has a researcher agent as a tool. The writer decides when it needs facts, calls the researcher, gets the results back, and uses them to write. The code below is exactly that.

import { Agent } from '@strands-agents/sdk'

const researcher = new Agent({
  id: 'researcher',
  name: 'Researcher',
  description: 'Finds factual information and returns concise bullet-point findings.',
  systemPrompt: 'You are a fact-finder. Return 3-5 concise bullet points. Be brief.',
  printer: false,
})

const writer = new Agent({
  systemPrompt: 'You are a prose writer. Use the Researcher tool to gather facts, then write one short paragraph.',
  tools: [researcher], // sub-agent auto-wrapped via asTool()
  printer: false,
})

const result = await writer.invoke('Write a paragraph about the deepest point in the ocean.')

Graph

Graph is for deterministic pipelines. You define agents as nodes and wire them together with edges. A node runs once all its upstream dependencies complete, so execution order is guaranteed. Nodes with no dependency between them can run in parallel.

This pattern works well when you know the steps upfront and need them to always run in the same order. A research pipeline is a good example. Plan the questions, research each one, then synthesize the results. You wouldn't want the synthesizer running before the researcher finishes, and you don't want the model deciding to skip steps.

import { Agent, Graph } from '@strands-agents/sdk'

const planner = new Agent({
  id: 'planner',
  printer: false,
  systemPrompt: 'Break the request into 2 short research questions.',
})
const researcher = new Agent({
  id: 'researcher',
  printer: false,
  systemPrompt: 'Answer each research question in 1-2 sentences. Be concise.',
})
const synthesiser = new Agent({
  id: 'synthesiser',
  printer: false,
  systemPrompt: 'Write a 2-3 sentence summary of the research.',
})

const graph = new Graph({
  nodes: [planner, researcher, synthesiser],
  edges: [
    ['planner', 'researcher'],
    ['researcher', 'synthesiser'],
  ],
})

// MultiAgentResult.content holds the combined output from terminus nodes
const result = await graph.invoke('What are the main impacts of lithium mining?')
console.log(result.content)

The edges array defines the DAG (directed acyclic graph — basically a dependency map). planner runs first, feeds into researcher, which feeds into synthesiser. The final output comes from the terminus node via result.content.

Swarm

Swarm is for when the path isn't known upfront. You define a set of agents with descriptions, pick a starting agent, and the model decides at runtime which agent handles the next step. Each agent either produces a final answer or hands off to another agent.

I'd reach for this when building something like a customer support bot where you don't know which specialist is needed until you see what the user actually wrote. The routing logic lives in the model, not in your code. You're not writing if request.includes('billing') anywhere.

import { Agent, Swarm } from '@strands-agents/sdk'

const triage = new Agent({
  id: 'triage',
  printer: false,
  description: 'Classifies the user request and routes it to the right specialist.',
  systemPrompt: 'Route to "billing" or "technical". Do not answer yourself.',
})
const billing = new Agent({
  id: 'billing',
  printer: false,
  description: 'Handles billing and payment questions.',
  systemPrompt: 'Resolve billing queries. Do not hand off further.',
})
const technical = new Agent({
  id: 'technical',
  printer: false,
  description: 'Handles technical and product questions.',
  systemPrompt: 'Resolve technical queries. Do not hand off further.',
})

const swarm = new Swarm({
  nodes: [triage, billing, technical],
  start: 'triage',
  maxSteps: 6,
})

const result = await swarm.invoke('My invoice shows the wrong amount.')
console.log(result.content)

Heads up if you're on Bedrock: Swarm uses structured output to drive handoffs. It forces a tool call to get the routing decision, and the current Claude Sonnet model on Bedrock throws a "does not support assistant message prefill" error when that happens. Swarm works fine with the Anthropic direct API or other providers that support forced tool choice. If you're on Bedrock and need dynamic routing, agent-as-tool is the safer option for now.

I haven't tested the plugin system, session persistence, or OpenTelemetry tracing yet. The plugin system looks simple to use and I'll probably dig into it next.

The SDK is open source. If you build something with it, I want to see it. The browser runtime especially. I'm curious where people take it.

What We Covered

The Strands Agents TypeScript SDK gives you a full agent framework without leaving your existing stack. Here's what we went through:

A basic agent runs in two lines. Bedrock is the default, but swapping to OpenAI or Anthropic is one import.
Zod tools give you runtime validation and compile-time type inference. The model can't pass bad input without Zod catching it.
MCP servers connect with a single McpClient import. Any MCP-compatible server works.
Streaming uses async iterators. Verbose event types, but that's TypeScript being TypeScript.
The browser runtime is real and working. Clone the demo and see it for yourself.
For multi-agent work: agent-as-tool for orchestrator/worker setups, Graph for fixed pipelines, Swarm for dynamic routing (just not on Bedrock yet).

If you want to go deeper, the TypeScript quickstart, the GitHub repo, and the API docs are the best next stops.

Watch the Full Video

If you prefer video format, here's a quick walkthrough of the TypeScript SDK and its key features:

DEV Community: Erik Hanchett

Nuxt vs SvelteKit: What works better?

The setup

The numbers

The Nuxt version: explicit API routes

The SvelteKit version: remote functions

What does Nuxt 5 offer?

My verdict

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

What is spec-driven development?

The trade-offs

The project: a Kiro birthday game

How I used SDD to build it

The tools that made it easier

Wrapping up

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

The app

Difference one: server functions vs server routes

Server components in both

Typed search params

What they actually share

Links

The verdict

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

Introduction

What loop engineering actually is

It's the agentic loop you already know

A practical example: fixing a PR on a loop

Automations are the other big use case

My take

3 Tools That Make AI Suck Less at Coding

Prerequisites

Find the mess: Fallow

Bonus: Knip

Review the diff: CodeRabbit

Measure the improvement: Kiln

How to pick

Conclusion

The most popular AI coding skills right now

Introduction

What is an agent skill?

The big workflow skills

Superpowers (obra/superpowers)

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

Matt Pocock's skills (mattpocock/skills)

GStack (garrytan/gstack)

GSD Core (open-gsd/gsd-core)

Framework skills and the "ships with your package" model

The Agent Toolkit for AWS

How to pick one and try it safely

Conclusion

TanStack Start Is Kind of a Big Deal

Introduction

Prerequisites

What we're building

Step 1: Create the app

Feature 1: One server function for reads and writes

Feature 2: Search params that are actually typed

Feature 3: Type safety that runs end to end by default

Adding in AI

Cleanup

Conclusion

Mastering the Latest TypeScript: What's New in 6.0 (and a Peek at 7)

Prerequisites

1. Native Temporal date and time types

2. Map.getOrInsert() and getOrInsertComputed()

3. RegExp.escape() for safe dynamic regex

4. The # subpath imports (and the tsconfig that powers them)

5. Smarter generic inference

tsconfig.json changes worth making now

What's coming in TypeScript 7

Wrapping up

Your Default Vite Config Is Not Enough (New with Vite 8)

Introduction

Prerequisites

Steps

1. server.forwardConsole

2. resolve.tsconfigPaths

3. server.proxy

4. server.hmr.overlay

4. The `#` subpath imports (and the tsconfig that powers them)