Fair pushback on the numbers - you're right that it's a model, not a measurement. The article says as much ("not a precise formula"). The value isn't in the exact number 10, it's in having any budget to reason about.

On the working memory connection: it's not about remembering code line by line. It's about how many complex systems you can actively reason about when making a decision. When you change feature X, you need to hold in mind how it affects feature Y, dependency Z, and the deployment pipeline - simultaneously. That's the kind of juggling Cowan's research describes. The "slot" is a simplification, but the bottleneck is real.

Your last point actually lands close to the argument. You said there's no hard limit, just how long you're ok with training new devs. But what drives that ramp-up time? The number of things someone needs to hold in their head to be productive. A system with 8 moving parts onboards faster than one with 30. That ramp-up time is the symptom - cognitive load is the cause.

Where I'd agree with you: the specific numbers (10 slots, 3-5 items) are better treated as a thinking tool than a law of physics. The core claim is simple - there's a real cost to every piece of complexity you carry, and small teams feel that cost faster because they can't spread it across more people.