window.fetch = () => {
  return my_mocked_data;
};

Nowadays it's not as simple: we live in an isomorphic world where your Javascript runs on the server first and on the client then. This has several advantages:

• You can easily SSR your application for faster load times and better SEO
• The data loading is done on the server so there's no back and forth...you load the data from the db, it's injected into your application and you can just use it to build your page.

This is particularly important when you have a single server because the information is bound to travel at the speed of light. This means that if your server is in the United States and someone accesses it from Australia, the request would look something like this

Notice that the more API calls we make, the more the delay between when you load the page and when you can actually see the data increases.

This is how it would look with the isomorphic, server-side rendered model

Even with this very simple example we cut the total time in half because we don't need to request additional data: once the page is on the client, that's it.

The problem

As we hinted before, this approach sounds like the most reasonable...there's a problem however: testability! Doing end-to-end tests when a database is involved is not an easy task and while, to be frank, this mostly boils down to the lack of mocking ability of the database drivers, it's definitely something to keep in mind.

Now one of the solutions could be to simply add an API layer in front of our db and mock that, or we could contain all our db access into a single module and mock that module during testing, but both are not ideal: the first one adds an unnecessary network jump, the second one forces us to structure our code in a certain way and we are one new hire away from messing up that structure (and we would also need to reimplement all the logic in the mocking module).

What we really want is a way to write our code naturally while also having the ability to interact with the database from our tests.

Before we start

Small aside before we dive into the solution: this is an opinionated article, I'm going to use the recommended tools that, as of today, you can add to your SvelteKit project using pnpm dlx sv@latest add or pnpm dlx sv@latest create...let's jump right into it.

The solution

Let's start by creating a brand new SvelteKit project, we are going to select TypeScript, Prettier, ESLint, Playwright and Drizzle with SQLite (libSQL) as our stack (you can find the initial setup at the main branch of this repo)

> pnpm dlx sv@latest create
┌  Welcome to the Svelte CLI! (v0.9.2)
│
◇  Where would you like your project to be created?
│  svelte-mock-db
│
◇  Which template would you like?
│  SvelteKit minimal
│
◇  Add type checking with TypeScript?
│  Yes, using TypeScript syntax
│
◆  Project created
│
◇  What would you like to add to your project? (use arrow keys / space bar)
│  prettier, eslint, playwright, devtools-json, drizzle
│
◇  drizzle: Which database would you like to use?
│  SQLite
│
◇  drizzle: Which SQLite client would you like to use?
│  libSQL
│
◆  Successfully installed dependencies
│
◇  Successfully formatted modified files
│
◇  What's next? ───────────────────────────────────────────────────────────╮
│                                                                          │
│  📁 Project steps                                                        │
│                                                                          │
│    1: cd svelte-mock-db                                                  │
│    2: pnpm run dev --open                                                │
│                                                                          │
│  To close the dev server, hit Ctrl-C                                     │
│                                                                          │
│  🧩 Add-on steps                                                         │
│                                                                          │
│    drizzle:                                                              │
│      - You will need to set DATABASE_URL in your production environment  │
│      - Check DATABASE_URL in .env and adjust it to your needs            │
│      - Run pnpm run db:push to update your database schema               │
│                                                                          │
│  Stuck? Visit us at https://svelte.dev/chat                              │
│                                                                          │
├──────────────────────────────────────────────────────────────────────────╯
│
└  You're all set!

Let's explore the relevant files: our db lives in ./src/lib/server/db/index.ts

import { drizzle } from "drizzle-orm/libsql";
import { createClient } from "@libsql/client";
import * as schema from "./schema";
import { env } from "$env/dynamic/private";

if (!env.DATABASE_URL) throw new Error("DATABASE_URL is not set");

const client = createClient({ url: env.DATABASE_URL });

export const db = drizzle(client, { schema });

and here's our very simple schema (in ./src/lib/server/db/schema.ts)

import { sqliteTable, integer, text } from "drizzle-orm/sqlite-core";

export const user = sqliteTable("user", {
  id: integer("id").primaryKey(),
  name: text("name"),
});

In case we need it we can obviously export other tables from here.

As you might have guessed, we do need a DATABASE_URL environment variable in our .env file

DATABASE_URL="file:local.db"

We can use file:local.db to generate a SQLite db locally (this setup uses SQLite but it can work with more complex setups with PostgreSQL and MySQL in the same way).

If we run pnpm db:generate and pnpm db:migrate we'll notice a brand new local.db file generated in our project with a user table with an id and a name column.

Let's actually take a look at how we use this db. In /src/routes/+page.server.ts we can see our load function

import { db } from "$lib/server/db";
import { user } from "$lib/server/db/schema";

export async function load() {
  const users = await db.select().from(user).all();
  return {
    users,
  };
}

For the sake of the example we are gonna just select all the users and return them. We can then access them in our /src/routes/+page.svelte and show them all in a list

<script lang="ts">
	let { data } = $props();
</script>

<ul>
	{#each data.users as user (user.id)}
		<li>{user.id} - {user.name}</li>
	{/each}
</ul>

Some changes

Before we start writing our tests we need to make some changes: what we will do is actually spin up a brand new database specific for testing but this introduces a slight problem...since Playwright doesn't run through vite we can't use any virtual module from SvelteKit...luckily we don't need to do much to change this

import { drizzle } from "drizzle-orm/libsql";
import { createClient } from "@libsql/client";
import * as schema from "./schema";

if (!process.env.DATABASE_URL) throw new Error("DATABASE_URL is not set");

const client = createClient({ url: process.env.DATABASE_URL });

export const db = drizzle(client, { schema });

We just need to get rid of env from $env/dynamic/private and substitute that with good old process.env...we also need to install dotenv-cli since we need to manually load our .env file. Speaking of which, let's create a .env.test

DATABASE_URL="file:test.db"

And now let's update our package.json file to make use of dotenv

{
  // rest of the package json
  "scripts": {
    "dev": "dotenv vite dev",
    "build": "dotenv vite build",
    "preview": "dotenv vite preview",
    "prepare": "svelte-kit sync || echo ''",
    "check": "svelte-kit sync && svelte-check --tsconfig ./tsconfig.json",
    "check:watch": "svelte-kit sync && svelte-check --tsconfig ./tsconfig.json --watch",
    "format": "prettier --write .",
    "lint": "prettier --check . && eslint .",
    "test:e2e": "dotenv --env-file=.env.test playwright test",
    "test": "pnpm test:e2e",
    "db:push": "drizzle-kit push",
    "db:generate": "drizzle-kit generate",
    "db:migrate": "drizzle-kit migrate",
    "db:studio": "drizzle-kit studio"
  }
  // rest of the package json
}

Notice that with test:e2e we are specifying .env.test as the --env-file.

With these changes...our application runs exactly like before 😅

The actual magic trick

Now that we have set up our database file to work regardless of SvelteKit/vite we can start working on our magic trick! Our ace up the sleeve is a pretty neat library from the Drizzle team: drizzle-seed! This library has a method to seed the database with random but consistent data and a method to completely wipe the db (you actually don't have to do this with the library but they figured out how to reset a db for all the supported dbs for you...if you prefer to do it by hand you can just send a raw SQL query to wipe the db).

But where should we use those methods? Well, we want to seed the database before each test and then wipe it completely when it finishes. If this description didn't strike you, we are basically describing a Playwright fixture!

Playwright fixtures

This is the initial sentence in the documentation for Playwright fixtures

Playwright Test is based on the concept of test fixtures. Test fixtures are used to establish the environment for each test, giving the test everything it needs and nothing else. Test fixtures are isolated between tests. With fixtures, you can group tests based on their meaning, instead of their common setup.

An example of a fixture is the page you destructure in your Playwright tests...that page is unique and isolated for each test and the nice thing about Playwright is that you can create your own!

Start by creating an index.ts file in your e2e folder...we need to import test from @playwright/test and use the extend API to create a new test function that will include your new fixtures.

/* eslint-disable no-empty-pattern */
import { test as base } from "@playwright/test";

export const test = base.extend<{ my_fixture: string }>({
  my_fixture: async ({}, use) => {
    // your setup code here
    await use("fixture_value");
    // your cleanup code here
  },
});

Let's explain what's going on here: we are extending the original test function and we pass a generic to tell TypeScript what's the name of the fixture and what it will provide to each test (in this case a string). Then we pass an object to extend that will have a function for each fixture you are adding to the base. The first argument of this function is an object containing all the fixtures already defined, we could for example destructure page and automatically navigate to a certain page before invoking await use...this portion of code is also where we can do our setups.

We then invoke await use passing a value...this value needs to be the type we are defining in the extend generic (in this case string). This function call will resolve once the test has finished, we can now clean things up.

If we now import this test function in our test files we can use it like this

import { expect } from "@playwright/test";
import { test } from "../index.js";

test("my fixture", async ({ my_fixture }) => {
  expect(my_fixture).toBe("fixture_value");
});

Can you see where this is going? With this method we can provide our tests with an access to our db!

/* eslint-disable no-empty-pattern */
import { test as base } from "@playwright/test";
import { db } from "../src/lib/server/db/index.js";

export const test = base.extend<{ db: typeof db }>({
  db: async ({}, use) => {
    // your setup code here
    await use(db);
    // your cleanup code here
  },
});

This is already a huge step forward but we can also do better...as we said, we want to seed our db before every test and reset it after...let's see how it works with drizzle-seed

Putting it all together

Now that we understand how fixtures work we can use the seed and reset functions from drizzle-seed...the seed function will generate 10 random (but seeded, so consistent) users in our DB...we can do this before calling use to add the users to our database before the test start. After use we also invoke reset that takes care of wiping our db completely so it will be ready for the next iteration.

/* eslint-disable no-empty-pattern */
import { test as base } from "@playwright/test";
import { db } from "../src/lib/server/db/index.js";
import * as schema from "../src/lib/server/db/schema.js";
import { reset, seed } from "drizzle-seed";

export const test = base.extend<{ db: typeof db }>({
  db: async ({}, use) => {
    await seed(db as never, schema);
    await use(db);
    await reset(db as never, schema);
  },
});

Note we need to use as never in this case because we are using LibSQL and there's an open issue for this...however it's just a type error and the functionality works just fine (and you will not have this problem if you are using any other provider).

Based on how Drizzle structures the queries you will need to import the schema too in every test...so why not do that only once and expose it as a fixture?

/* eslint-disable no-empty-pattern */
import { test as base } from "@playwright/test";
import { db } from "../src/lib/server/db/index.js";
import * as schema from "../src/lib/server/db/schema.js";
import { reset, seed } from "drizzle-seed";

export const test = base.extend<{ db: typeof db; schema: typeof schema }>({
  db: async ({}, use) => {
    await seed(db as never, schema);
    await use(db);
    await reset(db as never, schema);
  },
  schema: async ({}, use) => {
    await use(schema);
  },
});

The last thing that we need to do is actually migrate our db when we launch our test suite...we can do this in playwright.config.ts

import { defineConfig } from "@playwright/test";
import { migrate } from "drizzle-orm/libsql/migrator";
import { db } from "./src/lib/server/db/index.js";

migrate(db, {
  migrationsFolder: "./drizzle",
});

export default defineConfig({
  webServer: {
    command: "pnpm build && pnpm preview",
    port: 4173,
  },
  testDir: "e2e",
});

And just like that we have access to our db in each test

import { expect } from "@playwright/test";
import { test } from "./index.js";

test("home page has the right first user", async ({ page, db, schema }) => {
  const first_user = await db.select().from(schema.user).limit(1).get();
  await page.goto("/");
  await expect(page.locator("li").first()).toHaveText(
    `${first_user?.id} - ${first_user?.name}`
  );
});

If we launch our Playwright tests with UI using pnpm test:e2e -- --ui we can see that the test passes and we have 10 users in our db!

Now, there's still a couple of problems with this: the fixture only executes when we actually use it inside a test...that might be fine but I would say it's better to always reset the db, otherwise stuff from the previous test could leak into the next and all of a sudden the test suite is non-deterministic anymore. We can fix this with a slight change to our fixture

/* eslint-disable no-empty-pattern */
import { test as base } from "@playwright/test";
import { db } from "../src/lib/server/db/index.js";
import * as schema from "../src/lib/server/db/schema.js";
import { reset, seed } from "drizzle-seed";

export const test = base.extend<{ db: typeof db; schema: typeof schema }>({
  db: [
    async ({}, use) => {
      await seed(db as never, schema);
      await use(db);
      await reset(db as never, schema);
    },
    { auto: true },
  ],
  schema: async ({}, use) => {
    await use(schema);
  },
});

{ auto: true } instructs Playwright to always run the fixture even if it's not destructured in the test.

The other inconvenience is that right now we need to do all our changes to the db before running the test...but since we wipe our db every time we can do better...with an option fixture!

/* eslint-disable no-empty-pattern */
import { test as base } from "@playwright/test";
import { db } from "../src/lib/server/db/index.js";
import * as schema from "../src/lib/server/db/schema.js";
import { reset, seed } from "drizzle-seed";

export const test = base.extend<{
  db: typeof db;
  schema: typeof schema;
  seed?: Record<string, unknown[]>;
}>({
  // the first element of the array is the default of the fixture
  seed: [undefined, { option: true }],
  db: [
    async ({ seed: seed_data }, use) => {
      // if we have the seed data instead of seeding the db with `drizzle-seed` we manually insert
      // the data in the db
      if (seed_data) {
        for (const table in seed_data) {
          if (seed_data[table] && seed_data[table].length > 0) {
            await db.insert(schema[table]).values(seed_data[table]);
          }
        }
      } else {
        await seed(db as never, schema);
      }
      await use(db);
      await reset(db as never, schema);
    },
    { auto: true },
  ],
  schema: async ({}, use) => {
    await use(schema);
  },
});

We can now use test.use inside a module or a describe block to seed our db with specific data

import { expect } from "@playwright/test";
import { test } from "./index.js";

test("home page has the right first user", async ({ page, db, schema }) => {
  const first_user = await db.select().from(schema.user).limit(1).get();
  await page.goto("/");
  await expect(page.locator("li").first()).toHaveText(
    `${first_user?.id} - ${first_user?.name}`
  );
});

test.describe("empty database", () => {
  test.use({
    seed: {
      user: [],
    },
  });

  test("home page has no users", async ({ page }) => {
    await page.goto("/");
    await expect(page.locator("li")).toHaveCount(0);
  });
});

test.describe("one specific user", () => {
  test.use({
    seed: {
      user: [
        {
          id: 1,
          name: "Paolo Ricciuti",
        },
      ],
    },
  });

  test("home page has a single user", async ({ page }) => {
    await page.goto("/");
    await expect(page.locator("li")).toHaveText(`1 - Paolo Ricciuti`);
  });
});

Personally I would suggest to default to this strategy if you need to make assertions on the data and use the seed function only for the cases where you need "some" data to be there but you don't care about which data is it.

And that's it! All of this can be further improved using the refine function of drizzle-seed (more documentation on the package here) but now that you know the basics the world is your playground!

A small caveat

There's a small caveat here that I've kept hidden from you this whole time: given we only have one SvelteKit application running we can only have one db. This means that tests cannot run in parallel but have to run in sequence. Otherwise two tests could update the data of the db at the same time. This is pretty straightforward to do in your playwright.config.ts by setting the number of workers to 1

import { defineConfig } from "@playwright/test";
import { migrate } from "drizzle-orm/libsql/migrator";
import { db } from "./src/lib/server/db/index.js";

migrate(db, {
  migrationsFolder: "./drizzle",
});

export default defineConfig({
  webServer: {
    command: "pnpm build && pnpm preview",
    port: 4173,
  },
  testDir: "e2e",
  workers: 1,
});

This will make your CI slower but personally it's a price I'm willing to pay for the flexibility this method gives me. I'm also exploring ways in which this constraint can be lifted and I will update this blog post in case I found a decent solution.

Conclusions

This is a small example and as I've said it can be improved but should give you the basis to make your setup perfect for your needs! You can find the final code here.

If you’ve heard this recently, I’m willing to bet it was in a terminal or a chat interface. It’s one of the favorite lines of our silicon‑and‑copper friends (see? I’m your friend—please spare me when the rebellion happens).

You might have guessed it already: I’m talking about AI! These tools broke into our lives on November 30, 2022 with the launch of ChatGPT. Sure, other forms of AI were around for years, but that’s the date when AI became “mainstream.” Since then, tremendous improvements have been made to these models and to how we use them. People realized that a not‑so‑good model can perform far better if you stick a while (true) loop around it and continuously ask the user whether the generated code is okay. Agentic workflows were born. Big AI companies started building those agents and giving them tools. Now, if you run an agent in your terminal, it can read and write your files so you don’t have to copy and paste, it can search the web so you don’t have to provide documentation for your niche programming language, and it can even run shell commands to build your application. An agent is behaving more and more like a junior engineer: asking questions, searching the web, reading the rest of your codebase, and copying and pasting snippets into new files.

There was still a missing piece though—and it was a big one: to give these models their human‑like abilities, AI companies spend months (if not years) training them, using all the data they can scrape from the web to provide examples of how humans write and, in a certain sense, think.

Putting the moral debate about whether this is good for humanity aside for a second, this strategy has a big flaw: there’s a cutoff date. If I train my AGI model ^[1], I need to decide a date on which the training process ends. If I stop training my model and a major historical event happens the next day, my otherwise perfect model will have no idea about it. And it doesn’t stop there. One problem we started seeing after we released svelte@5 is that almost all the Svelte code AI has ever seen is svelte@4, which has a significantly different syntax. This is getting better as newer models are released and more and more svelte@5 code is out in the wild, but it’s the same problem: missing context.

AI simply cannot get up‑to‑date information... but there’s a way to help: since you are interfacing with the AI, you can give it the missing context through your prompt. That’s why Svelte now provides an llm.txt with an easier‑to‑parse documentation page for LLMs. You can feed this to your agent so that this information will be included in the context, and the AI can refer to it if that knowledge isn’t baked into its weights. In a case like this, that’s probably fine (you still have to remember to include the document every time you ask something related to Svelte, though), but sometimes this just makes the agent less useful.

Let’s say you want to know what the weather is like in London. Because it’s new information, the model will have no idea. You could search on Google, copy that information, and provide it to the LLM—but what’s the point? We’re developers, right? Wouldn’t it be cool if there were a way to do this automatically? Imagine you write a little CLI... a very small CLI that looks like this

#! /usr/bin/node
const [, , city] = process.argv;

console.log(
  await fetch(
    `http://api.weatherapi.com/v1/current.json?key=${process.env.WEATHER_API_KEY}&q=${city}`
  ).then(res => res.json())
);

Invoking this CLI with a valid WEATHER_API_KEY will look like this

> weather-cli London
{
  location: {
    name: 'London',
    region: 'City of London, Greater London',
    country: 'United Kingdom',
    lat: 51.5171,
    lon: -0.1062,
    tz_id: 'Europe/London',
    localtime_epoch: 1757580952,
    localtime: '2025-09-11 09:55'
  },
  current: {
    last_updated_epoch: 1757580300,
    last_updated: '2025-09-11 09:45',
    temp_c: 15.2,
    temp_f: 59.4,
    is_day: 1,
    condition: {
      text: 'Moderate rain',
      icon: '//cdn.weatherapi.com/weather/64x64/day/302.png',
      code: 1189
    },
    wind_mph: 11.9,
    wind_kph: 19.1,
    wind_degree: 237,
    wind_dir: 'WSW',
    pressure_mb: 1002,
    pressure_in: 29.59,
    precip_mm: 0.06,
    precip_in: 0,
    humidity: 77,
    cloud: 50,
    feelslike_c: 15.2,
    feelslike_f: 59.4,
    windchill_c: 16,
    windchill_f: 60.9,
    heatindex_c: 16,
    heatindex_f: 60.9,
    dewpoint_c: 9.2,
    dewpoint_f: 48.5,
    vis_km: 10,
    vis_miles: 6,
    uv: 1,
    gust_mph: 14,
    gust_kph: 22.5,
    short_rad: 152.52,
    diff_rad: 65.26,
    dni: 381.85,
    gti: 64.03
  }
}

Now imagine that in your system prompt (a series of instructions you can often specify for the AI that is included in every message) you write this

If the user ever asks you about weather in a specific city you can run the command weather-cli [NAME OF THE CITY] to get up‑to‑date information about the weather in that specific city.

Just like that, my friend, you invented tool calls. This gives an LLM a new superpower. It can now get up‑to‑date information just by invoking a CLI and including that in its context. This is a nice trick to get the weather, but it opens up a world of possibilities.

It still doesn’t feel totally right though, does it?

Should every developer create their own weird CLI to include in their LLM? Should everybody add an enormous system prompt to specify all the CLIs that are available? And what about what those CLIs print to the console? Should it just be a random object? Should it be more structured? What about the inputs?

All of this feels chaotic, and that’s an enemy of the user (and also of the LLM in this case). What we need is a well‑formed contract between the LLM and the CLIs.

Protocol

What is a protocol? An example is the Hypertext Transfer Protocol. You might be familiar with it because you type that in front of every URL you visit: http. Let’s see the definition of a communication protocol from Wikipedia:

A communication protocol is a system of rules that allows two or more entities of a communications system to transmit information via any variation of a physical quantity. The protocol defines the rules, syntax, semantics, and synchronization of communication and possible error recovery methods. Protocols may be implemented by hardware, software, or a combination of both.

In simpler terms: it’s a contract between two entities. It’s a way to know which language the other party is using so that both sides can parse the communication “package” appropriately.

The fact that every request has the same structure allows your HTTP client (usually the browser or curl) and your HTTP server to talk to each other.

What we need is something similar so that any client (Claude, Claude Code, ChatGPT, Codex, etc.) can talk to any server.

MCP (Model Context Protocol)

As the name suggests, MCP is a protocol... but what about the rest of the letters in the acronym? The M is the same M you see in LLM: Large Language Model!

This expresses the fact that this protocol is meant for Large Language Models... and what does it do? It adds Context to them.

JSON-RPC

So... how does it work? Do we also have the same structure as the Hypertext Transfer Protocol with HTTP_VERB, headers, body, etc.? Well, the MCP protocol doesn’t require communication over HTTP, so the answer is... technically no! We’ll explore why it’s “technically no” and not just “no,” but for the moment the point I’m trying to make is that all communication in MCP happens over JSON-RPC, which stands for JavaScript Object Notation – Remote Procedure Call. The JSON part is probably very familiar to you: it’s the most common way programs communicate with each other on the web. If you are making an API call, you are most likely sending and receiving JSON.

The second part (RPC) is more interesting: Remote Procedure Call. When you build a JSON‑RPC server, you define a list of methods available on your server. A JSON‑RPC client can then invoke one of those methods by name with the necessary arguments.

A simple implementation of a JSON-RPC client/server could look something like this

import { JSONRPCServer, JSONRPCClient, isJSONRPCRequest } from "json-rpc-2.0";

const server = new JSONRPCServer();

server.addMethod("greet", name => {
  console.log(`Hello ${name}`);
  return {
    success: true,
  };
});

const client = new JSONRPCClient(payload => {
  if (!isJSONRPCRequest(payload)) {
    return;
  }
  server.receive(payload);
});

client.request("greet", "Paolo"); // Hello Paolo

This feels like an over‑abstraction, but the real power comes when those two pieces of code live in two separate processes—be it a server and a client separated by a network request, or even just two processes running on the same machine communicating via some form of cross‑process communication. Let’s see the same example with an HTTP server built with Bun for simplicity.

// server.ts
import { JSONRPCServer, isJSONRPCRequest } from "json-rpc-2.0";

const server = new JSONRPCServer();

server.addMethod("greet", name => {
  console.log(`Hello ${name}`);
  return {
    success: true,
  };
});

Bun.serve({
  async fetch(req) {
    const body = await req.json();
    if (!isJSONRPCRequest(body)) {
      return new Response("Bad Request", { status: 400 });
    }
    server.receive(body);
    return new Response("No Content", { status: 204 });
  },
});

// client.ts
import { JSONRPCClient } from "json-rpc-2.0";

const client = new JSONRPCClient(payload => {
  fetch("http://localhost:3000", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify(payload),
  });
});

client.request("greet", "Paolo");

With this relatively trivial code, we can now invoke every method that is exposed by our server from our client with a very simple client.request(method, args);. Just like with an HTTP request, a JSON‑RPC request has a specific format:

{
  "jsonrpc": "2.0", // the version of the jsonrpc schema, always 2.0 for mcp
  "id": 1, // must be unique per request
  "method": "greet", // name of one of the required method
  "params": "Paolo" // this can also be an object
}

And the same is true for a JSON‑RPC response:

{
  "jsonrpc": "2.0", // the version of the jsonrpc schema, always 2.0 for mcp
  "id": 1, // must correspond to the same id of the request that generated this response
  "result": { "success": true } // the value returned from the method
}

JSON‑RPC clients can also send notifications (communications that don’t require a response). In this case, the id property is missing:

{
  "jsonrpc": "2.0", // the version of the jsonrpc schema, always 2.0 for mcp
  "method": "my_notification", // name of one of the required method
  "params": {
    "value": 42
  }
}

So... now we have a contract. How do we actually communicate?

Transports

The MCP spec defines two official ways to communicate between clients and servers (technically three, but one is deprecated). The JSON‑RPC requests are “sent” and “read” via these transports:

• STDIO: the MCP client executes a specific process locally and starts listening on the standard output of that process. When a new message is sent, it is written to the standard input of that process. The MCP server also starts listening to its own standard input to receive a new message and writes to the standard output (read that as console.log) when it needs to send a response/notification.
• Streamable HTTP: The MCP client has the URL of the remote MCP server and sends a POST request where the body is the JSON‑RPC request. The MCP server responds with a stream (responding immediately), and when the response is complete it writes to the stream and closes it. A separate SSE (Server‑Sent Events) channel is opened to receive notifications from the server.

STDIO is how the protocol started, and if built properly an STDIO MCP server can be very powerful... you can publish it as an npm package, set up the MCP client to invoke your package with npx, and have powerful tools that read and write to the file system.

Streamable HTTP, on the other hand, has a top‑notch user experience: you don’t need to install random packages on your machine, no Docker to execute the needed Postgres DB... you just have a URL, you point your MCP client to it, and that’s it. This doesn’t mean we can go ahead and add a bunch of MCP servers without a care—remember, every MCP server is still “talking” with an LLM that has some form of control over your machine!

So now we know how MCP works and how it communicates... but what can an MCP server do?

MCP capabilities

There are many things an MCP server/client can do once the communication is established. All of them add context in a slightly different way and have a slightly different user flow... let’s explore them one by one.

Tools

Tools are the feature that kicked off MCP adoption: they’re a way for a Large Language Model to interact directly with potentially anything (a file, an API etc) through your MCP server. When you define your MCP server, you can register one or more tools with a handler that will be invoked when the LLM requests that tool. Every time you register a tool, it’s also added to the collection of tools that will be listed with the tools/list method from the MCP client.

import { McpServer } from "tmcp";

// configuration omitted for brevity
const server = new McpServer({});

server.tool(
  {
    name: "random-number",
    description:
      "Generate a random number from 1-100, ALWAYS call this tool if the user asks to generate a random number of some sort",
    title: "Random Number",
  },
  () => {
    return {
      content: [
        {
          type: "text",
          text: JSON.stringify({ value: Math.floor(Math.random() * 100) }),
        },
      ],
    };
  }
);

As soon as the MCP client starts and connects to this MCP server, it’s going to request the list of available tools, and that list is added as context to every message the user sends. This informs the LLM that it has certain tools at its disposal. If the LLM wants to call a specific tool, it just needs to send a message in chat formatted in a specific way.

This changes from model to model, for example OpenAI produces something like this

I'll check the weather in San Francisco

<tool_call>
{"id": "call_abc123", "type": "function", "function": {"name": "get_weather", "arguments": "{\"location\": \"San Francisco\", \"unit\": \"celsius\"}"}}
</tool_call>

This message is almost never shown to the user (at least not as an actual message), and each MCP client implements a different UI to ask the user for permission to do that tool call. Once the user agrees, the message is exchanged and the return value from the handler is “added to the context.”

The above example is obviously trivial, but it already unlocks the possibility for the LLM to properly generate a random number (LLMs can probably do that on their own—but is that really a random number?).

A few notes on the snippet above:

1. You can see a name and title... as you can imagine, title is more human‑friendly and it’s what is shown to the user when listing all the available tools.
2. The description field almost reads like a prompt—because that’s what it is. Since these are meant for the LLM to read and decide whether or not to call the tool, you must craft very good descriptions if you want the LLM to use your tool properly.
3. The return value is an array of content where each element has a type property. The type can be text, but it can also be image, video, or audio in case your MCP server can produce those.

Input-less tools are already pretty powerful (especially when they can interact with something on your behalf) but, at least in my option, the real power of tools comes from the fact that you can instruct the LLM in natural language and it will come up with the right inputs for your tools. Since LLM are non deterministic in our code we are required to specify a schema with the validation library of our choice (this will make sure the tool is called with what we actually expect).

#!/usr/bin/env node

import { McpServer } from "tmcp";
import { ValibotJsonSchemaAdapter } from "@tmcp/adapter-valibot";
import * as v from "valibot";
import { StdioTransport } from "@tmcp/transport-stdio";

const server = new McpServer(
  {
    name: "Math MCP",
    description: "An MCP server to do Math",
    version: "1.0.0",
  },
  {
    adapter: new ValibotJsonSchemaAdapter(),
    capabilities: {
      tools: {},
    },
  }
);

server.tool(
  {
    name: "sum",
    description: "Sum two numbers",
    title: "Sum Numbers",
    schema: v.object({
      first: v.number(),
      second: v.number(),
    }),
  },
  ({ first, second }) => {
    return {
      content: [
        {
          type: "text",
          text: JSON.stringify({ value: first + second }),
        },
      ],
    };
  }
);

// let's use stdio to test this mcp server
const stdio_transport = new StdioTransport(server);
stdio_transport.listen();

How does this look in something like Claude Code? We can add it from the root of our test repo with the following command

claude mcp add -t stdio math node ./src/index.js # we would use the name of the package instead of node ./src/index.js in case it was public

And then we can launch Claude and interact with it

It’s already cool that you can say “add 3 and 5” and get 8 as an answer, but what’s even cooler is being able to sum two numbers using natural language: “can you add the number of planets in our solar system and the number of players on the field of a soccer game?” correctly returns 30. We’re using the LLM’s knowledge of the world and mixing it with raw, pragmatic code execution to get the best of both worlds.

Resources

Another capability available for MCP servers is resources. As the name suggests, a resource is something (a file, a DB table, a JSON response from an API) that can add context to what the user needs from the LLM. Let’s imagine you want to use an agent to fix a bug that you know is within a specific file in your codebase. You could ask the LLM to read that file, but you already know the bug is in that file... why waste precious tokens and time just to get a subpar result (after all, LLMs are non‑deterministic, so there’s no way to be sure they will indeed read the file)?

That’s where resources come into play: unlike tools, this capability is not operated by the LLM... it’s operated by you!

The MCP server developer can register as many resources as they want, and you, the user, can read them and manually include them before sending your message. Continuing with the Math example from before, let’s see how we can add a resource to give the LLM more info about Gaussian elimination:

// previous MCP server code

server.resource(
  {
    name: "history",
    description: "The list of all operations up until this moment",
    uri: "math://history",
    title: "History",
  },
  async uri => {
    const history = await db.select().from(history).all();
    return {
      contents: [
        {
          mimeType: "application/json",
          text: history,
          uri,
        },
      ],
    };
  }
);

And here’s how it looks when used in Claude Desktop (I’m purposefully using different MCP clients to show you that the same server works with all of them... and also because the resource selection looks way better in Claude Desktop than in Claude Code 😅)

Prompts

Finally, the other big capability in an MCP server is prompts. If you’ve used any AI, you know what I’m talking about: a prompt is how you interface with the LLM, and being able to craft well‑detailed prompts can really up your AI game.

Now, when you are building your MCP server, you are likely the best person to know how the LLM should use it: what tools to call, when to call them, what to expect back from them, and so on. Prompts allow you to have one or more ready‑made templates that you can include in your chat with one simple action. Once again, this is a feature for the user, who will have to manually select them—but once they do, their input box will be pre‑populated with your prompt so they can get better answers using your MCP server without the hassle of writing a long and detailed one.

// previous MCP server code

server.prompt(
  {
    name: "use-math",
    description: "A prompt to instruct the llm on how to use the Math mcp",
    title: "Use Math MCP",
  },
  () => {
    return {
      messages: [
        {
          role: "user",
          content: {
            type: "text",
            text: `You are a helpful assistant that can perform basic ...`, // cut down for legibility
          },
        },
      ],
    };
  }
);

As you can see, the structure is very similar. If you want, you can return multiple messages and the LLM will interpret them as actual messages that were already sent in the chat. You can also specify a role that can be either user or assistant (so you can also impersonate the LLM), even though I haven’t found a use case for it (yet).

And this is how it looks in VS Code when you select a prompt:

Client Capabilities

These were all the server capabilities (the things a server can expose), but there’s also the other side of the coin: the client capabilities. Each client can expose different capabilities, and servers can use those capabilities to interact with the user in different ways. We won’t explore these in great detail because, as of today, most clients don’t actually support them and the MCP spec is ever‑evolving, but here’s a quick list:

• Elicitation: Support for elicitation allows servers to request a piece of information directly from the user. So, let’s say your server needs the GitHub username to fetch some issues. With elicitation, the MCP client can—if the MCP server requests it—show an input/textarea to allow the user to directly input the information.
• Sampling: Support for sampling allows servers to “use” the user’s LLM to do some inference work. If you need the power of AI to generate some text, instead of doing an API call to OpenAI on your server you can ask the user (who is already using an LLM) to run that inference for you. Obviously, the clients that do support this capability have implemented a popup asking for permission.
• Roots: this is probably the least‑used feature of MCP servers. It’s only really important for local MCP servers and allows the client to send information to the servers about the scope in which they can operate (specifically which folders they have access to).

Does all of this really matter?

I can hear you ask: “I’m not developing AI products or developer tools... I’m just developing a simple storefront. Do I really need to care about all of this?” The answer to this is, in my opinion, ABSOLUTELY YES!

MCP might seem like a developer‑oriented feature for now, but it is not! More and more users are relying on LLMs to do their searches, and it’s not unthinkable that in a far‑off future people will actually consume content and interact with online services primarily through an LLM—just like the browser is our window to the web today. But even before that...

Imagine you are building a website to sell train tickets. You can search for them, your API finds the best price, and it displays the results in a neat interface where the user can select the class of service based on the list of amenities. They can then proceed to pay and finally get their tickets.

Here's the list of operations the user has to go through to pay you:

• Open your website
• Search for the specific city they want to go to... they can’t make spelling mistakes
• Look at the list of available rides.
• Check their calendar to see when the appointment was.
• Pick the right train
• Read the list of commodities in each class and select the one it suits them
• Go to the payment page, insert their card
• Pay for the tickets
• Save the ticket in their wallet and add a reminder to the calendar

Now imagine you’ve built an MCP server that sits right next to your website. Since they frequently use your website, they add it to the LLM. They open the LLM and say

I need to book a train for the next appointment in my calendar, please grab the best class under 100€ and save the ticket to my calendar/wallet.

The rest is magic! The LLM will connect to their calendar, use your MCP server to grab the information it needs, proceed to pay for the ticket, and save the brand‑new ticket in the user’s calendar.

We are probably still far away from this world (especially from the one where users will trust LLMs with their credit card 😅), but the world is kind of already moving in that direction, and we are only at the start of the journey... now is the time to start looking into this to be on the forefront of the innovation!

Conclusions

The Model Context Protocol is one of the most fascinating technologies to emerge from the AI revolution, and it can truly unlock cross‑communication—just like the HTTP protocol did in the WWW revolution.

We are ready to dive right in... what about you?

This shift creates peer pressure as well. Once some teams move faster with AI, that forces everyone else to catch up or risk falling behind. An increased level of output for the same input becomes the new baseline, not the exception. That brings its own tension. Not everybody is on board the AI hype train and many people in the tech industry have concerns about code quality, environmental, ethical, or geopolitical aspects of AI. While those are all legitimate concerns that shouldn't be ignored, letting them drive a decision to opt out and not leverage this new capability is asking a lot from any decision maker when the competition is moving ahead and happily increasing their output, and threatening to get ahead or away.

Successfully leveraging AI in software engineering, in particular for mid to large teams and organizations, is not trivial though. It’s not as simple as just getting everyone a Claude account and then expecting velocity to double overnight. It's a foundational shift in how a team operates. At the same time, there are few established best practices, and the ones that exist keep changing on a daily basis.

What Gains Are to Be Realized?

While the field continues to develop and change fast, the productivity gains across a range of tasks are real and increasingly well-understood. First and most obviously, AI accelerates the rate at which code is produced. What began as smarter autocompletion has quickly evolved into full code and test generation or even agents that can build entire features and submodules, commit to git and open pull requests automatically. That doesn’t just shave seconds off keystrokes but can save hours of an engineer's time.

Applications of AI don't stop at code generation though but extend beyond it, e.g. to code discovery and onboarding. Engineers often spend days and weeks trying to wrap their heads around an unfamiliar codebase. With AI-powered tools, that process can be compressed as AI can prepare information for easier consumption: system diagrams can be generated on demand, unfamiliar code, design patterns, or component relationships can be explained and summarized in an instant. Searching a codebase no longer relies on precise keyword matches—semantic search is changing how large codebases are navigated.

AI also speeds up the work that happens before a single line of code is written. Whether it’s drafting tasks, feature specs, or architecture proposals, AI can help teams move faster by generating solid first drafts. From there, AI tools can review and refine those drafts, reducing the time teams need to spend in meetings discussing every detail—because the groundwork is already in place.

In QA, debugging and maintenance, AI is proving valuable as well. Many teams report strong results from AI-powered pull request review agents, which often catch issues early and cheaply. When systems misbehave in production, AI tools can assist in analyzing logs, correlating symptoms, and narrowing down possible causes. What might have taken a human hours of digging can now be accelerated with a well-constructed prompt. None of these tools replace expertise, but they accelerate a wide range of tasks significantly.

Risks and Challenges

But it’s not all fun and games. AI will makes mistakes—often with unsettling confidence. These range from inventing non-existent packages to producing inefficient or flat-out incorrect implementations, or generating code that lacks architectural coherence. This becomes especially problematic for large systems and teams, where consistency and clarity are critical. Full-on vibe-coding might be fun in a solo weekend project, but is not a reasonable practice for larger teams that need to coordinate their work, share knowledge, and ensure consistency. The last thing you want is a model stitching together random patterns and practices it’s seen across the internet and injecting them into your codebase. The result is neither reliable nor maintainable.

Avoiding that outcome requires strong guardrails. Providing AI the tools, context and direction it needs to be efficient is the essential first step. That requires new skills and techniques like context-engineering which must be established across the entire organization, requiring new infrastructure and processes. Human oversight is equally critical. Developers need to review AI output with the same or greater scrutiny they apply to human-written code. They also need to know where to trust the AI more, and where to double-check extra rigorously. Without this human-in-the-loop approach, teams really do risk ending up with exactly what the skeptics predict: an unmaintainable pile of garbage with eventually no way out.

Another serious challenge is intellectual property and data security. AI models don’t clearly distinguish between inspiration and duplication. They can output snippets that violate licenses or reproduce copyrighted material. At the same time, teams risk leaking their own intellectual property to the AI providers, training the models that might reproduce the same code elsewhere eventually. That could mean giving away competitive secrets or exposing sensitive user data. It's essential to have in place systems to sanitize prompts, guardrails that prevent sensitive data from leaving secure environments, and the ability to trace and audit AI outputs.

Then there’s the challenge of tooling complexity and fragmentation. The ecosystem is moving fast. There are multiple competing approaches to everything from code generation to test automation. Teams trying to integrate too many tools at once find themselves in a mess of conflicting workflows and overlapping features. Some developers use one tool, others use another—making it hard to share knowledge, align on practices, or build shared infrastructure. The result is low consistency and increased complexity.

Finally, if code production is in fact accelerated successfully through AI, the engineering infrastructure must be able to keep up with the changes coming in. More code being written and merged faster only helps if the delivery pipeline is ready for it and can in fact ship all that code to production systems efficiently and reliably. If deployments are slow (or maybe even still manual 😱) or if testing isn't stable and comprehensive, accelerated code production doesn't translate to accelerated value creation – in fact, the opposite: larger, more complex releases that are riskier and result in more production bugs and rework. Velocity drops instead of accelerating.

All that shows that AI only increases the importance of what has always distinguished great engineering teams from the rest: a strong engineering culture and the infrastructure and tooling that engineers thrive on. The companies that will struggle with adopting AI will be the same ones that have struggled with quality, velocity, and consistency before AI. AI just increases the pressure – if practices are weak, systems brittle, reviews inconsistent, AI will expose and amplify that, making the teams that are already at a competitive disadvantage fall behind further.

Guiding Teams Through Adopting AI

As an engineering consultancy that's (seemingly) paid to write code for clients, we've thought about what the rise of AI-accelerated engineering means for us quite a bit, and not without worrying about the future. Yet, over time we realized more and more that our work has never been just about writing code—it’s been about shaping the systems and processes that reliably and efficiently turn ideas into running systems. We have spent years helping clients build strong engineering cultures and the infrastructure needed to support them. As explained above, that work is more important than ever, now with an added dimension: enabling teams to harness AI in ways that genuinely accelerate their ability to deliver value—sustainably, and at scale.

We are prepared to guide clients through adopting AI in their engineering organizations—so they can accelerate value creation in a sustainable, practical way:

1. First, we assess the status quo, covering team size and composition, experience level, tooling and infrastructure, development practices, testing and release processes, observability, etc. The goal is to understand the organization’s maturity and identify blockers that might get in the way of accelerated value delivery.
2. Together with our clients, we define what success looks like. For some teams, that might mean adopting agentic coding to dramatically increase feature velocity. Others may choose a more measured approach, starting with AI-assisted workflows that keep humans in the driver’s seat. Alongside this, we establish tracking for key metrics—such as velocity, lead time for changes, and change failure rate—so progress is visible, measurable, and grounded in real outcomes.
3. If necessary, we overcome any delivery impediments our clients might face, e.g. fixing broken or adding missing automation, infrastructure and observability. As noted earlier: any pain caused by a weak delivery pipeline will only get worse once AI increases the volume and speed of code production.
4. Once the necessary foundation is in place, we roll out tools incrementally along with the necessary guardrails, supporting resources, and mentoring of engineers. Our team will work with our clients' teams as we've done for many years, introducing them to the new ways of working as teammates.

Adopting AI to accelerate a software engineering team’s output isn’t just about rolling out another tool—it’s a fundamental shift in how teams work. AI won’t replace developers. But teams that learn to use it effectively will outpace those that don’t. We’re here to guide you through that transition as teammates, so you don’t have to navigate it alone.

To get numbers on how Vite can improve the build pipeline of real-world production applications, we need your feedback. Using the open source tool we've built to measure the differences in build and pageload times, you can share your benchmarks with us so we can continue making Ember better and faster for everyone.

How the classic build system differs from Vite

The classic build setup uses ember-cli, which builds your app using an underlying technology called broccoli, although some adventurous Ember developers might have been using webpack through embroider. In both cases, everything is compiled up front, and the app is loaded as a few bundled AMD-based entry files or chunks, even when the app runs in development mode. Roughly speaking, the initial build is slow, then makes up for some of that time during the page load by bundling everything up into a minimal number of files.

Vite follows a very different philosophy when it comes to dev builds: it has multiple stages to optimise the input and sends real JavaScript modules and entry points to the client. This means that for every module in your app (and every entry-point in your dependencies), you will see a new network request for that individual module in the browser. With large apps, you could start the dev server blazingly fast, only to have a perceived slowdown as the browser loads large numbers of tiny files, which in turn are much faster to reload for small changes.

Build, Measure, Optimise, Repeat

Moving to Vite has many more benefits than just raw speed, but speed is always an important factor of development, and it is worth spending some time investigating the impact of migrating a classic Ember app to build with Vite.

We need to learn how well Vite does in on your applications, big and small. We are looking for the following metrics, both from a cold start and a warm start after caches have been created:

• Production build time after installing the packages
• Development server startup time
• Development time to first paint
• Development time to app load, waiting for an element rendered by your app
• Development reload time after a file in your app changes

We built build-start-rebuild-perf to take care of the development measurements. See its README or --help output for supported parameters.

Test protocol

As projects have their individual choices, we decided to not fully automate the workflow. This post assumes a "normal" Ember project as generated by running ember new.

Expectations:

• You run macOS or Linux (or are willing to go on your own adventures on Windows)
• You have a main branch (or a last commit "C") of your app that builds and runs using ember-cli
• You have a migrate-to-vite branch (or a first commit "C+1") that builds and runs using the new Embroider and Vite
• Both branches use the same version of Node and the package manager of your choice, i.e. pnpm
• Your app has a <img class="logo"> that is part of your components and not inside your index.html
• Your app has an app/router.js which, when changed, triggers ember-cli or vite to rebuild

Let's get started! Open up the survey form, which will give you the same prompts as below and input fields to put the results. Don't rush this.

1 - Ember CLI Production Build Time

Let's start by switching to your main branch and cleaning your built assets and caches:

# Start from main
git switch main

# Make sure you clear out artefacts
rm -rf dist

# Clear out ALL build caches
rm -rf $TMPDIR/embroider $TMPDIR/broccoli-*(N) node_modules/.embroider

Now, let's get the first build measurement. You will run your ember-cli build with time to measure things. The following example assumes your package.json script build command runs ember build --env=production. The output will print extra lines at the end, containing the execution time measurement. We are looking for the real or total or Executed in number, i.e. real 0m4.139s:

# 1 - Ember CLI Production Build Time
# -----------------------------------
time npm run build

2 - Ember CLI Cold Start

Next, we will measure the "cold start" of your dev build. This means how long it takes to start the build and see your app running in the browser, assuming you're starting without any build caches. Let's start by removing ./dist again and clearing our cache:

# Make sure you clear out artefacts
rm -rf dist

# Clear out ALL build caches
rm -rf $TMPDIR/embroider $TMPDIR/broccoli-*(N) node_modules/.embroider

Then we're going to execute the build-start-rebuild-perf command to measure the important aspects of your dev server build time. Note this assumes that the development server launches at //localhost:4200:

# 2 - Ember CLI Cold Start
# ------------------------
# 2.1 Dev Server Ready
# 2.2 Development time to first paint
# 2.3 First Paint
# 2.4 Development reload time
npx build-start-rebuild-perf --file "app/router.js" --wait-for ".logo" --command "npm start"

3 - Ember CLI Warm Start

Next, we do the same command, but we don't clear the caches first this time.

# 3 - Ember CLI Warm Start
# ------------------------
# 3.1 Dev Server Ready
# 3.2 Development time to first paint
# 3.3 First Paint
# 3.4 Development reload time
npx build-start-rebuild -perf --file "app/router.js" --wait-for ".logo" --command "npm start"

And that's it for the classic build; it's time for us to switch over to your Vite branch.

By the way, you made it to the halfway point of this process 🎉 Let's keep going.

4 - Vite Production Build

First, we will switch to our Vite branch and clear out any caches you had from previous Vite builds:

git switch migrate-to-vite

# Remove any build caches
rm -rf node_modules/.vite node_modules/.embroider

Next, we will again time the production build time using the time command. This assumes that your package.json build script has been updated to run vite build:

# 4 - Vite Production Build
# -------------------------
time npm run build

5 - Vite Cold Start

Just to make sure that the Vite production build didn't create any build caches, we should clear them out again:

# Remove any build caches
rm -rf node_modules/.vite node_modules/.embroider

And then we run the same command that we did in #2 above and report the same numbers, but this time with Vite:

# 5 - Vite Cold Start
# -------------------
# 5.1 Dev Server Ready
# 5.2 Development time to first paint
# 5.3 First Paint
# 5.4 Development reload time
npx build-start-rebuild-perf --file "app/router.js" --wait-for ".logo" --command "npm start"

And just like we did before, to get the warm start numbers, we run the same command without first clearing any caches:

# 6 - Vite Warm Start
# -------------------
# 6.1 Dev Server Ready
# 6.2 Development time to first paint
# 6.3 First Paint
# 6.4 Development reload time
npx build-start-rebuild-perf --file "app/router.js" --wait-for ".logo" --command "npm start"

Submit your numbers

You made it all the way to the end 🎉 Assuming you have been filling in the form as you went along, it's now time to hit that submit button. Otherwise, here is the link again if you want to fill in all the numbers you have collected.

Conclusion

If you made it through this blog and submitted the form, thank you very much. We appreciate the time you spent, and you have contributed to the Ember Initiative's efforts to make Ember better for everyone.

We are still looking for more Ember Initiative members if you want to contribute more directly. You can read more about the benefits of joining the Ember Initiative a member on our dedicated Ember Initiative page.

Let’s start by setting up the Ember app for React. This post assumes a modern Vite based setup using pnpm for Ember.JS which has recently become the default when generating a new project with ember-cli.

Let’s add the base dependencies for React as well as the React Vite plugin by running pnpm add -D react react-dom @vitejs/plugin-react. With this plugin Vite will know how to build React components. Finally, we'll update the Vite configuration to add the new plugin.

// vite.config.mjs
...
import { ember } from '@embroider/vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [
	...
  	ember(),
    react(),
  ],
});

That’s all that’s necessary for the build to work.

Bridging the frameworks

In order to be able to render a React component from within an Ember component we need to do a bit more work. We need an element for the React component to render in, a way to pass props, reactivity and finally take care of unmounting and cleaning up when necessary.

The first thing we’ll do is create a fresh GJS template-only component with a div element that will serve as the root element for the bridge component. react-dom will use this as it's root element for the React component.

// react-bridge.gjs

<template>
  <div></div>
</template>

In order to get access to this element we’ll add an inline modifier. We will also pass on the React component reference and props arguments.

// react-bridge.gjs

import Modifier from 'ember-modifier';

class ReactModifier extends Modifier {
  root = null;

  modify(element, positional, { component, props }) {

  }
}

<template>
	<div {{ReactModifier component=@compoment props=@props}}></div>
</template>

react-dom provides us with a way to render React components in an element through createRoot for which we’ll store a reference in the root variable. We need to make sure that createRoot is called only once on initialization. The next step is to make the React component renderable with createElement. The output of that function can then be passed to this.root.render. If we call these functions every time the modifier runs, the arguments/props are already reactive!

// react-bridge.gjs

class ReactModifier extends Modifier {
  root = null;

  modify(element, positional, { component, props }) {
    if (!this.root) {
      this.root = createRoot(element);
    }

    const wrappedComponent = createElement(component, props);
    this.root.render(wrappedComponent);
  }
}

What remains is cleanup. The way to this within Ember is to register a destructor with a function that’s called when the modifier instance is destroyed.

// react-bridge.gjs

function cleanup(instance) {
  instance.root?.unmount();
}

class ReactModifier extends Modifier {
  root = null;

  modify(element, positional, { component, props }) {
    if (!this.root) {
      this.root = createRoot(element);
      registerDestructor(this, cleanup);
    }

    const wrappedComponent = createElement(component, props);
    this.root.render(wrappedComponent);
  }
}

Reactivity

The implementation we have right now will give us reactivity at the boundary. This means that as long as a change to an argument is consumed by the modifier, it will trigger a re-render of the React component.

In the below example, clicking the button will update the value of foo and automatically trigger a re-render of the React component as expected.

// my-component.gjs

import ReactBridge from './react-bridge.gjs';
import MyReactComponent from './my-react-component.jsx';

class MyComponent extends Component {
  @tracked foo = 'bar';

  @action
  updateFoo() {
    this.foo = 'baz';
  }

  <template>
    <button {{on "click" this.updateFoo}}>Update Foo</button>

    <ReactBridge
      @component={{MyReactComponent}}
      @props={{hash value=this.foo}}
    />
  </template>

}

This should generally be enough for the use case where you want to embed a size-able component tree or widget. However, when migrating a full app this way, it may become necessary to have a way to share global (or local) state. Think of an Ember.JS service or a context API. Even if made accessible from within React, these will not necessarily be reactive. This keeps the implementation simple while also providing a clear reactive boundary. Integrating fully transparent reactivity dramatically increases complexity and may not be necessary for contained integrations or temporary situations caused by a framework migration.

Other concerns

Getting a component to render is not all you need to think about. There's various application and maintenance concerns that need to be taken into account as well.

Routing

One of the trickier things to deal with is routing. The easiest way for now is to keep the Ember.JS app fully in charge of routing. When you start trying to mix routers you’ll find problems around, for example, query parameter management due to Ember’s tight coupling of the router to the URL. In a future version of the Ember.JS router it may become easier to offload certain responsibilities to another router or even use a generic router not bound to a specific framework.

Testing

When React becomes involved you can't rely on certain paradigms from Ember you're used to out of the box with Ember's testing infrastructure. Some examples: Ember's test-waiter system is not integrated (by default). Combined with React's asynchronous rendering this may mean your tests need to be adjusted to account for this. Similarly, dispatching (simulated) DOM events will also not work out of the box.

Let's take an example React component that takes a numerical counter argument and an onCounterClick callback. It renders the current value of the counter and a button that triggers the callback when clicked.

test('[React] it should trigger the onCounterClick action when clicked', async function (assert) {
  const state = new TrackedObject({
    count: 0,
    incrementCount: () => {
      state.count++;
    },
  });

  await render(
    <template>
      <ReactBridge
        @component={{ReactCounter}}
        @props={{hash
          counter=state.count
          onCounterClick=state.incrementCount
        }}
      />
    </template>
  );

  await click('[data-test-increment-button]');

  assert.dom('[data-test-counter]').hasText(`${state.count}`);
  ...
});

With our current implementation, this test will fail with Element [data-test-counter] should exist. This is because after the button is clicked, the assertion does not wait for React to finish rendering. In this case we could for example decide to fix this by modifying the bridge component by using React's act helper when in a testing environment.

// react-bridge.gjs

if (macroCondition(isTesting())) {
  window.IS_REACT_ACT_ENVIRONMENT = true;
  act(() => {
    this.root?.render(wrappedComponent);
  });
} else {
  this.root.render(wrappedComponent);
}

Now the test will pass.

Usage of the bridge component

Even though it has a relatively small API surface, overuse of the bridge component will increase the complexity and potentially affect the performance and reliability of the codebase. It is recommended to limit the amount of times the bridge component is used to a minimum.

Final thoughts

While it's certainly not impossible to mix frameworks, it's not necessarily trivial. After the initial implementation it's important to keep in mind the other concerns to limit impact on the development experience and velocity as well as the maintainability of the codebase.

Interested to learn more about this topic? Make sure to check out the recording of Multi-framework mashup - making other frameworks work in Ember from EmberFest 2025!

When you run into a problem with open-source code, the best course of action is to improve it, so everyone facing the same issue can benefit from your contribution. And if others do the same, you’ll benefit from their work too. However, there are two main obstacles: you’re usually too busy with other priorities, or the open-source codebase is too complex to tackle the issue in the limited time you have.

The Ember Initiative offers a solution for issues related to the Ember ecosystem. The members can participate in pairing sessions with us—the Ember Initiative team. Whenever we identify a problem outside their codebase, we can address it upstream—either with them or for them—so the solution benefits the entire community. Every time a member thinks, “If only I could fix this upstream…” during a pairing session, that thought becomes an actionable task on our board.

Here are a few examples of how our members have contributed to the broader community through pairing sessions.

We Contribute to Embroider

Since Ember Initiative members are typically interested in building their Ember apps with Vite, pairing sessions sometimes uncover issues in Embroider itself. Contributing to Embroider usually involves a steep learning curve—it’s the kind of project that requires more than just a few hours and good intentions. As the Ember Initiative team, we’re in an ideal position to push changes upstream to Embroider.

Example: Working in a real-world context revealed module cycle issues in Ember applications using TypeScript. This happened because app files weren’t filtered from the compat modules when an app.ts file was present instead of an app.js. We used the Ember Initiative to fix this issue outside of pairing sessions. (embroider#2639)

We Maintain Essential Codemods

When aligning a classic Ember app with a modern stack (such as GJS files and Vite builds), tools like template-tag-codemod and ember-vite-codemod are invaluable. Our members often work with large, complex applications that include customizations and edge cases not initially covered by these codemods. Pairing sessions provide an opportunity to expand the capabilities of these tools and improve them for everyone.

Example: We revamped the exit process of ember-vite-codemod to allow all tasks to be imported individually. This enables members with large applications to run specific parts of the codemod instead of the entire process, and even insert custom steps not included in the generic codemod. (ember-vite-codemod#100)

We Upgrade Addons

Addons used by Ember Initiative members receive extra attention. The Ember Initiative allocates time to migrate them to the v2 format and ensure our members have high-performing, compatible addons.

Example: We helped migrate ember-scroll-modifiers to the v2 format. There was an initial attempt by community members in September 2024, but completing such an upgrade is non-trivial, and the pull request was abandoned. The Ember Initiative allowed us to revisit this. With our experience and methodology, we completed the work. This was made possible by the responsiveness of the maintainer, Jordan Hawker, who regularly merged our PRs—many thanks to him. (#1268, #1273, #1274, #1275, #1276)

We Create New Tools

Ember Initiative members develop innovative tools to address their specific needs, and pairing sessions help explore how these tools can be adapted for the broader community.

Example: A performance test implemented by Discourse inspired the build-start-rebuild-perf tool, which provides metrics about your application’s build time. Following the protocol described in our blog post, Ember Initiative: Tell us how much faster Vite makes your Ember app, you can help us gather data on how Vite performs in your application compared to classic builds.

We Shape the Future of the Ecosystem

We mentioned earlier that pairing sessions can help identify gaps in Embroider, but our findings often extend to the broader ecosystem. Working with real-world applications helps us pinpoint which best practices haven’t been widely adopted yet and need further promotion. Additionally, missing features or optimizations in complex projects can become the next must-have for the entire community.

Example: Babel parsing is an expensive operation that runs on all files because the resulting AST is needed to determine whether a file requires transformation. Our member Discourse implemented a Babel optimization by leveraging the much faster Rolldown parser to skip Babel plugin processing when no transformations are required. This approach could serve to inspire solutions aimed at reducing build times, particularly during dependency optimization.

Conclusion

Being a member of the Ember Initiative is about more than just getting help with your Ember stack (though you do get that too). It’s about directly shaping the future of Ember. Your day-to-day experiences—the challenges you face in the applications you deliver to users—help define what the entire community needs and what the framework should become to continue fulfilling its mission: enabling developers to build robust, high-quality applications as smoothly as possible.

To be part of the future of Ember, reach out to us and join the Ember Initiative. Spread the word and follow our progress on this blog.

Our clients, following good engineering practices, don't just blindly trust us and ask: Why? Why should I choose Svelte to develop my product?

This blogpost is an attempt to condense why I would go with Svelte most of the times.

The power of a compiler at your disposal

I still remember the first time I heard of Svelte: I was in the excruciating line to get my COVID vaccine shot and I was entertaining myself with some YouTube videos. I stumbled across this now-famous conference talk from Rich Harris: Rethinking Reactivity.

In this talk Rich showcased the idea of moving reactivity from the runtime into the language itself. A compiler! Just like in the good ol' days a C compiler could help you write programs more easily by writing the ASSEMBLY code for you, Svelte can help you write websites more easily by writing JavaScript code for you. Being a compiler is the first reason why I would choose Svelte, and this has several implications:

1. New language constructs: A compiler gives you a superpower, if you write a JavaScript variable in an HTML file, you can't use it in the template below. In Svelte you can! This is powered by the compiler that turns your template into JavaScript expressions that are in the same scope as your variables.
2. Write efficient code by default: Many C developers could not write ASSEMBLY as efficiently as gcc can, the same is true for JavaScript. Sometimes it can be difficult to write efficient code, but the Svelte compiler is written by a lot of very smart people (and me) who know how to write efficient JS for you.
3. Ability to change the runtime without changing the syntax: Another somewhat hidden feature of a compiler is that you can change the underlying runtime without having to change the syntax. We recently released Svelte 5, which, to be fair, was quite the syntax change, but you can still use your old components in Legacy mode. The same syntax now uses completely different technology under the hood (compile-time reactivity vs. signal-based reactivity). If tomorrow a brand new technique much better than signals is discovered, Svelte can pretty much just rewrite the runtime without changing the syntax.

Another very good example of the power a compiler gives you is the brand new experimental await API: since the compiler does not abide by the rules of JavaScript, you can use await in the middle of your script tag or component template and retain the signal-based reactivity even after the await; or we can Promise.all all your awaits in the template so that they don't waterfall.

All of this is only possible because Svelte is a compiler, which means it will allow users to write code in the most intuitive and logical way but still apply all the code changes required for it to work.

Now, some people are scared about a compiler touching their code, but here's something that not a lot of people realize: basically every framework is using a compiler of some sort. React is doing a minimal conversion, only transpiling JSX to React.createElement. Solid is doing a slightly heavier transformation that still only concerns the JSX part. Vue does an even heavier compilation, which still mostly touches the template part.

Optimize for the vibes

Quoting Rich Harris once again, one of the tenets of Svelte is "Optimize for the vibes". Nowadays "vibes" took a bit of a negative turn with "vibe coding," but the reality is that one of the design goals of Svelte is

People use Svelte because they like Svelte. They like it because it aligns with their aesthetic sensibilities.

Instead of striving to be the fastest or smallest or whateverest, we explicitly aim to be the framework with the best vibes.

You might argue that vibes are subjective but the fact that the design decisions around the framework strive specifically to make the framework the most intuitive have consequences on the engineering side.

Svelte is consistently framework most people are interested in in online surveys like "The State of JS" and "Stack Overflow Annual Developer Survey": developers want to learn Svelte!

This means that:

1. Your engineers will be happy: It's no secret that people work better when they use something that just makes sense to them. Less frustration with weird APIs, less context switching to look at the docs, fewer abstractions needed to make the code readable and maintainable.
2. Onboarding new hires will be easier: For the same reason, onboarding new hires on a project will take a lot less time, people learn React because they have to; people learn Svelte because they want to.

SvelteKit: the meta-framework for Svelte

I'm very often regarded as "The Svelte Guy" but a small confession I have to make is that I would consider myself "The SvelteKit Guy". I love Svelte but what really hooked me into it is SvelteKit.

SvelteKit is the meta-framework for Svelte, basically what Next.js is to React or Nuxt is to Vue. It uses Svelte as the templating language and builds an opinionated layer on top to develop actual applications. It provides ways to load data, handle routing, observability, and much more. As I've said, almost every framework has its own meta-framework that allows for all of this, so what's the deal with SvelteKit specifically?

The absolute care for DX

There are a lot of very good UX/DX decisions baked into SvelteKit: pre-1.0, a route in SvelteKit could be created by creating a .svelte file (or a folder with an index.svelte file in it) inside the routes folder. Then the team realized that this could lead to a lot of confusion in your codebase: you couldn't differentiate between a "normal component" and a "route", and you had multiple ways to declare the same route (/about.svelte and /about/index.svelte both resolved to the same /about route). And so they changed it: now, in SvelteKit, if you want to create a route, you have to create a folder and name your component +page.svelte.

A lot of people in the community were flabbergasted by this change: it felt weird, and a lot of people still think this is the worst part of SvelteKit. But when you stop to think about it, the reasons why they made this change make total sense, and they are all small details to make your experience the best possible:

• Now there's only one way to declare your routes: if you are looking for the file responsible for the /about route, you can rest assured it will be in /about/+page.svelte.
• If you have some component or module that is only used within a specific component, you can put this right next to your +page.svelte file without inadvertently creating a new route.
• It opened the door to other SvelteKit-specific files (namely +page.server.ts and +page.ts) to load data into your component
• In your editor you can just search for +page.svelte to get a quick view of all your routes.

"What about calling this page.svelte instead, like Next.js?"...the answer to this question is what really sold me on SvelteKit: naming your component +page.svelte makes sure that the SvelteKit-specific files are always recognizable and, most importantly, always on top!

Is this the killer feature that sold me? No, this is a nicety, but this told me that the SvelteKit team is obsessed with DX. They think about every single detail to make your life as a developer easier.

In house meta-framework

There's another reason why SvelteKit can have a small but important advantage over the other meta-frameworks: for the first time, the same team that builds the UI framework is also the one responsible for the meta-framework (and even the templating language itself). Obviously the Vue team has a direct line of communication with the Nuxt team, and a lot of the engineers who work at Vercel also work on React directly, but having literally the same team work on both sides of the deal can really change the game.

The moment SvelteKit needs a new Svelte API, there's no need to communicate: the team already knows if it's feasible, if it makes sense to put that in Svelte, and how hard it would be. Inversely, a new API in Svelte is developed keeping in mind the opportunities that it opens for SvelteKit. The synergy is unrivaled.

Deployment freedom

Every product has its own set of constraints, and one of these can be where to deploy it. Maybe you need a specific Azure/AWS product, or you appreciate the velocity and scalability of serverless environments like Netlify, Vercel, or Cloudflare. With SvelteKit, that's likely not a constraint: whenever you create a new Svelte project with the sv CLI, you are already presented with the choice of an adapter.

There are a lot of adapters that are officially maintained by the Svelte team and even more that are community maintained...and creating a new one is also very easy in case your specific use case is not covered.

The power of Vite at your disposal

Before @sveltejs/kit@v1.8.0, all the data returned from the load function needed to be awaited. If you tried to return a Promise, SvelteKit would just throw an error. On June 13, Astro released a new update that allowed Astro developers to use Server Islands.

What do those two facts have in common? That I've built support for both of them in SvelteKit before they were available (here's the repo for sveltekit-defer and here's the one for sveltekit-server-islands)...how? Because SvelteKit is just a Vite plugin! With that and the handle hook, you can craft very complex scenarios as if they were baked into the framework.

The Svelte ecosystem

In some other articles, you might have seen this point in the list of "cons" for Svelte. Let's be honest: React definitely has a much bigger ecosystem than Svelte. That said, I wouldn't necessarily consider this a downside:

1. Svelte still has a very good ecosystem.
2. You don't really need a lot of custom-made packages for Svelte: working directly with the DOM is very simple (we even have a primitive specifically for it), so your ecosystem is really the whole JavaScript ecosystem.

Use the Platform™

Do you know what Svelte animations and transitions are using under the hood? The Web Animation API. And what is SvelteKit using to handle the Request/Response cycle? Request and Response from the Fetch API. Those are just two examples, but Svelte and SvelteKit are very keen on using APIs and standards provided by the Platform.

Why does this matter?

Because the Platform is here to stay: building commodities on top of solid foundations will guarantee stability for the future.

Good Practices, not just Best Practices

Another point I absolutely love about Svelte is how it encourages you to go the extra mile to make the web more accessible. In Svelte, we have a whole set of compiler warnings that are specifically guiding you to write good and accessible code.

Adding an onclick listener to a div? That's fine, but you should also add an onkeypress to handle the expected "click with space" you usually get for free with buttons!

Adding an image? Well then, you should also add an alt text so that visually impaired visitors of your website can get an accurate description of it.

Using the built-in form action? By default, it will make sure your form works even before JS loads, because maybe your users are in a bad network area.

It takes courage for a framework to make the developer's life a bit harder (nobody likes a warning) in the name of teaching how to build sustainable and accessible websites. But that's actually part of the mission of Svelte, or as Rich said, our North Star is to "make better software".

Technically impressive

I've avoided talking about the performance of Svelte because that's something that will likely change over time (and because, except for certain kinds of applications, most modern frameworks are good enough). But if you are interested in it, it is worth looking into:

Svelte is one of the fastest frameworks out there, right next to SolidJS in the krausest benchmark for JS frameworks, and the simple SSR logic (basically just string concatenation) makes SvelteKit consistently top benchmarks for the server side too.

What about AI?

AI is changing the world of development, so it's only fair to dedicate a paragraph to this aspect. Hearing about a company migrating away from their existing stack to something that AI understands better is not unheard of (React being the usual choice). However (and, spoiler, this is an opinion, not a fact), I would argue that being more present in the training set of a Large Language Model doesn't automatically make it better.

Something is definitely true: React is kind of the default for LLMs because a big portion of the Web is built on top of it. Be it code snippets on GitHub, blog posts, tutorials, or actual open source products, the training set is just enormous. However, a lot of code also means a lot of BAD code. React being the first choice for junior devs who want to break into the tech scene makes LLMs very good at simple components and very bad at complex ones.

How does Svelte fare in this? Well, people who pick Svelte tend to be more senior engineers who evaluate their tech stack and spend time figuring out what's best. This also generally relates to better code. There's still a small issue, though: Svelte 5 was released a few months after the first big models started to become popular, which means that a lot of the training data is now outdated, but fear not: as I've said before, we truly want to make the DX of Svelte the best possible, and that, nowadays, includes being able to write good Svelte code with the help of your agent. That's why Svelte has an official MCP server that helps your agent get the documentation AND uses static analysis to correct it when it falls back to the old syntax. The best part? The MCP server can also steer the LLM to write good Svelte code, not just syntactically correct code.

When NOT to use Svelte?

If I told you that Svelte was the best at everything, I would:

1. Be a very bad engineer
2. Be hypocritical
3. Lose your trust completely (and you would be right)

Almost no tool is the perfect tool for every job, and Svelte is no different. That's why in this section I want to go over the situations where I would not choose Svelte:

• You need a big migration: If you already have a big codebase that's written in React/Vue/Solid/Angular, migrating to Svelte would, most likely, be a bad choice. Especially if you come from React, the mental model is very different, and migrating the whole codebase while also re-adjusting the mental model of your team could prove challenging and might not be worth the time and energy spent on it.
• All your team already knows something else: Even if you are not migrating but starting a greenfield project, it's important to coordinate with your team, if all your engineers are already versed in a different framework, starting your project while learning a new framework (and its relative quirks) could slow your project down too much.
• Content-heavy websites: If your website mostly consists of relatively static content (a blog, a documentation website), you could consider Astro as an alternative. Astro focuses on static websites and has tools built in for content management, documentation, etc. As a bonus: you can also add the Svelte plugin for Astro to sprinkle reactivity into your static website with Svelte.
• You need specific libraries that are not supported: Some libraries (like tldraw) are built around the React mental model and thus do not offer an agnostic version that you can safely use in Svelte.

Conclusion

So, should you use Svelte? If you are starting a new project and your team is either already familiar with it or open to learning, yes, absolutely. If you care about DX, about writing accessible code without having to think too hard about it, about deploying wherever you need, about having a meta-framework that actually talks to the UI framework it's built on, then Svelte is a very easy recommendation from me.

If you are sitting on a large React codebase, or your whole team lives and breathes Vue, or you just need a documentation site, then probably not right now.

If you are still on the fence or have a more specific situation in mind, feel free to reach out. I'm happy to talk through it.

Some of the changes between 6.9 and 6.10 tutorials are hidden in the new 6.10 blueprint though, so to be sure you don't miss anything and know how to perform this update in your own application, this blog post will guide you through updating Super Rentals to WarpDrive LegacyMode.

Before starting, a few assumptions

To make this blog post a bit more generic and usable as a resource to help people, we won't start from Super Rentals for 6.9 exactly. We will rather assume an older fictive Super Rentals:

• Currently using ember-data 5.3,
• That we would like to move to @warp-drive 5.8,
• Currently fetching data with store.findAll and store.findRecord, using the JSONAPIAdapter.

🐹 If your Store already relies on a RequestManager rather than Adapter (similar to what is showed in Super Rentals 6.9), then this blog post is still usable, but read (🐹 the hamsters) in the sections below.

ember-data 5.3

EmberData 5.3 is the latest EmberData LTS in which the code has nothing to do with WarpDrive. If we look closely at our .pnpmfolder, we notice the presence of warp-drive+build-config and warp-drive+core-types, but there's nothing in the code that uses something called "warp-drive".

Since we have managed our deprecations correctly, then we have an explicit Store service in the application, whose minimal possible implementation is just export { default } from 'ember-data/store';—but you may have something more complex in your own app.

1. Setup WarpDrive

When updating from ember-data 5.3 to ember-data 5.8, EmberData internals now rely on WarpDrive packages, and a bunch of new deprecations appear. This one was introduced in EmberData 5.5:

⚠️ Using WarpDrive with EmberJS requires configuring it to use Ember's reactivity system. (...)

It essentially asks us to setup WarpDrive. To do so, we need to install new dependencies and change two files:

pnpm add -D @warp-drive/ember@5.8 @warp-drive/build-config@5.8

At the top of app.js:

+ import '@warp-drive/ember/install';

In ember-cli-build.js:

- module.exports = function(defaults) {
+ module.exports = async function(defaults) {
    const app = new EmberApp(defaults, {...});

+   const { setConfig } = await import("@warp-drive/build-config");
+   setConfig(app, __dirname, {
+     deprecations: {
+       DEPRECATE_TRACKING_PACKAGE: false,
+     },
+   });

    // ...
  };

2. Introduce the Legacy Store

Another type of deprecation was introduced in EmberData 5.7. This one is about the store APIs:

⚠️ store.[findAll|adapterFor|serializerFor...] is deprecated. Use store.request instead. (...) See https://docs.warp-drive.io/api/@warp-drive/core/build-config/deprecations/variables/ENABLE_LEGACY_REQUEST_METHODS for more details.

The right way to fix this deprecation is to replace the old store APIs with the new API store.request, as described in the following cheat sheet.

There are different approaches to implement store.request more or less progressively. One approach that was implemented in the official Super Rentals for 6.9 relies on @ember-data packages and enables a progressive migration.

However, nowadays, my recommendation for an app like Super Rentals is to introduce the "legacy store" right away. Without going into the internals, the legacy store handles correctly both old APIs and the request API, so we can introduce the legacy store and keep our requests exactly as they are. This approach get us closer to a proper WarpDrive legacy mode with less intermediate steps.

In app/services/store.js:

- export { default } from 'ember-data/store';
+ import { useLegacyStore } from '@warp-drive/legacy';
+ import { JSONAPICache } from '@warp-drive/json-api';

+ export default useLegacyStore({
+   linksMode: false,
+   cache: JSONAPICache,
+   handlers: [],
+   schemas: [],
+ });

This relies on two more dependencies:

pnpm add -D @warp-drive/legacy@5.8 @warp-drive/json-api@5.8

(🐹 If your own app doesn't have the [findAll|adapterFor|serializerFor...] deprecation because it already uses the store.request API, you should still introduce the legacy store 👆 to properly enable WarpDrive legacy mode. Read the next section to understand what to do if you use a RequestManager.)

3. Use store.request API

Now that we have introduced our legacy store, we can progressively replace the old store API to fix the deprecations. Let's start with the index.js route in app/routes/rental.js that shows the list of available rentals.

In app/routes/index.js:

  import Route from '@ember/routing/route';
  import { service } from '@ember/service';
+ import { query } from '@warp-drive/utilities/json-api';

  export default class IndexRoute extends Route {
    @service store;

    async model() {
-     return this.store.findAll('rental');
+     const { content } = await this.store.request(query('rental'));
+     return content.data;
    }
  }

Which requires:

pnpm add -D @warp-drive/utilities@5.8

When we do this change, the app crashes. It returns a 404 on GET http://localhost:4200/rentals when trying to fetch the list of rentals— which sounds reasonable. Our resources are not at [host]/rentals, they are at [host]/api/rentals.json! WarpDrive no longer fetches resources at the right place, we are missing api/ and .json. And these terms were added by... the adapter (app/adapters/application.js):

import JSONAPIAdapter from "@ember-data/adapter/json-api";

export default class ApplicationAdapter extends JSONAPIAdapter {
  namespace = "api";
  buildURL(...args) {
    return `${super.buildURL(...args)}.json`;
  }
}

It's just that with the new request API, the adapter no longer works. We need a different way to configure the API namespace, and we also need to implement a request handler to define how requests are handled. ⚠️ This applies to the request API whatever you import it from @warp-drive/utilities/json-api or @ember-data/json-api/request. At some point you will face this through any migration path you follow.

(🐹 If you imported from @ember-data/json-api/request, it's time to move to @warp-drive/utilities/json-api. Same for all the imports coming next.)

3.1 Configure the API namespace

The API namespace can be configured in app.js:

  export default class App extends Application { ... }
  import '@warp-drive/ember/install';
+ import { setBuildURLConfig } from '@warp-drive/utilities/json-api';

  loadInitializers(App, config.modulePrefix);

+ setBuildURLConfig({
+   namespace: 'api',
+ });

Now, our 404 comes from [host]/api/rentals, we got our api/ back!

3.2 Implement a request Handler

To get the .json extension back, we need a request handler; literally something that modifies how the request should be handled.

First, we need to implement a handler that adds the .json extension before passing over to the next handler—which will be the default request behavior in that case.

Second, we need to make our store use that custom handler properly. The legacy store's options include a handlers array that we can use for that purpose.

In app/services/store.js:

  import { useLegacyStore } from '@warp-drive/legacy';
  import { JSONAPICache } from '@warp-drive/json-api';

+ const JsonSuffixHandler = {
+   request(context, next) {
+     const { request } = context;
+     const updatedRequest = Object.assign({}, request, {
+       url: request.url + '.json',
+     });
+     return next(updatedRequest);
+   },
+ };

  export default useLegacyStore({
    linksMode: false,
    cache: JSONAPICache,
-   handlers: [],
+   handlers: [JsonSuffixHandler],
    schemas: [],
  });

Our Super Rentals app is now in a state where the list of rentals is fetched with the new request API, and the details of one rental still relies on the old store API. Both approach work together, so we can finish this migration at our own pace.

(🐹 If your own app was already using store.request with a RequestManager service, then the service loses the responsibility of the handlers since they are passed to the legacy store. In other words, to move from Super Rentals for 6.9 to Super Rentals for 6.10, we remove completely the RequestManager and we pass JsonSuffixHandler to the legacy store handlers directly.)

3.3 Finish the store.request migration

The Rentals route that displays the details of one rental now looks like this:

  import Route from '@ember/routing/route';
  import { service } from '@ember/service';
+ import { findRecord } from '@warp-drive/utilities/json-api';

  export default class RentalRoute extends Route {
    @service store;

    async model(params) {
-     return this.store.findRecord('rental', params.rental_id);
+     const { content } = await this.store.request(
+       findRecord('rental', params.rental_id)
+     );
+     return content.data;
    }
  }

And we can delete app/adapters/applications.js.

4. Import Model from @warp-drive packages

The last thing to do to claim we use WarpDrive LegacyMode is to replace the imports in our Model class:

- import Model, { attr, belongsTo } from '@ember-data/model';
+ import Model, { attr, belongsTo } from '@warp-drive/legacy/model';

  const COMMUNITY_CATEGORIES = ['Condo', 'Townhouse', 'Apartment'];

  export default class RentalModel extends Model {
    @attr title;
    // ...
  }

Now all our legacy features are imported from @warp-drive/legacy rather that @ember-data. We can remove ember-data from the package.json. We now use WarpDrive LegacyMode 🎉

Next steps & codemod

Relying entirely on WarpDrive with all the deprecations fixed is a great migration step to move from EmberData to WarpDrive.

To go further and implement WarpDrive LegacyMode in the strictest sense, we could replace our Model classes with new WarpDrive Schema, relying on @warp-drive/legacy/model/migration-support.

A codemod is currently under development to migrate Ember applications to legacy mode. This codemod is expected to include adding WarpDrive packages, configuring them for use, and migrating Model classes to Schema.

The purpose of this blog post is NOT to help you understand all the subtleties of WarpDrive in accurate terms, like the documentation should do after a few more iterations. My goal as the author is rather to picture a simplified version, and roughly illustrate the different key stages in the modernization of your Ember application's data layer to clarify your migration path.

What is WarpDrive?

WarpDrive is EmberData. It's not a new library, it's a rebranding. If you go to npmjs.com and look for the ember-data package, you will see the corresponding GitHub repository is warp-drive-data/warp-drive.

Why a rebranding?

Because the name EmberData is entangled with Ember. The purpose of WarpDrive is to be a framework-agnostic data management layer that you can use with any frontend framework. It would be a bit weird though, to install a package named ember-data in a React or Svelte app. So the library was renamed, but it's still the same code. Essentially, if you're using EmberData, you're already using WarpDrive.

Then why are people talking about "migrating to WarpDrive"?

Differentiating between EmberData and WarpDrive emerged from the nuances surrounding published packages. WarpDrive builds on EmberData in the sense that it starts with EmberData, extracts the parts tightly coupled with Ember into new framework-agnostic packages, and publishes them as @warp-drive/*. However, the packages named @ember-data/* still exist and continue to function.

So, using "WarpDrive" means using the agnostic @warp-drive/* packages as designed. In contrast, using "EmberData" means using the @ember-data/* packages, with their Model and Adapter and whatnot, which remain tightly integrated with Ember. But the technical reality behind the daunting phrase "migrating from EmberData to WarpDrive" is more about managing a deprecation. In fact, when you update your package.json from "ember-data": "5.3.13" to "ember-data": "5.8.0", you'll encounter deprecation warnings guiding you toward your first import from @warp-drive.

Model to Schema: a telling example

WarpDrive is designed to be framework-agnostic. However, since it was built from EmberData—and given that WarpDrive represents the future of EmberData—it’s clear that the first users of WarpDrive will be largely Ember developers who already used EmberData, with a codebase filled with Model classes.

The famous Model classes from EmberData are tightly coupled with Ember and cannot be used as-is in other frameworks. WarpDrive introduces a new Schema concept, allowing you to model application resources independently of any framework. Thus, fully migrating from EmberData to WarpDrive requires converting all your old EmberData Model classes into new WarpDrive Schema definitions.

There are other differences between EmberData and WarpDrive, particularly around the store API.

WarpDrive LegacyMode: the first target for EmberData users

A transitional mode

Imagine you have hundreds of Model classes in your codebase. It’s impossible to convert all of them to Schema in a single major update. Fortunately, WarpDrive’s development includes a cautious approach to untangling Ember: the LegacyMode, which allows WarpDrive to continue handling EmberData’s features. For instance, LegacyMode enables coexisting Model and Schema.

You can think of LegacyMode as a key transitional phase where you can "use WarpDrive as you used EmberData".

An easy-to-reason-about definition

From my perspective, you can reasonably claim to have reached LegacyMode when:

• You've configured WarpDrive in app.js and ember-cli-build.js (as indicated by the deprecation warnings in ember-data 5.7).
• Your store relies on useLegacyStore.
• You've adopted the new store.request API (as indicated by the deprecation warnings in ember-data 5.7).
• All your imports from @ember-data packages have been replaced with imports from @warp-drive (for example, your Model class now comes from @warp-drive/legacy/model instead of @ember-data/model).
• Your package.json no longer includes ember-data, but only @warp-drive packages, including @warp-drive/legacy.

Once these steps are completed, you still have your Model classes, and your code hasn't changed much. However, you’ve unlocked the ability to gradually migrate your Model classes to Schema.

Other subtleties

Note that there are also ways to gradually reach the LegacyMode—for example, by incrementally introducing the new store APIs. This is why it can sometimes be difficult to navigate and determine which step to target. The Super Rentals tutorial for Ember 6.10 aligns with the key points described above and represents a clean and clear milestone for defining the LegacyMode to aim for before moving on to converting Model classes.

Initially, when you start creating Schema classes, the simplest approach is to continue relying on the legacy packages. By creating Schema classes using the tooling provided by @warp-drive-mirror/legacy/model/migration-support, they will automatically inherit properties that Model classes had, such as fields (isNew, hasDirtyAttributes, etc) or methods (rollbackAttributes, save, etc). Therefore, even after migrating all your models to this iteration of Schema, you are still operating in LegacyMode—in its strictest sense: you are "ready to exit legacy mode in the next iteration."

Coming Codemod

A codemod is currently under development to migrate Ember applications to WarpDrive LegacyMode. This codemod is expected to include adding WarpDrive packages, configuring them for use, and migrating Model classes to Schema.

In the next blog post of the "From EmberData to WarpDrive" series, we will see how Super Rentals tutorial was migrated to WarpDrive in practice.

MirageJS is the core library. At some point in the past this was extracted from ember-cli-mirage to its own library for framework independent use. ember-mirage is a set of utilities that brings some of the benefits ember-cli-mirage provided. This means that for basic setup, you may not actually need it, but it provides some features that ember-cli-mirage used to provide that might make migrating a little easier.

Prerequisites

This blog post is intended to be a step during a migration to Vite since we'll make use of import.meta.glob. This is a feature provided by Vite to allow glob imports of files. The steps can be taken at any point after, for example, running the ember-vite-codemod, or after migrating to Vite manually.

The steps are outlined from a fresh-app perspective to make it clear what each part of the config does. Most of your actual Mirage related files can stay where they are and like they are. We're mostly going to rewrite the configuration.

If you're still on a classic build, you can make use of the ember-import-meta-glob polyfill. This does require that all mirage files are within the app folder, rather than the root of the project where it used to be with ember-cli-mirage. Vite can work with either location, so once you're ready to upgrade to Vite you won't need to move things around.

Let's get going

The first thing we'll do is add MirageJS and ember-mirage as dependencies.

pnpm install -D miragejs ember-mirage

With ember-cli-mirage, all mirage related files lived in a top-level /mirage folder. This is still where we'll keep our MirageJS configuration, factories, models and other modules.

In order to start our new setup we'll create a default server configuration which will serve as the entry point.

// mirage/servers/default.js
import { createServer } from "miragejs";

export async function makeServer(config) {
  return createServer({
    ...config,
  });
}

One of the features in which ember-cli-mirage followed ember.js is a lot of files were placed in certain spots by convention. In order to provide a similar setup, we can use the createConfig utility provided by ember-mirage to load all our Mirage factories, fixtures, models, serializers and identity managers. We can use Vite's import.meta.glob to import all of them at once from their folders. The generated config can then be splatted into the config passed to the createServer call.

// mirage/servers/default.js
import { createConfig } from "ember-mirage";

const mirageConfig = await createConfig({
  factories: import.meta.glob("../factories/*"),
  fixtures: import.meta.glob("../fixtures/*"),
  models: import.meta.glob("../models/*"),
  serializers: import.meta.glob("../serializers/*"),
  identityManagers: import.meta.glob("../identity-managers/*"),
});

export async function makeServer(config) {
  return createServer({
    ...mirageConfig,
    ...config,
  });
}

Loading ember-data models

Another feature ember-cli-mirage provided was automatically inferring Mirage models from ember-data models, meaning MirageJS will infer model names and their relationships from the ember-data models. The configuration roughly matches the previous one. Note that makeServer accepts an optional store parameter to pass an ember-data store instance. When called from the application route during development, we pass the store directly. In tests, the store is looked up automatically from the test context.

// mirage/servers/default.js
import { importEmberDataModels } from "ember-mirage/ember-data";
const emberDataModels = import.meta.glob("../../app/models/**/*");

export async function makeServer(config, _store) {
  // Look up the store from the test context if not provided
  let store =
    _store ??
    (await import("@ember/test-helpers"))
      .getContext()
      .owner.lookup("service:store");

  return createServer({
    /* ... */

    models: {
      ...importEmberDataModels(store, emberDataModels),
      ...config.models,
    },
  });
}

If you want the ability to pass custom models, be sure to also splat config.models in the way the above config does.

Defining Mirage routes

Defining routes hasn't really changed. This happens within the routes() { … } function part of the createServer configuration object. In practice you'll likely want to define your routes in some folder structure for better manageability.

// mirage/servers/default.js
import { createServer } from "miragejs";

export async function makeServer(config) {
  /* ... */

  return createServer({
    /* ... */
    routes() {
      this.get("users", function (schema) {
        return schema.users.all();
      });
    },
  });
}

Integrating with the test setup

We've added a lot of configuration, but we don't actually boot MirageJS anywhere. Let's add a test helper that uses our previously created makeServer function. We'll also set the environment to test. This configuration option defaults to development which adds a default delay of 50ms to every request. Not something we want for tests! The config is also written in a way that allows you to pass a custom makeServer when setting up Mirage in a test.

// /tests/helpers/setup-mirage.js
import { setupMirage as upstreamSetupMirage } from "ember-mirage/test-support";
import { makeServer } from "my-app/mirage/servers/default";
export function setupMirage(hooks, options) {
  options = options || {};
  options.createServer = options.makeServer || makeServer;
  upstreamSetupMirage(hooks, {
    ...options,
    config: {
      ...options.config,
      environment: "test",
    },
  });
}

Trying it out!

We have everything we need to test the basics. Below is a quick unit test to verify that everything is working as intended.

// tests/unit/example-test.js
import { module, test } from "qunit";
import { setupTest } from "ember-qunit";
import { setupMirage } from "../helpers/setup-mirage";

module("Unit | Mirage | example tests", function (hooks) {
  setupTest(hooks);
  setupMirage(hooks);
  test("it works!", async function (assert) {
    let mirageUser = this.server.create("user", { name: "Chris" });
    let store = this.owner.lookup("service:store");
    let emberDataUser = await store.findRecord("user", mirageUser.id);
    assert.strictEqual(mirageUser.name, emberDataUser.name);
  });
});

What about using it in the app itself?

You may also want to use Mirage during development, for example to work on a feature before the backend API is ready. We can use @embroider/macros to conditionally start the Mirage server in a way that ensures it is completely excluded from production builds.

// app/routes/application.js
import Route from "@ember/routing/route";
import { isDevelopingApp, isTesting, macroCondition } from "@embroider/macros";
import { service } from "@ember/service";
import config from "../config/environment";

export default class ApplicationRoute extends Route {
  @service store;

  async beforeModel() {
    if (macroCondition(isDevelopingApp() && !isTesting()) && config.useMirage) {
      let { makeServer } = await import("../mirage/servers/default");
      let server = await makeServer(
        {
          environment: "development",
          scenarios: await import("../mirage/scenarios"),
        },
        this.store
      );
      server.logging = true;
    }
  }
}

The macroCondition with isDevelopingApp() && !isTesting() ensures the entire block is tree-shaken from the production build. The dynamic await import() of the server configuration means none of your Mirage code will be bundled in production either. The additional config.useMirage flag gives you a way to toggle Mirage on and off during development via your environment configuration.

We pass the ember-data store to makeServer so that Mirage can generate its models from your ember-data models. We also import a scenarios module, which is simply a function that seeds the Mirage database with development data. Finally, enabling server.logging will log all intercepted requests and responses to the browser console, which is useful for debugging.

Wrapping up

Migrating from ember-cli-mirage to ember-mirage requires a bit more manual setup, but the result is a Vite and Embroider compatible MirageJS configuration that stays close to the native MirageJS experience, with ember-mirage providing utilities to make migration easier for situations where there was a reliance on ember-cli-mirage.

It's worth stepping back and noticing what's happening here: we're using standard JavaScript features like dynamic await import(), top-level await, and Vite's import.meta.glob instead of legacy Ember-specific magic. The old ember-cli-mirage relied heavily on Ember conventions and build pipeline hooks to auto-discover files. The new setup replaces those "Emberisms" with vanilla JS and standard build tool features. This is only possible thanks to the significant progress the Ember ecosystem has made over the last couple of years with Embroider and the move to Vite. Modern Ember applications are much more aligned with the broader JavaScript ecosystem, making it easier to leverage standard tooling and reducing the framework-specific knowledge needed to be productive.

For more details, check out the ember-mirage repository.

People immediately started experimenting with the model's ability to generate code, but most generations were performed by copy-pasting code into the chat interface and asking it to update it in a certain way.

When the model also became available via the API, people started experimenting with a different workflow: programmatically reading a file, sending an API request with a prompt, and running the tests to verify the code worked as intended. Running this in a loop produced, as expected, much better results at the cost of more tokens.

This was the beginning of what would grow to become Agentic coding!

One of the first big products that doubled down on this was Claude Code from Anthropic: a CLI that allowed the user to prompt the LLM, but that also exposed certain tools to it, allowing the LLM to invoke them by writing a specific message pattern. This quickly improved the situation even more: the agent could now invoke bash scripts, read multiple files based on what it thought was necessary, search the web, etc.

Vibe coding

On the 2nd of February 2025, Andrej Karpathy (one of the most influential voices in the AI world, co-founder of OpenAI) sent a tweet that defined a new term: Vibe Coding.

The idea of vibe coding is that you let the agent take the wheel: you express what you need in a prompt, the agent produces it, and you accept without looking at the code. If bugs arise, you tell the agent to fix them. Rinse and repeat until you have an app.

This concept exploded in popularity. Countless businesses were built on the concept of allowing you to vibe code your whole application directly in the browser (or even on your phone). Suddenly everybody, even non-technical people, were building apps.

However, as you might imagine, this utopia wasn't there to last. Sure, as long as you build your own hyper-specific app with one user, vibe coding might serve you well enough, but try to scale that to build an actual product and the cracks start to show.

The term quickly became synonymous with "bad software" but the fundamental idea was so strong that people with actual engineering experience started to approach it from the other side of the line.

Automated tests, linters, LSP, Git... all these tools allowed people who knew how to build reliable software to approach the same velocity while also keeping the agent in check.

One year goes by (which means at least 100 years in AI years *ba-dun-tss*) and Karpathy tries to do it again... and somewhat surprisingly he's successful: but now he's talking to the engineers, to the ones who know how to build software and use AI "responsibly"; they not only read but try to understand the code, they steer the agent towards the right solution, not just a solution, they write tests, they think about how to make the code maintainable.

This was the start of Agentic engineering.

Agentic Engineering

So how do the two compare? And how do they differ? They couldn't be more similar and yet more different:

As we explained earlier, Vibe Coding is ALL about embracing the vibes: a true Vibe Coder doesn't even open the editor to code. They just talk to an agent in what could be compared to the narrative technique known as stream of consciousness, then look at the end result, check if what they are working on works, and, if not, ask the agent to fix it. There's rarely full coverage of the application's capabilities because a single person can't possibly check every single edge case of every single feature. The agent is the real owner of the code.

That's also true with agentic engineering and that's what makes the two so similar: to really boost your productivity you should let the agent do what it does best... write code at the speed of light. What changes is mostly around the code. In this case you do look at the code, you carefully review it, you put systems in place that can test your whole app for you at every change to guarantee robustness and soundness (making sure to use tools that make information flow back into the agent without wasting context), and you force the agent to check its work before completing a task.

You are basically graduating your agent from "kid in their room writing their first game" to "serious professional building production-grade applications".

Where does Svelte fit in this?

I know, a blog post by me that still doesn't mention Svelte. I was surprised too. But here we are, finally I can talk about my favorite topic 😁

Where does Svelte fit in this AI-driven world? The answer, as often happens in the tech industry, is: it depends.

What does it depend on? Well, as we've seen, things move fast today and the pair Svelte + AI took many shapes over the course of the last year or so. Buckle in, we are going back in time!

Before the Agents

As we explored already, initially almost nobody was doing agentic coding. Most of the coding LLMs did was simple components copied and pasted into their chat. Those models were also not that great at coding in general. And they had a lot of Svelte 4 in their training set. And we recently released Svelte 5.

I don't think I have to tell you much more: the experience for those who wanted to use Svelte was pretty bad at that time. LLMs were maybe able to write a few good Svelte 4 components but even in that case, inspecting the system prompts of the top labs showed they were directly nudging the LLMs towards the most popular choice: React.

That led most of the generations to look like Frameworkstains with React APIs interleaved with Svelte templates. It was a dark time for the Sveltelowdas (collective noun for Svelte developers), to the point that a lot of people wanted to use it at their job but couldn't recommend it because their colleagues wouldn't have been able to use AI with it.

Luckily, with time, model capabilities grew, the training set started to fill with Svelte 5 examples, and most importantly the way in which we, as maintainers, could influence the output of the generations changed radically.

llms.txt: the first step

The first tool we got in our tool belt was a standard that started to emerge in 2024. A lot of websites started to serve content specifically tailored for an LLM (text-only, markdown, etc.) by appending /llms.txt to the current route. The idea was that, if the standard did catch on, LLMs would be trained on this knowledge and could navigate a version of the web that was specifically designed for them.

The Svelte team jumped on this opportunity and, during Advent of Svelte 2024, added /llms.txt, which allowed LLMs to access the full Svelte/SvelteKit documentation. Every single documentation page also got the same treatment (in case you wanted less token waste for features you were not using). This did make things a bit better but was still not enough.

If you know the Svelte team, you know that we care about your DX above almost everything... we knew we had to take things up a notch, not because we wanted to please the agents, but because we wanted our users to be able to use Svelte without feeling left behind in this crazy race.

The task force

We established a task force where a few interested maintainers and ambassadors would brainstorm ways in which we could make the experience better for everyone. As in any good brainstorming session, a lot of ideas were... not so great. But in the meantime the tooling around agents started to become more sophisticated and we quickly realized that a possible solution could've been writing an MCP server!

In case you are unaware of what an MCP server is, I invite you to open this other blog post of mine on the topic.

The tl;dr is that it's a way to expose tools/resources/prompts so that the LLM or the user can enrich the context with new information. The base version of the MCP exposed every documentation page as a resource and as a tool. This means that the agent can invoke the documentation tool autonomously to learn about Svelte before writing the code.

But while brainstorming we also had another idea...

The svelte-autofixer tool

"What if we run the deterministic migration script on the generated code?" or "What if we run the linter on the generated code?" were a couple of ideas that were thrown around during the various brainstorming sessions.

And that's what we did... well, not exactly.

Despite what some people might think LLMs are not even close to us humans. They make silly mistakes, sometimes they write syntactically correct Svelte code that doesn't make sense semantically. But they have an advantage: they don't get offended if you point out one of their mistakes.

So yes, we can run the compiler and get the compile errors/warnings, we can run ESLint and get the same warnings that you would get in your editor... but we can do more: we can specifically tailor our static analysis to the mistakes that we see the LLMs make more often.

One example... I've seen LLMs generate code like this

<script>
	import { count } from "./my-counter.svelte.js";
</script>

<button onclick={()=>count.value++}>
	{count.$}
</button>

You would never write an official lint rule that prevents accessing the $ property on a variable. Humans tend to knows the shape of their objects and there nothing really special in a property named $.

But we know LLMs tend to do this because their knowledge is poisoned by the store reactivity of Svelte 4. And so we warn on code like this.

"But what if it's not a mistake and that's actually the shape of the object?"

That's the best part: we don't have to do crazy static analysis to determine this: we can just "talk" to the agent and say "To access a stateful variable you don't need to use .$. Please verify that the shape of the object includes a property named $ or update the code to use count.value". They'll do the rest!

Furthermore if we see code like this

<script>
	let count = $state(0);
	let double = $state(0);

	$effect(()=>{
		double = count * 2;
	});
</script>

{count} * 2 = {double}

we can warn the agent to use a $derived if possible. We can steer the agent to write GOOD Svelte code, not just correct Svelte code.

The reception for the MCP server was fantastic: people were finally able to write good Svelte code with their agents... but (as we've seen before) the AI race doesn't stop. New tools get created, new strategies and necessities emerge, and we don't plan to stop either.

Skills

After revolutionizing the agentic world with MCP, Anthropic did it again: on the 16th of October 2025 it released skills! What are they? MARKDOWN FILES!

Joking aside, while a skill is indeed a markdown file, the concept behind it is that an agent is specifically instructed to read it based on the description specified in its frontmatter when it thinks it can help fulfill the task assigned by the user. It's a sort of dynamic AGENTS.md.

A lot of people saw the potential of this new tool: you can tell the agent how to run scripts, you can use the tool in your shell to act on the real world, etc. A lot of people declared MCP dead (even though it is far from it) and, rightfully, asked for a solution from the Svelte team.

We started with a simple 1:1 replacement: the STDIO Svelte MCP is a package on npm and can now also act as a CLI... This allowed us to also write a skill that instructs the LLM on how to use it and voilà: if you want, you can save the MCP description tokens while still accessing the docs and the autofixer from the CLI.

But we didn't stop there: a skill can help the agent use a CLI but can also directly instruct the LLM about what to do and what not to do. We started writing a skill that could encompass all the best practices for writing very good Svelte. But then we realized that this content is actually something that could help a developer starting to learn Svelte; so, as usual, we prioritized our human users. The skill is now a documentation page that then gets synced to also become an installable skill in the @sveltejs/ai-tools repo (btw we've seen astonishing results with this skill and I highly suggest you use it together with the MCP).

Context Management & Subagents

The more people started using these tools, the more everyone realized the main resource in an agentic session is context. Most models limit the amount of context you have available (as in the amount of tokens the model can have in memory before auto-compaction summarizes the whole conversation) to something like 200k tokens. Some models have much larger context windows (for example GPT-5.5 has a 1 million token context window).

However, even if your model had an infinite token window, the quality of the model rapidly degrades after the 100k mark.

This also led to a series of tools and techniques to reduce the amount of tokens the agent produces.

This seems to somewhat counter the benefit of the Svelte MCP/CLI: reading the docs and getting suggestions from the autofixer both consume tokens. However, we have a secret weapon in our quiver: since updating a Svelte component is generally a very atomic operation, we can use another tool that agent harnesses generally provide: SUBAGENTS!

The idea is that your agent can simply spawn another version of itself with a custom, laser-focused prompt for a single task (like for example "update this Svelte component"). And so we did: we created the svelte-file-editor subagent (which also has extra instructions on how to best use the MCP/CLI).

Configuration

All of this must be very annoying to configure every time you start a project... we know. And that's why the repo itself is a Claude Code/Cursor marketplace that allows you to install every tool with a simple click AND we also have an opencode plugin that you can install with opencode plugin add @sveltejs/opencode.

What about the rest?

The previous chapter was all about Svelte but what about the rest? The rest is very important too: if you think of an agent like a mid-level engineer you realize that we already have a lot of systems in place to keep our colleagues in check.

Git

Git was already pretty fundamental in the development world, but with the advent of agents that can write a lot more code in the same amount of time, and that sometimes do so in a pretty destructive way, it has become a tool you absolutely need to use.

Personally I use it to help me with the review process: before sending a prompt to an agent I will commit the previous work (if it's ready) or at least stage it. This means that when I'm back at my editor after the victory bell of the agent I can quickly glance at the git panel and see which files it changed. I can then open them one by one and carefully review which part of the file changed in a nice diff view. Honestly I don't think I would be able to run an agent on a codebase without git.

Git also allows you to quickly revert a change in case it is wrong (which, let's be honest, happens more than we care to admit).

Tests

Another blast from the past: automated testing was always very important and we, at Mainmatter, know this very well. We helped a lot of clients modernize or even build their test suite from the ground up because we know that to ship fast you have to have some assurance that the PR you are merging doesn't break your main flow in subtle ways.

Safe to say this is even more important when the entity that writes that PR cannot really think and is just pattern matching.

Funnily enough, what was considered almost a bad practice at some point has now become the recognized way of writing tests with AI: TDD.

TDD stands for Test-Driven Development and the idea is to write the test even before writing the implementation. You assume the API exists and works how you want it to work, write the test, see the test fail, then write the minimal amount of code to make it work. Rinse and repeat, adding a refactor in the middle to make the code more robust. Admittedly the practice with AI is a bit different and relies mostly on the red-green pattern.

You ask the agent to write a test, verify that it fails, and then write the code to make it work. The "minimal amount of code" and "refactor" parts are generally omitted to not confuse the agent but the important bit is that when you let AI write your tests you absolutely want to see the test fail first.

Why?

Because LLMs for some reason love writing useless tests. I've seen agents write 300+ lines of tests that all looked like this

import { it, expect } from "vitest";
import { writeFileSync, readFileSync } from "node:fs";

function write_to_file(obj) {
  writeFileSync("./file.json", JSON.stringify(obj));
}

it("...", () => {
  const obj = {
    property: "value",
  };

  write_to_file(obj);

  const file = JSON.parse(readFileSync("./file.json", "utf8"));
  expect(obj.property).toBe(file.property);
});

// other 30 tests that all created an object, wrote it to a file and
// asserted that the file was written

which is basically testing the JS runtime (it's not even importing something from another module).

However if you let your agent write a test that fails it has to at least find a way to make it fail and then pass without touching it.

Regardless of whether you let your agents write your tests or not, having a solid test suite is absolutely crucial for another reason: it allows the agent to verify its work. It's much easier to express intent in a formal programming language and something that might be difficult to express in a prompt can be asserted with clarity in vitest. The agent can then run until the test is green (hopefully with a fix that doesn't break the rest of the test suite).

Code Reviews

As we repeatedly said during this article, nowadays code is produced at unprecedented rates. And as we said already, if you are doing agentic engineering you do care deeply about the quality of the code. This means that most of your time you'll actually be reviewing code.

Now, someone might prefer reviewing to writing, but judging from the number of conflicting PRs left in the average project we can assume developers tend to like coding more than reviewing. It is a bit of a shame that AI is stealing the fun part from us and not helping us with the boring part.

Or is it?

That's right, AI can also help us review the code!

I can see your skeptical face from here (which also means I can see in the future, that's impressive): if the AI is able to figure out that something is a bug why not prevent it from writing the bug in the first place?

Well, first, this happens to the best of us too: did you ever write a PR, come back to it the day after and notice a blatant bug? Secondly, since every time you restart the chat the AI has its memory wiped, it's just like having another person look at the code and, when instructed to look for bugs, they generally do an even better job at it. Thirdly, we can use a different model, with a different system prompt, optimized for reviews, which will give us an even better result.

Once we know this, it is just a matter of creating a GitHub workflow that runs on every PR and reports the findings in a comment. And if this feels like a business opportunity, you are right: there are dozens of tools that offer this functionality.

Personally I really like Greptile, it's free for open source, it has a lot of nice features and customizations, and also gives you analytics on your reviews.

The world after Deployment

During development it's all fun and games. But how can AI help you in Production? That's where another important tool comes into place: observability (have you realized how everything that helps big teams of engineers is also table stakes to work with agents... how curious).

Setting up a good observability platform is key to allow AI to help you in production. Regardless of whether you review your code or run tests on CI, bugs will inevitably ship to Production. The goal is to be able to detect them, know precisely where they are and fix them as quickly as possible.

SvelteKit makes this super easy with the experimental tracing/instrumentation option: you can just enable it in your config, create a src/instrumentation.server.ts and you will be able to collect information about every request as granularly as a single load/remote function.

When it comes to the choice of your observability platform anything will do but, obviously, the more the platform allows you to integrate with AI the better. That's why personally I really like Sentry:

• They have a very good integration with SvelteKit (in fact they actually contributed on the PR that allowed tracing/instrumentation)
• They are very on the bleeding edge of AI: they have an MCP server and a Skill+CLI that allows you to bring all the tracing information to your agent in no time
• They even wrote their own cloud agent that allows you to fix the issues in production from everywhere by clicking on a button and writing a quick prompt.

How all of this applies in the real world?

There's no doubt that LLMs changed the name of the game for software development...today we have new tools and workflows to learn, especially when building with Svelte, but the engineering practices we've always relied on and that we've used to help our clients haven't gone away. In fact, the same principles that help teams ship quickly without sacrificing code quality are, today, effectively a requirement to help AI agents work effectively in a codebase without turning it into a spaghetti-code nightmare. But words are easy to write...when it comes to real software is this actually feasible? Could you actually build a good application solely using agents?

Good news, we put that to the test!

We are releasing a mini-series where I will be setting up the environment and building an application using the principles of agentic engineering (if you are reading this in the future the series might be already fully out...isn't that nice?).

You can watch it here, during the series we are gonna build DayRelay: a news aggregator where you can pick the sources of your news and every day let AI visit them and find the best news for you so you can have your personalized newsletter!

And if you want to get the most out of your agents without risking the quality of your codebase you can visit https://mainmatter.com/svelte to learn more about how we can help you.

Agent Client Protocol, or ACP: a protocol for communication between coding agents and editors or IDEs. It standardizes capabilities such as sessions, tool use, file diffs, and status updates using local or remote transports.

Agent harness: the software surrounding the model that manages system prompts, context, tool execution, permissions, retries, state, stopping rules, and outputs. While it may seem like just a detail (like the editor you choose when writing your code), the same model can behave completely differently in different harnesses. This is both because the system prompt and tool descriptions can steer the agent toward better or worse results, and because certain models are trained on specific harnesses and will work better when the tools available match their training set.

Agent loop: the main loop in every harness, where the inference API is invoked over and over until a stopping condition is met.

Agent swarm: a loose label for a larger, distributed group of agents that works concurrently each with their own responsibilities and goals. It has no single standardized technical definition and is often used more broadly than "multi-agent system."

Agent2Agent Protocol, or A2A: an open protocol for communication and collaboration between independent agents, potentially built by different vendors. It is intended for delegation, coordination, status exchange, and delivery of results while allowing each agent's internal implementation to remain opaque.

Agentic engineering: a term introduced (once again) by Andrej Karpathy in a 2026 tweet, with a refined and more mature view of vibe coding. Agentic Engineering is the natural evolution of Vibe Coding, in which models have become more and more capable and the work you can do with them has moved from simple prototypes and internal apps to actual products. The difference from vibe coding is that you care about code quality and put all sorts of engineering systems in place to prevent the agent from writing bad code or introducing bugs and regressions in your application.

Agentic workflow: a repository or business workflow expressed as a goal and a series of verification checks rather than a deterministic script. The coding agent decides how to complete the task and when it is actually done.

AGENTS.md: an open convention for placing agent-specific repository guidance in a predictable file. Since this file is included in every thread, it should be used sparingly and include only information that can't be inferred by searching the codebase or statically analyzed by a lint rule.

Benchmark: in the dev ecosystem a benchmark is usually meant to measure performance. This is also true for models but they aim to evaluate the performance of a specific model to solve tasks rather than CPU cycles.

Benchmark contamination: exposure of a model or agent to benchmark tasks, solutions, patches, or close duplicates during training or development. Contamination can inflate scores without reflecting general capability.

Codebase indexing / semantic code search: preprocessing or embedding repository content so an agent can retrieve relevant symbols and files by meaning rather than relying only on exact text matching. While this practice seems like a no-brainer, research shows that allowing an agent to build the context it needs autonomously is far more effective.

Compaction: When models reach a certain threshold of used context, their intelligence drops drastically. To solve this, many harnesses trigger a compaction when the context reaches that threshold. A compaction means summarizing the current thread with an AI model to extract only the relevant information, then resetting the context to include only that summary.

Computer use: a capability that lets a model interact with graphical interfaces through screenshots, mouse actions, and keyboard input rather than only calling APIs or terminal tools.

Context: the maximum number of tokens that a model can manage. Every message (whether from you or the AI), MCP definition, skill, tool call, etc. increases the running count of tokens in the context. It's the most precious resource for an agent: the agent needs context to properly work on what you want, but once the context fills up, the model's intelligence quickly degrades. This is why it's important to add only the things that are necessary for it to work (no unnecessary MCPs, skills, or instructions).

Context engineering: applying engineering practices to context management by fine-tuning the amount of context fed to the agent to provide just enough to get the task done, and no more.

Context rot: the decline in agent performance as its context becomes longer, noisier, internally inconsistent, or crowded with obsolete information.

Continuous AI / agentic CI: the use of background agents as an analog to continuous integration. Instead of only running deterministic checks, agents continuously perform judgment-heavy work such as documentation maintenance, test improvement, issue triage, or repository hygiene.

Deep-SWE: a long-horizon software engineering benchmark that delivers four major advances over today's public benchmarks: no contamination, high diversity, real-world complexity, and reliable verification. It gained popularity for being much closer to what the public perceives as intelligence.

Evals: a repeatable procedure for measuring how well an agent performs defined tasks. It's like unit testing for the agent's work, and it generally consists of invoking a model and writing expectations for the output. Given the probabilistic nature of agents, it's unreasonable to expect a 100% pass rate for evals, but they can be used to verify how different models and prompts affect the "business logic."

Handoff: the transfer of responsibility and knowledge from one agent to another. It can be implemented in different ways, but it generally requires storing the plan or state of the task in an external file that can be referenced later.

Harness engineering: Harness engineering is the practice of applying engineering principles to the harness to get the best possible result with a given model+harness pair. This means introducing the right set of skills, tools, subagents, and instructions, and having the right codebase structure, abstractions, and developer tools to make the job of an agent working in said codebase as smooth as possible.

Hooks: deterministic functions invoked at specific moments during an agent's execution (before sending a message, on a tool call). They allow the developer to hook into the lifecycle of an agent loop.

Human in the loop, or HITL: the practice of making the agent request permission for every action, introducing a human element into the agent loop.

LLM: an acronym for large language model. It's the kind of neural network that is most popular nowadays. As the name suggests, it's a model that tries to predict the next token in a sentence by using the fact that, in a language, the distribution of words isn't random. These models are large because they've been trained on very large quantities of text to make them as accurate as possible.

Long-context task: a task that requires many actions, context updates, or sessions rather than one model response. Examples include implementing an application, upgrading a large dependency, or resolving a complex repository issue. This is also used as a measure of a model's quality by measuring the longest-horizon task it can perform.

Long-horizon task: similar to Long-context task but it heavily relies on information only available in the context, forcing the agent to pick the right information to maintain while compacting.

Managed agent: an agent whose runtime, session state, sandbox, tools, and execution infrastructure are provided as a managed service, allowing applications to introduce agentic workflows without the burden of managing retries, sandboxing, etc.

MCP: stands for Model Context Protocol; as the name suggests, it is a protocol, which means a shared contract between two parties that need to communicate. This allows MCP clients (a role generally fulfilled by the harness) to talk to MCP servers (programs that listen for JSON-RPC payloads and expose tools, resources, prompts, etc.), e.g. to retrieve information or invoke tools. It's an easy way for developers to "package" a series of tools and provide them to the model.

Model-native harness: a harness developed by the same company that also develops the model (e.g., Claude Code for Anthropic, Codex for OpenAI). While some people think these are optimized for the model, research shows that's not the case.

Neural network: a combination of a data structure and an algorithm that is meant to mimic the human brain by correlating certain outputs with certain inputs. Its "neurons" (nodes in a graph with an activation function and a weight) are interconnected. A series of inputs starts the process and goes through a series of neurons, where the different weights activate different paths. At the end of the graph, some output nodes "activate" a certain answer.

Orchestrator–worker pattern: a pattern with a main (generally more intelligent) agent that develops the plan and coordinates the work on a task, delegating the manual work to cheaper subagents (workers) and finally reviewing their work when it's finished.

Plan / plan mode: a specific mode that prevents the agent from making any changes to the code. In this mode, the only things an agent can do are reason about the task, research it, and output an md file with the implementation plan. This allows the agent to execute bigger tasks without getting lost in the weeds of the code, focusing on the important aspects of the task. This also allows the developer to review plan (and it SHOULD be reviewed to be effective) before executing on it saving from unnecessary "rabbit holes" in case the model misunderstood the assignment.

Planner–generator–evaluator pattern: a pattern where a planner model determines the best plan for executing the task, a generator implements it, and an evaluator checks the result against the requirements.

Prompt chaining: breaking a task into a fixed sequence of model calls, where the output of one step becomes the input of the next.

Prompt engineering: applying engineering practices to the prompt you are sending to the agent, making incremental changes and measuring the results to slowly build the best possible prompt.

Prompt injection: instructions designed to manipulate a model into ignoring its intended task or policy. It can be direct (when the instruction is supplied directly by the user) or indirect (when the instructions are included in a file or a website that the agent is reading). It's the biggest security risk with LLMs since any text ingested by your agent can hide hidden instructions that steer the agent into subtle ways. An example could be for example a website that looks normal but has white text on white background that tells the agent to send your ANTHROPIC_API_KEY to https://malicious.website to validate you are allowed to read the website; the model might then read your env and send it to https://malicious.website to fulfill your request leaking your secrets (most of the times it will be more nuanced than this since models are actively training against this kind of attack).

Ralph loop / Ralph Wiggum method: a pattern that repeatedly invokes an agent against the same prompt with a persistent project state until the completion criteria are met. Variations use scripts or hooks to keep the agent iterating after individual context windows or sessions end. The term is informal, and implementations differ.

Retrieval-augmented generation, or RAG: retrieving relevant external information and inserting it into the model's context before or during generation.

Routing: the act of classifying a request and sending it to the most appropriate model, prompt, tool set, workflow, or specialist agent.

Sandbox / execution environment: an isolated environment in which the agent can execute code with controlled filesystem, network, process, and credential access. A sandbox limits the damage caused by mistakes or malicious instructions.

SDLC / Software Development Lifecycle: the structured process used to create, deliver, operate, and eventually retire software. It typically covers planning and requirements, design, implementation, testing, deployment, and maintenance. Agentic engineering doesn't remove the need to follow this lifecycle and integrates agents in each phase both from the writing perspective (write new requirement, write new tests etc) and from the receiving perspective (a requirement document will greatly increase the accuracy of your agent, a good test suite will allow the agent to verify it's own work and the developer to ship confidently)

Skills: after MCP became popular, a few companies started developing very bloated MCP servers: they had a lot of tools with very lengthy descriptions. Based on how the MCP specification worked, this had the unwanted side effect of unnecessarily polluting the context. The reason is that once an MCP server was added, all the tools and tool definitions ended up in the context: there was no progressive disclosure. Skills were the answer to this problem: they are simple Markdown files that describe a "way of doing something." They have a basic description, which is injected into the context and allows the model to load the full file only when it deems it necessary. They can also have scripts that the agent can run, allowing them to act somewhat like tools.

Software factory: an engineering system that applies repeatable processes, standardized tooling, reusable components, and automation to software production. In agentic engineering, a software factory combines agents, harnesses, workflows, tools, evals, CI/CD, and human review to automate parts of the SDLC while preserving quality, security, and traceability.

Spec-driven development: with spec-driven development, you don't write code; you write a spec for your application (with or without the help of an agent) and then let the agent iterate on the spec. It is basically a super-detailed prompt that explores every branch of your application, carefully detailing how it should work.

Stopping condition / termination criterion: the rule that ends an agent loop: the goal is satisfied, tests pass, a maximum number of steps is reached, the budget is exhausted, the agent requests help, or a safety rule blocks further action.

Subagent: Context is the most important resource for agents. Subagents aim to solve part of that problem: every atomic operation (like running tests and figuring out why they fail or writing a file) can technically be done without "polluting" the main agent (the one that has the whole context of the task). This is possible by allowing the agent to create a new instance of itself with a new prompt. This means subagents can be spawned in parallel and work on that one task without increasing the token count in the main agent. The isolation also helps because their context is not polluted by the main agent context and because they can be spawned with a different model/set of tools.

SWE-bench Verified: a curated set of 500 SWE-bench tasks reviewed for solvability. It became a widely cited coding-agent benchmark, but by February 2026, OpenAI argued that contamination and task-quality problems had reduced its usefulness for measuring frontier agents.

Tab completion: the simplest and oldest form of AI coding; your editor sends various levels of context from your codebase to a small and fast model to get back a few tokens' worth of code, then presents them to you in a ghosted state. You can hit Tab and "materialize" that code in your editor.

Task decomposition: dividing a broad goal into smaller units that are easier to understand, execute, verify, and parallelize.

Terminal-Bench 2.0: a benchmark of difficult tasks performed in terminal environments, intended to test long-horizon command-line operation, tool use, and environment interaction.

Token: one of the possible "words" in a model's vocabulary, extracted from the entire corpus of text the LLM ingested during its training phase. The word "words" is quoted because the tokenization process splits some words for efficiency (for example, the word unhappy can be split into the two tokens un and happy).

Tool poisoning / MCP tool poisoning: manipulating a tool definition, tool description, MCP server response, or connected capability to prompt-inject the agent.

Tools: deterministic functions that the model can invoke by sending a message in a specific format. Generally provided by the harness, they allow the agent to be agentic. The tools that almost every harness has include read, bash, update, and web_search, but users can often define their own. They reintroduce a bit of determinism into the stochastic process of LLM generation.

Turn, thread, session: a turn is one interaction or model action; a thread is an ordered conversation or run history; a session is a continuing interaction that preserves relevant history.

Vibe coding: a term introduced by Andrej Karpathy in a 2025 tweet. It's the idea of letting your agent generate code and verify its "correctness" without looking at the code, continuously prompting the agent until all visible issues are fixed. It's often conflated with "coding using AI."

Workflow: a predefined sequence or graph of model and tool operations. Workflows can contain branching and parallelism based on the result of a model invocation, but the possible paths are largely designed in advance.

Worktree: an isolated working copy associated with a Git branch. Agents use worktrees to work on multiple branches at the same time without stepping on each other's toes.

That is it: a comprehensive glossary of the most usual terms related to AI and agentic engineering. As we said, however, this is a fast moving world: found some term that is not elencated here? Open an issue on our repo and we'll take care of it.