Agentifying your entire software development lifecycle | antigravity-cli-tips

antigravity-cli-tips

Agentifying your entire software development lifecycle

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....