This article lays out seven hard-learned rules every engineer breaks at least once—like “rollback first, debug later,” testing backups by restoring them, and always having a tested rollback plan. It also covers handling external failures, using four-eyes checks for risky changes, logging trade-offs, and avoiding “temporary” fixes that stick around forever.

• When production breaks after a deploy, roll back immediately and debug afterward rather than wasting time proving your change is innocent
• Backups are worthless untested—actually run restore drills, since restore times can balloon as data grows and permissions/procedures may be unclear
• Every third-party API will eventually fail, so know rate limits, SLAs, and whether you can queue requests or serve stale data before it happens
• Risky changes (migrations, infra tweaks, dangerous scripts) need a second reviewer, and "temporary" fixes should be built clean since they often become permanent

The author revisits Fred Brooks’s classic software lessons in the era of AI coding agents, arguing that while agents wipe out accidental complexity, they amplify essential design challenges and generate unprecedented technical debt. He warns of new “agentic” tar pits, scope creep, and coordination overhead as AI swarms bloat codebases and shift the real work back to human judgment and taste.

• AI agents eliminate accidental complexity (boilerplate, tests, refactoring) but can't handle essential design work, which still requires human judgment
• Past ~100,000 lines of code, agents start "chasing their own tails," generating defensive boilerplate that clogs codebases—seen in McKinney's own projects and Posit's million-line Positron fork
• Coordination overhead doesn't disappear with AI, it just changes form: parallel agent sessions produce contradictory plans that force humans back into the loop
• Going from agent-generated prototype to production-ready code (testing, documentation, edge-case hardening) remains fundamentally human work