loading…
A system can pass every demo and still fail in production: an SDK works locally but not in a customer's network, a payment succeeds while the database update fails, or an AI agent returns HTTP 200 with the wrong action. This course begins where the happy path ends.
Production engineering is the discipline of making customer outcomes reliable when components, people, and assumptions fail.
| Format | What you will do |
|---|---|
| 16 pages · about 5 hours | Diagnose incidents, make production decisions, and harden customer-facing systems |
| 30% concepts · 70% practice | Timeouts, retries, idempotency, recovery, traces, evals, rollout, and response |
| Level: Intermediate | Best for FDEs and engineers who already know how to build an application |
Define working → Map boundaries → Observe → Isolate → Mitigate → Recover → Prevent
The method comes first. Each lesson then applies it to a different system so that you learn the principle rather than memorize one implementation.
| Case | What it exposes |
|---|---|
| Customer SDK stopped working | Environment drift, integration boundaries, evidence collection, and escalation |
| Payment or refund partially completes | Idempotency, durable state, reconciliation, and source of truth |
| Kintsu Agent behaves unpredictably | Nondeterminism, output validation, evals, and human escalation |
Clone the runnable failure-injection project: Kintsu Agent on GitHub. It is one recurring implementation lab, not the definition of production engineering. SDK, API, payment, database, and deployment cases appear alongside it.
For each topic, first state the general rule and the evidence it requires. Then apply it to at least two cases. A technically valid fix is not enough: you should be able to defend its operational and customer trade-offs.