For over three years as a director of engineering I kept hearing the “old rules” that a manager should not code, that good work takes time, that teams need protection from the business, and that consensus must precede commitment. When we introduced LLMs the cost of code collapsed, forcing me to test each rule against the assumption it relied on. About half of those rules rested on assumptions that broke, while the other half rested on assumptions that still hold, some of them now more critical than before.

The core insight is that every management practice sits on an assumption. Velocity tracking assumes output proxies effort; six‑month onboarding assumes syntax is slow to learn; consensus‑driven architecture assumes change is expensive. If a practice leans on the now‑cheap act of writing code, it must be re‑examined; if it leans on human coordination, trust, or correctness verification, it remains valid. Relying on felt speed alone is dangerous because metrics like pull‑request counts become actively misleading when code volume is no longer scarce. The durable move is to measure business outcomes and system health, treating code volume as a cost to justify, not as output to praise.

Correctness splits into machine‑checkable and semantic layers. Mechanical verification is accelerating, but semantic verification still depends on human judgment and institutional knowledge, so total verification workload can rise even as each check gets cheaper. The junior pipeline also suffers because the tasks that once built senior judgment are now automated. Structured review of generated code, deliberate unassisted exercises, and early exposure to real systems under senior oversight are potential responses. I am experimenting with versions of these, and Gemini 4 helped edit these notes, with more definitive data expected after Q4 2025.