Your AI writes code blind to cloud cost. Here's how to close the loop.

Most teams I talk to are shipping more code than ever, and a growing share of it is written by AI coding agents like Claude. A human reviews it, it gets merged, and it goes to production. It works, and it passes the tests.

Then nobody looks at what it costs to run: in the cloud, and in all the dev tooling around it.

Engineers care about this. Nothing in the workflow tells them, though. The agent that wrote the change never finds out it doubled the reads on a database, or that a config it touched now gets polled a million times an hour. So the next change gets written the same way, just as blind.

That gap is what this post is about, the cloud cost of AI-generated code: it ships, and nothing about how it behaves in production makes it back to whoever writes the next change, human or agent.

And the cloud bill is only part of it. The same code also drives the bill for the tooling around it: CI minutes on every push, APM and observability priced per host, per span or per gigabyte ingested, log pipelines, error tracking. For many teams, that tooling is a very significant share of what it costs to operate software, and it's even less visible to whoever writes the code.

Why cloud cost never reaches the code

Think about how every other quality signal reaches the people writing code. A test fails, and the PR is blocked. Latency spikes, and someone gets paged with a trace pointing at the guilty endpoint. The signal arrives fast, and it arrives where the code lives.

Cost doesn't work like that. It shows up weeks later as a few numbers on a few invoices, from the cloud provider, the CI platform and the APM vendor, each rolled up its own way. By the time anyone asks why the database bill or the observability bill went up, the change that caused it is three sprints old. If a person wrote it, they've moved on. If an agent wrote it, it has no memory of it at all.

So the loop that should exist stops halfway. We write, we ship, we run, we even measure. We just never feed what we measured back into the next round of writing.

Coding agents see the code, cost tools see the bill

The odd part is that the information already exists. It just lives in two places that never talk to each other.

Your coding agent sees the code. It can read the whole repo, follow a call graph and explain why a function exists. What it can't see is that this function runs forty million times a day, and that every call hits a paid API.

Your FinOps and cost tools see the bill. They can tell you that a service's Secrets Manager line tripled last quarter, or that one Aurora cluster is now your third-largest line item. What they can't tell you is which line of code is responsible, or what the fix looks like.

The bill without the code is a report. The code without the bill is a guess.

Neither side fixes the problem alone. A cost report hands engineers a ticket with no idea where to start. A coding agent asked to "reduce costs" optimizes whatever looks expensive to read, which is rarely what's expensive to run.

Real examples: Secrets Manager, AppConfig and Aurora

The patterns we keep finding are almost boring, which is exactly why they survive. They're small and everywhere, and they only show up when you put the code and the bill side by side. Every figure below comes from the accounts' own AWS billing data.

Secrets Manager called on every request

A Lambda handler or a request path calls Secrets Manager each time it needs a credential, instead of once. Secrets Manager charges per API call, so the cost follows traffic one for one. Across the teams we work with it's usually a five-figure line per year, and about five lines to fix.

Before:

import json
import boto3

def handler(event, context):
    client = boto3.client("secretsmanager")
    secret = client.get_secret_value(SecretId="prod/db")
    creds = json.loads(secret["SecretString"])
    return run_query(creds, event)

After:

import json
import boto3

_client = boto3.client("secretsmanager")
_creds = None

def get_creds():
    global _creds
    if _creds is None:
        secret = _client.get_secret_value(SecretId="prod/db")
        _creds = json.loads(secret["SecretString"])
    return _creds

def handler(event, context):
    return run_query(get_creds(), event)

In production you'd add a TTL so rotated secrets get picked up, or use AWS's caching library for Python. Either way, the cost curve stops tracking your traffic.

AppConfig costs: every poll billed as a full delivery

AppConfig bills two things at very different rates. Asking "has anything changed?" costs $0.0000002 per request. Receiving the configuration itself costs $0.0008, about 4,000 times more. The intended pattern is that every call to GetLatestConfiguration returns a fresh NextPollConfigurationToken, and the client sends it back on the next poll. AppConfig then answers "nothing new" for almost nothing, and only bills a delivery when the configuration actually changes.

At a US fintech, a few services didn't carry that token forward. So AppConfig delivered, and billed, the full configuration on every single poll. Two million polls a month became two million paid deliveries, for configurations that changed a handful of times. Other services in the same accounts handled the token correctly and cost almost nothing.

The fix was six lines of code: keep the token and send it back. The AppConfig bill dropped by over 99%, about $20k a year. If changing the client isn't practical, the AppConfig Agent manages the token for you.

Monthly Systems Manager spend, where AppConfig is billed. The fix rolled out over two weeks at the end of August; October is a partial month.

Cost tools read all of this as normal usage. The only tell is a ratio, deliveries against polls, and it only means something once you know what the code was supposed to do.

Aurora I/O-Optimized: the storage setting nobody revisited

At a global consumer-goods company, an Aurora database's cost had been climbing for months, to about $3,900 a month. Its per-request I/O charges were running at roughly ten times its compute and storage combined, which is exactly the case Aurora I/O-Optimized storage is built for. Switching is one line of configuration, and the cluster dropped to about $500 a month. We've seen the same pattern at several companies since, worth six figures a year in total, one line each time.

Weekly RDS spend for the whole account. The drop at week 48 is the storage switch; the account's other databases make up the rest.

These three don't need the same context, and it's worth being precise about that, because a good coding agent will catch some of this on its own.

Case	What it takes to spot	What execution data adds
Secrets Manager on every call	Code alone. Knowing it runs as a Lambda makes it obvious, since every invocation can re-run the handler.	How much it's worth: pennies at ten calls a day, five figures at forty million.
AppConfig token not carried forward	Code plus the API's billing contract, if the agent ever opens the client library.	The proof: deliveries at 100% of polls where they should be under 1%, and the $20k a year that adds up to.
Aurora I/O-Optimized	Billing. The config line looks the same whether switching saves money or adds it.	The answer itself. At the same company, the same switch on another cluster would have added about $4,100 a year.

So the agent that wrote the code had no reason to suspect any of it, and an agent asked to review it would likely catch the first one, maybe the second, and never the third. Even then, only execution data tells you which fixes are worth making, and whether a change saves money or costs more.

Closing the feedback loop between code and production

Now picture the same workflow with the missing half plugged in. Billing, inventory and metrics flow back to where code gets written. The agent drafting a change can see that the endpoint it's touching runs at a few thousand requests a second, and what each of those requests costs. The reviewer sees the expected cost change next to the test results. And once the change lands, the next one gets written knowing what the last one actually did.

This is where it starts to compound. Every fix teaches the system something about where the money goes, so the next round of code starts from better numbers. Efficiency stops being a quarterly FinOps cleanup and becomes part of how the team ships.

Teams running agentic software factories already think this way about security and compliance. They put policies and scanners in the loop, so whatever the agents generate converges toward code that passes them, without a human checking every line. Cost deserves the same treatment. Give the factory a north star for efficiency, measured against real execution data, and every agent in it converges toward efficient code the same way it converges toward secure, compliant code.

This is what we're building at Cloud ex Machina. Dex connects code with live billing, inventory and metrics data, finds the issues that only show up when you see both, and ships the fix as a pull request. Our plugin for Claude brings that cost context into the coding agent while it writes. The first version of a change won't always be efficient, but each round is informed by what the last one cost in production, so the code converges toward efficiency over time. Engineers don't change how they work, and the bill improves anyway. Together, Dex and the plugin create the loop this post is about, a feedback loop from code to its execution context and back.

We're now extending that loop beyond the cloud bill, starting to bring CI, APM and observability costs into the same platform. For many teams they're a large part of what it costs to run software, and they follow the code just as directly: a test suite that runs on every push, a log line in a hot path, traces sampled at 100%.

How do you make AI-generated code cost-efficient?

You can start closing the loop with what you already have:

1. Put cost next to latency. Wherever your team checks service health, add cost per service and per request, including the CI and observability spend each service drives. If it isn't on the dashboard engineers actually open, it doesn't exist.
2. Review metered calls in code review. Flag any new call to a paid API on a hot path, whether it's secrets, config, queues or a third-party service, and ask how often it runs. The same goes for logs, metrics and traces that your observability tool bills by volume.
3. Give your agents the numbers. A coding agent that can read usage and billing data can reason about cost the way it reasons about tests. Even a read-only export it can query is a start.

FAQ: AI-generated code and cloud costs

Does AI-generated code cost more to run?

No, not by nature. It costs whatever it costs, but nobody checks. Agents optimize for code that works and passes tests, and nothing tells them what it does to the bill, so small inefficiencies ship at the speed agents write code.

Can a coding agent reduce cloud costs on its own?

Only with data. An agent reading the repo has no idea which function is the hot one. Give it billing, inventory and metrics, and it can find and fix cost issues the way it fixes failing tests.

How is this different from FinOps?

FinOps tools manage the bill, things like budgets and commitments, and they're good at telling you where the money goes. Closing the loop takes that information one step further, into the code that spends it.

When should you switch Aurora to I/O-Optimized?

When per-request I/O is a large share of the cluster's bill. AWS's own rule of thumb is about 25% of total Aurora spend. Below that, the higher compute and storage rates cost more than the I/O you save. Size it on a few months of billing, not a short snapshot: a single I/O spike can make a switch look like a saving when it would actually add cost.

I'd love to hear how other teams handle this, especially if you've already wired production data back into your agents. And if you want to see what the loop turns up on your own stack, we run free three-week proofs of value. We agree on a savings target upfront, and you only pay if we hit it.