Engineering management after the cost of code collapsed
I have been a director of engineering for a bit over three years now, and I still hear and read what I call the "old rules" repeated over and over: a director should not spend time coding, good work takes time, protect the team from the business, get consensus before you commit, etc.
For a while I thought the people repeating these lines were behind. Then we introduced LLMs in my org and the cost of producing code dropped, and I started checking each rule against the assumption underneath it. The surprising realization was that about half of the old rules were resting on assumptions that broke and the other half were resting on assumptions that did not, and a few of those matter more now than they did before.
What follows is a cleaned-up version of notes I accumulated over the past year. Gemini 4 helped with the editing.
What we actually know
The cost of producing plausible code has collapsed and it is not going back. Almost every claim beyond that is either unproven or wrong.
- That AI tooling has made engineering orgs dramatically faster: unproven.
- That code review, documentation, and onboarding are obsolete: wrong.
- That you can run the same roadmap with half the people: a bet, not a fact.
If you rebuild your management practices on the narrow claim, you will be right. If you rebuild them on the broad claims you are gambling with other people's careers and calling it a conclusion.
Focus on auditing assumptions
Every management practice rests on a certain assumption. Velocity tracking rests on output being a usable proxy for effort. Six month onboarding rests on syntax being slow to learn. Consensus driven architecture rests on change being expensive. Headcount planning rests on output scaling with people, and so on.
The question for each practice is not how old it is but rather what the practice actually rests on.
If a practice rests on the cost of writing code, put it under review because that cost moved. If it rests on how humans coordinate, build trust, allocate attention, or verify correctness, then nothing about it changed, no matter how dated the ritual feels.
This sounds obvious but I think many are sorting by feel: whatever seems modern stays, whatever seems old goes. That produces teams that abandoned useful friction and kept useless process, because the age of a practice and the validity of a practice are unrelated variables.
The evidence is smaller than the noise
Be suspicious of anyone, including your own team, who reports large speedups and only that. The gains I'm familiar with show up clearly in greenfield work, boilerplate, and unfamiliar territory. They fade or invert in deep work on systems the engineer already understands. I'm very much looking forward to data and studies done after the Q4 2025, where a new breed of models were launched that completely eclipsed the capabilities of the ones older reports and research were based on.
However, the gap between felt speed and measured speed is itself a management problem. If your engineers feel faster and ship the same amount with more defects, you will staff wrong, plan wrong, and set expectations with the business that you cannot meet. The first job in an AI adopting org is instrumentation being honest enough to tell you whether you have accelerated at all.
Weak proxies for a cheap thing
Velocity, pull request counts, and tickets closed were always imperfect. They survived because the thing they approximated ie the effort of writing code was genuinely scarce, so the noise stayed within tolerable bounds.
Now the proxied thing is cheap. That does not leave the metrics merely imperfect but actually actively misleading, because the cheapest way to raise them is to generate volume, and volume is the one thing your organization no longer lacks.
AI-specific metrics solve the wrong problem. I think acceptance rates and prompt counts are the same mistake in a new form. The durable move is older and harder: measure outcomes for the business and the health of the system, and treat code volume as a cost to be justified rather than output to be praised. Good engineers said this before LLMs. It was true then. It is enforceable now in a way it was not, because nobody can argue that writing more code was the hard part.
"Right" still takes time (for now)
The rule that good work takes time splits cleanly in two.
Plumbing time collapsed. Scaffolding a service, generating tests, translating between frameworks, writing the first draft of a migration: all of this is fast now, and any timeline built on those costs deserves compression.
Correctness time splits in two
AI systems now check and correct code faster than any human reviewer, and pretending otherwise costs credibility. One one hand, mechanical verification is collapsing. Anything where correct can be expressed as a machine-checkable artifact: types, tests, contracts, lint rules, invariants, canary metrics. Agents run the test loop, read the failure, fix the diff, and run it again at a speed no reviewer matches. If your correctness lives in this layer, your checking time is genuinely falling, and it will keep falling.
But notice what makes this layer fast. It is fast because someone already wrote down what correct means, in a form a machine can evaluate. The specification did the work & the checker reads it.
Semantic verification is a different matter. Does the code implement the policy the business actually needs? Does this trade-off match your regulatory exposure? Here, correct lives in human heads and institutional history. AI checking AI has a structural problem: the checker shares training data, biases, and blind spots with the generator. Both layers fail in the same places for the same reasons. Self-review catches the typo. It does not catch the shared misunderstanding.
I believe three consequences follow, and the core of this post:
- Unit cost falls, total workload rises. Cheap checking invites more generation, and more generation demands more checking. The verification workload grows with volume even as each individual check gets cheaper. Net calendar time is ambiguous, and the incident profile shifts: fewer dumb errors, more systemic ones, because high-volume plausible output now passes high-volume plausible review.
- The boundary is a strategic variable. How much of your correctness is machine-checkable is not fixed. It is a function of your specifications, contracts, and invariants. Teams with strong specs get the full benefit of cheap checking. Teams with weak specs get generated code reviewed by the same machine that generated it. Investing in machine-checkable correctness is now among the highest-leverage infrastructure work an org can fund, because it sets how much of this wave you can actually use.
- The slowest part of verification was never the checking but accountability. Someone signs & someone absorbs the consequence of being wrong: the incident review, the regulator, the customer. Sign-off time does not compress, because it is not information processing. It is risk acceptance, and legal and trust systems assign that to people.
So verification still sets throughput. What moved is the location of the constraint: from checking speed to specification quality, and to the willingness of a specific human to own the result.
The junior pipeline is an unsolved problem
Nobody knows how to train engineers for this environment.
The judgment you want in a senior engineer was historically built by doing the work that AI now absorbs: fixing small bugs, writing boilerplate, getting stuck and then unstuck: these were not just tasks but actually the practice that produced judgment. If the machine takes the practice, the pipeline that produces seniors breaks, and it breaks on a delay, so you will not notice for three to five years.
There are plausible responses. Structured review of generated code, deliberate unassisted exercises, rotations through testing and verification work, earlier exposure to real systems under close senior oversight. I am running versions of some of these. I cannot tell you they work, because the outcome variable is the quality of a senior engineer half a decade from now.
What I can tell you is that anyone who claims to have solved this, whether vendor, essayist, or conference speaker, is selling something. Treat the pipeline as an open problem you personally own. It has the longest delay between action and evidence, and the fewest chances to correct course.
My take on the old rules
"A director should not code." The director who dabbles, reviews pull requests to feel useful, and becomes a bottleneck is real. So is the director whose mental model of the work is five years stale, who cannot tell the difference between a team that is genuinely faster and a team that is generating confident, wrong output at volume (slop cannons). The resolution is calibration. You do not need to ship. You need enough direct contact with the tools and the output that you cannot be fooled in either direction, by the hype or by the dismissal.
"Shield the team from the business." The assumption underneath this one is that attention is finite and context switching is expensive. That assumption is intact. What changed is the cost of starving the team of context. Engineers prompting AI tools without business context just produce fluent, plausible, wrong work, at scale. The revision is not to flood everyone with everything but to stop filtering by default and start selecting deliberately: which context, to whom, at what level of detail.
"We need consensus before we commit." Consensus was always about commitment and coordination, and the cost of surviving cheap pivots. What cheap pivots change is which decisions need consensus at all. Reversible decisions, or two-way doors, should be made by the smallest group possible, quickly, because a wrong reversible call is now cheap to undo. Irreversible decisions still deserve the slow process. The actual skill is classification, and most organizations misclassify constantly, treating reversible technical choices as permanent and permanent organizational choices as casual.
"We need more headcount." The unit economics of output changed, so every request deserves a harder question than it got three years ago: what part of this work is judgment, and what part is production we keep hiring humans to do? But do not overcorrect. Adding people to a late project still makes it later. Coordination cost, onboarding drag, and communication overhead did not change with the price of syntax. Scrutinize headcount because output per person moved, not because people stopped being the expensive part.
Why the tropes persist
Three years in, here is what I believe about persistence. Practices survive for reasons, and the reasons are always mixed: some obsolete, some still valid, some political. When you hear an old rule repeated, you are usually hearing a person defend the valid part with the wrong argument or defend the obsolete part with the argument that used to work.
Treating persistence as stupidity is the failure mode of every management fashion, and the AI fashion is not exempt. The leaders who will look worst in five years are not the cautious ones but the ones who replaced thinking with a new set of slogans, even accurate sounding slogans, and ran their orgs on claims that were still unmeasured.
The job is sorting
The temptation, when a technology this large arrives, is to pick a posture: burn the old playbook or defend it. Both postures are laziness. The playbook was never a single object. It was a hundred pages, some about the cost of typing and some about the nature of people, bound together so tightly that we forgot they were separable.
Do not let anyone, including a confident essay, including this one, convince you those were ever the same page.
Will the machines do the sorting
I was told recently that AIs will soon do the management too, including the sorting. I thought about it over the weekend and I believe it is partly right.
Management has an information-routing function: aggregating status, tracking progress, translating updates into dashboards, forecasting schedules, collating performance data. A large share of what a management layer does daily is moving information between formats and people. LLMs are excellent at this, and the value of this is going to zero. If your management layer earns its keep by summarizing Jira, then yeah, that's over.
Then there is the judgment function: hiring, firing, promotion, deciding which rule applies in this situation with these people, owning a bad call. This has the same structure as verification. Someone checks the output against reality, and someone absorbs the consequence.
We're back to the generation argument mentionned above, but applied to management work: management output becomes abundant, therefore cheap. But the thesis of everything above is that when generation is abundant, verification is the constraint. Machine-generated management still needs a human to verify it against the org's actual behavior and to sign the result. So this is perhaps not the end of the manager but rather the manager's demotion to editor and owner. It is the exact same shift the individual contributor is going through.
There is one more problem with delegating the sorting. Sorting requires a model of how your org actually behaves: trust relationships, hallway knowledge, the consequences of past decisions. Almost none of this is written down. The written record of an org is a small, polished fraction of the org, and a model sorts on the record. Worse, what the model encodes from its training is the industry's average judgment. An LLM will sort your playbook roughly the way the median org would. If your strategy is to be the median org, that is fine. Differentiation lives exactly in the decisions you refuse to delegate.
Here is my honest concession, the sorting as an intellectual exercise is automatable. I used AI to pressure-test parts of this essay, and its first-pass audit was decent. What is not automatable is the political and moral work.
Where this goes: spans of control widen, layers compress, the information-routing tier of management is genuinely at risk, and titles will persist longer than functions. The management work that survives is the work that cannot be written down, cannot be averaged, and cannot be signed by anyone else.
What survives
The residual of engineering work is specification and ownership. The residual of management work is judgment and ownership. Same shape, two levels.
At every level of the org, the work that survives is the work someone has to sign.
Let's push the extrapolation to its limit to really drive it home. Imagine an org where agents write the code, run the checks, route the status, schedule the work, and draft the plans. Humans set direction, define what correct means, and sign. Everything between the signature and the shipped result is machinery. Now run the timeline backwards: imagine this org came first, and someone proposed the one you actually run. We will hire hundreds of expensive people to produce text by hand, at typing speed. We will arrange them in layers, where the job of each layer is to summarize the layer below for the layer above. We will synchronize their calendars in rooms so they can tell each other what already happened. We will measure their worth by how much they emit. Nobody would fund this proposal. It is slow, it loses information at every handoff, and it spends the scarcest resource in the building on work the machinery already does.
The org you run was never designed but it rather accumulated. Every role, ritual, and layer exists because something used to be expensive: typing, routing, checking, remembering. The prices moved. The org chart did not. In the agentic limit, the chart stops recording who produces and starts recording who signs. Headcount stops measuring capacity and starts measuring how much accountability you can afford. The orgs that get there will look small, quiet, and mostly empty: a short list of names attached to a long list of decisions, and nothing else left to manage.