The code coverage data does not keep the source code. Instead, it keeps a reference to the code that the reader saw (when called from compile-file). When it adds colors, it re-reads the source file. That means it needs the original source file for coloring. If the source file was modified, it adds a warning in the beginning of the file, but tries to color it anyway.
If what the reader sees has not changed (that is the only changes involve only comments and whitespace) the coloring will work properly. Changes to what the reader sees, however, will confuse the coloring. In general, subforms that are modified are miscolored, but code outside the modified subform colors properly. For a top level form, if you modify it, this form will not color properly, but all the other forms will color properly. If you remove or add a top level form, all the following forms will not color properly. Note that this applies even if you do something like adding (or removing) a progn around some forms, which although it does not affect the compiler does cause the reader to see different forms.
Thus if you modify your code, the coloring becomes less reliable. In most cases this is not a big problem, but in many cases it is probably better to copy your source tree and compile the copy with code coverage, so you can continue to modify the source while reviewing the code coverage output.
LispWorks User Guide and Reference Manual - 20 Sep 2017