AI Coding Tools and the Runtime Context Gap

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.