Originally published on LinkedIn.
A squad of eight on a product area usually had one or two people who actually understood the system. The rest were following. They wrote code against decisions someone else had made, and the depth lived in a couple of heads. When someone wasn't pulling their weight, the team absorbed it and nobody could see it clearly.
In the AI age we staff one or two engineers per area.
This isn't a headcount story. It's the opposite: the same engineers now cover far more surface area, and we can sprint on more of the product at once than we ever could with squads.
The work that made large teams necessary moved. Execution capacity comes from the LLM. Most bug work runs in the background. The engineer's job moved up a level: build the system that writes the code, encode enough of the product intent that what comes out is right, and keep the whole thing running as the product underneath it changes. That's a harder job than writing the feature yourself. You're not solving one problem, you're designing the conditions under which a whole class of problems gets solved correctly without you.
One person owning an entire area used to be impossible because bug fixing alone would consume them. Keep up with the bugs and no new features ever get built. Now that volume runs in the background, and what remains is the part that never parallelized well anyway: knowing what should be built, and whether what shipped is right.
The second-order effects matter more than the speed. No handoff between the person who understood the requirement and the person who wrote the code. No context lost across a standup. And output per engineer is finally legible, because there's one name on the area.
This is why we're building an owners-only culture. The job isn't writing code anymore. It's owning a machine that writes code, and owning what it ships.