The pitch, and the part that makes me uneasy
Search Engine Land reported on August 26, 2026 that the Google Ads API Developer Assistant got a major AI agent upgrade (opens in new tab). That headline is most of what is public right now, which is worth saying out loud before anyone builds a workflow around it.
Where I land: generated code is fine for read-only reporting queries, and I want a human reading every mutate before it runs. Not skimming it. Reading it.
The reason is asymmetry. A badly written SearchStream query wastes quota and a few minutes of your afternoon. A badly written mutate changes budgets, pauses ad groups, or applies a bid adjustment on a live client account, and undoing it means reconstructing state you may not have recorded anywhere. Reads and writes are not two flavours of the same risk. They are different categories.
I have not tested the upgraded assistant. I do not have access to it, and I am not going to pretend I ran benchmarks I did not run. What I do have is years of running the Google Ads API in production for a handful of accounts, plus the general experience of cleaning up after automation that did exactly what it was told. So treat everything here as operational judgment about the API and about generated code in general, not as a review of the tool.
The other thing I would flag early is that “AI agent” covers a wide range of behaviour. An assistant that drafts a GAQL query and hands it to you is a very different product from one that plans a multi-step job and executes each step. The reporting does not make clear how far along that spectrum this sits, and that distinction is the whole ballgame for anyone deciding how much supervision to apply. Until I see documentation that says otherwise, I am assuming it drafts and I am reviewing everything.
What the Developer Assistant was before this
The original assistant was a documentation-shaped helper. It lived next to the reference docs, the GAQL query builder, and the client libraries for Java, Python, PHP, .NET, Ruby, and Perl. You asked it something, it pointed you toward the right resource and field, and you went off and wrote the code yourself.
That existed because the Google Ads API is genuinely hard to hold in your head. GAQL looks like SQL and is not SQL. There are no joins in the way you expect, the FROM clause picks a single resource and quietly determines which fields you are allowed to select, and the segmentation rules will reject combinations that look perfectly sensible. Resource names are opaque strings like customers/1234567890/campaigns/987654321, so a copy-paste error moves your operation to a different campaign rather than throwing a type error. The field reference runs to thousands of entries across dozens of resources.
Then there is the friction that has nothing to do with code. New integrations start with a developer token stuck at test account access, which means your beautifully working script runs fine against a test manager account and returns a permission error the moment you point it at a real one. Getting basic or standard access requires an application and a wait. I have watched people spend a full day debugging code that was correct, because nobody told them the token was the problem.
And the mundane detail almost everyone forgets: the Python and PHP libraries read a google-ads.yaml file that holds your client secret, refresh token, and developer token in plain text. On a lot of setups that file sits in the home directory of whatever user runs the cron job, on a box that also runs other things. Worth checking the permissions on it right now if you have not. chmod 600 is not a security strategy, but it is better than the 644 I keep finding.
What the AI agent upgrade actually changes
The tasks an agent should handle well here are the ones with clear inputs and a checkable output. Turning “show me spend by campaign for the last 30 days” into GAQL is a good fit. Mapping a metric you half-remember to the resource it actually lives on is a good fit. Stubbing out the client library boilerplate, the service client, the request object, the pagination loop, is a good fit, because that code is nearly identical every time and nobody enjoys typing it.
Here is the worked example I would use as a first test. A 30-day spend report is about the smallest useful thing you can ask for:
SELECT campaign.id, campaign.name, metrics.cost_micros
FROM campaign
WHERE segments.date DURING LAST_30_DAYS
ORDER BY metrics.cost_micros DESC
If the generated version matches that, good. Now check whether it told you that cost_micros is in micros and you need to divide by 1,000,000 to get currency. Missing that does not throw an error. It produces a report where every number is a million times too big, and someone downstream will believe it.
The thing I do not expect any model to handle reliably is versioning. The Google Ads API deprecates versions on a published schedule, older versions stop responding, and training data always lags the current release. Generated code that targets a sunset version does not fail with a friendly message telling you to upgrade. It fails at the transport layer, and you get to work out for yourself that the problem is the version string in your endpoint rather than anything in your logic.
My working assumption until something proves otherwise: treat the output as a first draft from a competent junior developer who has read all the documentation and has never seen your account structure. Useful. Fast. Not accountable for what happens next.
Is generated Google Ads API code safe to run?
Short answer: safe for reads, not safe for unreviewed writes. Read operations cost you quota and time. Write operations cost money and can be difficult to reverse cleanly.
The analogy I use with clients is the search-and-replace tool in WordPress. Running it in preview mode costs nothing and tells you exactly what would change. Running it for real against a live database rewrites rows, and unless you took a dump first, putting them back means guessing. Google Ads mutates work the same way, except the rows are budgets.
What should I always check before running generated code? Four things. The API version string. Whether the call is a read or a mutate. The customer ID and the login-customer-id, because those are different values and mixing them up is the most common mistake I see. And whether partial_failure is set the way you think it is, since with it enabled a batch of 50 operations can apply 47 and silently drop 3 into a response object you were not reading.
How do I test a mutate without touching a live account? Send it with validate_only set to true. The API runs full validation and returns errors without applying anything. Nothing is written, and you learn whether your resource names and field masks are correct. If the generated code did not include that flag, add it yourself. This is the single highest-value habit in the entire API and it takes one line.
What breaks most often in practice? Auth and permissions, not logic. AuthenticationError.NOT_ADS_USER and AuthorizationError.USER_PERMISSION_DENIED account for most of the time I have lost to this API, and they almost always mean the wrong login customer ID or a refresh token minted under a Google account that does not have access to the target account. No amount of code generation fixes an OAuth token issued to the wrong identity.
Does it help with quota? Not in any way I can see. Requests and operations are metered against your access level, and an agent that retries aggressively when something fails will burn through a daily allowance faster than a person writing the same job by hand, because a person gets discouraged and goes to read the docs. Put your own rate limiting and exponential backoff around anything it produces, and log the operation count.
What I expect next
This is my expectation, not anything Google has said. Read it as such.
An agentic API assistant fits the direction Google has been pushing all year rather than breaking from it. The same week this landed, Search Engine Land also covered new AI Max testing and planning tools, reporting for AI-generated product titles, and the unification of the Google tag with Tag Manager. The pattern is consistent: more of the work moves inside Google’s tooling, and the interface becomes a description of intent rather than a configuration you assemble.
The capability I would actually watch for is authenticated access to your own account structure. Generic snippet generation is a documentation search with better manners. An assistant that can see that your MCC has 40 child accounts, that three of them use portfolio bidding strategies, and that your naming convention encodes the client code in the campaign name, is a different product with a different value. It is also a much larger permissions decision, and I would want to know exactly what it reads before I granted it.
The risk that grows with adoption is correlated breakage. If a lot of agencies ship agent-written scripts that all target the same API version, because that is the version the model reaches for, then a routine deprecation stops being a routine deprecation. It becomes a lot of scripts failing in the same week. That has always been possible with copy-pasted Stack Overflow answers, but generated code raises the volume.
I genuinely do not know how this holds up for anyone managing hundreds of accounts under one manager account. Scale changes the quota arithmetic and it changes the review burden, and “read every mutate before it runs” is advice that works at 5 accounts and may be unworkable at 500. If you are operating at that size, I would be interested in what you find, because I am reasoning from a smaller footprint than yours.
Start here this week
Take one read-only job you already understand well, ideally one where you know the correct answer, and have the assistant generate the GAQL for it. The 30-day spend query above is a fine candidate. Compare its output against what you would have written and against what your Google Ads UI reports for the same window. Any discrepancy is your calibration data, and it will tell you more about how much to trust the tool than any announcement will.
Then pin your API version explicitly in code, put the next deprecation date in your calendar rather than in your memory, and keep google-ads.yaml and your refresh token out of every prompt you write, however much easier the debugging would be with them pasted in.