Gemini 4 Argon: the cost of fixing software

Having to roll back an update costs more than the hours of whoever programmed it. If it affected operations, you also have to review what happened with sales or orders while it was running.

That's why a figure in the Gemini 4 Argon announcement caught my attention: Google reports a 30% reduction in changes reverted after being shipped, along with a 35% increase in agent code. These are results from four weeks of internal use, according to the Antigravity announcement.

For those of us who pay for or maintain software, that reduction is worth reviewing. Fixing a delivery consumes time we had already set aside for something else. The test in your company will be how much of that work it manages to save you.

The 35% needs a careful reading

An increase in agent code means that code produced through these assistants grew. It doesn't allow you to conclude that a whole project gets finished 35% faster.

To know the delivery time you also need to count the review and what happens when the change reaches users.

Something similar happens with the 30% reduction in rollbacks. A rollback is going back to a previous version, like removing a newly installed part because the equipment stopped working properly.

Reducing those setbacks is valuable. But that figure also doesn't mean that 30% of all errors disappeared. There are failures that get fixed without rolling back an update.

It's worth keeping that difference in mind when someone presents you with a sales pitch based on the announcement.

What's relevant for a system that's already running

Google describes Argon as a model designed for complex tasks. In its Google Cloud post, it mentions work on existing systems, including an architecture change in Chromium.

For a small business, the interest lies in that kind of work: modifying a system that already has rules and users.

Adding a discount seems simple until it has to coexist with returns, previous promotions, and invoices already issued. That's where you notice how much a tool understands the whole system.

My take is that it's worth testing Argon on a task with those dependencies. The result should be evaluated with your business rules.

A test that actually helps you decide

Let's take a hypothetical example: fixing how your system applies discounts when a customer returns part of a purchase.

Before starting, write down what result you expect. Use test cases with known amounts and include a partial return. Also verify that a sale without a discount still works.

Then record the following:

Compare those results with a similar task from your team. If the change was simpler, note it: an uneven comparison can make any tool look extraordinary.

My takeaways

I find it useful that Google publishes internal usage results. They're a signal to investigate, with clear limits: they correspond to their environment and come from the one offering the model.

To decide for your company, I'd ask for a user-accepted improvement and observe how much work it leaves behind.

Speed starts to have value when you can move on to the next pending item.

Before expanding its use

Argon deserves a limited trial if your team maintains software with processes that are hard to modify.

Start where you can verify the result. If it reduces total time and corrections, you'll have evidence to expand its use. If it generates quick proposals that require a lot of fixing, that cost should also appear in the evaluation.

The work is done when the improvement works for those who depend on it.

References

• Gemini 4 Argon in Google Antigravity
• Gemini 4 Argon available on Google Cloud