If you maintain anything, even a small thing, the most useful story from the kernel tree this week is not a policy debate. It is a quiet file deletion that tells you exactly what is about to happen to your own backlog. The driver that got removed was not the story. The reason it got removed was the story, and the reason applies to every project that AI tools are starting to scan.
This piece is written for the maintainer of a small to mid size project. I am going to argue that the AI audit era makes a specific housekeeping chore worth doing now, while the cost is still measured in hours instead of weeks.
The shift underneath the headlines
For a long time, the only thing scanning your codebase at scale was CI and the occasional security researcher with a vendored grep. AI coding agents changed that. They are trained to flag patterns, anomalies, and suspicious constructs, and they do it across your entire tree in a single pass. They surface real bugs. They also surface a much larger category of patterns that look like bugs but were never problems because the code they live in never ran in production.
That second category is the one that costs you. Every report has to be triaged. The triage takes longer than the fix would have, and the fix is rarely worth doing. Multiply the triage by every small maintainer who suddenly has an AI auditor on their backlog and you get a slow, distributed tax on every project in your language’s ecosystem.
The good news is that the tax is avoidable. You just have to do the cleanup work before the auditor does, on your own terms, instead of theirs.
What “alive” means to an auditor
AI tools see text. They do not see the issue tracker, the deployment history, the deprecation notices in last year’s release notes, or the private conversation where the team decided to abandon the feature. To an auditor, every line of code is equally interesting, and every missing test is equally suspicious.
That gap is the whole problem. The auditor is not wrong about what it finds. It is wrong about what it does not know, which is the status of the file. The maintainer knows the file is dormant on purpose because they stopped shipping it two years ago. The auditor cannot know that, so it files a finding.
A maintainer who classifies files explicitly closes that gap. A one line status comment, a directory rename, a CI lint rule, any of these moves turn the auditor’s open question into a closed one. The auditor’s report gets shorter, and your triage time drops accordingly.
Three housekeeping moves that pay off this quarter
Here are three moves I would actually make, ordered by effort and impact.
First, write a maintainer’s index. Open a new file in your repo called MAINTENANCE.md or add a section to your contributing guide. In it, list every file or directory that is dormant on purpose, with a one sentence reason. Future contributors will read it. Future auditors will not, but the humans triaging their reports will, and that is the bottleneck.
Second, label dormant files at the top. For any file you intend to keep but not maintain, add a one line comment near the top in a format a grep can find, such as # status: dormant - see MAINTENANCE.md. The label does not have to be pretty. It has to be findable, and it has to point at the index.
Third, move genuinely abandoned code to an archive branch or a legacy/ directory. Rename if you have to. Update the top level README so anyone browsing the repo sees the boundary. Archive labels do not stop auditors today, but they do stop humans from accidentally reviving dead code during a refactor, and that is the failure mode that wastes the most review time.
The point of all three is the same. Make the status of code legible at a glance, so neither humans nor machines have to guess.
What the auditor finds when you do this well
Once you have labeled what is dormant, the auditor’s findings start to cluster in the right places. A flagged pattern in a file marked status: dormant is something you can close in thirty seconds with a one line reply pointing at the maintenance index. A flagged pattern in the active code is something you should fix.
That is the real payoff. Not fewer findings. Faster triage. The auditor still scans the whole tree, but the part of the tree that is supposed to be quiet is now visibly quiet, and the part that is supposed to be clean is the only part left to clean.
I have seen projects with a healthy review velocity and clear dormancy labels get a measurable drop in triage time after a few months of upkeep. I have also seen projects with no labels at all get buried in findings that no one has time to triage. The difference is not how much code they have. The difference is whether they told the auditor what the code is for.
A short checklist for your next sprint
If you have an afternoon and want to make your codebase cheaper to audit, here is the order I would use.
- Inventory files that have not been edited in five years and are not referenced in CI or the README
- Inventory features, flags, and environment variables that have not appeared in issues or commits in the same window
- For each candidate, ask whether deleting it costs any user a feature. If no, delete or archive
- For what stays, add a one line status note so the next reviewer can see the dormancy at a glance
- Write a one paragraph “what is dormant here and why” in your contributing guide
The auditor will not thank you. The next volunteer to maintain the project after you will. That is the only review that matters on this kind of work.
Trade-offs
The trade off is honesty. If you remove a feature, someone, somewhere, may still depend on it and you will never know. If you mark something dormant, you have to keep that label accurate, and a stale label is worse than no label because it tells the next reviewer a lie. The smaller trade off is reputational: removing public surface area feels like losing capability, even when the capability has been dead for years. The right answer is still to remove it, but expect some users to push back, and have a one sentence answer ready.
A narrower trade off worth naming: scoped AI rules on driver code are good for kernel quality and bad for contributors who relied on AI to draft those patches. That tension will show up in subsystem maintainer workloads over the next few release cycles. If you maintain anything, write the policy now, before the tension shows up in your own queue.
Coach’s note
Audit your own dead code before an LLM does it for you. Delete what is truly gone. Document what is dormant on purpose. Your future self, and the volunteer who maintains the project after you, will thank you. That is the only move that scales.