Code quality | Blog

~/blog/series/code-quality

Code quality

How to find out whether what the agent wrote is any good, with instruments that do not flatter it.

What this series is about

Generation got cheap. Checking did not, and most of the instruments people reach for were designed for code a human had already thought about.

That is the thread running through these posts. Coverage tells you a line ran, not that anything would notice if it broke. A duplication report scores AI code well because the matchers count tokens and agents produce near-clones rather than copies. Complexity comes out roughly level while the shape underneath changes. Every one of these numbers can improve while the codebase gets worse, and each post here works out where a particular instrument stops telling the truth.

What survives is unglamorous. Mutation testing, because it asks whether a test would fail. Churn, because it is the one signal that shows up before anyone complains. A frozen task set and a scorer with no taste, when the question is whether a model change made things worse. A baseline committed to the repository that grandfathers what exists and refuses what the agent just added.

The posts are ordered so the diagnoses come before the treatments. If you only want the argument for why this matters at all, that lives in the ai-quality guide. This series is the working half.

Where this is going

The gap I still want to close is measurement over time rather than per pull request. Every metric here is honest about one change and noisy about one week, and the useful version of this work is a trend line you can leave running. That is the next post I would like to write, and it needs a longer stretch of real data than I currently have.