Active Directory audits are the kind of thing that stays on the backlog forever. Too many accounts. Too much noise. Nobody wants to spend three days in PowerShell output. Last month I ran one using Claude. Took 15 minutes to get the first findings. Here is the exact workflow. Step 1: Pull the data with PowerShell (read-only, no changes) Get-ADUser -Filter * -Properties LastLogonDate, PasswordLastSet, MemberOf, Enabled | Select-Object Name, SamAccountName, Enabled, LastLogonDate, PasswordLastSet, @{Name='Groups';Expression={$_.MemberOf -join ','}} | Export-Csv ad-users.csv Get-ADGroupMember -Identity "Domain Admins" -Recursive | Get-ADUser -Properties LastLogonDate, Enabled | Select Name, SamAccountName, Enabled, LastLogonDate | Export-Csv domain-admins.csv Step 2: Feed it to Claude with this prompt "You are an Active Directory security auditor. I am sharing a CSV of all AD accounts in our domain. Identify: (1) accounts that have not logged in for 90+ days but are still enabled; (2) accounts with privileged group membership (Domain Admins, Schema Admins, Enterprise Admins, Backup Operators) and their last login date; (3) accounts with no login date at all; (4) service accounts with user-format names instead of svc_ naming convention; (5) accounts with passwords set more than 365 days ago without a non-expiring policy exception. For each finding, give me a risk level (Critical/High/Medium) and the exact PowerShell command to remediate it." Paste your CSV output directly after the prompt. Step 3: What we actually found 847 total accounts in the domain. The IT director thought there were 6 Domain Admins. There were 23. 14 accounts had not logged in for more than 180 days but were still enabled and unlocked. 3 service accounts with personal-looking display names had full Domain Admin membership — leftovers from an old consultant engagement nobody had cleaned up. 11 accounts had never logged in at all. Created for a project, never used, sitting with default permissions.

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.