What Google reported
On October 13, Google described an overnight Gemini 4 Argon run on a Python codebase of roughly 200,000 lines. Over 11 hours, Argon proposed six optimizations. Engineers accepted two after review and rejected four. Google says these included a cache that could return stale data, use of a private dependency attribute, gains limited to synthetic tests, and added complexity. Google’s post also says a faster startup-import path did not improve the first request in a new process. This is the company’s reported engineering case, not an independent small-business test.
Google lists API, AI Studio, and Antigravity as access routes. Check the relevant product for current account availability.
Pick one maintenance job with a visible baseline
A small business does not need a 200,000-line system to try this pattern. Choose one internal, nonproduction tool with a recurring annoyance: a slow report generator, an import that repeats work, or a maintenance task that times out on a known sample. Keep the scope to one module or operation. Before asking a coding agent to inspect it, save the current version and write down what the task produces, how long the same fixed input takes, and which tests define acceptable behavior.
The baseline should match how the tool is actually used. If staff run a report after importing a monthly file, measure that path with a representative sample and record the output. A faster synthetic microtest does not show that the staff workflow improved. Keep the sample data non-sensitive and remove any credentials or live service access from the test environment.
Ask for a reviewable maintenance patch
Give the agent a narrow goal and ask it to return proposed changes, the reason for each one, tests, and a repeatable before-and-after measurement. Work on a separate branch or disposable copy. Preserve the tool’s inputs, output format, and existing integration points unless the task specifically calls for a reviewed change to one of them. Ask for small commits or clearly separated patches so the owner can accept one idea and reject another.
Then run the same fixed workload against the original and candidate versions. Check the result content as well as elapsed time: totals, rounding, row counts, filenames, and downstream imports can break even when a benchmark looks better. Run the existing test suite and add a focused test for the behavior the patch changes. If the result depends on warm caches, generated data, or a special environment, record that condition rather than treating it as a normal production gain.
Keep the decision with the maintainer
A useful result is a patch the person responsible for the tool can understand, reproduce, and maintain. Review dependency assumptions, hidden state, error handling, and the complexity added by each proposal. A small improvement may be worth keeping; a larger apparent gain may not be if it relies on private internals or makes the next change harder.
For this first trial, omit production credentials and deployment access. Have the maintainer accept or reject each patch, record why, and merge only through the business’s normal review process. Keep the original version available so a regression can be reversed.
A practical next step
Choose one internal tool and one repeatable maintenance task. Prepare a representative non-sensitive input, record the current output and runtime, and decide which existing tests must keep passing. Then ask for a proposed patch with evidence, review each change, and compare both versions on the same workload. If the candidate does not preserve outputs or the maintainer cannot explain the change, close the trial without merging it.
A short software brief can help map the tool, its interfaces, and the first testable maintenance task before a pilot begins.