Engineering Management After Code Got Cheap

The author — a director of engineering for three years now — admits that for a long time he considered anyone who repeated the “old rules” to be behind the times: a director shouldn't write code, good work takes time, shield the team from the business, build consensus before deciding. But after LLMs were rolled out across his organization, the cost of producing code fell, and he began stress-testing every rule. The conclusion was unexpected: roughly half of the rules rested on premises that had broken, and the other half on premises that held — and now matter even more.

What we actually know

What got cheaper is the production of plausible code — and the price isn't coming back. Everything else, the author insists, is either unproven or false. That AI has radically sped up development — unproven. That code review, documentation and onboarding are obsolete — false. That the same roadmap can be run with half the headcount — a bet, not a fact. Building practices on the narrow claim is reasonable; building on the broad ones means gambling with other people's careers and calling it a conclusion.

Sort, don't burn

The central idea: every management practice should be tested against what it rests on. If it rests on the cost of writing code — up for revision, because that cost has shifted. If it rests on how people coordinate, build trust and check correctness — nothing has changed, however archaic the ritual may look. The age of a practice and its soundness are independent variables, yet many people sort “by feel.”

Metrics like velocity and the number of closed tickets were always weak approximations, but tolerable while the labor of writing code was scarce. Now the cheapest way to juice them is by volume — and volume is precisely what's in surplus.

Verification becomes the bottleneck

Mechanical checking (types, tests, contracts, linters) is something agents run faster than any reviewer. But it's fast because someone wrote down in advance what “correct” means. Semantic checking — whether the code matches the required business policy and regulatory risks — lives in people's heads, and AI checking AI shares the generator's blind spots. Cheap checking provokes more generation, and thus more checking; the share of systemic errors grows instead of dumb ones. The slowest part of verification isn't the checking but the accountability: signing off on a result doesn't compress, because it's the acceptance of risk, not the processing of information.

Unsolved problems

Separately, the author singles out the break in preparing juniors: a senior's judgment was born out of small bugs and routine work that the machine now takes over — and the damage will show up with a three-to-five-year delay. Anyone who claims to have solved this problem is selling something.

Revisiting his theses, the author keeps them alive but with caveats: a director doesn't have to write code, but does need contact with the tools, so as not to be fooled by either the hype or the denial; shielding the team from the business is dangerous — without context, AI produces coherent, wrong work at scale; consensus is needed only for irreversible decisions.

In the limit, the author carries the thought through, the org chart stops recording who produces and starts recording who signs off. Such companies will look small and nearly empty: a short list of names attached to a long list of decisions.

Source: Hacker News