01 / Product engineering
How do you stop breaking API changes from reaching clients?
Breaking API changes keep reaching clients the same way: the change looked safe in review, and the first to notice is a consumer in production. Catch them at the seam, before deploy, with two gates: a semantic diff of the OpenAPI spec against main that fails CI on removed endpoints or fields, new required request fields, narrowed enums, changed types, or changed auth on an existing route; and consumer-driven contract tests, where each consumer records the requests and response fields it actually depends on and the provider verifies against them before release. The spec diff is cheap and covers the declared surface; contracts catch what the spec does not constrain. Versioning and deprecation then become a decision someone makes, not a surprise a client discovers.
02 / Access control & security systems
How should physical access follow identity across sites?
Physical access is starting to follow the record of who someone is: the identity provider, the lease, or the tenant record, with the badge converging on the credential that person already uses to log in. A joiner, a mover, or a leaver should reach every site from that record, without someone editing three consoles. The change and the door event then belong in one audit trail.
03 / Operations tooling & internal platforms
How should internal ops tools handle exceptions?
Internal ops tools keep failing the same way: only the happy path is modeled, and every exception lives in a spreadsheet or a Slack thread. Holds, overrides, reassignments, late arrivals, and partial completes should be first-class states in the workflow, each recording who decided, why, and when. Operators then work that queue inside the system. The decision and the work belong in one audit trail.
04 / Integrations & data movement
How do you make webhook retries safe to repeat?
Webhook delivery keeps failing the same way: retries without a stable idempotency key, ambiguous success codes, and unbounded backoff. Treat every attempt for the same logical event as one delivery. Send the same Idempotency-Key on each retry, treat 2xx as accept, and honor Retry-After as a lower bound. Use bounded jittered backoff, with a dedupe window measured in hours, not days. The failure modes belong in the design, not in a ticket after records go missing.
05 / Applied AI
Who decides whether an AI agent's action actually runs?
Production AI keeps landing on one split: an agent proposes an action, and a separate, deterministic layer decides whether it runs. Permissions, approval for risky changes, and the audit record live there, and the layer fails closed. Evaluation belongs in the release path as a gate on every prompt or model change, compared to a baseline, not a notebook someone checks once. Every deployment we ship includes an evaluation set, guardrails, and a review loop.
06 / Reliability & modernization
How do you catch a data feed that has quietly gone stale?
Upstream feeds keep failing the same way: the pipeline looks green while the warehouse quietly goes stale. Treat every integration and data feed as a monitored dependency with an owner: schema assertions at the boundary, freshness checks that page when data stops moving, and synthetic checks that prove a known record still arrives. Agents and operator UIs should refuse to act on data that fails those checks, not guess. Observability belongs on the seam, not only on the app that consumes it. Stabilize the data path before you modernize the UI that sits on top.