Live Previews and Feedback for AI Coding Agents

Published July 22, 2026 · by the AQ team

Reviewing an AI coding agent's work means looking at the running application, not just the diff. As of July 2026 there are three practical ways to get a live preview of an agent's changes: run the dev server inside the agent's checkout and look at it yourself, tunnel that local server to a URL a teammate can open, or push the branch and let a preview deployment platform host it. The other half of the problem is feedback: a comment on a preview is only useful once it reaches the agent as its next instruction, and most stacks still close that loop by hand.

Why the diff is not enough

A diff tells you what changed in the code. It does not tell you whether the modal opens centered, whether the empty state reads sensibly, or whether the layout survives a narrow viewport. Agents are fast at producing plausible-looking frontend code, which makes visual review more important, not less: the failure mode is code that reads fine and renders wrong.

There is also a people problem. The person best placed to judge an agent's UI work is often a designer or product manager who is never going to read a unified diff. If your review process for agent output is "open the pull request," you have excluded the reviewers with the strongest opinions about the result. Agents are starting to check their own work (OpenAI's Codex, for example, can drive an embedded browser, take screenshots of what it built, and attach them to the task and pull request, as of July 2026), but a screenshot from the agent is evidence, not review. Someone still has to click around.

Route 1: run the dev server in the agent's checkout

The baseline is to start the app yourself from wherever the agent worked. If each agent task runs in its own git worktree (the common isolation pattern for parallel agents), each worktree is a full working directory, so each one can host its own dev server. The one operational detail that bites people is ports: two dev servers cannot share port 3000, so give each checkout its own.

# Each agent task in its own worktree, each preview on its own port
cd .worktrees/task-42
npm install
PORT=4001 npm run dev

cd ../task-43
PORT=4002 npm run dev

This is free and immediate, and for a solo developer reviewing their own agents it is usually enough. Its limits are social: the preview lives on your machine, dies when your laptop sleeps, and nobody else can open it. It also means dependency installs and env files per worktree, worth scripting once tasks run in parallel.

Route 2: tunnel the local server to a shareable URL

When someone else needs to look, the quickest path is a tunnel: a small client on your machine connects out to a relay and hands you a public HTTPS URL that forwards to your local port. No firewall changes, no deploy. The mainstream options, as of July 2026:

• Cloudflare quick tunnels. One command (cloudflared tunnel --url http://localhost:4001), no account required, and you get a random URL on trycloudflare.com. Cloudflare caps quick tunnels at 200 in-flight requests and positions them for testing and demos only; named tunnels on a real domain are the production path.
• ngrok. The most established tunnel. The free plan includes one automatically assigned dev domain, up to 3 concurrent endpoints, and monthly caps (1 GB of bandwidth, 20k HTTP requests); custom domain names require a paid plan.
• Tailscale Funnel. If your team already runs a tailnet, Funnel exposes a local service on your tailnet domain to the public internet. It is deliberately double opt-in (a tailnet admin enables it, then the device enables it), limited to ports 443, 8443, and 10000, and bandwidth-limited. For a reviewer who is already inside your tailnet you do not need Funnel at all: plain Tailscale Serve shares the port privately.
• VS Code port forwarding. Built into the editor via Microsoft dev tunnels. Forwarded ports are private by default (the visitor signs in with the same GitHub account), and can be flipped to public. Usage is subject to bandwidth and tunnel limits.

All tunnels share two caveats. The preview still depends on your machine staying awake with the dev server running, and a public tunnel URL is a real door into a dev build: anyone holding the link can reach whatever the app can reach, so treat public tunnels to apps with real data as an incident waiting to happen.

Route 3: preview deployments with built-in comments

For web frontends, preview deployment platforms solve both hosting and feedback at once. Vercel builds every pull request into its own preview URL, and comments are enabled by default on preview deployments on all plans: reviewers comment on the page itself through the Vercel Toolbar, attach screenshots by dragging over a region, and threads can sync to Slack. By default commenting is limited to members of your Vercel team. Netlify's equivalent is Deploy Previews with the Netlify Drawer: reviewers take and annotate screenshots, record videos, and file the feedback as issues that sync to GitHub, GitLab, Jira, Linear and others, with a free Reviewer role for stakeholders, as of July 2026.

This is the most polished review experience available today, and if your app already deploys on one of these platforms it is the obvious answer. The constraints are structural: the app has to build and run on the platform (backends with private dependencies, internal services, and heavyweight monorepos often do not), the agent has to commit and push before anyone can look (so you review after the fact, not while it works), and every review cycle costs a build.

Closing the loop: feedback has to reach the agent

Whichever route produces the preview, the feedback it generates is for the agent, not just the author. Today the loop usually closes by hand: a reviewer leaves a comment on a preview or drops a screenshot in chat, and a human copies it into the agent's prompt with enough context (which page, which element, which viewport) for the agent to act. It works, and screenshots pasted into a CLI agent are genuinely effective because the agent sees exactly what the reviewer saw. But every hop a comment makes before reaching the agent costs time and detail, and platform comment threads are built to end in a human assignee, not an agent's next turn. Users are asking vendors to bridge exactly this gap: there are open requests to sync Vercel preview comments into GitHub pull requests specifically so coding agents can consume them, as of July 2026. The direction of travel is clear: the comment on the preview should become the agent's next prompt, with the screenshot and page context attached.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. In this page's terms, AQ builds route 1 and the feedback loop into the product so you do not assemble them from parts. Every workspace gets its own isolated git worktree with dependencies installed automatically, and each workspace can run a live dev-server preview. Because agents run in persistent tmux sessions on your team's VM rather than on your laptop, the preview does not die when your lid closes, and it works for anything that can run a dev server on your VM, not only apps that build on a hosting platform.

Sharing is built in rather than tunneled by hand: a workspace's preview has shareable links, plus guest links for people outside the workspace. Feedback closes the loop directly: comments are pinned on the preview itself, screenshots are supported, and a pinned comment can be sent to the agent as a prompt, so a designer's "this button is misaligned" becomes the agent's next instruction without a human courier. Reviewers who want to go deeper can open the same workspace in the browser (on macOS, Windows, Linux, or a phone) and watch or steer the live agent session instead of waiting for a push.

Plainly: for a solo developer, a worktree, a port, and an occasional quick tunnel are enough, and this page tells you how. AQ earns its place when previews and the comments on them need to be a team loop: agents working on a shared VM, a preview per workspace, and feedback that lands back in the agent's session. The Free plan is the full product on a VM you bring (you pay only your cloud provider); the Team plan is $100 per user per month (promotional; standard $200, billed monthly) and includes a dedicated always-on VM managed by AQ in its own isolated network, with the rate locked for your first 12 months.