Measuring the Percentage of Code Written by AI: Generated Lines Versus Shipped Changes
See where each measure falls short, how to keep attribution consistent, and why a percentage cannot stand in for code review.
You can count lines an AI tool generated, or you can track AI-assisted changes that survived review and shipped. To measure the percentage of code written by AI, choose based on what you need to learn: how much text the tool produced, or how much of your finished work it helped deliver. Those numbers can diverge when you rewrite, discard, or substantially edit a suggestion.
Vibe coding makes this distinction worth understanding. You guide an AI tool in natural language, inspect what it produces, and keep iterating toward a working product. The tool can produce a lot of code without making every generated line useful or safe to ship.
Generated lines versus shipped changes at a glance
Both measures need a defined scope. Generated lines count the AI tool's initial output, while shipped changes count completed work where AI contributed to the implementation. Pick one repository and one period of work before counting, then apply the same boundary to the numerator and denominator.
| Criterion | Generated lines | Shipped changes |
|---|---|---|
| What you count | Lines initially produced by an AI tool | Completed changes where AI contributed to the implementation |
| What the result tells you | How much code generation occurred | How much finished work involved AI |
| Main blind spot | Discarded output can inflate the figure | One tiny fix and one substantial feature can count equally |
| Recording effort | Requires a way to preserve output before edits | Requires a brief record of how each change was made |
| Best fit | A narrow question about generated code volume | A question about your build workflow |
Neither column measures code quality. A change can be AI-assisted and well tested, or entirely hand-written and broken. Keep review and testing separate from attribution.
When counting generated lines helps
A generated-line percentage is the closer answer to a literal question about who produced the initial code text. For a small experiment, you could save the tool's initial output, count its code lines, and compare them with all new code lines produced during the same period. State whether rewritten and deleted lines remain in your count. Without that rule, two people can report different figures for the same build.
The method becomes harder to interpret across a whole project. A large generated component may be replaced before release. A short AI suggestion might lead you to write a much better implementation yourself. Copying code between files can also make reused code look like new work. Use this measure when you can observe the output and care specifically about generation volume, not when you need a shortcut for judging the finished product.
When tracking shipped changes helps
A shipped-change measure starts with work you actually kept. For each completed fix or feature, note whether AI generated an implementation, helped revise one, or only helped you think through the problem. Then count the changes with implementation help against all completed changes in your chosen period. Keep the categories consistent so an explanatory ChatGPT answer is not silently counted as code generation in one session and excluded in another.
This approach fits a solo builder returning to a project after a few days away. A note such as “AI drafted the invite form; I revised validation and tested duplicate submissions” preserves more context than a bare percentage. Its weakness is that changes differ in size, so report it as a share of changes, not as a literal share of code lines. If the distinction matters, record both measures instead of blending them into one number.
Choose the measure that matches your next decision
Use generated lines if you are examining how much initial code your tool produces. Use shipped changes if you want to understand how AI fits into the work you keep. For most day-to-day build decisions, the second record gives you something you can act on: which changes need another review, which decisions need explanation, and where a useful prompt is worth saving.
If you do report a percentage, include its counting rule beside it. “AI contributed to completed changes” and “AI produced initial lines” are different claims. Read public vibe coding statistics the same way, noting how each source defined AI use and who answered. None of these figures tells you whether you checked auth, validated database writes, or understood a diff before deployment.
For a separate check before shipping, use this guide to testing AI-generated code safely.
Keep the useful history after the count
A percentage cannot tell you why you rejected an implementation or which prompt finally fixed a stubborn bug. Save those details while they are fresh, along with the next action for the project. That small record makes the measurement useful when you resume building.
Keep your build decisions and prompts in VibeCrumbs so the context behind your shipped changes stays available.