I Tried Obfuscating Java Code for AI — Here's What Broke
An attempt to obfuscate Java code before sending it to AI exposed how deeply Spring Data, JPA, and Lombok depend on identifier names.
When a client contract banned AI assistants from touching the codebase, a developer tried an obvious workaround: hash-rename every Java identifier before sending code to an AI, then reverse the mapping afterward. What looked like a two-day script turned into a month-long project, because in real Java frameworks, names carry meaning far beyond simple labels.
The failures piled up in layers. Spring Data repository methods like findByActiveTrue actually generate SQL from the method name itself, so renaming them crashes the app at startup. JPQL queries reference entity class and field names directly, while native SQL queries must keep table and column names untouched. Lombok generates getters and setters from field names at compile time, meaning a rename has to cascade through every call site in the project. Add Jackson's JSON key mapping, Bean Validation's field-name-based messages, @ConfigurationProperties YAML bindings, reflection strings, and OpenAPI schema generation, and the author ended up writing eight separate framework detectors.
The working solution flipped the approach: scan the project for framework annotations and conventions first, generate exclusion rules per framework, and only then run identifier collection and renaming through a JavaParser AST. The takeaway is that obfuscating Java code for AI isn't a string-replacement problem — it's fundamentally a framework-awareness problem.