ANTIGRAVITY LABJP
Articles/Editor View
Editor View/2026-04-30Intermediate

Pasting Screenshots into Antigravity to Fix UI Bugs Faster — A Practical Guide to Multimodal Input

Explaining a 2px CSS misalignment in plain English takes longer than pasting one screenshot. Here's the practical workflow I use to fix UI bugs in Antigravity by leaning on its multimodal vision.

antigravity435screenshot3multimodal7ui-debugeditor31gemini16workflow50

Try describing in plain English how a button is misaligned by exactly 2 pixels — it's surprisingly tedious. Last week I was chasing a Tailwind dashboard layout that only broke in production. After spending five minutes typing my way around the issue, I gave up, snapped a browser screenshot, pasted it into Antigravity, and added one line: "the area inside the red circle is misaligned." A working patch came back in thirty seconds.

Antigravity is powered by Gemini, which is genuinely strong at reading images. And yet, in my experience, very few developers paste screenshots into the chat — most still try to describe layouts in words. This guide walks through how to use image input for everyday tasks like UI bug hunting, design reviews, and dialog spec handoffs, with concrete examples of what works and what doesn't.

Why screenshots are so effective for UI work

Position, color, padding, line thickness, and the relationships between visual elements are expensive to express in text. When you write "the bottom menu is overlapping a bit," the model has to reverse-engineer your screen width, which direction the overlap is in, and how many pixels we're talking about. A screenshot collapses all of that ambiguity into a single artifact.

The Gemini-family models embedded in Antigravity recognize text within images, button positions, padding, and alignment with a level of precision that makes "show, don't tell" the right default for visual problems. Layout breakage, low-contrast dark mode text, and clipped controls all transmit dramatically faster as a picture than as a written description of the DOM.

Concretely, screenshots have paid off most for me in:

  • Responsive layouts that only break at a specific viewport
  • Dark mode regressions where text loses contrast
  • Subtle icon spacing or alignment drift
  • Sticky elements colliding with other content during scroll
  • Spotting deltas between a Figma comp and the live implementation

Three ways to get a screenshot into Antigravity

1. Paste directly from the clipboard (fastest)

This is my default. On macOS, ⌘ + Shift + 4 captures a region to disk by default; add Ctrl (⌘ + Ctrl + Shift + 4) and the image goes straight to the clipboard. On Windows, Win + Shift + S does the same via Snipping Tool.

Switch to the Antigravity chat panel and ⌘ + V (or Ctrl + V) inserts the image inline. Image first, then your prompt — that order keeps the rhythm tight.

[image attachment thumbnail]

The notification bell and the user avatar in the top-right of this dashboard
overlap by about 2px. Please fix it via gap or margin.
The component lives at src/components/Header.tsx.

In one shot, you've handed the model the visual symptom, the file to edit, and the kind of fix you want.

2. Drag and drop a file

If you already have screenshots or Figma exports on disk, dragging them onto the chat is just as good. This is especially handy when you want to send several images at once — for instance, a Before/After pair.

After dropping, always label what each image represents. "Left is the design, right is the current implementation" sounds obvious, but writing that one line makes a measurable difference in output quality.

3. Reference an existing image with @

When the image already lives in the repo (say, docs/screenshots/before.png), @ references are the most reproducible option:

Compare @docs/screenshots/before.png with @docs/screenshots/after.png
and propose a CSS patch for Header.tsx that brings the implementation
closer to the After state.

I cover the wider story in Giving Antigravity Precise Context — A Practical Guide to @-References for Sharper AI Outputs; if your team shares image assets through the repo, this pattern is the most repeatable.

Telling the model what to look at

A naked screenshot doesn't always tell the model where to focus. Three habits I've settled on:

1. Annotate the image before pasting

Open the screenshot in Preview, Skitch, or Paint, and circle the area in red (or draw an arrow). With a marker in place, your prompt collapses to "fix the spacing inside the red circle" or "the button under the arrow is clipped."

2. State the viewport context

A one-liner like "viewport 1280px, Chrome 124, dark mode" lets the model decide whether to look at media queries, browser-specific rules, or theme variables first.

3. Ask for a specific output format

"Reply with Tailwind class names" or "Return as a unified diff" keeps the next step (review and apply) frictionless. Reviewing the diff is exactly what the Antigravity Diff View — A Practical Guide to Reviewing AI-Suggested Changes is for.

Failure patterns I learned the hard way

Image input is powerful, but careless use confuses the model rather than helping it.

Failure 1: Image too large, signal too low

A full-page screenshot from header to footer leaves the model guessing what matters. Crop tightly to the broken area, or annotate aggressively to constrain attention.

Failure 2: Asking for multiple bug fixes from one image

"Five issues on this page, please fix them all" is an invitation to conflicting edits. One image, one bug. If you really do have five issues, send five turns.

Failure 3: Skipping the file context

The model can't reverse-engineer your DOM perfectly from a screenshot. Always name the source file ("the card component is src/components/Card.tsx"). Skip this and the model may invent a new file or edit the wrong one.

Failure 4: Pasting sensitive data

Internal admin pages tend to display real emails, names, and revenue numbers. Take a breath between capturing and pasting, and check that nothing confidential is in frame. My personal habit: open the screenshot in Preview first and blur anything sensitive before sending it anywhere.

Worked example: a Tailwind layout fix in four minutes

Here's a real one from last week. I had a Next.js + Tailwind dashboard where the sidebar overlapped main content, but only when the viewport hit exactly 1024px.

I started by typing the issue: "at the md: breakpoint the sidebar is supposed to shrink to 200px but it's overlapping." The model came back with a few reasonable hypotheses (grid template misuse, missing padding, z-index conflicts) — none of which were right.

So I shrank the browser to 1024px, took a screenshot, circled the overlap in red, and wrote:

As shown in the attached image, the sidebar is overlapping the main area.
Viewport 1024px, Chrome, light mode.
Please adjust the Tailwind classes in src/components/Layout.tsx.
The sidebar should be a fixed 200px and the main area should fill the rest.

The reply nailed it on the first try: I had been using flex where I needed grid-cols-[200px_1fr], and flex-shrink was quietly squeezing the sidebar. The diff applied cleanly and shipped to production four minutes after the screenshot landed.

If I had stuck to text, this would have been a multi-turn back-and-forth. The lesson stuck: when something can be shown in seconds, it can also be solved in seconds.

Small habits that compound

A few practices I've folded into my daily flow:

  • Use the browser DevTools responsive panel for captures: from the Network/Inspector tab's three-dot menu, "Capture node screenshot" is great when you want to communicate a viewport-specific issue cleanly
  • Always screenshot error overlays: when the dev server crashes or a runtime error appears, capture both the error overlay and the console. Future-you will thank present-you when explaining the situation to the model. Related: port-collision errors after every agent restart are covered in Why Antigravity Agents Trigger So Many EADDRINUSE Errors — A Practical Fix Guide
  • Send Figma + browser side-by-side: when a designer asks for parity tweaks, combine them into a single image. The model will pick out the differences for you
  • Don't combine image input with Cmd+K inline edit: image attachment lives in the chat panel, not the inline editor. Keep them in separate workflows. If Cmd+K itself is misbehaving, walk through the steps in What to Check When Cmd+K Inline Edit Stops Responding in Antigravity — 7 Recovery Steps

Image input lowers the verbalization tax that AI-assisted development quietly imposes on us. Pick the next small UI quirk you notice today, paste a screenshot into Antigravity, and see how quickly it gets resolved. That single experience tends to permanently change how you reach for the chat panel.

Share

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • Copy-paste ready implementation code
  • New advanced guides published daily
  • $5/mo or $10 for lifetime access
View Membership →

If you found this article helpful, a small tip ($1.50) would mean a lot to us. Your support helps keep this site ad-free and covers server and hosting costs.

Related Articles

Editor View2026-06-15
Supervising Multiple Agents at Once on the Antigravity 2.0 Desktop: Screen Layout and Interruption Design
Now that Antigravity 2.0 has been recast as an agent control tower, here is how I lay out the screen, decide when to interrupt, and surface state when running several agents in parallel.
Editor View2026-05-09
Splitting AI Context Across Multiple Repos with Antigravity Multi-root Workspaces
When you open multiple similar repos in a single Antigravity window, the AI sometimes pulls conventions from the wrong project. Here is how I split AI context per folder using .antigravity/rules, learned from running four near-identical Next.js sites side by side.
Editor View2026-05-03
Gemini CLI vs Antigravity: When to Use Which (2026 Field-Tested Verdict)
After running Gemini CLI and Antigravity in parallel for six months across real solo-dev projects, here's a concrete framework for which tool fits which task — with code examples, cost realities, and decision rules.
📚RECOMMENDED BOOKS
Build a Large Language Model (From Scratch)
Sebastian Raschka
LLM Dev
Prompt Engineering for LLMs
Berryman & Ziegler
Prompting
AI Engineering
Chip Huyen
AI Eng
* Contains affiliate links
See all →