Revised rules of engineering leadership.

Will Larson (lethain.com) · article · 2026-06-15 Reader 🖥️

Code Was Never the Bottleneck Durable, Domain-Owning Teams (vs. Fluid Teams)Guardrails Team Autonomy

In an AI-accelerated engineering organization, the scarce resource shifts from code production to judgment and decision-making: individual judgment matters more (because migrations one person can now drive alone have outsized blast radius), durable domain-owning teams matter more (because execution being cheap doesn't make deciding the right thing cheap), and the organization's capacity to make quick, durable, good decisions becomes the actual bottleneck on how much benefit it can realize from AI.

practical · mixed — A list of five revised leadership 'rules,' each immediately paired with concrete evidence from the author's own company (Imprint) over the past year — expository framing in service of a practical argument about how to lead an AI-accelerated engineering org.

Structure

Part	Role
Rule 1: migrations can now be driven by an individual rather than a team.	claim + evidence
Rule 2: first-pass code is nearly free, but working code's cost is set by the development harness.	claim + evidence
Rule 3: optimize the base-case of process for agents, while still routing edge cases to humans.	claim + evidence
Rule 4: durable, high-ownership teams with domain context are even more important, not less.	claim + evidence (includes rebuttal of the 'genius engineer' vision)
Rule 5: quick, good, and durable decision-making is a prerequisite to benefiting from AI at all.	claim + evidence (includes the changing CTO role)
Closing: what has and hasn't changed — organizational misalignment, lack of clarity, and poor architecture remain the binding constraints.	conclusion

Key terms

Migration
A large-scale, complex change to shared infrastructure or architecture (deploy process, configuration system, repo structure) — historically a team effort, now feasible for one person or a very small group to drive end-to-end at roughly 10% of the prior time cost, which raises rather than lowers the stakes of that individual's judgment.
Development harness
The surrounding infrastructure — tests, CI/CD, validation environments, change preview-ability — that determines whether a cheap AI-generated first pass of code becomes reliable working code; the thing that is still not free even though generating code itself nearly is.
Base-case of process
The common, lower-risk path through an operational process (e.g. routine code review, routine ticket triage) that can be fully automated with good harnesses and domain context, as distinct from the higher-risk edge cases that still require human judgment.
Durable team
A persistent, high-ownership team that stays on the same area long enough to accumulate deep domain context and a strong sense of ownership, as opposed to talented individuals rotated project-to-project.

Propositions

explicitMigrations (large, complex, shared-system changes) that used to require a team can now be roughly 95% owned by a single driving individual or small team and completed in roughly 10% of the previous time — which raises, not lowers, the stakes of individual judgment, because even small sharp edges in a fast migration will break colleagues' mental models of the shared system.conf: high
explicitWriting a first pass of code is now nearly free, but turning that first pass into reliably working code still costs real effort, and how much it costs is set by the quality of a team's development harness — tests, CI/CD, validation environments, change preview-ability.conf: high
extendsSWLW #710: Revised rules of Eng Leadership, When AI costs more than the engineer, and more. · p5 — Larson's 'development harness' concept names the specific mechanism (tests, CI/CD, validation) through which 'amplification is a magnitude, not a direction' actually plays out.
explicitDisagreement about whether 'everyone should write code' at a company is often a miscommunication: the real question is not whether non-engineers write code but whether there is a safe boundary within which they can participate without materially risking production systems.conf: high
explicitThe practices that were most valuable for speeding up engineering two years ago — investment in harness quality (tests, CI/CD, validation) — remain the most valuable practices today, unchanged by the AI-tooling shift.conf: high
explicitMost steps of most operational processes (e.g. routine code review, routine ticket triage) can be fully automated for their base case with a good-enough harness and domain context, while a minority of higher-risk steps still require human judgment; failing to distinguish base case from edge case creates unnecessary risk.conf: high
explicitAs execution speeds up via automation, routine human planning rituals like weekly or biweekly sprints are 'operating at too low an altitude' — human coordination still matters but should move to a higher level than routine task-sequencing.conf: medium
explicitDurable, high-ownership teams that accumulate domain context over time remain essential in the AI era, because execution being cheaper doesn't make deciding the right thing cheaper — evidenced by a production incident where an AI harness proposed a reasonable-looking but wrong fix because the necessary instrumentation had never been captured.conf: high
supportsSWLW #710: Revised rules of Eng Leadership, When AI costs more than the engineer, and more. · p12 — Both argue human/team judgment becomes more, not less, important as AI accelerates execution.
explicitcontestedThe vision of AI-first companies run by a small number of 'genius engineers' who build perfect, unmaintained software one by one is compelling but implausible at scale, because high-judgment individuals eventually get hemmed in by lack of domain context — durable teams, not roaming star individuals, remain the fundamental organizational building block.conf: high
contradictsAI + Teams = ? · p5 — Castenfors argues the standard durable small team's boundary should dissolve to let outside domain experts prototype directly; Larson argues durable, stably-staffed engineering teams become even more important as the fundamental unit — opposite prescriptions for team composition under the same AI-acceleration premise.
supportsDesigning the AI-native engineering organization · p8 — Both argue the durable value in the AI era is judgment and domain context/agency, not narrow technical execution skill.
explicitRealizing the benefits of AI-accelerated execution requires the organization to also make decisions quickly, durably, and well — speeding up code or process delivers no value if the organization can't commit to and act on the resulting change.conf: high
extendsSWLW #710: Revised rules of Eng Leadership, When AI costs more than the engineer, and more. · p1 — Larson's own full post gives concrete operational detail (deploy cadence, the instrumentation incident, the CTO-as-bottleneck pattern) behind the newsletter's compressed synthesis that leadership's decisive work is unchanged in essence.
explicitThe average CTO role has become substantially more technical and less bureaucratic over the past year because, in practice, the CTO is often the only person positioned to make binding decisions fast enough when teams disagree — not because executives are inherently better decision-makers, but because binding decisions are uniquely valuable when the people bound by them are aligned enough to honor them.conf: high
explicitThe structural constraints on an AI-accelerated engineering org haven't changed in kind, only in relative weight: organizational misalignment, lack of clarity, and poor technical architecture remain the binding constraints on speed, even as the raw cost of writing code approaches zero.conf: high

Arguments

Durable, domain-owning teams remain the fundamental unit of engineering organization even in an AI-accelerated company — not individual 'genius engineers,' and not ad hoc project rotation.

Explicit premises:

Execution (writing/shipping code) has become much cheaper via AI harnesses.
Deciding the right thing has gotten only 'a bit easier,' not much easier.
Domain context accumulates through sustained ownership of an area, not through one-off high-judgment interventions.
A documented production incident shows an AI harness proposing a plausible but wrong fix due to missing domain-specific instrumentation.

Implicit premises:

The 'genius engineer, nothing to maintain' vision conflates execution speed with decision quality.
Organizations that rotate talented people project-to-project lose exactly the context needed to catch the kind of error the production incident illustrates.

Inferences:

As AI continues to cut execution costs, the relative value of durable, domain-holding teams versus any individual's raw throughput should keep rising, not falling.

Narratives

Larson's team cut a multi-repo frontend into a mono-repo in about a month, 95% driven by one engineer, moving entirely off npm for package hosting in the process.
→ Concrete evidence that migrations (rule 1) have become individually ownable at a pace that would have taken a team much longer before.
An AI harness proposed a 'reasonable but wrong' fix to a production issue because the data needed to diagnose it correctly had never been instrumented at all — the only real path forward was adding the missing instrumentation, which required domain judgment the harness didn't have.
→ The piece's sharpest evidentiary anecdote for why durable, domain-context teams remain essential (supports the key proposition that AI accelerates execution but not judgment).
Deploy frequency went from roughly 6/week (manual) to 200-400/week over a year — roughly 20-30x per engineer even after headcount doubled — driven by a deploy/migration overhaul done 90% by two infrastructure engineers in two months.
→ Concrete throughput evidence behind the 'migrations can be done by an individual' rule and the piece's overall claim about how much execution speed has structurally changed.
Internal adoption of Claude Code/Cursor went from about 25% to 100% of the team within two months, achieved without any top-down mandate — just by making the tooling good and removing friction for holdouts.
→ A specific, bottom-up adoption pattern that illustrates tool-quality-plus-friction-removal, rather than mandate, as the actual driver of adoption.

Questions addressed

✅ Does 'everyone should write code' mean non-engineers are now meaningfully contributing production code at scale?
No — the real issue is defining a safe boundary within which non-engineers can participate (analogous to a SaaS product's customization layer), not literal production code contribution by non-engineers.
✅ Will AI-first companies be run by small teams of 'genius engineers' building perfect, unmaintained software?
No — implausible at scale, because domain context (not raw execution speed) is the real constraint, and only durable teams accumulate that context over time.
⭕ Is concentrating binding decision authority in a single executive (the author himself) a sustainable structure as the company keeps growing via the very acceleration the article celebrates?

Gaps

incompleteLarson presents his own increasingly centralized decision-making ('I am the only person who can make binding decisions when teams disagree') as a feature of the current moment, but doesn't address the scaling risk this creates: concentrating binding authority in one person is itself a bottleneck and single point of failure, especially as headcount and surface area keep growing via the very acceleration the piece celebrates.
Read next: Pair with distributed decision-rights frameworks (e.g. mission-based leadership, DACI, team-autonomy models) to examine whether centralized fast decision-making can coexist with team autonomy at larger scale, or whether it's only a transitional phase.
incompleteThe piece doesn't name or seriously engage a company that actually tried the 'small number of genius engineers, nothing to maintain' model and failed, so the rebuttal to that vision rests on general argument and one internal anecdote rather than a tested counter-example — notable given how widely that vision is currently discussed.
Read next: Look for case studies (successes or failures) of genuinely tiny, AI-leveraged engineering orgs that tried to skip durable-team structure entirely.
incompleteLarson doesn't discuss what happens to engineers whose prior differentiated value was coding speed/skill now that 'first-pass code is nearly free' — his 'development harness' framing implies a shift in what's scarce (harness quality, judgment, domain context) but doesn't say what role, if any, the formerly-valuable 'fast coder' skill now plays, or how such engineers should re-skill.
Read next: Pair with pieces that directly address re-skilling and the changing value of coding speed as abstraction rises.
incompleteThe claim that 'most steps of most processes can be fully automated in most cases' with the right harnesses and judgment doesn't specify how an organization tells, in advance, which steps are genuinely base-case versus hidden edge-case — the piece's own production-instrumentation incident shows a seemingly routine issue turning out to be exactly such a hidden edge case, but Larson doesn't generalize from it into a method for catching these before they cause harm.
Read next: Pair with pieces on classifying and escalating agent autonomy by risk (fitness-function or review-gate frameworks) for a concrete method.