Which Engineering Rules Survive When AI Writes the Code

Velocity tracking rests on a simple assumption: the time an engineer spends on a ticket is roughly proportional to the effort involved. For most of the last decade, when writing the code was the slow part of the work, that assumption held, and the chart on the wall was a reasonable proxy for team health. Now that LLM coding tools produce a plausible first pass in seconds, the bottleneck moves to deciding what the code should do, and the time-on-ticket signal stops measuring what it used to measure. The honest audit a software team owes itself is not which practices are old, but which of them still rest on a cost that has moved.

A practice is a stack of assumptions wearing a habit. The test is to name the assumption under the practice and ask whether it still holds. If the assumption moved, the practice is on probation, even if it is brand new and beloved. If the assumption is still true, the practice is load-bearing, even if it looks like bureaucracy your peers are deleting. The year a rule was written tells you almost nothing about whether it should survive. The cost shift it depends on tells you almost everything.

Several long-standing practices rest on the cost of writing code and are now under genuine review. Six-month onboarding plans assume that learning a codebase is mostly learning the syntax and idioms of a particular language and framework; when a model can scaffold that, the assumption weakens. Consensus-driven architecture reviews assume that redoing a design decision is expensive enough to justify broad alignment up front; when an engineer can prototype three alternatives in an afternoon, the cost of changing the design later drops, and the alignment ritual becomes harder to justify on those grounds alone. Headcount planning, in its crudest form, treats one engineer as one throughput unit, grounded in the idea that adding people linearly increases code shipped. The narrow claim, that the cost of producing plausible code has collapsed and is not going back, is the central observation of one engineering director's audit of his own organization. The broader claim, that teams can now run the same roadmap with half the people, is a bet, and the source flags it as such.

Other practices are unchanged because their assumption is about humans. Code review, when it works, is a verification and trust-building exercise, and the cost of writing the code is incidental. Documentation exists to align a group on what is being built and why, which has nothing to do with the cost of typing. Attention allocation, incident response, and the work of deciding which corners to cut under deadline pressure all still rest on the limits of human bandwidth. Those practices are old because the constraint they encode is old, and the constraint has not moved. The friction they introduce is still doing the work it was introduced to do.

The trap on either side is sorting by feel. Teams under pressure to modernize end up keeping the rules that look modern and discarding the ones that look old, while the opposite failure is defending every existing practice on the grounds that it was working when it was written. Age and validity are unrelated variables. Useful friction, the kind that prevents two engineers from redoing each other's work or surfaces a hidden dependency, gets cut under modernization pressure, and useless process that happens to look rigorous gets kept. The same author who proposes the audit warns that teams sorting by feel end up abandoning useful friction and keeping useless process because age and validity are unrelated. The audit is the only way to tell them apart, and the audit is not the same thing as the sentiment.

Honest limits matter. The narrow claim, that the cost of producing plausible code has collapsed, is solid and well-attested. The broader claims, that engineering organizations are now dramatically faster, that the same roadmap can be shipped with half the headcount, that code review and onboarding are obsolete, are bets, and the source that proposes the audit flags that the evidence is smaller than the noise. Run the test. Mark the bets as bets. Resist dressing the conviction of the moment up as a verdict.

A software team's standing rules are not a museum. They are a list of assumptions, and the assumptions are what need to survive contact with reality. The cost of writing code moved. The cost of coordinating humans, of trusting a reviewer's eye, of verifying that the system actually does what it claims did not. Run the audit, write the answers down, and be honest about which rows are conclusions and which rows are guesses.