Any good product leader will tell you, sometimes not building something is actually good for the customer. Slower dev cycles have you the ability to take time with decisions and make adjustments. The obsession with shipping more code is making things worse for users and I would argue, damages the company in the long run.

Eveyone has a backlog. What happens when you clear it in a month? Do you suddenly have better ideas about what you want to build? Do you suddenly have better intuitive designs? Do you have more users or the same users using the product twice as much? In most cases, the answer is no.

AI gives you the speed to execute when you need to, but knowing what to build and how will still remain a bottleneck.

Now the real question is "is the revert rate the same because you still have the same process, or do you fix-forward more often now, so your revert-rate is because of higher-severity incidents?"

The way we do this is to have period "post project" metric checks, looking for

- are the users using the new feature (repeatedly)

- what sentiment is associated with it on customer calls (extracted via call transcripts, but ideally the relevant engineer joins the call)

I mean we (huge tech company with ~2000 devs) literally never actually revert anything, in my 2 years here I have quite literally never reverted a commit. We have a staging/release cycle that means nothing ever needs a revert, you just fix issues in followup commits on trunk

This is another one of the infinite meaningless metrics that AI cash burners love to use without context

Ehhhh:

1) You can merge a "new change" to fix a merge, instead of reverting

2) It's unclear whether the substance of their individual PRs are the same. Never thought I'd want an LOC metric.

3) Really, I'm going to double down on the idea that merges could be fixing merges. Also happens to increase the merge metric.

Is your company making 5x more? Are your customers 5x happier? Are you getting paid 5x more?

What’s the point of doing 5x more?