Chrome DevTools MCP but from the inside — a Vite plugin that lets AI debug your frontend in any browser

崮生 — Thu, 26 Mar 2026 02:50:38 +0000

Chrome DevTools MCP is great, but it doesn't work if you're building browser extensions, embedded Webviews, or any non-standard runtime. Found an open source alternative: vite-plugin-pilot — live demo: https://2234839.github.io/vite-plugin-pilot/

Instead of connecting through Chrome's debugging protocol (the official backdoor), it plants an agent inside your page (the insider approach). So it works anywhere a browser runs — extensions, Webviews, custom clients, even regular frontend development.

The core idea is simple: it lets AI agents eval JS in the browser, so they can check their own frontend code for bugs, interact with the page, and verify that everything looks right.

It's also useful for exploring how to implement things in weird runtime environments. The agent can explore on its own, and these are places where Chrome DevTools MCP and similar tools just don't work.

Some things it can do:

Standalone server mode — npx pilot server, no Vite required. Connect to any website through a Tampermonkey userscript or a console bridge script. Not tied to Vite projects anymore.
Browser-to-Claude Code channel — Alt+Click any element on the page, and it generates a prompt you can send directly back to Claude Code. No more copy-pasting between browser and terminal. (Full disclosure: this feature requires a Claude Code Pro/Max account, haven't tested it myself)
Multi-tab support — agent can switch between tabs, each tracked independently.
Vue/React aware — handles v-model, scheduler quirks, etc.

One thing that's kind of interesting: this whole project was iterated on by AI (glm5-turbo + Claude Code). It started as a single vite-plugin.ts file, and the project itself used its own playground to test and improve itself. Since it was built by an agent using the plugin, it's pretty well tuned for how agents actually use it.

MIT licensed, TypeScript, works with any Vite project.

P.S. Sorry if the English is a bit off — my English isn't great, so this post was translated and polished by AI from my original Chinese notes. If anything reads weird, that's on me (and my AI translator 😅)

Backend API Design with Effect

崮生 — Thu, 24 Apr 2025 03:50:19 +0000

Recently while developing TsFullStack, I deeply integrated Effect into the backend API design.

Why Effect-TS?

Consider this file upload API example - it internally depends on authService (user authentication). If we were to pass auth through parameters, it would become extremely cumbersome in nested call scenarios, especially when new dependencies need to be added later (requiring full-chain modifications).

Traditional solutions like thread-local variables (CLS in Node.js), InversifyJS, or Vue's provide/inject all share one critical limitation: you can't know a program's dependencies until runtime (or after reading the entire codebase).

Effect solves this elegantly through its type system. In this TsFullStack example running our upload API, if I manually comment out the authService provider, TypeScript immediately flags the missing AuthService dependency:

This gives us compile-time knowledge of all dependencies. Why is this revolutionary?

Writing robust systems: Eliminates whole categories of dependency-related bugs
Unit testing: No more guessing what dependencies a component needs - they're explicitly declared in the type system

Forem: 崮生

Chrome DevTools MCP but from the inside — a Vite plugin that lets AI debug your frontend in any browser

Backend API Design with Effect

Why Effect-TS?