DEV Community: KahWee Teng

Thread Claims Interoperability. Your Network Has Three Meshes.

KahWee Teng — Wed, 19 Aug 2026 17:45:31 +0000

I was debugging a Home Assistant Thread configuration when I ran dns-sd -B _meshcop._udp . and counted the results. Every ecosystem claims Thread. Matter unifies everything, they say. I have three separate Thread networks on the same physical network.

eero-thread-3d8a is eero's mesh, with three border routers. MyHome503847291 is Apple's, backed by a single Apple TV. AMZN-Thread-9e6b is Amazon's, with three Echo devices. None of them share traffic.

The Command Nobody Runs

Thread border routers broadcast their presence over mDNS under _meshcop._udp. Run the browse and you get every border router regardless of ecosystem:

dns-sd -B _meshcop._udp .

Each result is a border router instance name. To see the full TXT record for one of them:

dns-sd -L "eero_thread #3F2A" _meshcop._udp local

That gives you enough detail to reconstruct your full Thread topology:

nn=eero-thread-3d8a    ← network name
xa=3d8ab4c291e7f052   ← thread extended address
id=3d8ab4c291e7f052   ← device ID

The nn= field is the Thread network name. Every border router sharing the same nn= is on the same mesh. Group by nn= and you have your mesh count.

The xa= field (the Thread Extended Address, equivalent to a MAC at the Thread layer) is where instance names come from. eero_thread #3F2A has xa=...c4a93f2a. The suffixes match. Except for the Thread leader: Thread's election protocol assigns RouterID 0 to the winning node, giving it RLOC16 0x0000. That's why my gateway eero at 192.168.1.1 shows up as eero_thread #0000. Instance names change whenever Thread reassigns router IDs after a reboot or re-election. The hostname and IP are the stable identifiers.

None of this is in any smart home app.

Three Meshes, No Bridge

Thread devices on the same mesh route packets over 802.15.4 radio directly — no Wi-Fi, lower latency, fewer failure points. The assumption behind Thread is that your devices share a mesh.

They probably don't. A device on eero's mesh talking to one on Amazon's routes: Thread → eero border router → Wi-Fi → Amazon border router → Thread. Two extra hops, Wi-Fi back in the critical path, which is exactly what Thread was designed to avoid.

This is structural. Apple, Amazon, and eero each provision Thread credentials at setup time. Thread 1.3 has no mechanism for border routers from different vendors to merge meshes — the Connectivity Standards Alliance lists it as a known limitation. "Matter over Thread" performance depends on which mesh the communicating devices happen to share.

For battery-powered Thread devices it's worse. They're end devices — they sleep, wake, send a packet, sleep again. When they wake they contact their parent router on their own mesh. A sensor on Amazon's mesh is unreachable from an eero automation without going through Wi-Fi both ways, with no timing guarantee. Automations chaining across ecosystems will have gaps. The more ecosystems in the mix, the more gaps.

eero Joins Every Device Without Asking

Scanning _matter._tcp and grouping by hostname reveals the fabric picture:

dns-sd -B _matter._tcp .

For each result, resolve the hostname:

dns-sd -L "E0F4C2918B3A-00000000014B0CDA" _matter._tcp local

Then query the AAAA record to get the IPv6 address — Thread devices show a mesh-local fd prefix rather than an IPv4:

dns-sd -q A3E817F294C06B5D.local AAAA IN

Five of my devices each hold three fabrics:

A3E817F294C06B5D.local  FD8C:3A17:B294:0000:2E4F:91C3:7A08:D365
  Amazon Alexa     ← paired by user
  Apple Home       ← paired by user
  eero             ← auto-commissioned by eero

I never added these to eero. Matter commissioning is supposed to be deliberate — the commissioner initiates, the device responds, they exchange cryptographic credentials. eero does this automatically for every Matter device it can reach via mDNS.

The rationale is border router coordination: holding a fabric on every device lets eero steer which Thread mesh a device prefers. The side effect is that eero holds administrative access to every Matter device on your network regardless of which app you used to pair it.

eero also registers itself as a Matter device in the browse — raw MAC address as hostname, link-local IPv6 only, no IPv4, eero-only fabric. It's not a controllable device. It's eero claiming a seat in the fabric to manage border router priority. You'd never see it from the app.

One Echo on the Wrong Mesh

One Echo Studio showed up on a network called eero-thread-b7c1. An eero-named mesh, but the only border router on it was an Amazon Echo.

Amazon Echos create their Thread mesh on first setup and name it AMZN-Thread-XXXX. This one picked up a stale credential instead, probably a leftover from a previous reset, and had been running as an eero-named mesh with Amazon hardware ever since. Thread devices joining it were routing through Amazon's stack under an eero identity. Neither ecosystem handles that gracefully.

The fix is a factory reset. Fresh credentials, correct name, correct mesh. You'd never catch this from the Alexa app — it shows the device as connected and fine. dns-sd shows the nn= field and the OUI on the border router, and the mismatch is immediate.

Why I Commission via eero First

Given all this, the practical question is which ecosystem to use when first pairing a new device. I now default to eero, for three reasons.

First, eero has three border routers. Apple has one. If the Apple TV reboots, every device on its Thread mesh loses its border router. eero's mesh survives losing any single node.

Second, eero joins everything anyway. There's no configuration that prevents eero from auto-commissioning a Matter device onto its fabric. Fighting it is not possible. Accepting it means the question is just whether eero is the first fabric or the third.

Third, all five of my Thread-capable Matter devices carry IPv6 addresses in the FD8C:3A17:B294 range — eero's Thread mesh-local /48 prefix. That prefix is fixed for the life of the Thread network. Whatever fabric Apple or Amazon holds on those devices, eero's mesh is the one routing their packets. Pairing via eero first means the fabric that controls the device matches the mesh that moves its traffic. That alignment is the closest you can get to a clean setup under the current fragmentation.

The apps show which ecosystems have keys to a device. The network shows which mesh is doing the actual work. For most setups, those are different answers. Knowing which one is which changes how you approach commissioning.

Go deeper

The original article with its interactive Thread network model

Tripsy Now Has a CLI (and an MCP)

KahWee Teng — Wed, 19 Aug 2026 17:44:34 +0000

Everything I wrote in Reading and Writing Tripsy's SQLite Database on macOS is now unnecessary.

Tripsy released an official CLI and an MCP server. Install the CLI in one line:

curl -fsSL https://tripsy.app/install_cli | bash

The installer drops two binaries: tripsy for the CLI and tripsy-mcp for running the MCP server standalone. Log in once and credentials go into the OS keychain:

tripsy auth login --username you@example.com

What the old approach cost

The SQLite method required quitting Tripsy before every write, backing up the database directory, managing WAL checkpoints, generating unique identifiers that avoided CloudKit tombstones, re-querying Z_PRIMARYKEY every session because it jumps during sync, and then opening each inserted row through the Tripsy UI to push it to CloudKit. Updates to existing rows were silently reverted. One wrong identifier and the row vanished on the second app open with no error.

That's a lot of ceremony to fix a check-in date.

The CLI is the right tool

Fixing a hosting date, adding a missing transportation, backfilling a confirmation number — these are two-line commands:

tripsy hostings update --trip 1094984 <id> --set starts_at='2026-06-07T22:00:00Z'
tripsy transportations create --trip 1094984 --name 'Drive SF → Fresno' --transportation-type roadtrip

Commands map directly to the API: tripsy trips, tripsy activities, tripsy transportations, tripsy hostings, tripsy expenses, tripsy documents. Output is human-readable by default, JSON when piped or passed --json. Every response includes a breadcrumbs field suggesting follow-up commands.

A few things worth knowing:

--help on every subcommand. tripsy activities --help shows syntax, examples, and common gotchas. Run it before guessing flag names.

tripsy request for everything else. Named commands cover the common cases. Raw API calls go through tripsy request for anything not yet wrapped.

tripsy doctor. Checks auth and connectivity. Start here if something misbehaves.

I prefer the CLI over the MCP for most things. The MCP hands control to an AI that interprets your intent — useful for open-ended planning, but less predictable for precise edits. The CLI does exactly what you tell it.

Surprises

Two things I didn't expect.

Every response includes a breadcrumbs field that suggests what to run next. After listing activities, the output tells you the exact command to show or create one. After creating a transportation, it gives you the show command with the new ID pre-filled. Most CLIs make you look this up. This one just tells you. It's a small thing that makes the tool feel designed for exploration rather than assumed expertise.

--set silently truncates values at the first space. Set an address with --set address='43011 N Fork Drive, Three Rivers, CA' and the stored value is 43011. No error, no warning — just wrong data. The workaround is tripsy request PATCH with a --data JSON body, but that path had its own issues with endpoint discovery. For a tool that otherwise has good ergonomics, this is a jarring gap. Worth filing.

The MCP for planning conversations

The MCP is the better fit when you want to reason about a trip rather than edit specific fields. Add https://mcp.tripsy.app in Claude, sign in, authorize — done in under a minute. From there, Claude can read your trips, suggest activities, and adjust itineraries through natural language.

The Tripsy blog post announcing it frames it as iterative conversation rather than database management. That framing is right for planning. It's less right when you need to fix a wrong departure time on a specific flight.

The SQLite post has mostly lost its value

The schema documentation and CoreData timestamp explanation are still accurate — the ZGENERALACTIVITY structure, Z_PK management, and CoreData epoch offset haven't changed. If you're debugging what Tripsy stores locally or building something directly on the raw data, it's still a useful reference.

For anything else, the CLI is the better tool, and the SQLite approach no longer makes sense to reach for. The quit-Tripsy, backup-the-WAL, generate-a-fresh-identifier workflow existed because there was no alternative. Now there is.

The API has been available since May 2026. Use the CLI.

Go deeper

The detailed SQLite workaround this official CLI replaced

Your Linter Needs to Be as Fast as Your AI

KahWee Teng — Wed, 19 Aug 2026 17:44:30 +0000

I switched my own projects from ESLint to Biome because linting had become the slow part of an otherwise fast loop. Claude Code or Codex could hand me a complete patch, then ESLint made me wait to find out whether the patch was usable.

Biome made the save-and-check cycle feel immediate. I gave up a few type-aware rules I was barely reading anyway.

Where ESLint slowed me down

ESLint wasn't designed for a workflow where your AI commits 300 lines in one shot. It's a plugin framework, and every layer adds cost:

A parser (@typescript-eslint/parser, or Babel, or both)
Plugins that extend configs that extend other configs
Optional type-checking via tsconfig.json

That last one is the real killer. Type-aware rules like @typescript-eslint/no-floating-promises require ESLint to resolve your entire TypeScript type graph before running. On a medium-sized project, that's 15–30 seconds per run.

ESLint also runs on Node.js. Not a complaint — that's how it ships to everyone. But interpreted JavaScript is just slower than compiled code for CPU-bound parse work.

The result: most teams quietly disable type-aware rules because CI times balloon. Without them, ESLint catches style issues, not logic bugs. You're running a slow tool for modest returns.

What Biome changes

Biome is a linter and formatter written in Rust, with its own parser, and no dependency on the TypeScript compiler.

	ESLint + Prettier	Biome
Runtime	Node.js (JavaScript)	Native (Rust)
Parser	External or separate	Built-in
Formatter	Prettier parses again	Same AST as linter
Type-checking	Optional, expensive	None (syntax-only)
Config surface	Plugins + extends chains	Single `biome.json`

The double-parse problem alone matters at scale. ESLint parses your files, then Prettier parses them again for formatting. Biome parses once and runs both passes on the same AST.

According to Biome's own benchmarks, formatting runs ~25x faster than Prettier (multithreaded on modern hardware) and linting runs ~15x faster than ESLint on equivalent rule sets. Single-threaded, the numbers drop to around 7x and 4x respectively. Both figures come from Biome's benchmark suite, not independent testing — and the ESLint comparison deliberately excludes type-aware rules because Biome doesn't support them. Run the benchmark on your actual codebase before committing to the numbers.

Everything runs in parallel across files by default.

The setup I use

npm install --save-dev --save-exact @biomejs/biome
npx @biomejs/biome init

init generates a biome.json. A working config for a TypeScript React project:

{
  "$schema": "https://biomejs.dev/schemas/1.9.0/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "double",
      "trailingCommas": "es5"
    }
  }
}

Add to package.json:

"scripts": {
  "lint": "biome lint ./src",
  "format": "biome format --write ./src",
  "check": "biome check --write ./src"
}

biome check runs lint, format, and import sorting in one pass. That's the command you want on save and in CI.

For VS Code, install the Biome extension and set it as the default formatter:

{
  "[javascript]": { "editor.defaultFormatter": "biomejs.biome" },
  "[typescript]": { "editor.defaultFormatter": "biomejs.biome" },
  "[typescriptreact]": { "editor.defaultFormatter": "biomejs.biome" }
}

Disable Prettier if it's installed — they'll conflict on save.

What I gave up

Biome's rule surface is smaller — around 250 rules vs ESLint's 1,000+. No @typescript-eslint/no-misused-promises. No eslint-plugin-react-hooks. No type-aware rules at all, because Biome doesn't run the TypeScript compiler. Custom rules written in JavaScript aren't possible; Biome's rules are compiled Rust, so you're limited to what the project ships.

Migrating also means a large formatting diff on day one. Biome's formatter matches Prettier's output in most cases, but not all. If your repo has clean formatting history, expect one noisy commit.

These are real limitations. Whether they matter depends on how much you rely on niche rules.

The linter has a smaller job now

ESLint's value was always in catching things humans missed — a convention violation, a misused promise, a forgotten dependency in a hook.

With AI generating the first draft, I can hand a lint error back to the agent that wrote the code. That makes quick feedback more useful to me than a large rule catalog that slows the loop down.

That changes what I need from a linter. It has to run on every save, catch obvious errors, and stay out of the way. Biome fits that job better in my projects than a large ESLint plugin stack.

Fast feedback is the feature

I switched from ESLint to Biome on my own projects. The speed difference was immediately obvious in the save-on-format loop. What I gave up: a handful of type-aware rules I was barely reading the output of anyway. What I gained: a linter I actually leave on.

Lint speed is part of the same AI coding loop in Claude Code: what I actually use.

Go deeper

How I think about code review when AI writes the first draft

AI-Generated Code Review: What Reviewers Should Still Block

KahWee Teng — Wed, 19 Aug 2026 17:42:16 +0000

I spend less review time fixing awkward AI code than I did a year ago. A strong current model can often rewrite another model's clumsy abstraction in one pass. What I still cannot outsource is approval: I will not ask a teammate to approve code neither of us can explain.

Those are different problems. Teams keep bundling them together as “code quality,” then spend expensive review time litigating taste.

The current models I use produce much better code than the ones I used when I copied snippets out of ChatGPT. The older output often needed a human to sand down every rough edge. I would spend longer simplifying its first attempt than I saved by generating it.

That has changed in my workflow. A strong current model can read a messy change from an older model, identify an unnecessary abstraction, and rewrite it into something smaller. I expect the cost of correcting yesterday's AI code to keep falling.

That makes some technical debt less permanent than it used to be. We should change the review standard accordingly.

Review rule
Spend human attention in proportion to blast radius and rollback cost, not generated line count.

A prompt turns constraints into architecture

I usually get a working implementation. The trouble starts when the model treats every detail in my prompt as a first-class system concern.

I describe an airport feature and stress its boundaries: who can access it, when it applies, which cases should not qualify, and what must happen at the edges. The model responds by building gates around every condition. It writes a long ladder of if statements, feature flags, eligibility checks, and fallbacks.

Each condition sounds reasonable in isolation. Together, the code resembles a rule engine that nobody requested.

The model struggles to decide whether those conditions belong in a component, a domain rule, or a policy boundary. It also struggles to distinguish a passing requirement from a constraint that deserves a durable abstraction. It gives similar weight to every sentence because the prompt is its whole specification. A human engineer usually gets that distinction from the roadmap, previous arguments, and the cost of changing the code later.

This creates an awkward review. The working diff contains three layers of gating. A reviewer asks why, and the honest answer is often: “Claude did it.” That explains the origin. It never justifies the design.

The cost has moved from writing to approval

Better future models will clean up a meaningful share of the excess. We should ship some of it and move on.

For a reversible feature, spending an hour polishing a model's awkward first draft can cost more than merging a working change and asking a later model to simplify it when the code proves worth keeping. The rewrite is cheap. The business value arrives sooner.

Reviewers still pay a cost now. They need enough legibility to decide whether the change is safe, matches the product intent, or silently widens the system's behavior. A future model cannot retroactively make today's approval informed.

I lower the bar for polish and keep the bar for comprehension. Generated components do not need beauty on their first merge. Reviewers need explainable control flow and tradeoffs.

I would also separate a real maintenance concern from a team preference dressed up as one. Code review has always carried local taste: whether a helper belongs above or below a component, which abstraction feels clean, and how much indirection looks respectable. Those arguments consume real time because everybody has a mental picture of neat code.

In my experience, AI tends to write toward the most common pattern it has seen. That makes the result less tied to one engineer's private style. Stable, discoverable, cheap-to-change code does not need to satisfy the team's aesthetic ideal.

Every blocking review comment should name the cost it avoids: a failure mode, an ownership boundary, a likely future extension, or a path that will make incidents harder to diagnose. “This feels ugly” is not a cost. If a team wants a style, it should encode it in a formatter, a linter, or a short written convention. It should not rediscover the rule in every pull request.

The same shift is why fast validation matters more in AI workflows. AI writes the initial diff quickly, but the team still needs feedback before the context disappears. I made that case while moving to Biome: fast checks keep the review loop from becoming a CI archaeology project.

Line-by-line review is the wrong interface

Line-by-line review does not scale to generated code. It survives because humans used to write every line slowly and reviewers had time to follow.

Spelling, formatting, imports, dead branches, and simple convention violations should never consume reviewer attention. A formatter, linter, or targeted check can catch them more consistently than a tired engineer scanning a large diff. Teams already know this. They still leave too much of it for pull-request discussion.

AI needs a distinct review job. One agent writes the change. Another examines the diff against the ticket, the relevant tests, and the parts of the repository it touches. It should flag expanded permissions, duplicate business rules, missing tests, and behavior that does not match the stated requirement.

An AI reviewer needs an independent prompt, an independent model or context, and deterministic checks beneath it. Human reviewers can then focus on the remaining questions: did we choose the right behavior, is the risk acceptable, and are we changing a boundary that will be hard to undo?

Reversibility should set the bar

Change	Sensible review bar	Block when
Local UI or internal tool	Behavior is tested; rollback is cheap	Control flow is unexplained or scope quietly expands
Business rule or data migration	Intent, edge cases, and ownership are explicit	Rules are duplicated or recovery is uncertain
Authentication, payments, shared infrastructure	Design and failure modes are understood end to end	Permissions, callers, observability, or rollback remain unclear

I would accept an inelegant AI-generated condition tree in code that is easy to replace: a local UI flow, an internal tool, or a feature whose behavior is covered by ordinary tests. The team can ship, observe, and refactor once reality tells us which rules matter.

Payments, authentication, and shared infrastructure require the stricter standard. Those systems accumulate callers, permissions, data, and operational assumptions. The cost of a bad abstraction rises before the next model gets a chance to repair it. “We can ask Opus to clean it up later” cannot serve as a rollback plan.

For low-stakes code, the question is whether the change works and remains cheap to rewrite. For high-stakes code, the old standard holds: understand it, challenge the design, and reject the abstraction if it is not earned.

The review I want is aimed at the decisions that matter, with automated checks handling the mechanical parts. Human attention belongs on the business boundary, not the missing comma.

Go deeper

Read the complete code-review field note on KahWee.com

Vite’s ?url Import Gives You a URL, Not jQuery

KahWee Teng — Wed, 19 Aug 2026 17:41:49 +0000

The confusing part is only four characters long: ?url. Add it to a Vite import and the value changes from executable JavaScript to the address of an asset.

import $ from 'jquery/dist/jquery.slim.js';
import jqueryUrl from 'jquery/dist/jquery.slim.js?url';

typeof $;          // "function"
typeof jqueryUrl;  // "string"

Import	Value in your code	What happens at import time
`jquery.slim.js`	jQuery’s API	JavaScript is loaded as a dependency
`jquery.slim.js?url`	A URL string	The file is treated as an asset

[!TIP]
If the next line calls the imported value, you probably do not want ?url. If the next line passes it to src, addModule(), or another URL-based browser API, you probably do.

The 20-second fix

This fails because jqueryUrl is a string, not the jQuery function:

import jqueryUrl from 'jquery/dist/jquery.slim.js?url';

jqueryUrl('#app').hide();
// TypeError: jqueryUrl is not a function

Remove the suffix when you need to use jQuery in the current module:

import $ from 'jquery/dist/jquery.slim.js';

$('#app').hide();

For jQuery 4, prefer the package’s public slim entry point instead of reaching into dist:

import { $ } from 'jquery/slim';

$('#app').hide();

The jQuery project documents jquery/slim as the supported npm import for the slim build. Older jQuery 3 projects often use the dist/jquery.slim.js path shown above.

What Vite actually does

Vite calls ?url an explicit URL import. It opts a file into the asset pipeline and makes the module’s default export a string.

During development, that string may point to the source file. In a production build, Vite can give the asset a hashed filename or inline it as a data URL, depending on the file and configuration. The stable contract is not the exact path. The stable contract is: you receive a string that the browser can use as a URL.

Importing that URL does not execute the file in the current module. The file can still execute later if you load the URL through a browser API such as a script element or a worklet loader.

When ?url is the right tool

A Paint Worklet is the clean example because addModule() asks for a URL:

import workletUrl from './paint-worklet.js?url';

CSS.paintWorklet.addModule(workletUrl);

The same idea applies when a document needs a classic script URL. For example, you can load the jQuery distribution into an iframe rather than importing jQuery into the parent page:

import jqueryUrl from 'jquery/dist/jquery.slim.js?url';

const script = iframe.contentDocument.createElement('script');
script.src = jqueryUrl;
iframe.contentDocument.head.append(script);

Here the string is exactly what script.src needs. jQuery executes when the iframe loads the script, not when Vite imports the URL.

Do not use bare ?url for a worker graph

If a worker imports other modules, let Vite process the worker and its dependencies. Vite’s recommended worker syntax stays close to the browser standard:

const worker = new Worker(
  new URL('./worker.js', import.meta.url),
  { type: 'module' },
);

Vite also supports ?worker when you want an imported constructor, and ?worker&url when an API specifically needs the URL of a processed worker.

Need	Use	You receive
Call jQuery in this module	`jquery/slim` or `jquery.slim.js`	jQuery’s API
Pass a file to a URL-based API	`?url`	URL string
Read a file’s contents	`?raw`	Source string
Create a processed worker	`new Worker(new URL(...))` or `?worker`	Worker instance or constructor

The rule worth remembering

?url does not mean “import this module from a URL.” It means “import the URL of this file.”

That one distinction explains both the error and the fix.

Sources

Go deeper

Read the original guide and future updates on KahWee.com

Sora Isn't the Problem: It's the Mirror

KahWee Teng — Mon, 20 Oct 2025 04:50:32 +0000

This article was originally published on KahWee's blog. Read more on the original site.

The Real Problem

I finally got access to Sora in TikTok form, and something clicked. This isn't annoying because Sora is bad. It's annoying because it's honest.

The Core Problem: Friction Is Gone

Here's the insight: lying used to have a cost. If you wanted to fabricate video evidence, you had to work. Film it. Edit it. Make it convincing. That work was friction. Friction meant there was a penalty for lying—time, effort, risk of being caught in the production.

Sora removes that penalty entirely.

Now you prompt an AI. You want a fake historical event? Seconds. Celebrity deepfake? Done. False testimony on video? Trivial. The cost of lying just collapsed to zero. It's now easier to fabricate than to capture reality.

This changes everything.

Why This Breaks the System

Social media has always optimized for engagement over truth. But engagement-over-truth only works if truth is expensive enough to be selective. You can't put everything on the feed. You have to choose.

With friction, lying is selective. You lie when it matters, when the payoff justifies the work. The system survives because most content is still just... regular stuff. People sharing their lives. Creators doing legitimate work.

Sora removes that selection. Now lying is free. So the system optimizes: if truth and lies cost the same to produce, and if engagement cares about neither, then the algorithm picks based on one thing: what keeps you scrolling?

The answer isn't truth. It's novelty. Spectacle. Uncanniness. Deepfakes of celebrities doing weird things are more engaging than someone filming their actual day.

Once friction is gone, the system must fill the feed with fabrication. Not because creators are evil. But because the incentives make fabrication cheaper than reality.

What This Looks Like

Echo chambers accelerate. TikTok already concentrates algorithmic curation into bubbles. Sora makes that bubble self-reinforcing: same IP, same memes, same likenesses, generated infinitely. Homogeneity at scale. The machine feeding itself.

Truth becomes optional. Audiences stop sorting by "real vs. fake" and start sorting by "entertaining vs. dull." The Verge reported getting trapped in scroll loops of deepfaked celebrities and fabricated moments—even knowing they were AI. The uncanniness is the feature. Plausibility doesn't require proof anymore.

Persuasion decouples from evidence. Short-form video already rewards punchy narratives over grounded reporting. Sora makes that worse: you can visually assert anything now. Any scene. Any dialogue. Any context. Spectacle beats verification. Virality beats truth.

The Epiphany

Here's what hit me: Sora isn't breaking social media. It's just making visible what was always there.

We built platforms optimized for engagement. Then we added algorithms designed to concentrate attention. Then we added infinite scroll and habit-forming UI. Then we added unlimited content generation via AI.

At each step, we told ourselves it was fine. "Engagement metrics are just incentives." "Echo chambers are just efficiency." "Disinformation is a problem we'll solve later."

But watching Sora—watching people trapped in loops of fabricated celebrity cameos—you can't pretend anymore. The problem isn't that AI is too good at generating video. The problem is that friction is gone. When lying costs nothing and engagement doesn't care about truth, the system must fill itself with slop.

That's not a bug. That's the machine working exactly as designed.

What Friction Did For Us

We didn't realize it, but friction was a natural check on this. Video production was slow. Editing took time. Deepfakes required skill. There was a price for lying on camera. Most people paid it in truth instead.

Now there is no price. Lying is as effortless as telling the truth. The system was never equipped to handle that. It was designed assuming some friction. Some cost to fabrication. Some incentive to be selective about deception.

Sora removes that assumption.

The result is what you're seeing: infinite scroll of fabricated content, algorithmically sorted for engagement, presented in a UI designed for habit formation, watched by people who stopped caring if it's real.

That's not a problem with Sora. That's what happens when you remove friction from a system designed to exploit engagement above all else.

The machine didn't break. It just stopped pretending.

Related posts:

AI The New Backdoor Layoff - How companies use AI as cover for not hiring
On Technological Stratification - How AI widens inequality and access gaps
Perplexity replaces Google Search and Apple News for me - How AI is changing information consumption
Google AI Overviews are cutting web traffic in half - The impact of AI on traditional web patterns

Migrating from Remix to React Router v7

KahWee Teng — Mon, 20 Oct 2025 04:50:17 +0000

This article was originally published on KahWee's blog. Read more on the original site.

Why I Switched

Last weekend, I made the decision to migrate one of my full-stack React applications from Remix to React Router v7 framework mode. The migration took about two days and went surprisingly smooth - here's why I made the switch, what the process entailed, and the practical insights that made it successful.

Why React Router v7?

React Router v7 is Remix v3 renamed. Ryan Florence and Michael Jackson merged the projects because "Remix v2 had become such a thin wrapper around React Router that an artificial separation developed between the two projects."

The practical benefits are immediate: instead of juggling @remix-run/node, @remix-run/react, @remix-run/serve, and others, everything consolidates into the unified react-router package. My dependencies dropped from 16 to 3. The new react-router typegen command eliminates manual type annotations in loader functions. The Vite-based build system is cleaner than Remix's custom setup.

The Toughest Part: TypeScript Type System Overhaul

While the API compatibility made most changes straightforward, TypeScript integration was by far the most challenging aspect of the migration. The git log reveals multiple commits dedicated to resolving type issues:

LoaderFunctionArgs and useLoaderData typing: Every route needed manual type updates
Route module type safety: New type patterns required learning React Router v7's approach
Interface mismatches: Database query results needed type alignment with component expectations
Case-sensitivity bugs: Database queries failed due to case-sensitive matching that worked in Remix

Multiple commits were dedicated to resolving TypeScript errors, indicating hours of type debugging across the migration.

This taught me that React Router v7's type system is more strict than Remix v2, which is ultimately beneficial but creates friction during migration.

Migration Overview: What Actually Changed

The migration touched 40 files with 327 insertions and 918 deletions - a net reduction of 591 lines. Here's the breakdown:

Package Dependencies

- "@remix-run/node": "^2.17.0"
- "@remix-run/react": "^2.17.0"
- "@remix-run/serve": "^2.17.0"
- "@remix-run/dev": "^2.17.0"
+ "@react-router/node": "^7.8.2"
+ "@react-router/serve": "^7.8.2"
+ "@react-router/dev": "^7.8.2"
+ "react-router": "^7.8.2"
+ "react-router-dom": "^7.8.2"

Build Scripts

- "build": "remix vite:build"
- "dev": "remix vite:dev"
- "start": "remix-serve ./build/server/index.js"
+ "build": "react-router build"
+ "dev": "react-router dev"
+ "start": "react-router-serve ./build/server/index.js"
+ "typecheck": "react-router typegen && tsc"

Vite Configuration

The Vite config transformation was dramatic:

- import { vitePlugin as remix } from '@remix-run/dev';
- // Complex remix configuration with future flags
- remix({
-   future: {
-     v3_fetcherPersist: true,
-     v3_relativeSplatPath: true,
-     v3_throwAbortReason: true,
-     v3_singleFetch: true,
-     v3_lazyRouteDiscovery: true,
-   }
- })
+ import { reactRouter } from '@react-router/dev/vite';
+ // Simple, clean configuration
+ plugins: [reactRouter(), tsconfigPaths(), tailwindcss()]

Import Updates Across Components

Every route and component needed import updates:

- import type { LoaderFunctionArgs } from '@remix-run/node';
- import { useLoaderData } from '@remix-run/react';
+ import type { LoaderFunctionArgs } from 'react-router';
+ import { useLoaderData } from 'react-router';

The Step-by-Step Migration Process

Phase 1: Dependencies and Configuration (30 minutes)

Package.json overhaul: Replaced all @remix-run/* packages with React Router equivalents
Script updates: Changed build/dev commands to use react-router CLI
Vite configuration: Simplified from complex Remix config to minimal React Router setup
New config file: Added react-router.config.ts for framework-specific settings

Phase 2: Import Refactoring (90 minutes)

This was the most time-consuming phase. Every file importing from @remix-run/* needed updates:

Route files (23 files): Updated loader/action imports and useLoaderData calls
Component files (8 files): Changed Link and Form imports
Entry files (2 files): Updated server/client entry points
Utility files (7 files): Modified auth and theme utilities

The process was methodical: start with entry points, then routes, then components, fixing TypeScript errors as they appeared.

Phase 3: Configuration Fine-tuning (30 minutes)

TypeScript config: Updated to use React Router types
Route file naming: Converted splat routes from api.auth.$.ts to api.auth.$rest.tsx for clarity
Development scripts: Added the new react-router typegen command

Understanding React Router Typegen: The Game Changer

One feature that took me time to fully appreciate was react-router typegen. This wasn't available in Remix - it's a React Router v7 innovation that represents a significant leap in TypeScript integration.

What React Router Typegen Does

The typegen command generates route-specific TypeScript types automatically:

react-router typegen
# Generates types in .react-router/types/ directory

It creates a +types/<route-file>.d.ts for each route, providing:

Automatic type inference for loader data without manual interfaces
Route-specific parameter typing (URL params, search params)
Action and loader return type validation
Component prop type safety based on your actual route implementation

The Rationale Behind Typegen

React Router's type generation executes your route config (app/routes.ts) to determine routes, then generates corresponding TypeScript definitions. This build-time analysis provides runtime safety without polluting the API design.

Instead of manually defining LoaderData interfaces for every route, typegen infers them from your actual loader implementations. This eliminates the common Remix pattern of:

// Old Remix pattern - manual interface definition
interface LoaderData {
  recipes: Recipe[];
  user: User | null;
}

export async function loader(): Promise<LoaderData> {
  // ...
}

With React Router v7, you simply write:

// New React Router v7 pattern - types inferred automatically
export async function loader({ request }: LoaderFunctionArgs) {
  // Return whatever you want, typegen handles the interface
  return { recipes: await getRecipes(), user: await getUser(request) };
}

// Component gets proper typing automatically
export default function RecipeList() {
  const { recipes, user } = useLoaderData<typeof loader>();
  // recipes and user are fully typed without manual interfaces
}

The type inference approach fixes the interface drift problem that plagued my Remix codebase. With manual interfaces, you change a loader to return additional data but forget to update the interface. TypeScript doesn't complain because the interface still "works" - it just silently ignores the new properties.

useLoaderData<typeof loader> eliminates this entirely. The type reflects your actual loader implementation, not what you think it should return. When you refactor a loader's return structure, every component using that data updates automatically.

Here's where this really helps:

export async function loader({ request }: LoaderFunctionArgs) {
  const user = await getAuthUser(request);

  if (!user) {
    return { recipes: [], user: null, requiresAuth: true };
  }

  const recipes = await getUserRecipes(user.id);
  return { recipes, user, requiresAuth: false, totalCount: recipes.length };
}

export default function RecipePage() {
  const data = useLoaderData<typeof loader>();
  // TypeScript knows data.requiresAuth is boolean
  // data.totalCount only exists when user is present
  // data.user is exactly User | null based on the conditional logic
}

The manual interface approach would require defining a union type or optional properties, then keeping that interface in sync with the loader logic. With type inference, your implementation is the contract.

What Happened to Remix?

Ryan Florence and Michael Jackson handed React Router v7 to an open governance committee while they focus on Remix v3. But Remix v3 isn't an iteration - it's a complete rewrite with no React dependencies. They're building on a fork of Preact for "AI-first development" and "AI driven user interfaces." This leaves React Router v7 as the clear successor for production React applications that want the Remix experience.

Migration Notes

The API compatibility made most changes straightforward - loaders, actions, and components work identically. The migration was primarily changing imports and build configuration.

Some gotchas:

Route files with .ts extensions needed to become .tsx for React Router v7 to recognize them
The entry.server.tsx got much simpler - React Router v7 removed the bot/browser request splitting logic
Bundle size dropped ~30% and build times improved with the unified package structure

AI assistance was critical for batch import updates across 40+ files. What could have been a full day of manual work became two focused sessions.

Worth the Switch?

React Router v7 is actively developed while Remix v2 is in maintenance mode. The simplified dependency tree, better TypeScript integration, and improved build system provide immediate benefits. For teams on Remix v2 with future flags enabled, the migration is straightforward.

Whether coming from Remix or considering alternatives to Next.js, React Router v7 framework mode handles full-stack React applications well.

The migration is complete and running smoothly on React Router v7. The process has proven that React Router v7 framework mode is a worthy successor to Remix, offering the same power with simplified tooling and enhanced type safety.

AI Overviews are cutting web traffic in half

KahWee Teng — Mon, 20 Oct 2025 04:48:38 +0000

This article was originally published on KahWee's blog. Read more on the original site.

The Numbers

New research from the Pew Research Center, as reported by Ars Technica, reveals that Google's AI Overviews are significantly impacting website traffic. According to the study, when AI-generated summaries appear at the top of Google search results, users are almost half as likely to click through to other websites—dropping from a 15% to an 8% click rate.

Even more striking, just 1% of users click on the sources cited within the AI Overviews, with Wikipedia, YouTube, and Reddit being the most frequently referenced. The study found that about 1 in 5 Google searches now display these AI Overviews, especially for longer, question-based queries.

Despite Google's claims that AI features drive engagement and new opportunities for websites, the data suggests users are more likely to end their search after reading an AI-generated summary—potentially leaving them with incomplete or even incorrect information, as generative AI is known to occasionally produce errors.

My experience mirrors this trend

I use Dia, a browser with an LLM model built in, and I love it. I barely use Google anymore. With information synthesized directly, I rarely visit websites either. Getting immediate, contextualized answers without clicking through multiple sites has completely changed how I consume information.

This behavioral shift raises fascinating questions about the future of the web. Are we witnessing the emergence of the "dead internet theory" in practice? When AI systems can synthesize and present information without requiring users to visit original sources, what happens to the web's fundamental click-through economy?