Code got cheap. Engineering management did not

The cost of producing plausible code has collapsed. That is the narrow claim engineering leaders can safely make; almost everything beyond it remains unproven, argues a director of engineering with more than three years in the role.

The author says Gemini 4 helped edit notes collected over the past year, during which the organization introduced LLMs and revisited familiar management rules: directors should not code, good work takes time, teams should be shielded from the business, and consensus should precede commitment.

The conclusion is not to discard those rules, but to audit the assumptions beneath them. Some assumptions changed when code became cheap. Others—about human coordination, trust, attention, accountability, and correctness—did not.

Measure outcomes, not code volume

Claims that AI tooling has made engineering organizations dramatically faster remain unproven. Assertions that code review, documentation, and onboarding are obsolete are wrong. Running the same roadmap with half the people is a bet, not a fact.

Velocity, pull-request counts, and tickets closed were always weak proxies. They persisted because the effort of writing code was genuinely scarce. Now that volume is abundant, those metrics can become actively misleading. Prompt counts and AI acceptance rates risk repeating the same mistake in a newer form.

Recommended reading

Shopify’s AI push brings storefronts back to HTML

The more durable approach is to measure business outcomes and system health, treating code volume as a cost to justify rather than output to celebrate. The first management task in an AI-adopting organization is honest instrumentation. Engineers may feel faster while shipping the same amount of work with more defects, leading to incorrect staffing, planning, and business commitments.

The author expects better evidence after Q4 2025, when a new generation of models was launched that “completely eclipsed” the capabilities behind older reports and research. Until then, large speedup claims deserve skepticism.

Verification is moving, not disappearing

AI has sharply reduced the time required for plumbing: scaffolding services, generating tests, translating between frameworks, and drafting migrations. Timelines based on those costs should be compressed.

Correctness is more complicated. Mechanical verification—types, tests, contracts, lint rules, invariants, and canary metrics—can be automated at a speed no human reviewer can match. Agents can run a test loop, inspect the failure, modify the diff, and repeat it rapidly.

That advantage depends on someone having already defined correctness in a machine-checkable form. Semantic verification remains slower: whether code implements the policy the business needs, reflects regulatory exposure, or makes the right trade-off. AI systems checking AI-generated work share training data, biases, and blind spots, allowing both generator and checker to fail in the same way.

Three consequences follow:

• Unit cost falls while total workload can rise. Cheap checking encourages more generation, which creates more material to verify.
• The verification boundary is strategic. Strong specifications, contracts, and invariants let teams capture more of the benefit.
• Accountability remains human. Sign-off is risk acceptance, not information processing, and the person who approves a result still absorbs the consequences of failure.

The constraint is shifting from checking speed to specification quality and human ownership.

The junior pipeline remains unresolved

The industry does not yet know how to train engineers for this environment. The judgment expected from senior engineers was historically built through small bug fixes, boilerplate, and the experience of getting stuck and unstuck—the same work AI tools increasingly absorb.

If machines take away that practice, the senior-engineer pipeline could weaken on a delay of three to five years. Possible responses include structured review of generated code, deliberate unassisted exercises, rotations through testing and verification, and earlier exposure to real systems under close senior oversight. The author is trying some of these approaches but cannot yet say whether they work.

Anyone claiming to have solved the problem—whether a vendor, essayist, or conference speaker—is selling certainty the evidence does not support.

Updating the old management rules

A director should not become a coding bottleneck, but directors also need enough direct contact with tools and output to distinguish genuine speed from high-volume, confident errors. The answer is calibration, not total withdrawal.

Shielding teams from the business protected scarce attention and reduced costly context switching. Those constraints remain. But engineers using AI without business context can now produce plausible, incorrect work at scale. Leaders should filter context deliberately rather than removing it by default.

Consensus is still about coordination and commitment, but cheap reversibility changes which decisions require it. Reversible “two-way door” decisions should be made quickly by the smallest viable group; irreversible choices still warrant a slower process. Organizations often misclassify both.

Headcount also deserves tougher scrutiny because output economics changed. Leaders should ask which work requires judgment and which consists of production that can be accelerated. Yet coordination costs, onboarding drag, and communication overhead remain, so adding people to a late project can still make it later.

The same distinction applies to management itself. LLMs can route information, summarize status, assemble dashboards, and forecast schedules. A management layer whose value is mainly summarizing Jira is vulnerable. Hiring, firing, promotion, contextual judgment, and ownership of a bad decision are different: generated recommendations still require a human to compare them with reality and accept the consequences.

That is likely a shift toward managers as editors and owners, not proof that management has disappeared. Organizational behavior also depends on trust, informal knowledge, and the consequences of past decisions—much of which is absent from the written record. Models tend to reproduce the median organization’s judgment. Differentiation lies in the decisions a company refuses to delegate.