Code Generation Acceptance

Name the acceptance event

Acceptance can occur at several points. A developer may insert an inline completion, apply a proposed patch, approve a pull request, or merge reviewed code. These events answer different questions and should not share an unlabeled percentage.

GitHub's Copilot metrics documentation treats suggestion acceptance as a usage measure and reports pull request lifecycle activity separately. Accepting code in an editor does not establish that it was committed, deployed, or retained after review.

Before calculating a rate, identify the surface and unit: suggestion events, lines, patches, or pull requests. Specify whether partially accepted suggestions count and whether the denominator includes suggestions that were generated but never shown. Record the available telemetry rather than assuming every tool exposes equivalent events.

Calculate with a consistent denominator

For an event-based measure, use:

Acceptance rate = accepted suggestion events / eligible displayed suggestion events × 100.

In a hypothetical week, an editor shows 1,000 suggestions and developers accept 350. The event acceptance rate is 35%. If those accepted events insert 1,400 lines, that line count is a separate measure. Dividing accepted lines by displayed events would mix units and produce an uninterpretable rate.

Suppose a review of the resulting changes later finds that some inserted code was rewritten before merge. That does not retroactively erase the editor acceptance events. It establishes a second observation about retention or rework. Link the stages where reliable identifiers allow it, and state when the connection is estimated.

When comparing teams, aggregate accepted and eligible event totals before calculating the overall percentage. A simple average of team percentages gives a team with ten suggestions the same influence as a team with ten thousand suggestions.

Interpret the rate in context

A higher rate may indicate useful suggestions, but it may also reflect repetitive tasks, different suggestion lengths, or a less selective review habit. A lower rate might occur because a developer asks an agent to explore alternatives and intentionally keeps only one. The rate alone cannot explain these behaviors.

Compare similar languages, tasks, tool modes, and time periods. Changes in telemetry coverage or product behavior can alter the metric even when developer preferences remain stable. Annotate those changes rather than attributing every movement to model quality.

Follow accepted code through review

Use acceptance to investigate relevance at the point of interaction. Use tests, review, and later outcomes to investigate quality. Google's review guidance covers functionality, design, complexity, tests, and documentation, all of which extend beyond a developer choosing to insert a suggestion.

For an adoption pilot, report acceptance alongside completed work, correction effort, and defects during a stated observation window. Do not set an acceptance quota for individuals. Keeping an unsuitable suggestion to improve a dashboard number creates work rather than demonstrating value.