Generative AI Leader Practice Question: Evaluating ROI for a GenAI-based code review…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Number of reviews completed per day and lines of code written

  Why it's wrong here

  Review counts and lines written measure volume only, ignoring defect detection or rework, so quality improvement is unmeasured. These suit tracking raw throughput in a delivery dashboard, but a code review assistant's value lies in catching issues, which this pair cannot show.

• ✗

  Model inference latency and cost per token

  Why it's wrong here

  Latency and cost per token measure operational efficiency of the model, not whether reviews improved productivity or code quality. These metrics suit capacity planning and infrastructure budgeting, but they capture no developer output or defect reduction, so they cannot evidence ROI for a review assistant.

• ✗

  Developer satisfaction score and reduction in code churn (percentage of code rewritten)

  Why it's wrong here

  Satisfaction and churn capture perceived experience and rework, but neither directly measures review throughput or defect detection, so productivity gains stay invisible. This pairing suits assessing developer experience programmes, not quantifying a review assistant's combined output and quality return.

• ✓

  Time saved per code review and bug detection rate (percentage of bugs caught before deployment)

  Why this is correct

  Time saved per code review quantifies productivity gains, while bug detection rate before deployment measures quality improvement. Together they capture both dimensions of ROI for a GenAI code review assistant, unlike single-axis metrics such as suggestion count or developer satisfaction.

Go deeper

Related to this question