Revised rules of engineering leadership

Will Larson published a post recently that reads less like a thought piece and more like a working log. He spent six-plus years in hypergrowth environments, revised his mental models when AI tooling shifted the cost of shipping code, and then wrote down what changed. We read it, tested the claims against what we see in the operators and technical founders we audit, and found four patterns worth taking seriously.

Migrations can now be owned by one person

Larson's first revised rule is that complex, large migrations can be 95% owned by a single individual and completed in roughly one-tenth of the previous time.

When migrations were expensive, a bad migration was a budget problem. Now it is a mental-model problem. Colleagues who co-maintain the codebase build shared assumptions about how things work. A migration done quickly but sloppily cracks those assumptions. They appear when a colleague hits unexpected behavior weeks later.

What this means for engineering leaders: the cost reduction in AI-assisted migrations is real, but it shifts accountability rather than reducing it. You are managing judgment now, not a project. The individual driving a migration carries more influence over the codebase than they would have three years ago, and the standards for that work need to reflect that.

For founders building B2B SaaS: if your engineering team has started running migrations faster with AI tooling, the question to ask is whether your review and documentation practices have kept pace. Speed without those anchors creates invisible debt.

First-pass code is cheap; working code is not

Larson's second rule addresses a misconception that has spread quickly: that "everyone should be writing code" means the cost of producing working code has dropped uniformly.

His actual position is more precise. First-pass code is nearly free. The cost of working code depends on your development harness: tests, CI/CD, validation environments, and the ability to preview changes before they land. That cost is not free. The harness either exists or it does not, and AI does not conjure it.

He also makes a point about the "everyone codes" debate worth reading carefully. Even at a company where marketing or ops contributors write code, they are not managing server allocation. They are operating within a safe boundary the engineering team defined. The harness is what creates that boundary. Without the harness, non-engineering contributors are not productive. They are risky.

The practical consequence for engineering leaders: the investments that paid off two years ago still pay off today. If your CI/CD pipeline was slow and brittle before AI tooling arrived, it is still the bottleneck. AI has not changed the order of operations. It has accelerated everything that touches the harness, which means a good harness compounds faster now than it used to.

We see this consistently in the technical founders we work with. The teams that invested early in test coverage and preview environments are absorbing AI tooling cleanly. The teams that skipped it are generating first-pass code at volume and then spending the savings managing incidents.

Optimize the base case for agents, not the exception

The third rule is about process design. Larson's argument: most steps of most processes can be fully automated in most cases, and most planning processes (weekly sprints, bi-weekly standups) are operating at too low an altitude.

The framing he uses is useful: distinguish the base case from the high-risk exception. In most areas, an automated code review harness catches what a human reviewer would catch, and catches it faster. In some areas, human judgment remains cheaper than the cost of getting it wrong. The failure mode is not over-automating the base case. The failure mode is failing to identify where the exception applies.

The corollary about planning altitude is one we have heard from multiple technical leaders independently. Bi-weekly sprints made sense when the unit of work was a two-week task. When an AI-assisted engineer can move from spec to working code in hours, the sprint is often managing artifacts of the process rather than actual work. The human coordination that matters is happening at a higher level: architectural decisions, prioritization across domains, judgment calls about what to build at all.

If your sprint review is catching things a good harness would catch automatically, the ceremony is doing the wrong job.

Durable, high-ownership teams matter more now

The fourth rule cuts against the grain of the current moment. As individual productivity increases and the cost of doing any specific thing falls, you might expect team composition to become more fluid. Hire specialists, ship fast, rotate them out.

Larson's view is the opposite. Durable, high-ownership teams with accumulated domain context become more valuable as individual output increases, because the thing that is not getting cheaper is judgment about what to build.

He documented this from his time at Uber: persistent teams accumulate domain context, build real camaraderie, and develop genuine ownership over an area in a way that rotational or project-staffed teams do not. That accumulated context is what allows teams to make fast, correct decisions when the cost of action is low. Without it, you have velocity without direction.

This is a useful corrective for B2B SaaS founders who have been restructuring teams around AI productivity. Speed is real. But the judgment layer that decides where to apply that speed is still a product of tenure, ownership, and accumulated context. An engineer who has owned a domain for two years and now has AI tooling is more productive than a new engineer with the same tooling and no domain context. AI tooling amplifies what is already there.

The thread connecting all four rules

When the cost of execution falls, the value of the judgment that precedes it rises. Cheaper execution raises the stakes on whatever judgment precedes it: migration quality, harness investment, exception identification, domain context. The pattern is the same across all four areas.

Your team's AI tooling is likely already compressing execution time. The question is whether your leadership practices have updated to match the new cost structure. If they have not, your leadership practices are still calibrated to the old cost structure.

For related reading: how B2B founders build inbound pipeline through LinkedIn comments and how to find the right influencers to engage with.