I'm an infrastructure engineer who ships AI products. Here's why both halves matter.
Two things sit on my plate.
Production infra at Pax8. AI products at Respondyr, on the side. This post is about why both halves are load-bearing, and why it's rare to be genuinely strong at both.
Shipping fast can leave a mess
It's a familiar pattern. A demo ships on Friday. It looks great. It breaks somewhere around customer #500. Someone gets paged, and a few weeks later that demo has been quietly rebuilt into something that actually holds up in production.
That's not a knock on anyone. Shipping the demo and hardening it for production are genuinely different skills, and most roles only ask for one of them. The work often ends at "the demo works," and the rest surfaces later.
The catch is that the rework is expensive, and it shows up after the fact. Over time, product instincts drift toward shipping faster and infra instincts drift toward distrusting it — and the handoff between them gets harder than it should be.
Infra instincts can stall a product
Mirror gripe. Hand an infra engineer an AI product idea and you'll get an architecture diagram, a service mesh proposal, a list of SLO questions, a retry-and-backpressure conversation, a design review, and no shipped product for three months.
This one isn't a moral failing either. It's the failure mode of a profession paid to worry about the long tail. If you spend years reasoning about what happens at 3am during a region failover, "let's just see if it works" feels actively unsafe.
Model-skepticism doesn't help. A lot of infra engineers were trained back when "AI" meant the thing that polluted your error budget with non-determinism. They have a point. But the ground has shifted under that instinct.
So here I am
I came up infra. GitOps, multi-provider Terraform, declarative state, every secret managed by IaC, every deployment reconciled. The instincts are baked in deep enough that I don't like shipping anything without them. Hand me a hackathon idea on a Friday afternoon and I'll still want it in a repo with a CI pipeline before Sunday — the reflex doesn't really switch off.
Somewhere in the last year I started figuring out the other half. Not the demo — the demo's the easy part. The part where someone hands you a vague problem, you figure out what they actually meant, you ship a working version by Friday, and it still runs on Monday without an apology.
The hardest part of building AI products isn't the model. It's sitting with the person who'll use the thing and translating what they actually need into a system that doesn't fall over. I'd rather embed for two weeks and ship the right thing than write a Notion doc about the wrong thing for six.
At Respondyr I put AI agents in the critical production path, because I own the call and I built the guardrails they run inside. At Pax8 I shipped the opt-in release pipeline — not for agents, but because staging kept drifting ahead of prod when changelogs grew too long for anyone to want to release. It happens to be exactly the loop agent-driven deploys need. The trust is earned in CI, never assumed.
I built a Jira and Confluence MCP server in Python, solo. Twenty engineers at Pax8 reach for it every day. Nobody mandated it. They picked it up because it was easier than the alternative. That's the measure of an internal tool I care about most.
I run Respondyr on the side. The whole product is a multi-service architecture on EKS, pure GitOps, multi-provider Terraform across AWS and Cloudflare, internal cost-tracking gateway in front of every paid LLM call. If I can't see what an agent is spending or how it's failing, I don't trust it in production. Because if I'm going to ship an AI product, I'm going to ship one I'd put my own on-call rotation against.
A quick aside on agents versus workflows, because the industry keeps blurring it. Respondyr is as much workflow as it is agentic. If not more. The marketing engine is a deterministic workflow with a Playwright MCP agent dropped in for the long tail of prospect intake forms that don't have a public email address. I love the determinism of a workflow. Cheaper to run, easier to test, easier to debug, easier to explain to whoever's on-call at 3am. I appreciate the autonomy of an agent when determinism actually runs out of road. It's easy to reach for an agent because it's the louder word. Knowing which one to use, and when, is what's hard.
This site is the same story in miniature. Designed in Google Stitch on a Thursday afternoon. Ported to Astro. Cloudflare Pages, Terraform-managed DNS, auto-deploy via GitHub Actions. One evening, end to end. The infra is honest and the shipping was fast.
The thesis
If you're building AI products with real customers, products that have to survive contact with people who don't read your docs, I can be useful from day one.
If you're running production infrastructure that needs to ship AI, same.
There aren't a lot of people who are honestly both — the two skill sets pull in opposite directions, and most of us end up picking a side. I'm trying not to.
My email is in the footer.