DEV Community: YK

How I drive a cloud coding agent from my phone through the browser

YK — Mon, 27 Jul 2026 16:10:20 +0000

tl;dr: I put Google's Identity-Aware Proxy in front of a Cloud Run service
running a coding agent in a web terminal. Now I open a URL on my phone, sign in
with my Google account, and I'm talking to the agent.

Source: github.com/ykdojo/antigravity-cloud-run

This builds on my containerized dev environments
setup: the agent runs with
--dangerously-skip-permissions inside a container on Cloud Run, reachable
through a web terminal. The missing piece was using it away from my laptop.

This particular setup was done for Antigravity CLI, but it should work for
pretty much any other CLI coding agent.

Two ways to reach a session from a phone, and why I picked IAP

My sessions already join my Tailscale network, so the obvious route was the
Tailscale app on the phone. It works, but there's a catch: tailnet traffic
bypasses Cloud Run's front end entirely, so the autoscaler thinks the service
is idle and reclaims the instance after about 15 minutes, mid-use. The only fix
is pinning the instance with min-instances=1, which costs money around the
clock whether I'm using it or not.

IAP flips that. Identity-Aware Proxy is Google Cloud's managed sign-in gate:
you put it in front of a service, and only the Google accounts you allowlist
get through. You open the service's regular run.app URL, sign in, and you're
at the terminal. The terminal's
WebSocket is a real ingress request, so opening the tab wakes the instance,
keeps it alive while you're connected, and lets it scale back to zero when you
close the tab.

If you want the instance to never die, deploy with min-instances=1 and it
never scales down to zero.

The stack, layer by layer

IAP decides who gets in. Only the Google accounts you allowlisted can access it.
ttyd turns the browser into a terminal. The agent is a TUI and the browser speaks HTTP/WebSocket; ttyd bridges the two.
tmux keeps the session alive when the connection drops, and you can attach to the same session from multiple devices.
agy does the work.

Setting it up

Enabling IAP on the service itself is three commands:

gcloud run services update SERVICE --region REGION --iap

gcloud run services add-iam-policy-binding SERVICE --region REGION \
  --member serviceAccount:service-PROJECT_NUMBER@gcp-sa-iap.iam.gserviceaccount.com \
  --role roles/run.invoker

gcloud beta iap web add-iam-policy-binding --resource-type=cloud-run \
  --service SERVICE --region REGION \
  --member user:YOU@gmail.com --role roles/iap.httpsResourceAccessor

If your project lives in a Google Cloud organization, you may be done. Mine
doesn't, so I needed to take a long detour. In case you need to go through the
same thing, here is what I went through.

The 502 detour: no organization, no automatic OAuth client

After enabling IAP, every request returned a 502 with this body:

Empty Google Account OAuth client ID(s)/secret(s).

The reason: IAP's Google-managed OAuth client only authenticates
users inside your organization. A personal project has no organization, so
there is no client at all, which is why it says "empty". External users need a custom OAuth
client handed to IAP. Four steps, mostly console clicks:

Branding (console, Google Auth Platform → Overview → Get started): app name, support email, audience External, agree to the API user-data policy.

Test users (Audience page): while the consent screen is in Testing, only listed test users can sign in. Add every account you granted the accessor role to. Testing mode also expires sign-ins after about 7 days; publishing the app removes that if the weekly re-sign-in bothers you.
Custom OAuth client (Clients page): type Web application. Add this authorized redirect URI, with your new client's ID substituted in: https://iap.googleapis.com/v1/oauth/clientIds/CLIENT_ID:handleRedirect. Note that Google now shows the secret only at creation time, so grab it then.
Hand the client to IAP, at the project level so every IAP service in the project inherits it:

   # iap_settings.yaml
   access_settings:
     oauth_settings:
       client_id: CLIENT_ID
       client_secret: CLIENT_SECRET

   gcloud iap settings set iap_settings.yaml --project PROJECT

Delete the yaml afterwards. IAP stores the secret as a hash.

The change takes effect in seconds: the 502 is gone, and the service URL
redirects to a Google sign-in instead. On the phone: open
the service URL, pick your Google account, and the terminal loads.

What IAP breaks

One thing stops working: gcloud run services proxy, which is how my
dashboard embeds cloud terminals locally on my laptop. IAP rejects the proxy's tokens, and
on a no-organization project there's no clean way around it.

So it's a per-session choice, and I made it a flag: my deploy script takes
-i to bring a session up with IAP, and the dashboard shows those sessions
as an "open in browser" link instead of an embedded terminal. Default is no
IAP.

Here's a phone session with IAP next to a laptop session without it. The
IAP one opens in a browser tab; the other one connects through the local
proxy and gets embedded in the dashboard:

It's a checkbox when creating a session too, off by default:

Limitations

The basic functionality works: I can open a session from my phone, type a
task, and watch it run. A couple of rough edges I'm hoping to address later.

Scrolling isn't great. It's a terminal in a browser tab, so scrolling back
through output on a touchscreen is fiddlier than it should be.

Font size is the other one. I can't get it to set properly on the phone. It
works in every other browser I tried, so I'm not sure what's different there
yet.

For coding agents, real-time collaboration beats the "wisdom of the crowd"

YK — Sat, 25 Jul 2026 22:43:04 +0000

tl;dr: I ran AI coding agents on 30 Project Euler problems in two ways: five agents working separately, and five agents collaborating in real time. For both, I also computed the majority vote across the five answers at the end. The collaborating agents beat both the separate agents and their majority vote. Average accuracy without the vote went from 72% to 87%.

The setup

I had AI coding agents, specifically Gemini 3.5 Flash running through Antigravity, tackle 30 math and programming problems from Project Euler: all problems published this year except one (983), whose answer I could not verify on the website.

For each problem, five agents ran in five concurrent containers. I ran them in two ways:

Solo: no ability to communicate with each other as they solved the problem.
Collaborative: extra prompts letting them know they can collaborate, and an MCP server that lets any agent broadcast a message to the rest, kind of like sending each other emails.

In both cases I also took the majority vote across the five answers at the end. So in total there are four methods to compare: solo individuals, solo with vote, collaborative individuals, and collaborative with vote.

Each agent had 30 minutes of working time, plus up to 10 extra minutes to wrap up and submit a final answer, so a single run can take up to about 40 minutes.

The results

Individually, solo agents got 108 of 150 runs correct (72%). With real-time collaboration, the same setup got 130 of 150 (87%). The majority vote went from 24 of 30 problems (80%) to 27 of 30 (90%). As you can see, both real-time collaboration and the "wisdom of the crowd", aka majority voting, are effective, but real-time collaboration had a stronger effect on the overall accuracy.

	solo	collaborative
average run time	14m	10m
median worst-of-5 time	31m	11m

The worst-of-5 time is relevant because if you wait for all five answers, that is when you get the final answer through the vote. The average time is relevant in a different way: it is a proxy for measuring the tokens and compute you use. Antigravity unfortunately does not give you exact token counts, but tokens and compute scale with the time it takes to solve a problem.

More collaborative runs end inside the first five minutes (97 vs 77), and fewer of them run past the 30 minute mark (23 vs 38).

On worst-of-5 time, solo sets pile up at the 30 to 40 minute end because many problems left at least one agent running until the cap. Collaborative sets most often finish within the first five minutes because once one agent solves the problem and shares its findings, the rest can finish quickly too, though the harder ones still run long.

Three individual problems are worth calling out:

The rescue. On problem 989, solo agents went 0 for 5, and two of them submitted confident wrong answers. In the collaborative run, one agent shared a verified characterization of the problem's structure at minute 5, two others confirmed intermediate values against an example given in the problem statement, and all five agents converged on the correct answer, unanimously. Collaboration solved a problem that no individual agent solved in any run.
The speedup. On problem 993, solo went 3 of 5 with one agent falling into a subtle extrapolation trap. The collaborative run went 5 of 5, about 4 times faster.
The failure. On problem 1006, nobody solved it in either setup. But in the collaborative run, a correctly verified intermediate value circulated between agents, and two of them submitted it as the final answer.

Disclaimers

These agents are not deterministic. If you try to reproduce the results you might get slightly different numbers, but in principle you should be able to get similar results.

Per Project Euler's rules, no numeric answers are published here or in the repo. Runs were scored against privately held answers that were verified on the site itself.

Open questions

The insights here were drawn from experiments with only 5 agents, so there are still many unknowns.

What about 25 agents, 50, 100? Does it scale to solving harder and harder problems?
With 100 agents, is it better to have one big group chat, or ten separate group chats of ten, with some way to communicate between the groups as well?
Does it work as well with other models?
Does it work with other harnesses?
Is it better to let them collaborate freely as we did here, or assign them specific roles?

A lot of open questions, but I believe this is a decent start.

Prior art

One of the closest things currently in production is xAI's Grok Heavy line: Grok 4 Heavy ran multiple agents in parallel that compare notes like a study group, and the newer versions make a multi-agent setup the default for complex queries.

Appendix

The exact prompts, the Dockerfile, and the full per-run outcome data (correct or not, and time taken, for all 300 runs) are in the appendix.

How I set up containerized dev environments you can spin up in seconds for Antigravity CLI

YK — Sat, 25 Jul 2026 22:42:26 +0000

tl;dr: I set up a way to spin up containerized dev environments for AI agents with limited, controlled access. They only get the credentials and network access they need, so they can keep working without asking for permission, and without compromising security. Local sessions start in seconds, and the same image deploys to Cloud Run when I want it off my laptop.

Source: github.com/ykdojo/antigravity-cloud-run

Avoiding permission fatigue

With Antigravity CLI you have a few options. You can approve each request manually. You can configure it in such a way that certain types of requests are accepted automatically. Or you can run it with --dangerously-skip-permissions and skip approval entirely.

The third option is convenient, but it is risky. Running on your main machine with your credentials, it could do a lot of damage, not just to your local environment but to your accounts: GitHub, email, whatever else you are signed into.

So I decided to put it in a container instead, so I can run it with --dangerously-skip-permissions without approving every single request. It gets a separate GitHub account and only the specific keys it needs. For example, you can give it read-only keys for your accounts if you don't want it to be able to post by itself. That way, its blast radius is limited.

What it gets access to

First, it gets my OAuth token for Antigravity, so that it's able to use my subscription's usage quota. There is no API key option today, only that token file. Until this feature is implemented (related requests), this is what I decided to go with. You log in once inside a container, and every session after that is seeded from that token, locally and in the cloud.

You also give it a list of environment variables, and they get injected into the container automatically every time you spin up a session, locally or in the cloud.

I also built a dashboard to manage sessions, so I can spin one up, stop it, or delete it in a few seconds. That is the nice thing about containers. It is easy to throw one away and start fresh.

Conversation history carries across sessions, as long as you name the session the same way. Locally it lives on my machine through a volume mount.

On Cloud Run it works pretty much the same way. The keys are synced to Secret Manager and wired into the service as environment variables, and conversation history goes to a Cloud Storage bucket, one per session, synced every 60 seconds and again on shutdown. So a session you restart picks up where it left off, same as local.

Cloud sessions are IAM-gated and never public. You reach one by running gcloud run services proxy, which opens a local port on your machine and tunnels it to the container, so you open localhost in your browser and talk to the agent and its shell from there. The dashboard does this for you per session.

Adding it to your Tailscale network

This part is optional, but if you already use Tailscale I recommend it for this.

The reason you need it is that Cloud Run only lets one port per service be reachable from outside, and that port is already taken by the web terminal. So if the agent starts a server inside the session and you want to look at it, there is no way in. Tailscale is the workaround.

Each session joins my private network as its own node, so a server on port 3000 is at http://<session-name>:3000 from my laptop, or from any machine on my tailnet. Because of how the access rules are set up it only works one way: I can reach the container, and the container cannot reach my machines.

When the Tailscale key is present, the session also writes its own address into the agent's AGENTS.md on startup, so the agent knows where it lives and can hand you a working URL instead of localhost.

What is it good for?

People have asked me this, and the assumption behind the question is usually that I want something running 24/7. I don't, not really.

What I do want is somewhere I can let an agent go free, for long running tasks and for tasks I would rather not run on my main machine. Research is one: going through a bunch of YouTube videos, or a bunch of Reddit threads. I don't necessarily want that running from my main machine.

Building a feature on a side project is another one. I don't necessarily want it using my main machine's resources, so it's convenient to run it in a container. For example, I like to have it create a draft PR on its own, take screenshots using Playwright, and attach them to that PR and send it to me so I can approve it and merge it.

15 Antigravity CLI tips

YK — Fri, 17 Jul 2026 20:03:43 +0000

I've been using Antigravity CLI since it was launched, and along the way I've been writing down tips for myself. I figured I'd share them here in case they're useful to others. I originally put them in this repo.

Tip 1: Set up terminal aliases for quick access

To help you launch Antigravity CLI quickly, you can alias agy to just a.

To set this up, add this line to your shell config file (such as ~/.zshrc or ~/.bashrc):

alias a='agy'

I personally like to set up aliases for other tools I use often too, not just Antigravity. For example:

alias gb='github'  # GitHub Desktop
alias co='code'    # VS Code

Tip 2: Set up your custom status line

You can customize the status line at the bottom of Antigravity CLI to show useful info (see the official docs). For example, I built this script that shows the model, current directory, git branch, uncommitted file count, sync status with origin, and a visual progress bar for token usage:

Claude Opus 4.6 (Thinking) | 📁antigravity-cli-tips | 🔀main (scripts/color-preview.sh uncommitted, synced 14m ago) | █▄░░░░░░░░ 15% of 250k tokens

To set this up:

Copy the script to your Antigravity CLI config directory:

   mkdir -p ~/.gemini/antigravity-cli
   curl -o ~/.gemini/antigravity-cli/statusline.sh https://raw.githubusercontent.com/ykdojo/antigravity-cli-tips/main/scripts/context-bar.sh
   chmod +x ~/.gemini/antigravity-cli/statusline.sh

Add the following to your ~/.gemini/antigravity-cli/settings.json:

   {
     "statusLine": {
       "type": "command",
       "command": "~/.gemini/antigravity-cli/statusline.sh"
     }
   }

The script supports 10 color themes (orange, blue, teal, green, lavender, rose, gold, slate, cyan, or gray). Edit the COLOR variable at the top of the script to change it.

It also adapts to narrow terminals by wrapping at natural breakpoints instead of getting cut off:

Claude Opus 4.6 (Thinking) | 📁antigravity-cli-tips
 | 🔀main (scripts/context-bar.sh uncommitted, synced 11m ago)
 | ░░░░░░░░░░ 0% of 250k tokens

Tip 3: Create a folder for your projects

I find it convenient to start Antigravity CLI from a single parent folder that contains my projects. That way, the agent automatically has access to any directory within it.

For example, I use a folder like this:

~/Desktop/antigravity-projects $

With my projects inside it, I can say things like "create a new project here," "clone a new project here," or "look at project A and apply certain features to project B" - all without extra permission prompts.

Tip 4: Set up AGENTS.md

AGENTS.md is a file you place in your project root to give Antigravity CLI persistent instructions. Anything you write in it gets included in every prompt within that directory. It's great for things like coding conventions, project-specific rules, or how you want the agent to behave in general.

If you also use Claude Code, you can symlink CLAUDE.md to point to the same file so both tools share the same instructions:

ln -s AGENTS.md CLAUDE.md

You can also set up a global AGENTS.md at ~/.gemini/AGENTS.md for instructions that apply across all projects.

Tip 5: Talk to Antigravity CLI with your voice

I found that you can communicate much faster with your voice than typing with your hands. Using a voice transcription system on your local machine is really helpful for this.

On my Mac, I've tried a few different options:

superwhisper
MacWhisper
Super Voice Assistant (open source, supports Parakeet v2/v3)

You can get more accuracy by using a hosted service, but I found that a local model is strong enough for this purpose. Even when there are mistakes or typos in the transcription, the AI is smart enough to understand what you're trying to say. Sometimes you need to say certain things extra clearly, but overall local models work well enough.

I think the best way to think about this is like you're trying to communicate with your friend. Of course, you can communicate through texts. But if you want to communicate faster, why wouldn't you get on a quick phone call? You can just send voice messages. It's faster, at least for me.

A common objection is "what if you're in a room with other people?" In that case, I just whisper using earphones - I personally like Apple EarPods (not AirPods). They're affordable, high quality enough, and you just whisper into them quietly. I've done it in front of other people and it works fine. In offices, people talk anyway - instead of talking to coworkers, you're talking quietly to your voice transcription system. This method works so well that it even works on a plane. It's loud enough that other people won't hear you, but if you speak close enough to the mic, your local model can still understand what you're saying.

Tip 6: Master different ways of verifying its output

One way to verify its output if it's code is to have it write tests and make sure the tests look good and don't just hardcode true. That's one way, but you can of course check the code it generates as it goes. You can also use a visual Git client like GitHub Desktop for checking changes quickly. And having it generate a PR is a great way as well - have it create a draft PR, check the content before marking it as ready for review.

In addition, you can set up different ways for the agent to test your code in different formats. For example, if you're building a web app, you can set up Playwright MCP and it'll be able to use the browser to test your app all on its own. To set it up, add this to ~/.gemini/config/mcp_config.json:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "-y",
        "@playwright/mcp"
      ]
    }
  }
}

With this, the agent gets browser automation tools like browser_navigate, browser_click, and browser_take_screenshot, so it can open your app, interact with it, and visually check the result on its own.

Tip 7: Learn to use various CLI tools from the agent

For example, you can create a draft PR through the gh command, and once it's created, you can ask the agent to open it in your browser with the open command so you can review it yourself. If you have a change you want to check quickly or fix manually, you can use the code command to open it in VS Code, or use the github command to open GitHub Desktop and see a visual diff. You can use ffmpeg for quick video editing, or ImageMagick for quick image editing and conversion. There are a lot of things you can do if you're familiar with these CLI tools.

Tip 8: Attach images with Ctrl+V

You can attach an image from your clipboard to your prompt by simply pressing Ctrl+V.

Tip 9: Cmd+A and Ctrl+A are your friends

Sometimes you want to give Antigravity CLI a bunch of text from a webpage or terminal output. You can give it a URL, but another method is to just select all (Cmd+A on Mac, Ctrl+A on Windows/Linux), copy, and paste it directly into the CLI.

Some pages don't lend themselves well to select all by default - but there are tricks to get them into a better state first. For example, with Gmail threads, click Print All to get the print preview (but cancel the actual print). For YouTube videos, click "Show transcript" and then Cmd+A or Ctrl+A.

Tip 10: Manage your to-do list in AGENTS.md

It's convenient to keep a to-do list or project status in your AGENTS.md file. Since the agent reads it with every prompt, you can just ask "what's on the to-do list?" and it'll know exactly where things stand. You can also ask it to update the list as you make progress.

For example, you might have a section like this in your AGENTS.md:

## To-Do

### Done
- [x] Unity 3D URP project scaffold
- [x] Card hand UI with 7 cards at bottom of screen
- [x] Card hover effect (scale + blue outline highlight)
- [x] Card drag with placeholder in hand

### Up Next
- [ ] 3D world view - camera at an angled perspective looking down at a game field/board

Then you can just ask "what do we have for the to-do list" and it'll give you a summary of what's done and what's next.

Tip 11: Pre-allow directories outside your project

By default, Antigravity CLI auto-allows reading and writing files inside your current project directory. But if you ask it to access files in a different directory, it'll prompt you for permission every time.

You can fix this by adding those directories to the allow list in your ~/.gemini/antigravity-cli/settings.json (see the official docs):

{
  "permissions": {
    "allow": [
      "read_file(/Users/yk/Desktop/projects/massive-coop-roguelike)"
    ]
  }
}

Path matching is recursive, so allowing a directory covers all files and folders inside it. If you also want write access, add write_file too - and write_file implies read_file, so you don't need both for the same path.

This also comes up when the agent edits its own config. For example, setting up an MCP server writes to ~/.gemini/config/mcp_config.json, which is outside your workspace, so it triggers a permission prompt. You can pre-allow it the same way:

{
  "permissions": {
    "allow": [
      "write_file(/Users/yk/.gemini/config/mcp_config.json)"
    ]
  }
}

Tip 12: Use realpath to point it at files in a different location

When you want to tell Antigravity CLI about files in a different folder, use realpath to get the full absolute path:

realpath some/relative/path

Then paste that absolute path into your prompt so it knows exactly where to look.

Tip 13: Skip permissions in isolated environments

If you're working in an isolated environment - like a container, a VM, or a dedicated test machine - where you're okay with the agent doing anything without asking, you can launch Antigravity CLI with:

agy --dangerously-skip-permissions

This auto-approves all tool permission requests without prompting.

For convenience, you can even add an alias like in Tip 1:

alias ad='agy --dangerously-skip-permissions'

Tip 14: Continue from a previous conversation

Two ways to pick up where you left off:

agy -c (or --continue) continues the most recent conversation
/resume inside a session opens an interactive picker of your past conversations

Tip 15: Agentify your entire SDLC

It's common to over-rely on agents like Antigravity to generate code, but it's just as important to use them for the other parts of the software development lifecycle: understanding issues, designing solutions, reviewing PRs, and testing.

I made a video about this for the Google Cloud Tech YouTube channel, and there's also a blog post version:

7 advanced Claude Code tips from 17 months of intense use

YK — Wed, 15 Jul 2026 19:30:13 +0000

I've been using Claude Code intensely for about 17 months now, and I've ramped it up significantly over the past few months. So I wanted to share some of the more advanced tips I've learned.

1. Use auto mode

Auto mode lets Claude decide whether a command is safe to run in context, instead of asking you to approve every single one. (You can cycle to it with shift+tab.) I've been using it for the past month or so and it's been working really well so far.

The main thing it fixes is mindless approving. When a command is too long to read carefully, or you're getting tired, you end up approving things without really thinking about them. Auto mode takes that pressure off, so I think it's a good default.

Over the past month or so, using auto mode has allowed me to be a lot more productive while still feeling safe.

2. Use Claude Code from your phone

Remote Control lets you drive Claude Code from your phone, which pairs really well with auto mode - you can kick something off, walk away, and check on it from anywhere.

The way I personally like to use it: whenever I need to do something, I start up a thread and run /remote-control (or /rc for short), and drive that same session from my phone. Because it's the same session, you can go back and forth between your phone and your computer.

On your phone, you can use the transcription feature to talk to it quickly. Even if there are transcription mistakes, Claude is pretty much always able to figure them out.

One of my favorite workflows with this: let the agent do the development and testing, take screenshots, and show them to me through a draft PR. That way I'm able to delegate a lot more, and it's able to achieve a lot more on its own than a traditional AI assistant.

There's also a server mode (claude remote-control --spawn=worktree --capacity=N) that lets you start brand new sessions from your phone, but I prefer the /rc method, and I turn it off when I'm not using it. A potential attacker who gets access to your Claude Code session essentially has access to everything on your computer, so I'd rather be careful. The exception is when I have a completely isolated environment - then it's super convenient to be able to start a Claude Code session from anywhere from your phone.

3. Use Fable 5 as much as you can

I've found that it's just generally a more capable model than Opus 4.6 or 4.8, and it's more friendly and easier to deal with than Opus 4.8. It feels like the best of both worlds: the ease of working with Opus 4.6, but also the intelligence of Opus 4.8.

By no means is it a perfect model, but it is the best model we've seen. So I think it's an advantage to use it as much as possible.

4. Give it a separate machine to control

As an experiment, I decided to give Claude Code full access to one of my spare machines so that it could control it, and I could start new sessions from my phone without worrying about leaked data.

So far, it's been working well. It's able to do anything on my spare laptop through computer use: it can click and drag things, and it can use the browser through Playwright and Claude in Chrome. I give it separate accounts so it doesn't mess things up. And the freedom of just letting it do everything it needs to do with --dangerously-skip-permissions - I've found that to be great. This is another way for me to enable agents to do a lot more on their own.

5. Master the loop: investigate, design, implement, verify

After implementing many features and fixing many bugs with Claude Code, I found a simple loop like this to be pretty effective.

Investigate: ask it questions about the problem and try to understand it as much as you can. Pull related issues, Slack threads, and all the relevant context so you can get the full context of the problem. If it's a bug, create reproducible steps so you can verify your solution later.

Design: discuss potential solutions, trade-offs, and what might be the best way forward. Have a long conversation if necessary, and build prototypes if necessary as well.

Implement: this is kind of a straightforward path once you've done solid investigation and design. But try to keep the code simple - it might create overly complex code, or touch other parts of the codebase or things you haven't asked for. So ask it to keep it concise.

Verify: review the changes by asking it about specific parts of what it's made. You can have it create a draft PR and make sure it looks good. Go back and forth. Have it test everything thoroughly by writing tests, running them, and through Playwright if relevant.

This is a good way to ensure you move quickly, but with quality.

6. Use Claude in Chrome, if you haven't yet

Claude in Chrome has been around for a while, but I've noticed that not a lot of people use it still, so that's why I wanted to mention it here.

You could use Playwright for browser-related tasks. But what makes Claude in Chrome convenient is that it runs in your own browser profile, so you can give it access to logged-in state.

It does its job well most of the time, but it sometimes still makes mistakes. For example, I was trying to search something on Slack, but instead it sent a message publicly. That was a little bit frustrating, but luckily not fatal. So you want to either be super careful about it and watch it closely, or give it separate accounts.

7. Use it to learn faster, not to replace understanding

If it produces complex code that you don't understand, sometimes that's fine for a casual project. But if it's a more serious project and you want to understand what's going on, ask questions about it.

If there's a draft PR you want to review, or maybe someone else's PR, ask it to walk you through the changes so you can understand them well. If you don't understand specific parts, don't be afraid to ask basic questions - you can ask deeper and deeper questions until you understand it fully. You can ask it to simplify things, or to summarize its responses.

Really, work with it as a learning partner.

Originally posted on this repo.

Agentifying your entire software development lifecycle

YK — Mon, 13 Jul 2026 16:17:27 +0000

This is an adapted version of this video on the Google Cloud Tech YouTube channel. The slides are available here.

A common complaint about agentic coding is that people write more features with it, but they end up creating more bugs too. More code tends to naturally lead to more tech debt. Part of the reason we have this problem is that we tend to over-rely on agents to generate code, but not enough for maintaining it, reviewing it, or testing it.

That's the motivation behind this post. It walks through a simplified version of the software development lifecycle (SDLC):

Identify and understand the issue
Design a solution
Implement it
Review and test it

This doesn't cover all of SDLC, but it should be sufficient for this discussion. Let's go through these steps one by one.

Step 1: Identifying and understanding the issue

I have two example issues to cover here.

The first one is simple enough that it doesn't have to be agentified, but it'll be important later. For context: if you go to gitfut.com/yourusername, you get a card with a score for your GitHub contributions and stats like commits and stars earned, similar to a football (soccer) trading card. The nice thing about it is that it's open source. I was looking through it and found an issue, which I copied to my own fork so I could work on it there. The problem this person had was that his last name is "De Ruwe" in two words, but his player card was only showing "Ruwe". It's short enough to just read yourself; we'll come back to it in step 3.

The second example is an issue on Daft, an open source data processing library I've been part of for a while. This one is fairly complex, and there's an attached discussion that's also complex on its own.

I could read it sentence by sentence myself, but a faster way to handle this part of the process is to hand it to a tool like Antigravity:

Can you summarize this issue as well as the attached discussion and tell me what's going on? What's the problem exactly? What's the status?

This speeds up the process of identifying and understanding the issue. It's especially useful when there are a lot of discussions going on and a lot of attached PRs and issues.

Once the agent comes back with a summary, I go back and forth with it to dig into specific parts. For example, if the summary is long:

You gave me a lot of information. It's a lot for me to read, so can you summarize it further? And also give me a summary of this PR that you mentioned, 7184.

This is a process I use a lot: going back and forth with the agent to dig into certain issues or materials. I might also ask it to open certain pages so I can look into them myself.

Step 2: Designing the solution

Back to the GitFut example (I'm not associated with the project in any way, just a fan). When I looked at my own card, I wondered: how good is this score really? What does the number actually mean? It would be convenient to see a distribution of GitHub users and where you rank in relation to them. So I decided to implement this feature and sent a PR. The idea is to add a new distribution tab, so you can see that you're in the top X% of all GitHub users and the top X% of active devs.

This required designing a couple of things. The visual look was relatively trivial compared to the system side: how do you gather this data in a privacy-friendly way? How do you store it? How do you show it?

For that, I had a long conversation with a coding agent, asking questions like: what's a good way to fetch all the data? Can I fetch 20,000 accounts? It turns out I could. In the end, I fetched about 20,000 accounts and stored them in a privacy-friendly, anonymized way in the code itself, so it's efficient. I also looked at how many of those accounts were active in the past year. You can look at the PR itself to see how it was implemented. This bleeds a little into implementation, but it's an example where an agentic process for this part of the SDLC was really helpful.

Step 3: Implementing it

Now let's go back to the name issue from step 1 and implement a fix.

To recap: this person's last name is "De Ruwe" in two words, but the card only showed "Ruwe", because the app assumed the last word of your full name is your last name. The original project ended up fixing this by treating the last two words as the last name instead. But that heuristic isn't always right either. I have a middle name, for example, so if I had my full name on my GitHub account, the card would incorrectly show my middle name as part of my last name.

I would solve it differently: instead of guessing, make the name customizable. The issue reporter actually suggested this approach himself. GitHub only has a single setting for your full name, so let the user change how their name appears on the card, the same way they can already pick a country. The country selector works through a URL parameter: if I pick Canada on my card, the URL gets ?country=CA, and anyone opening that URL sees the card with a Canadian flag. Remove the parameter and the flag is gone. The name can work exactly the same way, which I think is a reasonable approach.

At this point, I've identified the problem and designed a solution, so I can start implementing. I take the URL of the repo I'm working on (in this case my fork, so I don't affect the original project) and prompt something like:

I'm working on this repository. It is a fork, so make sure to stay on this fork. I'm not sure if it's cloned yet. If not, you can clone it. If it's already cloned, pull the latest version and switch to the main or master branch.

I keep all my Antigravity projects in a single projects folder, so it knows where to look for them. Then I describe the issue:

I'm working on this issue. The way I want to work on it is I want it to be like the country selector. If you look at the country selector, you can hover over it on anyone's card, select a country, and that's stored in the URL parameter. Can we do the same thing for the name? For the name within the card, maybe there's an overlay element I can hover over and edit the name to whatever I want, so that it's also stored in the URL parameter.

That's the kind of prompt I would use for this task. One small tip: I didn't remember the command for running the project locally, so I just asked Antigravity:

I've been working on this project, but I forgot how to run it. Was it npm run dev? Remind me, and actually run it for me so I can check it.

It looked at package.json, confirmed the command, and ran it for me.

The end result: there's now an edit option on the card itself, and the custom name is stored in a URL parameter, just like the country. If the person from the issue wants his full last name to show up, he can simply set it. To me, this is the most flexible and comprehensive solution, instead of trying to be smart about which part is the last name exactly. Maybe I just want to use my first name only, or my nickname.

Step 4: Reviewing and testing

For this step, I have the complete version of the PR I was just working on. The title and description were all generated agentically, and there are quite a few changed files.

Suppose someone else on my team created this PR, or I created it and forgot about it a little bit, and I want to review it before sending it out. You could review everything manually, but I've found an interactive way of reviewing to be pretty effective:

I have this PR that I want to review. I see that there are a lot of files that changed. Can you summarize each one for me so I can review them one by one? Keep each summary to one or two sentences so that it's easy to review.

Antigravity fetches the information from GitHub (or wherever you host your code) directly and summarizes each file. Then I go through them one by one. If a summary is good enough and the change makes sense, I mark that file as viewed. If something surprises me, like a sharing utility file that changed for reasons I don't quite understand when I look at it manually, I can say:

I don't quite understand this part. Can you explain this line by line?

Then I copy and paste the relevant parts of the codebase.

There's a question about craft here: how much of the code do you need to understand? How much do you want to understand? To me, this is the answer. You don't necessarily have to understand everything manually, but you have to know there's always an option to dig in with however much depth you need, line by line if necessary. Tools like Antigravity are helpful for speeding up the process. It doesn't mean you lose control of your code. On the contrary, I think you gain more control by being able to dig into any part of the codebase more easily.

Wrapping up

That's the entire (simplified) SDLC, agentified.

If you want more tips like this, check out the rest of this repo, and you can watch the full video version of this post here.