What issues can Lombok cause with static code analysis tools?

Static analysis tools that operate on source code (rather than compiled bytecode) may not understand Lombok's annotations at all, and so analyze the class as if the generated methods simply don't exist — this can produce both false positives (flagging a field as "never read" when it actually is, via a Lombok-generated getter) and false negatives (missing a real bug inside logic that only exists after Lombok's generation, since the tool never sees it).

//  a source-based analyzer might flag `email` as unused,
//  not realizing @Getter/@Setter generate real accessors for it
@Getter @Setter
private String email;

The fix generally depends on the specific tool: many mainstream static analysis tools (SonarQube, Checkstyle, PMD, certain IDE inspections) have added explicit Lombok awareness over time, either natively or via a plugin, so this has become less of a problem than it once was — but a lesser-known or in-house tool that only parses raw source may still need this pointed out or configured for, and coverage tools measuring line coverage can also misreport results for Lombok-generated code that technically has no corresponding source lines to mark as covered.