Annotation processors currently can only produce new source code files, so it is not possible to modify existing files. This is a drawback, as it makes many use cases of annotation processing at compile time rather impossible or at least very complex.

If annotation processor would be allowed to modify the AST, they could be very useful in a lots of cases, just to name an single one:

Example: auto-final. Java source code by default is non-final, while it is a good practice for have all code final by default. As a result, source code must be cluttered with lots of final keywords in many places. If annotation processors would be allowed to modify the AST, then they simply could add the FINAL Modifier on all locations inside of a package annotated by e. g. @AutoFinal, and remove Modifier.FINAL on all elements annotated by e. g. @NonFinal. As the modification happens in the AST, the compiled result would not be larger or slower than the original source code, hence leading to optimal performance at runtime. Hence, AST modification is a performance enabler, since neither factories nor proxies are needed at runtime!

Effectively allowing to modify the AST is the sole missing brick to turn annotation processors into really broadly useful cross-vendor compiler plugins, and many tool and library vendors could get rid of their current use of tricks and hacks (e. g. Lombok).