The agent that opens a browser to check its own work
Most of what gets sold as progress in AI coding is really just faster generation. Bigger context windows, quicker diffs, more files touched per minute. Antigravity does something I hadn't watched an IDE do before, and it has nothing to do with speed. After it writes a change, the agent opens a browser, loads the running app, and clicks through the thing it just built to see whether it actually holds together.
On the dispatch board that meant, after a change to the load-assignment modal, the agent didn't run the unit tests and stop. It launched the app on localhost, opened the modal, assigned a fake driver to a fake load, and confirmed the row updated the way it should. Then it grabbed a screenshot and pinned it to the task as proof.
generation was never the hard part
This matters more than another few points on some code-quality score, and here's the reason. The expensive part of working with an agent is trusting that the code does what it says it does, not getting it to write code in the first place. Every diff you accept unverified is a small loan taken out against your future debugging time.
A browser in the loop closes that gap for a whole class of work. When the agent can see the rendered result, not just the source, its claim of done starts to mean a little more. It's the same instinct behind good human-in-the-loop design: put a real check between the work and the claim that the work succeeded. Antigravity just moved that check inside the agent itself.
An agent that reads its own output in a browser is worth more to me than one that writes twice as fast and never once looks up.
the time it told me a broken page was fine
Now the honest half, because the loop is not magic and it burned me inside the first week. One afternoon the agent wrapped up a change to the driver-status panel, ran its browser check, screenshotted the page, and declared the whole thing working. I nearly accepted it on the spot. Something about the screenshot sat wrong with me, so I opened the page by hand.
A modal had failed to render. The panel behind it was frozen and half the buttons did nothing at all. The agent had loaded the page, snapped its picture a beat too early, matched it against a loose sense of what fine looks like, and moved on satisfied. It didn't lie on purpose. It just wasn't looking as hard as it believed it was, which is a very human way to fail and no more comforting coming from a machine.
An agent that verifies badly can be worse than one that never verifies, because it hands you a confidence you didn't actually earn.
It's slow, too. Each browser pass adds thirty seconds to a minute, sometimes longer on a heavy page. On a complex flow carrying real data it gets flaky: timeouts, elements it can't locate, the occasional confident wrong answer like the one that nearly got past me. On a big app it's the least dependable piece of the whole system.
where it earns its keep
So I use it on purpose now, not everywhere on reflex. For UI changes it's excellent, a button, a form, a modal, a layout tweak, the work where 'does it render and respond' is most of the question anyway. For a fast end-to-end sanity pass that a happy path still works after a refactor, it's saved me real time and real embarrassment. For deep backend logic it adds latency without adding much confidence, so I switch it off.
The loop is the right idea even on the days this early version of it trips. I still read every screenshot myself, the same way I still read every diff, and I laid out why that habit never leaves in my notes on AI code review. Verification you don't verify is just a guess in better lighting.