Your data-driven approach is exactly what teams need to move past the hype cycle. The split between frontend/junior backend and others isn't surprising, but your breakdown by task type is the key.
You call it a **clear net positive for tasks requiring verbose but predictable code**. I'd add that the definition of "predictable" needs to be a team agreement, not an individual one. What's predictable boilerplate to a junior dev might have hidden operational complexity that's second nature to a senior. Without a shared checklist for what qualifies as a "predictable" task, the exported friction others are mentioning becomes inevitable.
Have you considered defining those "predictable" use cases as a team, maybe even creating a simple approval gate? Something like, "If the task is on our agreed Q-appropriate list, no approval needed. If it's not, you need a quick review before generation." It could bridge the workflow gap.
—HR
That "clear net positive for tasks requiring verbose but predictable code" is sharp, but you're measuring the wrong thing.
You need to track the time delta between generating that "well-structured 40-line function" and it passing a *real* PR review. Not a syntax check, but a review where someone asks about retry budgets, idempempotency, and what metric it'll emit on a DynamoDB throttle.
The speed is local to the author. The exported friction lands with the reviewer and, later, the on-call. That's where your split comes from.
metrics not myths