AI Debt Calculator

The output is only as honest as the six answers, and four of them are estimates that people reliably get wrong in the same direction. Volume and acceptance rate get guessed low, because nobody counts the suggestions they took without thinking. Review thoroughness gets picked one level above what actually happens on a Friday afternoon with a release pending. Coverage of AI code gets confused with overall repository coverage, which is a friendlier number.

A few things make the inputs sturdier. Answer for the last month, not for how the team intends to work. Pick the review level that describes your median pull request rather than your best one - if any meaningful share of AI-generated code merges on a quick scan, that is the level you are operating at. For test coverage, look specifically at the modules where AI assistance is heaviest rather than at the repository total, because those are usually the newest files and the ones least likely to have been backfilled with tests.

It is worth answering as a group, because the argument is more informative than the score. When a tech lead says review is thorough and three engineers say it is basic, you have learned something no calculator was going to tell you. Write down what you settle on, including the disagreement, so the next run has something to compare against.

Monthly suits a team actively changing its practices; quarterly is enough for one that is not. Re-run it immediately after anything that alters the inputs: a new assistant rolled out, a review policy changed, several people joining or leaving. More often than monthly mostly measures how you felt on the day you filled in the form.

Record the six inputs every time, not only the resulting score. A score on its own is unreadable three months later, because two teams can arrive at the same number by opposite routes - one with heavy AI use and disciplined review, one with light AI use and no review at all - and those two teams need opposite fixes. The inputs tell you which factor moved. The score just tells you that something did.

Keep the estimator stable. Have the same person or the same group answer each time, working from the same interpretation of what "thorough" means, and note it in your record when that changes. A consistent bias is harmless because it cancels out across runs; a bias that drifts quietly turns a real improvement into a flat line, or invents one that never happened.

Change one thing at a time between runs. Tightening review standards and mandating coverage on AI-heavy modules in the same month leaves you unable to say which one paid. Expect movement to be slow, too: the bands are deliberately wide, so drops inside a band are the real signal, and a team waiting for the band label to change before claiming progress usually gives up first.

A score can also rise with no change in behavior, because time under AI adoption is one of the weighted factors. That is intentional. Holding your practices constant while AI-assisted code keeps accumulating is not a neutral position, and a flat process against a rising score is exactly the picture that should prompt action.

One thing to avoid entirely: do not attach this score to a performance review or a team goal. Every input is self-reported, and the quickest way to move a self-reported number is to change the reporting rather than the practice.