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. 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.

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, the honest answer is: it’s a debugger hook with extra steps, and it’s a meaningful improvement. Those aren’t contradictory.

The Gap Is Real (But Let’s Be Precise)

When an AI coding tool edits your project, it’s working from source text. Here’s what it doesn’t have:

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 looks 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.

Server-side runtime (the dev server):

Compiled module graph. Frameworks like Next.js, Vite, and Astro transform your source before serving it. The AI sees source files; the dev server sees the compiled, bundled, tree-shaken output.
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. 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.

An Uncomfortable Question

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 — an AI with runtime access can patch around this, but it can’t solve it.

This doesn’t invalidate the tooling argument. Even well-structured codebases have the source-to-runtime gap. But 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

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.

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.

┌──────────────────────────┐    ┌──────────────────────────┐
│ 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

The critical piece is the source mapping — connecting “this DOM element at runtime” back to “this component in this file at this line.” Different tools achieve this at different depths: framework middleware (deepest, framework-specific), browser proxy (client-only), or MCP server (varies).

The Tools Building This

A few projects are working on this, each with different tradeoffs. Frontman hooks into the framework as middleware for the deepest integration. Stagewise uses a browser proxy approach with more polish. Tidewave goes deep on backend runtime for Phoenix/Rails/Django. Chrome DevTools MCP exposes browser state to any agent. For a detailed comparison, see our roundup of browser-aware AI tools.

The Maintenance Trap

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.

But “it looks right” is not the same as “I understand what changed.” If an AI rewrites your Tailwind classes, restructures your JSX, or adds inline styles to fix a layout — and you ship it without understanding the diff — you’ve created maintenance debt.

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.

Frontman is open source on GitHub. The runtime context gap is real regardless of which tool you use to address it.