I can't agree with 4 - it's sophomoric reasoning at it's best. The code is the product, it's what the system (human/ai/factory/combo/etc) is producing. The IC will always be more familiar with the nuance and the implications of the decisions than the manager. There is only one real stat to track - profit. As for the size of your team, not all human developers are equal, but agentic tend to behave similarly. A small team of highly coordinated things will always outproduce a pile of generic ones acting will little or no methodology. Please deeply re-evaluate at a philosophical level what quality over quantity really means for delivering outcomes.
Not to be tautological, but isn’t the product the product?
Which code? The high level code? The transpiled intermediate code? The assembly it runs on eventually? The microcode optimizations on the processor?
I’ve written assembly professionally. That code matters occasionally. But mostly I don’t worry about it. I don’t worry much about the transpiled JavaScript tsc output either. Or the intermediate code generated for LLVM. Or the bytecode most managed languages make for their interpreters.
Like I said, you still have to do the hard parts, but most of software development is boilerplate or yet another implementation around the hard parts. AI is a tool you have. Using it effectively does not mean it is your only tool.
Also, profit is not the ultimate metric. Value provided is the metric. Optimizing for money, to paraphrase a great book, is like trying to get better at tennis by studying the score board.
No company is measured by "value provided" on any market, it's a feel-good metric. And you\re playing word-games now despite even saying you're not trying. Like I stated earlier, it's entirely a sophomoric take. And now I understand why.
