But, maybe it's true that most code covers edge cases; then in my opinion, staff developers should be building tools for the rest of the company to use, and if they are powerful enough, you might be better off by having fewer people employed as programmers and more people writing programs. Obviously a lot has to go right for this sort of thing to happen.
I think service/API companies like Netflix are the most suited to your approach, but even with Netflix leaning into that style of company hard they still have thousands of engineers. There is most definitely some amount of irreducible work for a problem/domain/other.
> Obviously a lot has to go right for this sort of thing to happen
It feels like a very naive approach. When I'm building stuff, the edge cases often require a lot of digging into the surrounding context and working with other teams.
I don't think you can solve this by abstracting it away, because it's still working at the same level of abstraction just in a different part of the codebase.
There is also the fact that every abstraction is leaky...
Also, this shouldn't be framed as 10x more code but 10x faster velocity. That is what I meant by "[staff developers] are not good at writing 10x more LOC than other developers". Staff devs cannot move 10x faster than average devs on every problem.
Most work is undifferentiated. Staff developers don't add much value over another dev for basic work (Code quality has high diminishing returns) and they might only be 2-3x as fast, if that.
It's possible that many businesses could be sustained as they currently are today with 1/10th of the code and/or 1/10th of the people, but in a growing company that's impossible.