Last month a Series A startup I know woke up to a $47,000 AWS bill. The month before it had been $6,000. Nobody did anything "wrong" — a new microservice quietly fanned every request out through a NAT Gateway, and at a few cents per GB processed, it added up fast. They found out on the 3rd of the following month, when the invoice landed. By then the money was already gone. Here is the uncomfortable truth: most teams only discover cost anomalies AFTER the fact. You log into Cost Explorer, you see the ugly hockey-stick graph, and you spend the next two days doing forensic archaeology on something that happened two weeks ago. Dashboards are rear-view mirrors. They tell you where you crashed, not that you were about to. What if the loop were flipped? Instead of a human remembering to check a dashboard, imagine an AI agent that: 1. Pulls the AWS Cost Explorer API every morning, grouped by service. 2. Computes a rolling 7-day baseline for each service and flags anything spiking more than ~20%. 3. Hands the raw numbers to Claude and asks it to reason about the likely cause — not just "spend went up," but "EC2-Other jumped 340%, this pattern is consistent with NAT Gateway data processing charges from a new workload." 4. Fires a Slack alert to your team channel with the service, the dollar delta, the percentage jump, Claude's diagnosis, and a recommended next action — before the bill lands. That is the difference between a threshold alarm and an agent. CloudWatch can tell you a number crossed a line. It cannot tell you why, and it cannot tell you what to do about it. Claude can look at "Lambda invocations up 1,200%, duration flat" and say "this looks like a retry storm or an event-source loop, check for a Lambda writing to the same S3 bucket that triggers it." Three anomaly types this catches beautifully: NAT Gateway fan-out: A new service routes all egress through a NAT Gateway. Data processing charges creep up invisibly under "EC2-Other." Lambda runaway invocations: A recursive trigger or a bad retry config turns a $5/month function into a $2,000/month function overnight.

Everyone's screenshotting "ChatGPT wrote my Terraform in 10 seconds." Cool. Now push it to prod and watch it open a 0.0.0.0/0 security group because the model pattern-matched on a tutorial from 2019. The generation half is solved. The validation half is where engineers actually get paid. Here's the workflow I run every day. I never let AI output go straight to apply. Every block of generated HCL passes through five gates, in order, and fails closed: 1. terraform fmt -check — style and parse. If it can't format, it's malformed. 2. terraform validate — syntax and internal consistency against the provider schema. 3. tflint (with the AWS/GCP/Azure ruleset) — catches invalid instance types, deprecated arguments, missing tags, unpinned providers. 4. checkov (or tfsec/Trivy) — the security gate. Public buckets, unencrypted volumes, wildcard IAM, open SSH. This is the one that saves your job. 5. terraform plan — the reality check against real state. No surprise destroys, no "this will replace your database." Only after all five pass does a human read the plan. Real example from this week: I asked Claude to generate an S3 bucket for log archival. Clean HCL, looked perfect. Checkov flagged CKV_AWS_18 (no access logging), CKV_AWS_21 (no versioning) and CKV_AWS_145 (no KMS encryption). The AI wrote functional code, not compliant code. Three findings, thirty seconds, zero incidents. The prompt discipline matters too. I don't say "make an S3 bucket." I say: "Generate Terraform for an S3 bucket for log archival. Require: SSE-KMS with a customer-managed key, versioning enabled, public access block on all four settings, access logging to a separate bucket, and a 90-day lifecycle transition to Glacier. Pin the AWS provider to ~> 5.0. Do not use deprecated arguments." Constraints in the prompt = fewer findings in the gate. Actionable takeaway you can steal today: wrap those five commands in a single shell script or a pre-commit hook. AI generates, the pipeline judges, you approve. You get the speed of AI and the safety of policy-as-code. That's the whole trick.

Your Kubernetes cluster is probably 60% empty air, and you're paying full price for it. Here's the uncomfortable truth most teams discover the first time they actually measure it: pods request 2 CPU and 4Gi of memory, then sit there using 180m and 900Mi. The scheduler reserves the full request, so your nodes fill up on paper while the actual silicon idles. You end up adding nodes you don't need to run workloads that barely breathe. The old fix was to stare at Grafana for an afternoon and hand-tune YAML. The new fix is to let an AI agent do the reading for you. Start with the data. Run this: kubectl top pods -n production --containers Then pull what each pod actually requested: kubectl get pods -n production -o json | jq '.items[] | {name: .metadata.name, resources: [.spec.containers[].resources]}' Now you have two numbers per pod: what it reserved vs. what it uses. Paste both into Claude, GPT-4, or Gemini with a prompt like: "Here is kubectl top output and the configured requests for these pods. For each pod, recommend right-sized CPU and memory requests with 20% headroom. Memory is non-compressible, so never go below observed peak. Output a YAML patch." The model returns structured recommendations in seconds, complete with the reasoning for each one. Real numbers from a mid-size cluster I looked at: 42 pods, average CPU utilization against requests was 14%, memory 31%. Right-sizing dropped the reserved footprint enough to remove 3 of 11 m5.xlarge nodes. That's roughly $420/month per node on-demand, so about $1,260/month, or $15k/year, from one afternoon of work. Two guardrails before you get excited. First, never trust a single snapshot. kubectl top is a point in time. Look at 7-day P95, not the number at 2pm on a Tuesday. Second, treat CPU and memory differently. CPU is compressible, so an under-provision means throttling. Memory is not, so an under-provision means OOMKilled. Tell your AI agent this explicitly or it will happily suggest a memory request that kills your pod under load.

Last week one of my clients spent 3 hours debugging a CrashLoopBackOff. The fix took 45 seconds once we knew what to look at. The investigation took 3 hours. That's the real Kubernetes tax — not the cluster cost, the engineer time. Here's the workflow I now use instead: Step 1 — Grab the raw context. Three commands: kubectl describe pod <pod-name> -n <namespace> kubectl logs <pod-name> -n <namespace> --previous kubectl get events -n <namespace> --sort-by='.lastTimestamp' Step 2 — Feed it to Claude or GPT-4 with this prompt: "You are a senior Kubernetes SRE. I have a pod failing in production. Here is the output of kubectl describe, previous logs, and recent events. Identify the root cause, explain why it's happening, and give me the exact fix with kubectl or YAML changes. Flag any security or resource misconfiguration you spot while you're in there." Paste all three outputs. Step 3 — Get a diagnosis in 30 seconds. Last week's result for that client: OOMKilled container with a memory limit of 128Mi trying to load a 400MB ML model. The AI spotted it immediately, suggested the right limit (1.5Gi), and flagged that the pod had no resource requests set — which was causing noisy neighbor problems on the node. The AI also noticed the liveness probe was firing before the app finished loading, which was masking the real issue in older logs. Two config changes. Done. What makes this work is the combination of context: describe output shows resource limits and probe config, previous logs catch the last gasp before the crash, and events show the timeline. Most people only look at one of these. I've built a library of 7 prompts covering the most common K8s failure modes — CrashLoopBackOff, OOMKill, Pending pods, ImagePullBackOff, probe failures, init container failures, and a security audit prompt. Each one is tuned to pull out the exact signals AI needs to give a useful diagnosis. Drop a comment below and I'll share the full prompt library with you. What's the most annoying Kubernetes failure you keep running into? Drop it below — I'll write a prompt for it.

Last quarter a client asked me to review their Azure bill. $180,000/month. They thought it was roughly correct for their workload. It wasn't. After 90 minutes of feeding Azure data into Claude with the right prompts, we found $23,000/month in waste they had no idea was there. Here's exactly what we did and how you can run the same audit yourself. THE FIVE-STEP AZURE AI COST AUDIT Step 1: Export your Azure Cost Management data. In the Azure portal: Cost Management > Cost Analysis > Download. Export last 90 days as CSV. Or via CLI: az costmanagement export create --name "90day-audit" --type ActualCost --scope "/subscriptions/YOUR_SUB_ID" --dataset-granularity Daily Step 2: Pull Azure Advisor cost recommendations. az advisor recommendation list --category Cost -o json > advisor-recommendations.json Step 3: Find orphaned resources with Azure Resource Graph. az graph query -q "Resources | where type =~ 'microsoft.compute/disks' | where properties.diskState =~ 'Unattached' | project name, resourceGroup, properties.diskSizeGB, location | order by properties.diskSizeGB desc" -o json Step 4: Feed everything into Claude with this prompt: "You are an Azure FinOps consultant. I'm sharing: (1) Azure Cost Management export last 90 days, (2) Azure Advisor cost recommendations JSON, (3) orphaned resource inventory. Provide: top 5 cost drivers, Advisor recommendations ranked by monthly savings/effort ratio, estimated waste from orphaned resources with specific resources to delete, and three changes I can make THIS WEEK to reduce the bill immediately." Step 5: Validate findings with Azure Cost Management's What-If forecast before acting. WHAT WE ACTUALLY FOUND ($180K/MONTH CLIENT) $8,400/month: 23 stopped VMs still provisioned -- nobody deallocated them after a migration project $6,200/month: 840GB unattached premium managed disks from a test environment shut down 14 months ago $4,100/month: Oversized App Service Plans (P3v3 where P1v3 handles the load -- Advisor flagged this for 6 months, ignored)