Building a Firecracker VM Orchestrator in Go - Part 2: API Server

Introduction If you missed the first post in this series, start here. It covers the foundation: five provider interfaces that decouple the Flames control plane from any specific infrastructure backend. This time we're building the first thing that actually does something: the API server. This is the first real consumer of those provider interfaces. A running binary. go run ./cmd/flames-api, curl against it, create a VM. That kind of thing. But what made this spec interesting wasn't the HTTP handlers, it was the design conversation I had with Claude Code along the way. I pushed back on several decisions, changed the architecture in meaningful ways, and the final result is quite different from what was initially proposed. That's the part worth documenting. The Steering Here's the thing about working with AI agents on architecture: the first draft is usually reasonable but generic. The value I bring is knowing where generic breaks down. Let me walk through the key moments where I steered