When a code audit with AI is repeated every so often, a practical problem appears: the agent flags things you already knew about and had decided not to touch. If you do not record that decision, every audit reopens the same debate.
What an Edge Case Is
An edge case (corner case) is a behavior that affects a very small corner of real usage. To know whether something is one, you need to cross the finding with usage data: how many requests that endpoint receives, how many users go through that action, how often. Without those metrics, saying "this is an edge case" is just an opinion, and opinions should not carry priority in an audit: what they carry is an experiment.
Recording What You Will Not Fix
An audit does not end with the list of what you fix; it must also record what you decide not to fix and why. A good record includes, for each finding, whether it was fixed, whether it was dismissed and with what justification, and when it is worth reviewing.
In the next round, the audit should start from that previous document. The agent is asked to read it, not to propose again what was already dismissed unless the context has changed, and to point out what is new. That way the work accumulates instead of starting from scratch.
History as a Source
Besides the audit record, the repository holds a lot of useful information: commits, design decisions and the patterns you want to follow or avoid. Documenting them in a project documentation folder gives the agent context to interpret each finding better. Documentation is incremental work: start with what helps the agent make decisions the most and do not try to document everything at once, just as you do not go from zero to a high test-coverage threshold in a day.
Variability Is Normal
If you repeat an audit several times you will see different lists, with different order and wording. That is normal: a model generates the most probable answer on each run. What matters is that, overall, the most important findings always appear, and that when you move from one list to another with your own criteria, the resulting roadmap works as a source of truth. By comparing several rounds you can even write your criteria down as a specification and reduce the variability.
Quick Summary
Define an edge case with usage data, not intuition. Record what you fix and what you dismiss, and make the next audit start from that record. Accumulate the criteria in documentation and specifications.