← Field Notes

Nobody tells the vibe coders. Production does.

A viral list of 107 infrastructure terms is making the rounds as a gotcha for AI-assisted builders. It's half right. Here's the half that matters, and the env var that humbled me this week.

4 min read

There's a list going around; you've probably seen it. A hundred-plus infrastructure terms, rate limiting to Kubernetes to chaos engineering, with the punchline "who's going to tell the vibe coders… until the app gets its first million users."

It's a good joke. It's also half wrong, and the half that's right isn't right for the reason people are sharing it.

The half that's right

The gap between "app that works in the demo" and "app that survives contact with customers" is real, and it is made of exactly that boring stuff. Nothing on the list is fake. Every item is a scar someone earned. If you build software for money, you will eventually meet enough of that list to respect it.

AI-assisted building makes the demo phase absurdly fast, which means more people arrive at the survival phase having skipped the decade where those words used to get tattooed on you one incident at a time. That part of the critique lands.

The half that's wrong

You do not need 107 concepts to ship. At a million users you'll need sixty of them, and you'll have revenue and a team by then. The list quietly conflates every scale of system, which is how junior engineers end up running Kubernetes for a site with forty visitors. Premature infrastructure is a failure mode too. It's just a more respectable-looking one.

At the scale where most real businesses live (including the local service companies I build for), the list collapses to about a dozen:

backups, secrets management, timeouts and retries, idempotency, rate limiting, database migrations, monitoring and alerting, health checks, DNS, scheduled jobs, cache headers, and a way to roll back.

The actual senior skill was never knowing all the words. It's knowing which dozen apply right now, and having the discipline to find out when the next one starts applying. That second part is where everyone, vibe coder and veteran alike, actually gets hurt.

The env var that humbled me this week

Here's my confession, so you know I'm not throwing rocks from a glass house.

This week I migrated one of my own products, Trove, between hosting accounts. The platform stores its secrets write-only, so I couldn't export them: I had to reconstruct every environment variable from the source and, crucially, check each one against what the code actually reads.

Two of them didn't match.

The code reads RATE_LIMIT_SALT. Production had RATE_SALT_LIMIT. Same words, wrong order. The rate limiter is deliberately fail-open, so nothing crashed. Production had been quietly running on the built-in dev fallback the entire time. The security property I thought I had shipped didn't exist.

The code reads TELEGRAM_CHAT_ID. Production had TELEGRAM_CHAT_IDold, a rename that half-happened months ago. Every notification the app thought it was sending me went silently into the void. No error. No alert. The feature just… wasn't.

Both bugs sat in production for months. Both were one word wrong. And no list of 107 terms would have caught either one. I could define every word on that list from memory and the notifications would still be dead, because vocabulary doesn't check wiring. Both were found the same way: a process that forced me to verify what the system actually does instead of what I remembered building.

The real dividing line

So no, the dividing line isn't vibe coders versus real engineers, and it isn't who can define circuit breakers on a whiteboard.

It's whether anything in your loop ever checks. A deploy that verifies the page actually renders. A form submission that proves the notification actually arrived. A migration that diffs what the code reads against what the environment holds. A monitor that tells you the site is down before your customer does.

Vibes plus verification is a legitimate way to build software in 2026. It's roughly how I build now, twenty-five years into this. Vibes without verification is how you find out about that list one production incident at a time, with customers watching.

The boring list is real. You just don't have to learn it the hard way, and you don't have to learn it all at once. You need the dozen that apply, a loop that checks, and the humility to assume at least one env var is lying to you right now.

Mine were.


Bexar Labs runs the boring list as a managed service for Central and South Texas businesses: websites, AI answering, and the infrastructure underneath, from $199/mo. If your app works right up until it doesn't, that's a conversation I've had before: bexarlabs.co/services.