AI can cut coding time by 40% and still ship nothing sooner if the build is where the work waits. In LeadDev, Sandeep Khandelwal argues that leaders should measure developer friction instead of output.
He means the time lost to slow pipelines, flaky tests, vague error messages, and waiting on other teams. Thirty minutes a day across 50 developers comes to about 125 hours a week, and no productivity report shows it.
I think the article points at a planning question more than a metrics one. When code gets cheaper to write, some of the most valuable work on a team is a better error message or a test that stops flaking. That work rarely wins a slot against a feature. My view is that it should be planned like a feature, with someone named against it, rather than squeezed into the gaps.
After years of running web teams, I have come to believe the friction that costs the most is the kind people have stopped mentioning, because they learned the workaround long ago.
What would it take for a fix to a flaky test to beat a feature in your next planning meeting?
Photo source: https://photos.robertstowe.com/iguazu-falls