Last updated: June 17, 2026
19 years in software engineering with 7.5 years focused on SRE, observability, incident response, and platform reliability. Open to senior or staff SRE / Platform Engineering roles — remote or SF Bay Area.
Recent Projects:
Identified ~$130/month of cloud waste across NAT Gateway, ALB, EIP, and EKS nodes.
Cloud costs spiral quietly — resources accumulate, nobody rightsizes after traffic drops, dev infrastructure gets forgotten. LLMs are well-suited to this problem: given utilization data, they can reason about it, draw conclusions, and recommend action.
A Go service runs as a Kubernetes CronJob, scanning AWS resources and sending findings to Claude via Bedrock. The model reasons about each resource — wasteful or not, why, and what to do. Results write to DynamoDB, upload to S3, and email via SNS with a presigned link to the full report. See the details →
Ask Claude questions about your AWS spend — grounded in real scan data.
A weekly report tells you what changed. It doesn't make engineers mindful of cost. A better approach: let them ask quick questions and get direct answers grounded in actual usage data.
Claude Haiku on Bedrock queries the scan data in S3. If data is older than 7 days, it triggers a fresh scan automatically. The same data is exposed as a remote MCP server — add one line to ~/.claude.json and Claude Code queries cost findings directly from your terminal. reCAPTCHA v3, SSM budget circuit breaker, and a VIP lane for deeper access without the public rate limit.
Try it →
Scores deployment risk before merging the PR and comments directly on pull requests.
Code review checks correctness. It doesn't assess deployment risk — how much of the system is exposed if a change misbehaves, or how carefully it needs to be rolled out.
A write inside a background goroutine is a fundamentally different risk from a write inside an HTTP handler. One runs continuously against production; the other only triggers on request. No static analysis tool reasons about that distinction. This does.
On every Go PR, a GitHub Actions workflow diffs the changed files, sends them to Claude via Bedrock, and posts a blast radius score — low, medium, high, or critical — directly on the PR. Based on the score, it generates an Argo Rollouts canary config the engineer can commit before merging. How it works →
Automated multi-region failover with 61s DNS recovery and 83s full restoration.
Pilot light DR in us-west-2. Route 53 health checks trigger automatic failover. Infrastructure mirrored with Terraform and deployed identically across both regions — same app, same pipeline, different variables. Validated with a live test: scaled the primary to zero and watched what happened.
Go app on EKS, Terraform, GitHub Actions — and five things AI quietly got wrong.
Go app on EKS, everything provisioned with Terraform, deployed via GitHub Actions. Event-driven SQS pipeline, config through SSM and External Secrets Operator, Karpenter for node scaling. What used to take weeks took days.
Passing terraform plan doesn't mean it works. Karpenter CRDs applied before the cluster was ready. Wrong CPU architecture on first deploy. ALB health check misconfigured. DR duplicated as a folder copy with no mention that Terragrunt exists. Config that looks right and breaks at runtime — things AI won't volunteer unless you ask.
Five specific examples →
Contact
Open to senior or staff SRE / Platform Engineering roles — remote or SF Bay Area.