How AI Dev Tools Can Turn Your Cloud Bill Into Useful Insights
You manage a service team that owns a few services running in your organization. It’s Tuesday morning. A budget alert lands in your inbox…
How AI Dev Tools Can Turn Your Cloud Bill Into Useful Insights
Not a cloud bill but — Savannah Bananas Split Shake!
You manage a service team that owns a few services running in your organization. It’s Tuesday morning. A budget alert lands in your inbox. You open it, look at the number, and think: somewhere in our codebase, something changed. The question is where.
Before, finding the cause meant jumping between billing consoles, deployment history, and infrastructure files to piece things together, it worked, but it took time, lots of context-switching, and sometimes just luck.
I’ve done this kind of work for years. Each month in our business review, we do a deep dive into the line items together. Did anything unexpected show up? Are there new charges we didn’t plan for? Usually, someone on the team already knows the reason. Someone might say, “Oh, I spun that up to test XYZ,” and that solves it. But getting to that answer, by digging through usage data and matching it to code changes, used to take a lot of time.
This is where LLMs have really helped. Modern AI-powered dev tools like Claude Code, Kiro, and Cursor make the process much easier.
The Rise of Code-Aware AI Tools
Over the past year, AI development tools have grown rapidly. Tools like Claude Code, Kiro, and Cursor work right in your development environment, next to your codebase, deployment history, and git history. This gives them full context on how your infrastructure was built and how it has changed.
With this context, it’s much easier to understand your cloud costs.
This approach works with any cloud provider. Whether you use AWS, Azure, GCP, or a mix, the main idea is the same: export your billing data, load it into a tool that understands your codebase, and let it find the connections. The export format may vary by provider, but the analysis process stays similar.
The Core Idea: Import Your Billing Metrics, Ask Questions, Get Answers
The best part is you don’t need a separate tool. You can bring your billing metrics straight into your development environment, right next to your code.
Export your data from your cloud provider’s cost management console as a CSV file. It’s best to include a full quarter, so the tool has enough history to spot trends, seasonal patterns, and gradual cost increases. Then, paste it into a session.
This gives you two things right away: a financial view from your billing metrics and a technical view from your codebase and deployment history.
Now ask it the question:
“Here is a CSV of our cloud billing data for the last quarter. Compare it against our codebase, deployment history, and infrastructure-as-code files. Identify the top cost drivers, flag any unexpected increases, trace cost changes back to specific commits or configuration changes, and recommend concrete optimization opportunities with estimated dollar impact.”
The real value comes when you combine these two views.
If you see a cost spike in your billing data, the tool can compare it with your git history and deployment timeline. It can trace the change back to a specific commit, resource, or architectural decision. Instead of searching through different systems, you just ask, and the tool already has the information it needs.
Monthly Business Reviews and Weekly Spot Checks
Your monthly business review is when you dig deep. You look at the full picture, compare month over month, and ask tough questions: Are we moving in the right direction? Are there structural cost changes to address? What will next quarter look like if we keep going this way? Can this architecture handle the growth projections the business has set? Remember, these projections can be multi-dimensional.
Bringing your billing CSV into an AI dev tool makes these reviews much more productive. You can ask it to break down what changed, connect cost shifts with deployments, and find optimization opportunities, all based on your real codebase. What used to take hours with spreadsheets and cross-referencing now takes minutes.
Between monthly reviews, your weekly operational meetings act as spot checks. The goal is simple: quickly scan the line items each week to make sure nothing slipped through. Are there any unexpected spikes? Did a test environment get left running? Did a config change quietly increase data transfer costs? The team usually knows what’s running and what it costs, so these talks are fast. When something stands out, there’s usually a clear reason.
With an LLM helping, even these weekly spot checks become faster. You paste in the latest data and ask what changed, where the increase came from, or what code is driving it. This way, you catch issues early, before they become surprises at the next monthly review.
Over time, combining deep monthly reviews with quick weekly spot checks gives you a clear sense of your cost trends. You start to see patterns and can plan for how costs will scale as usage grows. You can spot issues early and learn where to make tradeoffs, like spending more in one area to save in another or making a small change now to avoid a bigger bill later.
What to Export and What to Leave Out
Before you paste anything, take a moment to think about data hygiene.
What to include: your metered usage data and cost breakdowns in CSV format, exported from your cloud provider’s cost management tool, like AWS Cost Explorer, Azure Cost Management, or GCP Billing. Choose a date range that covers at least one full quarter. This gives the tool enough context to tell the difference between a one-off anomaly and a real cost trend. A clean export should include service name, usage type, usage quantity, cost, and date. That’s all the tool needs to do its job.
What to leave out: any confidential information. This includes sensitive account IDs, internal project names tied to client work, personally identifiable information, or anything your organization considers proprietary. The tool only needs the cost and usage data, not the identifying details. If you’re unsure, leave it out. And never, never, commit any of this to your code repo.
What You Can Do With That Context
You can connect cost changes to code changes. Because the tool understands both your billing metrics and your deployment history, it can spot correlations that would otherwise take a lot of time. For example, a spike in data transfer costs might match a deployment that changed how your functions communicate. An increase in storage costs could be traced back to a configuration change from three weeks ago. These connections become clear quickly.
You can also analyze your infrastructure for optimization opportunities. With your codebase in context, the tool can scan your infrastructure-as-code files and give you specific, dollar-based recommendations. This might mean changing volume types, applying intelligent tiering to storage with infrequent access, or switching workloads to more cost-effective instance families. The suggestions are tailored to your actual setup, not just generic advice.
You can also plan for scale. When you see your cost trends clearly, week by week and quarter by quarter, you can look ahead. What happens if traffic doubles? Where are the cost cliffs? What should you re-architect now before it gets expensive? This kind of planning used to require a finance team and a spreadsheet. Now, you can have the conversation in your dev environment with real data to support it.
Learn where to make tradeoffs. Not every cost increase is bad. Sometimes you spend more on compute because you’ve improved reliability. Sometimes a higher storage bill means better data retention practices. The key is to see those tradeoffs clearly and make them on purpose, not discover them three months later in a billing review.
Turn your cost rules into enforceable policy. Describe your cost governance rules in plain English (“use GP3 volumes only,” “all resources need an Owner and CostCenter tag,” “Graviton for all Lambda functions”), and the tool generates the policy JSON to support them. Your standards become part of your infrastructure, not just guidelines.
Validate before you deploy. Once a policy is defined, the tool scans your codebase and flags any resources that would conflict with it. This way, you catch mismatches before they reach production and keep your infrastructure aligned with your standards from the start.
The Context File: Your Team’s Institutional Memory
One of the most useful features of these tools is the context file, a set of instructions that stays across sessions. Claude Code uses CLAUDE.md, Kiro has its spec files, and Cursor has .cursorrules. The names are different, but the idea is the same. Instead of repeating your organization’s standards every time you start new infrastructure, you write them once.
Lambda Functions
Always use ARM64 architecture (Graviton)
Attach a CloudWatch Log Group with 7-day retention
Use Python 3.12+ runtime
EC2 Instances
Prefer Graviton instances when available
Use GP3 volumes by default
Tag everything: Environment, Owner, CostCenter
Storage
Apply S3 Intelligent-Tiering for infrequently accessed buckets
Set lifecycle policies on all S3 buckets
Every engineer on your team, every new service, and every infrastructure change automatically inherits these defaults. Cost optimization becomes the easiest path, built into how your team works by default.
Why This Approach Works
This approach works well not just because of the AI, but because of how it fits into your workflow.
Most cost analysis tools are separate from your development workflow. You build something, ship it, and then later a billing review reveals costs tied to decisions that are already in production.
These AI dev tools are already where your code lives. When you bring your billing data into them, you’re not bridging two worlds. You get analysis that’s grounded in the technical context that drives your costs. The feedback loop between what you build and what it costs becomes much shorter.
A shorter feedback loop means you can make better decisions sooner, with less friction for everyone.
But here’s the bigger picture: the manual work of cloud cost analysis, like spreadsheet wrangling, cross-referencing, and detective work, is exactly the kind of tedious, high-context task that LLMs are built for. What used to take hours and a lot of institutional knowledge can now happen in a conversation. That frees your team to focus on what really matters: making better architectural decisions and building better services.
Getting Started
Here’s how you can start using this approach:
Pick your tool. Claude Code, Kiro, Cursor, or any AI dev tool that can access your codebase and accept pasted context will work if you don’t already use one; most offer free tiers to get started.
Connect your codebase, and if you use git, your deployment history will come along with it.
Export your billing metrics and paste the CSV into a session. Ask the question you actually care about. For example: “What in our codebase is driving the increase in this line item?” or “What are our top three cost optimization opportunities right now?”
Set up your context file so that every future session and every engineer on your team benefits from your organization’s best practices automatically.
Add it to your monthly review and weekly spot checks. Go deep in the monthly business review. Use the weekly OE meetings to scan for anything unexpected. Build a shared understanding of what your services cost and where they’re heading.
The gap between your cloud bill and your codebase has always been smaller than it seems. AI dev tools and the LLMs behind them are what finally close it.
I write about AI, engineering, and the tools that change how teams build. Follow me on Medium for more.
By Joshua McDonald on March 10, 2026.
Exported from Medium on August 26, 2026.
Reader discussion