ITzWorking
All pillars
// Pillar 05 of 05

Hardening

The work AI doesn't add unless told to.

AI generates the happy path. It almost never generates the production path: the secrets rotation, the timeout budget, the idempotency key, the dashboard, the runbook. Senior engineers add this work as default, because they've been the person paged at 3am when it was missing.

// Without it

The intern's loop

A junior demos a feature that 'works.' It works in dev. In production: the secret is in the repo, the API has no timeout, retries amplify a downstream outage into a self-DDoS, and there's no log line that explains why customer #4127 saw an error. The feature is now a liability the team has to babysit.

// The practice

Default, not heroic

Every shipped feature passes a hardening checklist before merge: secrets in the right store, categories swept for, timeouts and retries with explicit budgets, idempotency on anything that mutates, structured logs at every boundary, error tracker wired in, one-line note in the runbook. None of this is heroic. It's the default a senior engineer would apply with or without AI in the loop.

// Outcomes

Answerable at 3am

When something breaks at 3am, the on-call can answer 'what' and 'where' without escalating. When it doesn't break, the system can prove it didn't, with traces. When it scales 10x, the team isn't retrofitting. They're shipping.

// Self-check
  1. 01Does anyone actually walk through this list before merge, or is it on a wiki page nobody opens?
  2. 02Can the on-call answer 'what' and 'where' at 3am without escalating?
  3. 03Are secrets in a real secret store, or in env files committed by accident?
  4. 04How many TODO comments in your codebase are about timeouts, logs, or error handling, and how old are they?

Tight specs, hard deadline, real users?

Start a project