DEV Community: Danni Friedland

Add Runtime Context to Your AI Coding Workflow (Next.js + Frontman)

Danni Friedland — Wed, 04 Mar 2026 11:51:21 +0000

This is a practical walkthrough. We'll take a Next.js app with a layout bug, install Frontman, and fix the bug by clicking the broken element in the browser instead of describing it to an AI that can't see it.

By the end you'll know whether runtime-aware AI coding actually saves time or is just a debugger with extra steps. (Spoiler: it's both.)

Prerequisites

A Next.js 14 or 15 project (or npx create-next-app@latest to create one)
An API key from Claude, OpenAI, or OpenRouter
5 minutes

Step 1: Install Frontman

npx @frontman-ai/nextjs install

That's it for setup. The installer handles your config automatically. Start your dev server:

npm run dev

When you open your app in the browser, you'll see a small Frontman toolbar. Click it and enter your AI key (Claude, OpenAI, or OpenRouter). The key is stored locally in your browser — it's never sent anywhere except directly to your AI provider.

Step 2: The Bug

Let's create a realistic layout bug. Here's a card grid component with a subtle problem:

// src/components/CardGrid.tsx
export function CardGrid({ items }: { items: Item[] }) {
  return (
    <div className="grid grid-cols-3 gap-6 p-8">
      {items.map((item) => (
        <div key={item.id} className="rounded-lg bg-white p-6 shadow-sm">
          <h3 className="text-lg font-semibold">{item.title}</h3>
          {item.featured && (
            <span className="mt-2 inline-block rounded-full bg-blue-100 px-3 py-1 text-sm text-blue-800">
              Featured
            </span>
          )}
          <p className="mt-4 text-gray-600">{item.description}</p>
        </div>
      ))}
    </div>
  );
}

This looks fine in your source code. But when 2 of 6 items are featured, the cards with the badge are taller than the ones without, breaking the grid alignment. The bottom row doesn't align. The gap-6 interacts with the conditional badge in a way that isn't obvious from reading the JSX.

What Cursor/Copilot Would Do

You'd describe the bug: "The cards in CardGrid aren't aligning properly — some are taller than others."

The AI would read the source, see grid-cols-3 gap-6, and probably suggest one of:

Adding h-full to the cards (might work, might cause other issues)
Adding min-h-[200px] (arbitrary, fragile)
Restructuring the component entirely (overkill)

It can't see that the actual problem is the conditional featured badge pushing content down, and that the real fix is just adding flex flex-col to the card and mt-auto to the description paragraph. The AI is guessing because it doesn't see the rendered layout.

Step 3: Fix It With Runtime Context

With Frontman running, open the page in your browser. You can see the misaligned cards.

Click the misaligned card. Frontman highlights it and shows you:

The component: CardGrid at src/components/CardGrid.tsx:5
The element: <div class="rounded-lg bg-white p-6 shadow-sm">
Computed styles: the actual padding, dimensions, and flex/grid properties as the browser computed them
Parent layout: the grid container with its resolved gap, column widths, and row heights
Children: what's actually inside this card (including the conditional badge)

Now describe the fix:

"Make all cards the same height and align the description text at the bottom, regardless of whether the Featured badge is present."

Frontman sends the AI:

Your description
The source code of CardGrid.tsx
The computed layout: actual grid dimensions, card heights, which cards have the badge
The component tree context

The AI generates a targeted edit — adding flex flex-col to the card wrapper and mt-auto to the description paragraph. It knows this is the right fix because it can see the actual height difference between cards with and without the badge.

The edit is applied to your source file. Hot reload shows the result immediately. Cards align.

Step 4: What Just Happened Under the Hood

Here's the flow:

1. You clicked an element in the browser
2. Frontman's client-side code identified the React component
   and resolved it to a source file:line via sourcemaps
3. The click target + component info were sent to the
   Frontman middleware running inside the Next.js dev server
4. The middleware gathered:
   - Source code of the component
   - Computed styles from the browser
   - Component tree (parent/child relationships)
   - Server-side context (routes, module graph)
5. All of this was packaged as MCP tool responses
   and sent to the AI alongside your description
6. The AI generated a source code edit
7. The edit was written to disk
8. Next.js HMR hot-reloaded the change
9. The browser updated — you see the fix immediately

The key insight: the AI didn't guess what the layout looks like. It knew — because Frontman gave it the computed layout data from the browser. The fix was targeted instead of speculative.

Step 5: Beyond CSS — What Else You Can Do

The card grid example is simple. Here are more realistic scenarios where runtime context helps:

Debugging a 404

Your page returns a 404 but the file exists. Instead of manually checking the route table, middleware chain, and rewrites:

"Why is /api/users/me returning 404?"

Frontman gives the AI access to the registered route table and middleware state. The AI can see that a middleware redirect is firing before the route matches, or that the file-based route doesn't resolve to what you expect.

Fixing a Hydration Mismatch

A component renders differently on server and client. Server logs show a hydration warning but you can't tell which component caused it:

Click the component in the browser. Frontman shows the server-rendered HTML vs. the client-rendered DOM, plus the component's source location. The AI can see the mismatch directly.

Understanding an Unfamiliar Codebase

You joined a project and need to understand what renders the dashboard sidebar:

Click the sidebar. Frontman tells you: DashboardLayout > Sidebar at src/layouts/DashboardLayout.tsx:23. You have your answer in 2 seconds instead of grepping through the component tree.

Step 6: Try It Yourself

# Next.js
npx @frontman-ai/nextjs install

# Or Astro
astro add @frontman-ai/astro

# Or Vite (React, Vue, Svelte)
npx @frontman-ai/vite install

Full setup instructions and documentation: frontman.sh

frontman-ai / frontman

The AI agent that lives in your framework/browser

Ship frontend changes from your browser — no code editor needed

Frontman is an open-source AI coding agent that lives in your browser. It hooks into your dev server as middleware and sees the live DOM, component tree, CSS styles, routes, and server logs. Click any element in your running app, describe what you want changed in plain English, and Frontman edits the actual source files with instant hot reload. It supports Next.js, Astro, and Vite (React, Vue, Svelte). Free and open-source — Apache 2.0 (client libraries) / AGPL-3.0 (server). Bring your own API keys (Claude, ChatGPT, or OpenRouter).

Who Is This For?

Frontend developers who want richer context than terminal-based AI tools provide. Frontman reads the rendered page, not just the source files, so it knows what your CSS actually computes to and which component renders which DOM node.

Designers and product managers who want to change copy, adjust…

View on GitHub

When NOT to Use This

Runtime-aware AI coding is not a silver bullet. Don't use it for:

Complex state logic — the visual output doesn't tell you if your reducer logic is correct
Performance optimization — Frontman sees the DOM, not your render cycles or bundle size
As a substitute for understanding your code — if you can't explain the AI's diff to a colleague, don't commit it

The runtime context gap is real, and closing it saves time on a specific class of problems (visual bugs, layout issues, routing confusion, server-side debugging). But it doesn't replace engineering judgment. It just means the AI has to guess less.

Frontman is open source on GitHub. This tutorial uses Next.js, but the workflow is identical for Astro and Vite projects — just swap the package name.

AI Coding Tools That Actually See Your Browser (2026)

Danni Friedland — Wed, 04 Mar 2026 11:22:09 +0000

There's a new category of AI coding tools emerging: ones that connect to your running application instead of just reading source files. The pitch is the same across all of them — give the AI runtime context so it stops guessing about what your app actually looks like and does.

The implementations are very different. Some hook into the dev server. Some proxy the browser. Some expose DevTools via MCP. Some are free, some charge monthly, some are experimental. I've been working in this space and wanted to write an honest comparison, since most "tool roundup" articles are either thinly disguised ads or surface-level feature lists.

Disclosure upfront: I'm involved with Frontman, one of the tools listed. I'll be transparent about where it's stronger and where it's weaker than alternatives.

Why This Category Exists

AI coding tools (Cursor, Copilot, Claude Code, Windsurf) work from source files. They don't see:

The rendered DOM, computed styles, or layout geometry (client side)
The compiled module graph, registered routes, server logs, or middleware state (server side)

For any web application with a runtime, this means the AI is guessing about a significant chunk of the application's behavior. The result is the describe-check-fix loop: the AI makes an edit, you check the browser, it's wrong, you describe it again.

Runtime-aware tools try to close this gap. Here's how each one does it.

The Tools

1. Frontman

Website: frontman.sh
Source: github.com/frontman-ai/frontman (Apache 2.0 / AGPL-3.0)
Stars: ~131
Approach: Framework middleware

Frontman installs as middleware inside your framework's dev server (Next.js, Astro, or Vite). Because it runs inside the framework, it has native access to both client-side context (DOM, component tree, computed styles, click targets) and server-side context (routes, compiled module graph, server logs, framework-specific state). Both are exposed to the AI agent via MCP.

The workflow: open your app in the browser, click any element, describe what you want changed. Frontman maps the element back to the source file and line, gives the AI runtime context, generates the edit, and hot reloads.

Strengths:

Deepest framework integration — sees both client and server runtime
Fully free. No prompt limits, no account required
BYOK — connect Claude, OpenAI, or OpenRouter directly
Open source with permissive client library licensing (Apache 2.0)
Supports 5 frameworks: Next.js, Astro, Vite+React, Vite+Vue, Vite+Svelte

Weaknesses:

Early stage (~150 stars). Rough edges and incomplete documentation
Limited to supported frameworks (no Angular, no Remix yet)
Source mapping breaks on deeply abstracted component libraries
Small community — fewer examples, tutorials

Best for: Developers who want the deepest runtime integration, use a supported framework, prefer open source, and don't want to pay for another subscription.

Disclosure: I'm involved with this project.

2. Stagewise

Website: stagewise.io
Source: github.com/stagewise-io/stagewise (AGPL-3.0)
Stars: ~6,500
Backing: YC S25
Approach: Browser proxy / CLI injection

Stagewise started as a browser toolbar and is pivoting to a full "developer browser" (Electron-based). It runs npx stagewise@latest which starts a CLI proxy on port 3100 and injects a toolbar into your running app.

Two modes:

Standalone: has its own built-in AI agent. Requires OAuth login.
Bridge mode: connects to your IDE agent (Cursor, Copilot, Windsurf). You describe changes in the browser, but execution happens in the IDE.

Strengths:

Most polished option in the category. YC backing shows.
~6,500 stars — active community, more examples and tutorials
Supports React, Next.js, Vue, Angular, plus CSS frameworks (Tailwind, Bootstrap, MUI, ShadCN)
Bridge mode integrates with existing IDE workflow

Weaknesses:

Prompt limits: ~10 free prompts/day, EUR 20/month (+19% VAT in EU) for ~100/day
Requires account and OAuth login before first use
Proxy architecture means limited server-side visibility (it sits between browser and server, not inside the server)
No Svelte or Astro support
Bridge mode requires context-switching between browser and IDE
Pivoting to Electron-based "developer browser" — adds significant overhead and scope creep
No BYOK option — inference goes through their servers
AGPL-3.0 only (no permissive client library option)

Best for: Developers who want the most polished UX, don't mind a subscription, and primarily work with React/Next.js/Vue/Angular.

3. Tidewave

Website: tidewave.ai
Source: github.com/tidewave-ai
Stars: ~1,600 combined
Created by: Jose Valim (creator of Elixir)
Approach: MCP server + custom browser app

Tidewave isn't a coding agent itself — it's an MCP enhancement layer that gives your existing agent (Claude Code, Codex, Cursor) access to runtime state. It's built by Jose Valim via Dashbit, so the deepest integration is with the Elixir/Phoenix ecosystem.

What makes Tidewave unique is its backend depth: database queries, runtime evaluation, stack traces, and live process state. For a Phoenix developer, this is like having the BEAM runtime piped directly into your AI agent. Rails and Django support exists but is thinner.

Strengths:

Deep backend integration — DB queries, runtime eval, stack traces
Built by Jose Valim — technical credibility is unquestionable
Works with your existing agent (Claude Code, Codex) rather than replacing it
Strong Phoenix/Elixir support is unmatched by anything else

Weaknesses:

JS framework support is thin (~28 stars on tidewave_js)
The agent isn't open source
$10/month for the browser app

Best for: Phoenix/Rails/Django developers who want to enhance their existing AI agent with deep backend runtime context.

4. Chrome DevTools MCP (Google)

Source: [Experimental / Google]
Approach: MCP server exposing DevTools state

Google's experimental project that exposes Chrome DevTools state as MCP tools. Your AI agent can query the DOM, read console output, inspect network requests, and access other DevTools data programmatically.

Strengths:

Official Google project — signals the category is real and becoming infrastructure
Works with any web app (framework-agnostic)
Free and open
Integrates with any MCP-capable agent

Weaknesses:

Raw — no agent included, you wire it up yourself
Browser-only — no server-side context (routes, module graph, server logs)
Experimental — limited documentation, may change or be abandoned
Requires manual setup and configuration

Best for: Developers who want to add browser context to an existing agent and are comfortable with DIY integration.

5. Onlook (Honorable Mention — Different Category)

Website: onlook.dev
Source: github.com/onlook-dev/onlook
Stars: ~24,700
Backing: YC-backed
Approach: Figma-like visual editor for React/Next.js

Onlook is "Cursor for Designers" — a visual editor that lets you manipulate React/Next.js components like Figma layers, generating real code. It's a different product category (visual design tool, not runtime-aware coding agent), but it overlaps in the "non-engineers editing code" use case.

Key difference: Onlook uses a sandboxed web container, not your real dev server. This makes it safer for experimentation but means it doesn't see your actual runtime environment — middleware, environment variables, real API responses, etc.

Best for: Designers who want a Figma-like interface for React/Next.js, or teams prototyping UI without setting up a full dev environment.

Comparison Table

Feature	Frontman	Stagewise	Tidewave	Chrome MCP	Onlook
Architecture	Framework middleware	Browser proxy	MCP server	MCP server	Visual editor
Client runtime	Yes	Yes	Yes	Yes	Sandboxed
Server runtime	Yes	Limited	Yes (deep)	No	No
Standalone agent	Yes	Yes	No (enhances existing)	No	Yes
Open source	Yes (Apache 2.0 + AGPL)	Yes (AGPL)	Mixed	Yes	Yes
Free (no limits)	Yes	No (10/day free)	No ($10/mo)	Yes	Yes
BYOK	Yes	No	Yes	Yes	Partial
Next.js	Yes	Yes	Thin	Yes	Yes
Astro	Yes	No	No	Yes	No
Svelte	Yes	No	No	Yes	No
Vue	Yes	Yes	No	Yes	No
React	Yes	Yes	No	Yes	Yes
Angular	No	Yes	No	Yes	No
Phoenix/Rails	No	No	Yes (deep)	No	No
Account required	No	Yes	Yes	No	Yes
Stars	~130	~6,500	~1,600	Experimental	~24,700

Which One Should You Use?

Honest recommendations based on your situation:

If you're a Phoenix/Rails/Django developer: Tidewave is the obvious choice. Jose Valim built it specifically for backend-heavy stacks with deep runtime integration that nothing else matches for those ecosystems.

If you want the most polished experience and don't mind paying: Stagewise. The YC backing shows in the UX quality. If you primarily use React/Next.js/Vue and EUR 20/month doesn't bother you, it's the most mature option.

If you want free + deep framework integration + full control: Frontman. No prompt limits, no account, BYOK, open source. The tradeoff is that it's early-stage with fewer stars and rougher edges. If you're comfortable being an early adopter and filing issues when things break, the runtime integration depth is the deepest available for JS frameworks.

If you want to add browser context to your existing agent: Chrome DevTools MCP. It's bare-bones but framework-agnostic and free.

If you're a designer who wants a visual editor: Onlook. Different category entirely, but the best Figma-like interface for editing React code visually.

If you're building something outside these frameworks: Wait. The category is too young for broad framework coverage. Stick with your current AI tool and check back in 6 months.

The Category Is Real

Six months ago, "AI coding tool that sees your browser" wasn't a category. Now there are at least five projects with different architectures attacking the same problem. Google is building infrastructure for it. The fact that these tools exist across different companies, funding stages, and ecosystems suggests the runtime context gap is a real problem worth solving — not just a marketing angle.

Everything listed here is early. Some of these tools will be dead in a year. Some will be table stakes. The only way to know which is to try them on a real project and see if the workflow improvement justifies the setup cost.

I'm involved with Frontman, so take my perspective accordingly. I tried to be honest about every tool's strengths and weaknesses — if I got something wrong about a competitor, call it out in the comments and I'll correct it.

I Built an AI Coding Agent That Lives in Your Browser

Danni Friedland — Wed, 04 Mar 2026 11:05:40 +0000

The Problem

Every AI coding tool I've used has the same blind spot: it edits source files without ever seeing the running application.

You describe a layout bug. The AI reads your JSX, guesses what the DOM looks like, and generates a fix. You switch to the browser. It's wrong — the AI didn't know about the inherited padding, the conditional render that adds a third child, or the CSS variable that resolves differently at this breakpoint. You switch back, describe it again with more detail, and repeat.

This loop — describe, edit, check, re-describe — is where a surprising amount of AI-assisted development time actually goes. Not on the AI generating code. On you being the bridge between the AI's understanding of the source and the application's actual behavior.

The same thing happens on the server side. Your AI edits a Next.js API route but doesn't know what middleware is active, what the compiled module graph looks like, or what's in the server logs. It's guessing about the runtime from the source alone.

What I Built

Frontman is an open-source AI coding agent that lives inside your browser. Instead of working from source files alone, it hooks into your framework's dev server as middleware and sees both sides of the application:

Client side: the rendered DOM, component tree, computed styles, layout geometry, console output, click targets.

Server side: registered routes, compiled module graph, server logs, middleware state, framework-specific context (Astro island hydration, Next.js server/client component boundaries, Vite's HMR state).

The workflow: open your app in the browser, click any element, describe what you want changed in plain English. Frontman maps the runtime element back to the source file and line number, gives the AI the full runtime context, and applies the edit. Hot reload shows you the result immediately.

It supports Next.js, Astro, and Vite (React, Vue, Svelte). You bring your own AI key — Claude, OpenAI, or OpenRouter. No subscription, no prompt limits, no account required.

frontman-ai / frontman

The AI agent that lives in your framework/browser

Ship frontend changes from your browser — no code editor needed

Who Is This For?

Designers and product managers who want to change copy, adjust…

View on GitHub

How It Works

The key architectural decision: Frontman installs as actual middleware inside your framework's dev server, not as an external proxy or browser extension.

This matters because the dev server already knows everything about both sides of your application. Next.js knows its route table and server/client component boundaries. Vite knows its HMR module graph and compiled output. Astro knows which islands hydrated. By running inside the framework, Frontman gets native access to all of this without reimplementing it.

npx @frontman-ai/nextjs install   # for Next.js
astro add @frontman-ai/astro      # for Astro
npx @frontman-ai/vite install     # for Vite (React/Vue/Svelte)

One import in your framework config, start the dev server, and the agent is available in the browser.

Both client-side and server-side context are exposed via MCP (Model Context Protocol), so the AI agent works with structured runtime data rather than parsing HTML strings or grepping server logs.

Source Mapping

The hardest part isn't getting runtime data — it's mapping it back to source code. "This <div> with these computed styles" needs to become "this component at src/components/Card.tsx:47." Frontman uses a combination of sourcemaps, React/Vue/Svelte fiber/instance metadata, and framework-specific component registries to make this connection. It's not perfect — deeply abstracted component libraries can break the mapping — but for most application code it's reliable.

Tradeoffs (The Honest Part)

What works well:

CSS and layout fixes — the AI can see computed styles, so it knows why something looks wrong, not just that you say it does
Visual debugging — click the broken element instead of describing it
Server-side debugging — the AI sees the actual error in server logs alongside the component that triggered it
Onboarding — "what component renders this section?" is answered instantly
Designer/PM collaboration — non-engineers can click elements and describe changes without opening an IDE

What doesn't work well (yet):

Complex state management changes — the visual output doesn't tell you if the logic is correct
Performance optimization — Frontman sees the DOM and server state, not render cycles or bundle sizes
Large refactors — runtime context helps with surgical edits, not architectural changes
Unsupported frameworks — if you're on Angular, Remix, or SvelteKit (without Vite), there's no middleware adapter yet

Compared to alternatives:

Stagewise has more polish and ~6,500 stars, but uses a proxy architecture (less server-side visibility), requires an account, and limits free usage to ~10 prompts/day (EUR 20/month for more). Frontman is fully free with no prompt limits.
Tidewave has deep backend integration for Phoenix/Rails/Django like ours, but not fully Open Source.
Chrome DevTools MCP is browser-only — no server-side context.

Frontman is early-stage. There are rough edges. The documentation could be better. Some framework-specific features are incomplete. I'm not going to pretend otherwise.

Why Open Source

Frontman is licensed as Apache 2.0 (client libraries) and AGPL-3.0 (server). The client libs are permissively licensed so you can include them in any project without concern. The server is AGPL to keep the core open.

The BYOK model means your code and your AI interactions stay between you and your AI provider. Nothing routes through our servers. There's nothing to route through — there are no servers.

This isn't altruism. Open source is the only credible model for a tool that sits inside your dev server and sees your source code. If I can't read the code that has access to my codebase, I'm not installing it. I assume you feel the same way.

Try It

# Next.js
npx @frontman-ai/nextjs install

# Astro
astro add @frontman-ai/astro

# Vite (React, Vue, or Svelte)
npx @frontman-ai/vite install

Full setup instructions: frontman.sh
Source code: github.com/frontman-ai/frontman

frontman-ai / frontman

The AI agent that lives in your framework/browser

Ship frontend changes from your browser — no code editor needed

Who Is This For?

Designers and product managers who want to change copy, adjust…

View on GitHub

What's Next

More frameworks: Remix, SvelteKit (standalone), Angular are on the list
Performance tools: Expose render timing and bundle analysis to the agent
Test generation: Use runtime state to generate more accurate test cases
Better source mapping: Improve component resolution for deeply abstracted UI libraries

If you run into issues or have ideas, open an issue on GitHub or find me in the comments here. Contributions are welcome — the codebase is TypeScript and the architecture is documented in the repo.

Frontman is at frontman.sh and GitHub. I built it because the describe-check-fix loop was eating my productivity and I couldn't find an open-source tool that solved it properly.

Multi-Select is here: Stop fixing UI one element at a time

Danni Friedland — Fri, 27 Feb 2026 19:06:06 +0000

Multi-Select is here.

Stop fixing your UI one element at a time like it's 2024.

Select multiple elements. Give each one instructions. Hit go. Frontman edits them all in one shot.

That button that's 2px off? The header that says "Untitled"? The card that looks weird on mobile? Select all three, describe what you want, and get back to your coffee while Frontman rewrites the actual source code.

How it works:

Click elements in your running app (hold Shift to multi-select)
Add instructions to each — "make this bold", "fix the padding", "change copy to X"
Frontman generates real code edits for all of them with hot reload

No more context-switching between browser and editor for every tiny fix. Batch your nitpicks. Ship faster.

Why this matters

Most AI coding tools work blind. They can't see your running app, your actual DOM, or how your changes look in the browser. So you're stuck in this endless loop:

Switch to editor
Describe what you want to change
Switch back to browser
See if it worked
Repeat for every. single. fix.

Frontman can actually see your DOM and UI. So instead of describing "the button in the top-right corner of the header component", you just click it. Instead of fixing one thing at a time, you select everything that's bugging you and fix it all at once.

Try it out

Frontman works with Next.js, Astro, and Vite (React, Vue, Svelte). Open source and Apache 2.0 licensed.

Give it a try: frontman.sh

Star it on GitHub: github.com/frontman-ai/frontman ⭐

AI Coding Tools and the Runtime Context Gap

Danni Friedland — Fri, 20 Feb 2026 13:37:43 +0000

Current AI coding tools operate on source files. They read your code, predict what the application does, and generate edits. This works well for pure logic — functions with clear inputs and outputs, refactoring, type-level changes.

It falls apart when the source code isn't the whole story. And for any application with a runtime - a web app running in a browser, a server handling requests, a framework with middleware and compiled output — the source code is never the whole story.

This isn't just a frontend problem. Yes, the browser has computed styles and a rendered DOM that don't exist in your source files. But the server side has its own runtime context that source code alone can't capture: which routes are registered, what the compiled module graph looks like, what's in the server logs, what middleware is active and in what order. An AI editing your Next.js API route doesn't know what the dev server's module resolution actually produced. An AI editing your Astro page doesn't know which islands hydrated and which didn't.

The question is whether connecting AI tools to this runtime state - both client and server — is a meaningful improvement or just a debugger hook with extra steps. Having worked on this problem, I think the honest answer is: it's a debugger hook with extra steps, and it's a meaningful improvement. Those aren't contradictory.

Let's Be Precise About The Gap

When an AI coding tool edits your project, it's working from source text. Here's what it doesn't have, split by where the information actually lives:

Client-side runtime (the browser):

Computed styles. The final CSS applied to an element is the product of specificity, cascade order, media queries, CSS variables, container queries, and inheritance. The AI sees class names. The browser computes actual values.
The rendered DOM. Your JSX is not your DOM. Conditional rendering, portals, fragments, and framework transformations mean the actual tree can look very different from what the source suggests.
Layout geometry. Is there 16px or 24px between the sidebar and content area? The AI can read gap-4 in a Tailwind class but can't see that a parent's padding also contributes to the visual spacing.
Client state. What data is in your stores? What did the last API call return? What error is displayed?

Server-side runtime (the dev server / framework):

Compiled module graph. Frameworks like Next.js, Vite, and Astro transform your source before serving it. The AI sees your source files; the dev server sees the compiled, bundled, tree-shaken output. These can diverge significantly — think barrel file re-exports, auto-generated routes, or framework-injected wrappers.
Registered routes and middleware. File-based routing means the route table is a runtime artifact. Middleware ordering, redirect chains, and rewrite rules exist in the server's state, not in any single source file.
Server logs and errors. A component that renders fine might be throwing warnings server-side, or an API route might be failing silently. The AI editing your code doesn't see stdout.
Framework-specific context. Astro island hydration directives, Next.js server/client component boundaries, Vite's HMR module graph — these are framework runtime concepts that source code only partially describes.

Source code has never been the complete picture of a running application. That's why we have debuggers, inspectors, and profilers. AI tools just make the gap more painful because they iterate faster.

An uncomfortable question worth asking

If your code is so decoupled from its runtime behavior that neither you nor an AI can predict what it does, you might have an architecture problem that no tool will fix. Deeply nested utility classes, conditional rendering spread across five files, CSS overrides cascading through three abstraction layers, middleware chains that no single person understands — an AI with runtime access can patch around this, but it can't solve it. The complexity is in your code, not in the tooling gap.

This doesn't invalidate the tooling argument. Even well-structured codebases have the source-to-runtime gap. But it's worth being honest: runtime-aware AI is most valuable when your code is already reasonable, and least valuable when it's used to paper over a mess you should be simplifying.

What "Runtime-Aware" Actually Means (Technically)

Strip away the marketing and the architecture is straightforward: you give an AI agent access to runtime information from both the browser and the dev server, then let it correlate that information back to source files.

The interesting part is that modern web frameworks already bridge client and server — Next.js, Astro, and Vite all have dev servers that know about your component tree, module graph, and build output. A tool that hooks into the framework middleware gets both sides for free.

Concretely, a runtime-aware tool exposes two categories of context via MCP (Model Context Protocol) or similar:

┌──────────────────────────┐    ┌──────────────────────────┐
│ Client Runtime (Browser) │    │ Server Runtime (Dev Svr)  │
│                          │    │                           │
│  DOM tree                │    │  Route table              │
│  Computed styles         │    │  Compiled module graph    │
│  Component tree          │    │  Server logs / errors     │
│  Console output          │    │  Middleware state          │
│  Client state            │    │  HMR module map           │
│                          │    │                           │
└────────────┬─────────────┘    └─────────────┬─────────────┘
             │                                │
             └──────────┬─────────────────────┘
                        ▼
                 Runtime Bridge (MCP tools)
                        │
                        ▼
              AI Agent + Source file mapping
              (sourcemaps, framework metadata)

The critical piece is the source mapping — connecting "this DOM element at runtime" or "this server route" back to "this component in this file at this line." Different tools achieve this at different depths:

Framework middleware (e.g., Frontman): hooks into the framework's dev server as actual middleware, so it has native access to both the client-side component tree and the server-side module graph, routes, compiled output, and logs. This gives the deepest integration — the agent can see what Vite compiled a module to, which Next.js routes are registered, or which Astro islands hydrated — but limits you to supported frameworks.
Browser proxy (e.g., Stagewise): sits between browser and dev server, injecting a toolbar overlay. Gets client-side context (DOM, clicks, visual state) but has limited server-side visibility since it's not inside the framework.
MCP server (e.g., Chrome DevTools MCP, Tidewave): exposes runtime state as tools that an external agent can call. Chrome DevTools MCP is browser-only. Tidewave goes deep on the server side for Phoenix/Rails/Django but is thin on JS frameworks.

None of this is magic. On the client side, it's the same information you get from React DevTools + Chrome DevTools + sourcemaps. On the server side, it's what you'd get from your framework's debug mode + server logs + the module graph. The value is packaging it so an LLM can consume it programmatically and closing the feedback loop: instead of describe → edit → switch to browser → check → switch to IDE → re-describe, you get click element → describe → hot reload. The underlying models are the same. They just have more context about the running application.

The Tools Building This

A few projects are working on this, with different tradeoffs:

Frontman

Open source (Apache 2.0 / AGPL-3.0). Framework middleware for Next.js, Vite (React/Vue/Svelte), and Astro. The key architectural choice: it installs as actual middleware inside your framework's dev server, not as an external proxy or browser extension. This means it has native access to both sides — client-side tools (component tree, DOM, click targets, performance data) and server-side tools (registered routes, compiled module graph, server logs, framework-specific state like Astro island hydration or Next.js server/client component boundaries). Both are exposed to the agent via MCP. BYOK — you connect your own Claude/OpenAI/OpenRouter keys, no subscription. Early-stage (~129 stars), rough edges. Disclosure: I'm involved with this project.

Stagewise

YC-backed, ~6,500 stars. Started as a browser toolbar, evolving into a developer browser. Two modes: standalone (hosted agent, account required, ~10 free prompts/day, EUR 20/month for more) or bridge mode (connects to Cursor/Copilot, but you interact in the IDE). More polish, less openness.

Tidewave

Built by José Valim (Elixir creator). Not a coding agent itself — an MCP enhancement layer that gives your existing agent (Claude Code, Codex) runtime access. Strongest in full-stack Phoenix/Rails/Django with deep backend integration (DB queries, runtime eval, stack traces). JS support is thin. $10/month for the browser app.

Chrome DevTools MCP

Google's experimental MCP server exposing DevTools state to AI agents. Raw — you wire it up yourself. But it signals that runtime-context-for-AI is becoming infrastructure, not a product niche.

The Maintenance Trap

Here's where most "AI tool" articles stop, and where this one shouldn't.

Runtime-aware AI makes it very easy to iterate on changes. Click, describe, hot reload, done. This is genuinely useful for prototyping, design tweaks, and CSS fixes where you can see the result is correct — and for server-side fixes where the agent can see the error log clear after an edit.

But "it looks right" is not the same as "I understand what changed." If an AI rewrites your Tailwind classes, restructures your component's JSX, or adds inline styles to fix a layout — and you ship it without understanding the diff — you've created maintenance debt. The code works today but is opaque to the next person (including future you) who has to modify it.

This is the "vibe coding" risk, and it applies to all AI-generated code, not just runtime-aware tools. But runtime-aware tools amplify it because the feedback loop is so tight. When you can go from "broken layout" to "looks right" in 30 seconds, the temptation to skip reviewing the actual code changes is real.

The rule should be the same as it's always been: don't commit code you don't understand. Whether a blind AI wrote it, a seeing AI wrote it, or you wrote it while sleep-deprived — if you can't explain the diff to a colleague, it shouldn't be merged.

Runtime-aware tools are better inputs to AI, not substitutes for engineering judgment. They reduce the guess-and-check cycle, which is real waste. They don't reduce the need to understand your own codebase.

Where This Actually Helps (and Where It Doesn't)

Good uses:

CSS/layout fixes where you can visually verify correctness
Prototyping UI changes before committing to an approach
Debugging visual regressions by pointing at the broken element
Debugging server-side issues where the AI can see the actual error in server logs alongside the component that triggered it
Understanding route/middleware behavior — "why is this page returning a 404?" when the answer is buried in framework route resolution
Onboarding to an unfamiliar codebase ("what component renders this?" / "what route serves this page?")

Bad uses:

Complex state management changes (the visual output won't tell you if the logic is right)
Performance optimization (runtime-aware tools see the DOM and server state, not your render cycles or bundle size)
Replacing your understanding of the codebase with "the AI can see it"

Not applicable:

Pure backend services with no web runtime (CLI tools, data pipelines, libraries)
Projects with clean, predictable UIs where the source-to-render gap barely exists

Closing Thoughts

The idea of giving AI tools access to runtime context isn't revolutionary. It's the obvious next step, the same way debuggers were the obvious next step after print statements. The engineering value is real but bounded: you're eliminating a specific feedback loop, not fundamentally changing what AI can do with code.

If you're using AI tools and spending significant time in the describe-check-fix cycle — whether that's checking the browser for visual regressions or tailing server logs for errors — runtime-aware tools are worth evaluating. If your project is simple enough that AI edits usually work on the first try, you probably don't need them.

The category is early. Everything listed here is either beta, experimental, or both. That's fine — try them on a side project, see if the workflow fits, and make your own judgment.

Frontman is open source on GitHub. I'm involved with the project, so take my perspective accordingly. The runtime context gap is real regardless of which tool you use to address it.