The people who sign off on your code.

What I Look For

Consistency assumptions that don't survive network partitions. Engineers often model distributed systems as slow local ones — they're not. I check for missing idempotency keys, non-atomic cross-service state updates, and Saga patterns that have no compensating transactions. Retry logic with exponential backoff is another perennial miss.

A Problem I Caught

A checkout service was writing order state to Postgres and then publishing to Kafka in the same function, with no outbox pattern. Under normal conditions: fine. When the broker went down for four minutes during a deploy, they created ~6,000 orders that never emitted an event. Fulfillment never started. Support tickets started around minute seven.

What I Look For

Floating point in money calculations. It never ends well. I also look for race conditions in ledger entries, missing idempotency on payment intents, and webhook handlers that don't dequeue atomically. Regulatory edge cases get missed too — transaction limits, AML triggers, reconciliation logic that only runs nightly.

A Problem I Caught

A subscription billing system was calculating prorated amounts using JavaScript floats. The error was fractions of a cent per charge — invisible in testing, but across 200k monthly subscribers it was accumulating roughly $800/month in rounding drift that didn't match their payment processor. Nobody noticed for eight months.

What I Look For

Training-serving skew — the silent killer of ML systems in production. Features computed differently at train vs. inference time can tank model quality with zero error logs. I also catch data leakage in feature pipelines, non-reproducible training runs, missing model versioning, and prompt injection vectors in LLM-integrated systems.

A Problem I Caught

A fraud model was trained with normalized transaction amounts using the training set's min/max. In production, the same normalization was recomputed nightly against the last 30 days of live data. As transaction volumes grew, the normalization window shifted, and the model quietly degraded over three months. Fraud rates climbed 18% before anyone correlated it.

What I Look For

IAM policies that are too permissive, secrets in environment variables that propagate to child processes, and Terraform state that's a single point of failure. I also look at blast radius: how bad is the worst-case deploy? Most teams haven't modeled it. Observability gaps are another recurring theme — you can't debug what you can't see.

A Problem I Caught

A team was using a single AWS IAM role across all Lambda functions in their account. One function had a dependency with a known path traversal CVE. An attacker could have read any secret in Secrets Manager, started or stopped any EC2 instance, and enumerated the entire account. The fix was a week of IAM decomposition — the discovery was a fifteen-minute code review.

What I Look For

Pagination that breaks under concurrent writes, rate limiting that doesn't account for distributed callers, and versioning strategies that painted the team into a corner six months ago. I also catch missing idempotency on mutating endpoints, over-fetching that'll become a performance cliff at scale, and error response shapes that leak implementation details.

A Problem I Caught

An API was using cursor-based pagination where the cursor was a base64-encoded Postgres offset. The client was long-polling a high-write table. As rows were inserted, offsets shifted mid-page — callers were silently skipping records and occasionally seeing duplicates. It was catastrophic for the downstream sync job that assumed completeness.