Wiring Antigravity 2.0 to Chrome DevTools for agents 1.0: Lighthouse Audits, Extension Debugging, Memory Hunts, and an Operational Plan

Letting the agent run Lighthouse: what to pass, what to keep

Lighthouse itself is old news. The new value is the agent reading the report in the context of your codebase and proposing causes, not just symptoms. Make that easier with two small things.

Hand the agent a threshold table first

{
  "landing": {
    "performance": 0.85,
    "accessibility": 0.95,
    "best-practices": 0.95,
    "seo": 0.95,
    "lcp_ms": 2500,
    "cls": 0.1
  },
  "blog": {
    "performance": 0.75,
    "accessibility": 0.95,
    "lcp_ms": 3500,
    "cls": 0.1
  }
}

Use a tight prompt for the audit itself

Run a Lighthouse audit against {{URL}} with the "{{profile}}" threshold table.
If any axis is below the floor, identify the top 3 likely root causes
based on the actual rendered HTML and the network waterfall, and propose
the smallest change set that brings each axis back above the floor.
Do not propose framework changes.

That last line — "Do not propose framework changes" — is there because agents will reach for "rewrite the rendering layer" if you let them. I started teaching myself HTML in 1997 and both of my grandfathers were carpenters of shrine architecture; the instinct that I picked up early was that you do not swap the foundation in a single move. Whether to swap a framework is a human call. The agent's job is the small change set.

Read LCP twice

LCP from a single audit is misleading. I always run it across two or three emulation profiles and look at the spread. Pin a low-end device in the Antigravity 2.0 job config (I use moto-g-power because it is close to the device tier my apps see) and you get numbers that match production.

A release-week smoke I keep around

Once emulation stopped flaking, this kind of smoke became routine:

# .github/workflows/web-vitals-smoke.yml (excerpt)
- name: Vitals smoke (mobile / Tokyo / Slow 4G)
  run: |
    chrome-devtools-for-agents emulate \
      --device "moto-g-power" \
      --geo "tokyo" \
      --network "slow-4g" \
      --capture vitals.json https://example.com
- name: Hand off to agent for triage
  run: |
    agy run "@vitals.json: triage regressions against thresholds.json; \
             open a GitHub issue per regression with the smallest patch suggestion"

The discipline that matters: the agent opens issues, it does not open PRs. The triage is mechanical; the fix is mine. My grandfathers' shop drew the cut marks before anything touched the wood; the cutting machine never made the call to cut.

Extensions: where I gained the most time

The single piece of 1.0 I am happiest about is direct extension control. The agent can install an unpacked extension, click the toolbar action, reload it, clear its storage — all without me leaving the chat. The AdMob debug extension I keep around for my apps used to need a human in the loop. It does not anymore.

A tight prompt for extension regression

Load the unpacked extension at ./dist/, click the toolbar action,
verify the popup shows the latest "test-ad" entry, then reload the
extension and confirm the badge resets. Capture screenshots before
and after each step.

Forcing screenshots is the trick. Agents love narrating state changes in prose, but most extension bugs are render-timing mismatches, so the artefact that holds the evidence has to be visual. Drop them into the Antigravity 2.0 artifacts panel and /fork becomes useful for comparing hypotheses side by side.

Three small gotchas I keep hitting

When to use auto-connect, and when not to

Auto-connect lets the agent join the browser instance you are already using. It is great when it fits, but it also lets the agent step on your personal session.

I use it for:

• Debugging dashboards that require login (AdMob, App Store Connect, Search Console)
• Reproducing extension behaviour against a real device-flavoured environment
• Inspecting how my own authenticated APIs render in the front-end

I never use it for:

• Baseline Lighthouse runs (personal extensions and cookies bias the score)
• Competitive research (your cookies should never leak)
• Pre-release smoke (I want the CI environment, not my desk)

In Antigravity 2.0 I keep a dedicated Chrome profile labelled chrome-agent-only and add --profile chrome-agent-only to every auto-connect call. That single rule has prevented every "did the agent just click a real button on my live dashboard" moment.

Memory analysis: treat it as a hypothesis machine

The new memory analysis tool is genuinely good, but it works best when you treat it as a way to surface hypotheses, not fixes. I learned this the hard way on the wallpaper apps in the portfolio — memory regressions there were often downstream of AdMob initialisation order, which the heap snapshot only hints at.

The prompt I actually use

Open {{URL}}, perform 50 cycles of {{user_action}}, then run the memory
analysis tool. Compare retained sizes between snapshots N=10 and N=50.
Surface the top 5 detached DOM nodes and their constructors. Do not
attempt a fix; produce a hypothesis report with evidence anchored to
the snapshots.

"Do not attempt a fix" matters. Without it, the agent will charge into the code.

Where it earns its keep

• Detached DOM nodes — high signal. Three for three in my recent uses
• Missing event listener removals — middling signal. Combine with a literal addEventListener search
• Lost WebGL contexts — basically zero signal. Reach for WEBGL_lose_context yourself

Permission tiers on the browser side

Antigravity 2.0 ships three autonomy levels in /permissions. The moment you plug Chrome DevTools for agents in, the surface area of "browser actions" grows fast. I split mine into three axes:

1. Read-only (DOM access, Lighthouse, memory snapshots) → always-proceed
2. Write (form input, extension reload) → request-review
3. Dangerous (auto-connect clicks against authenticated sessions, storage writes) → strict

That mirrors the "read agent / write agent / release agent" tiering I use on my Android release pipeline. Aligning the two saves brain cycles when you carry the same mental model into a different project.

A workable steady-state for a solo operator

Running this stack as one person, the rules I have settled on:

• Read-only browser work is fine to leave automated
• Always keep request-review on writes, even when you trust the agent
• Run Lighthouse in CI, look at the failures only
• Capture image evidence for any extension regression; agents narrate, screenshots persist
• Maintain a separate Chrome profile for auto-connect; never blend with daily browsing
• Treat memory analysis as a hypothesis surface, not a fixer

Since I saw that ring of light over Kichijoji Station in late 2019, the question I keep returning to in art is "when does intuition become certainty?" The same question applies in operations: what should the agent finish, and what must I personally sign off on? Chrome DevTools for agents 1.0 has finally reached the granularity where I can answer that without losing sleep.

If the bundled CLI side is not yet familiar, start with the agy introduction first; the operational plan above lands much more cleanly once you have run the basic loop a few times.