Greg Blotzer

Software Engineer · Boston, MA

I've always learned by doing. Studying for certifications between shifts, picking up C# from a book to make a career pivot, learning Python on CheckIO ahead of a new hire joining so I'd be ready when they started. I started in QA with manual testing on video games at Electronic Arts. Those early years shipping titles are documented on MobyGames. From there came different stacks, browser automation, CI/CD, then cloud infrastructure, each step less about changing careers and more about following the interesting problem to its next layer. These days that path has led me to building AI-powered systems and thinking carefully about the infrastructure layer that makes them trustworthy at scale.

A decade of asking why does this break and how do we know it works turns out to be good preparation for building systems where the failure modes are subtle and the feedback loops are slow. I care about that tension and trying to thread the needle between moving fast enough to be useful and thinking carefully enough to not cause harm.

I'm based near North Cambridge and rely on public transit. Open to remote or hybrid roles accessible via the Red Line, Cambridge bus routes, or the Fitchburg commuter line as far west as Concord.

Bedrock-powered multi-agent system that goes from a natural language prompt or architecture diagram to validated, security-scanned Terraform. Two-agent supervisor architecture with a five-action-group ReAct loop, dual input paths (text and diagram), four CDK stacks, and a GitHub Actions CI/CD pipeline with OIDC and staged deploys.

Houseplant care assistant designed and directed with AI-assisted development. Supports three swappable AI backends (Anthropic Claude Haiku 4.5, Google Gemini 2.0 Flash, and local Ollama) switchable at runtime via a Settings UI. Plant names validated against the GBIF species database before any AI call. API keys stored AES-256-GCM encrypted. Pluggable storage interface (SQLite or DynamoDB), provisioned with Pulumi. The Go implementation was built with AI-assisted development under architectural direction.

AWS budget monitoring and alerting system with a six-stage CI/CD pipeline, prod/dev dual environments, and a manual approval gate before production. The system caught its first organic spend alert unattended, a Route 53 domain registration, which directly motivated promoting it to a dedicated production environment. The prod/dev architecture navigates an AWS Budgets constraint: because budgets are account-scoped, two environments would both fire on the same spend. Prod owns the single budget; dev runs the full stack silently as a canary. Documented with five post-mortems.

Mac Dev Setup Script github.com/dablotz/setup-scripts

Scripted developer environment bootstrap for macOS. Installs and configures Homebrew, pyenv, nvm, and common tooling. Practical tooling built for personal use and shared openly.

gregblotzer.com

This site. Static HTML and CSS served through AWS CloudFront with Origin Access Control, an ACM-issued SSL certificate, and Route 53 for DNS. Built without a framework or hosting service, using the same infrastructure pattern you would use for a production web property, applied to a personal portfolio page.

The Case for Purpose-Built Context Infrastructure in AI-Assisted Development

Argues that AI session context is a production asset that belongs on purpose-built infrastructure, versioned, governed, and provenance-tracked, not scattered across conversation histories and tool caches.

The Asset You Probably Haven't Classified

On session context and reasoning chains as ungoverned attack surfaces, using the GitHub Copilot supply chain breach as an anchor for why the industry's post-incident conversation missed the most important layer.

AWS Certified AI Practitioner Earned Feb 2026
AWS Solutions Architect - Associate In progress, 2026

For questions about a specific project, the issues tab on the relevant repo is the best place. For everything else: LinkedIn works well.