OpenRewrite is one of the most powerful tools for automated code transformations, yet we still hear a lot of misconceptions about what it does and how it works. Some of these misunderstandings can hold teams back from taking full advantage of the platform, so we’re here to set the record straight.
Below, we break down the most common myths we hear, explain why they’re inaccurate, and share what’s really true about OpenRewrite.
Myth 1: OpenRewrite is just a code formatter
Reality: OpenRewrite can reformat code, but it is primarily a platform for semantic code transformations. It parses code into a Lossless Semantic Tree (LST) and can thus make deep structural changes across entire codebases.
Code formatters are designed to standardize the way your code looks, such as putting braces on new lines, using tabs versus spaces, setting indentation style, and so on. While OpenRewrite can absolutely handle formatting, it goes far beyond that.
OpenRewrite parses code into a Lossless Semantic Tree (LST) format so it knows as much about your code as a compiler, and then some. That means it’s able to make more complicated changes to your code, whether cosmetic, syntactic, or semantic. It can automate changes you’d otherwise spend weeks or months making by hand.
Formatting is just one set of recipes among thousands. The platform’s real strength is its ability to apply consistent, semantic changes across your codebase, all while preserving the existing style and conventions of your projects.
Myth 2: OpenRewrite requires a code formatter
Reality: OpenRewrite detects your project’s style and automatically respects it, including curly brace placement, indentation, whitespace, and other formatting preferences.
On the flip side, another common misunderstanding is that OpenRewrite depends on a third-party code formatter (like Prettier or IntelliJ) to clean up the changes it makes. In fact, you don’t need a code formatter at all to use OpenRewrite, since it automatically detects your project’s style and respects it.
This means you don’t have to reformat your entire codebase just to run a recipe. Every change OpenRewrite makes blends seamlessly with your existing code style, so you won’t be left with messy diffs.
Myth 3: You need to write your own recipes to use it
Reality: OpenRewrite is “batteries included” with thousands of prebuilt recipes for common use cases such as framework upgrades, API deprecations, and code cleanups. These recipes can be run out of the box without writing custom code.
There’s no requirement to start from scratch. OpenRewrite includes thousands of prebuilt recipes that cover a wide range of scenarios: upgrading Java or Spring versions, patching vulnerabilities, updating build configurations, and much more.
You can run these recipes out of the box, as-is. If you want more control, you can parameterize or combine existing recipes using YAML or the Moderne Recipe Builder. Many recipes also already offer parameterization so you can take advantage of useful functionality like changing types, or renaming methods.
Of course, you can write your own custom recipes, but for most teams, the included recipes provide more than enough to start getting value immediately.
Myth 4: It might break my code or run unsafe transformations
Reality: Recipes are deterministic, reviewed, and built with a “do no harm” philosophy, meaning they make the same change every time they run and are designed to avoid risky transformations. They can also be previewed in full before merging, and offer tools like the verify compilation recipe to add extra safeguards.
OpenRewrite recipes are deterministic and predictable: they make the same change every time they run. When you run a recipe, you can preview every single change in a structured diff before committing it. If something doesn’t look right, you can roll it back. Plus, since they can be combined and chained together, recipes also typically focus on only making precise, narrowly scoped edits instead of sweeping, risky transformations. This makes it much easier to review and trust their output.
That said, recipes are still written by humans. Just like any other code, they can occasionally have gaps in coverage. This is why some teams treat OpenRewrite as a way to automate the vast majority of a transformation (often 80% or more) while leaving rare exceptions to handle manually.
But, a core principle of OpenRewrite is do no harm. Particularly recipes in the official org.openrewrite and io.moderne namespaces are carefully authored and reviewed with this in mind. Most are open source or source-available, so you can inspect exactly what they do.
OpenRewrite also provides tools like the verify compilation recipe, which can check whether your code still compiles after changes. Over time, safeguards like this are becoming built-in to recipe runs by default.
The bottom line: recipes are written with safety in mind and generally won’t break your code. But like any automation, it’s wise to review changes, especially if you’re making a big transformation across a large codebase.
Myth 5: It only works with Java projects
Reality: Java is where OpenRewrite started, but it has expanded to become a multi-language transformation platform that supports Java, Groovy, Kotlin, XML, YAML, C#, JavaScript, and TypeScript, with more language support planned for the future.
OpenRewrite was originally built primarily with Java code and supporting technologies (like Maven and Gradle) in mind, but it has evolved into a multi-language transformation platform. In addition to Java, it now supports Groovy and Kotlin, plus configuration like XML, YAML, and properties files. There is also growing support for C# as well as JavaScript and TypeScript.
More language support will continue to be added over time—including the ability to write recipes in those languages—so OpenRewrite can automate changes across the full surface area of a modern codebase, not just the Java parts.
Myth 6: OpenRewrite uses reflection or runs code to make decisions
Reality: OpenRewrite analyzes source code and does not execute your application code, instead relying primarily on compiler APIs to analyze code structures deterministically.
There’s a perception that OpenRewrite relies heavily on reflection, the Java APIs that allow code to inspect classes and methods at runtime. That’s not the case. Reflection isn’t a core part of how OpenRewrite works, though it may occasionally be used internally alongside other techniques.
Recipes themselves are indeed just programs, so in theory they could do anything a normal program can. But in practice, recipes are deterministic and don’t execute your application code. They analyze your source code to determine changes rather than running it.
Myth 7: If it pulls old libraries, my app will be vulnerable
Reality: OpenRewrite never introduces executable code from older libraries because it only uses them for extracting type signatures, such as method names and parameters, so it can apply safe upgrades to your code. These stripped-down definitions are never executed and pose no security risk.
Some recipes need type signatures from older library versions in order to understand what they’re upgrading you away from. When this happens, OpenRewrite extracts only the type information it needs (method names, parameters, class hierarchies, etc.) and discards the actual implementations.
These stripped-down definitions are never executed and never become part of your application. This is a common false positive reported by security scanners, but there’s no risk to your application. They exist solely so the recipe can understand how to safely refactor your code.
Myth 8: OpenRewrite is only for upgrades
Reality: OpenRewrite supports upgrades along with a wide variety of use cases, including enforcing code standards, performing framework migrations, fixing vulnerable dependencies, removing feature flags, cleaning up dead code, and much more.
Yes, OpenRewrite is widely used for upgrading Java or Spring versions, but it’s just as useful for:
- Enforcing code style and standards
- Removing deprecated APIs and dead code
- Cleaning up anti-patterns
- Phasing out feature flags
- Modifying infrastructure automation (e.g. updating Terraform configurations or right-sizing Kubernetes manifests)
- Switching between libraries, frameworks, or even vendors (e.g. Oracle to Postgres)
- Moving from on-prem to the cloud or across clouds (e.g. AWS to Azure)
- Producing data tables to gain insights about your code
Once you start thinking of OpenRewrite as a tool for ongoing code health, you’ll find dozens of ways to use it.
Myth 9: Large refactors are impossible without a monorepo
Reality: OpenRewrite, in conjunction with the Moderne platform, can consistently apply large-scale changes across hundreds or thousands of repositories without requiring a monorepo.
In the past, large refactors were easier in a monorepo because you could make one change and instantly propagate it everywhere. But most enterprises don’t have monorepos, they have hundreds or thousands of repositories.
OpenRewrite with the Moderne platform makes it possible to run consistent, large-scale transformations across all of those repositories at once. This levels the playing field, so you don’t need to reorganize your entire development model just to keep up with necessary changes.
Myth 10: OpenRewrite can’t upgrade internal libraries or frameworks
Reality: OpenRewrite can upgrade internal frameworks just as easily as external ones, and many large enterprises are using it to update both their internal and external libraries.
OpenRewrite isn’t limited to external dependencies like Spring or Jackson. Recipes can be written or adapted to update your in-house libraries, frameworks, and coding patterns as well.
Many large enterprises rely on OpenRewrite specifically for this purpose: to standardize internal libraries and eliminate drift across all of their repositories.
Myth 11: It rewrites everything at once without control
Reality: OpenRewrite gives you fine-grained control over which recipes run and where they run, allowing you to scope runs to specific repositories or directories and review every change before merging.
OpenRewrite gives you full control to determine which recipes to run and where to apply them. You can scope a recipe to a single repository, a specific directory, or even a subset of files. You can also preview every change and decide which updates to merge.
For enterprises with thousands of repositories, the Moderne platform makes this even easier. It allows you to run recipes across all your code repositories at once and review the results in a consistent, centralized workflow before committing any changes.
Myth 12: You have to check every line of code changed
Reality: OpenRewrite applies changes predictably, so you can review them at a higher level by validating the recipe logic and spot-checking diffs, saving time compared to line-by-line review.
Because changes are applied in a predictable, structured way, you can review OpenRewrite runs at a higher level. Instead of manually checking every single line, you can review the recipe itself and spot-check the diff.
This is a huge time-saver compared to manual refactoring, where every line needs careful human review.
Myth 13: You only run recipes once
Reality: OpenRewrite is most valuable when integrated into ongoing workflows that run recipes regularly or through CI/CD pipelines to continuously enforce standards, manage technical debt, and apply fixes.
Many teams run recipes weekly or integrate them into CI/CD pipelines. This allows them to continuously enforce coding standards, clean up technical debt, and apply security fixes before they become problems.
Treating OpenRewrite only as a one-time “big bang” upgrade misses a lot of its value. The platform shines when it becomes part of your regular development workflow.
Myth 14: OpenRewrite uses AI to make changes
Reality: OpenRewrite recipes are deterministic and don’t rely on AI for decision-making, so you always know what changes are being made.
Most recipes are human-authored (though some authors are now using coding assistants to help write them) and make the same predictable change every time they run. It’s not typical for recipes to involve AI.
There are a handful of recipes in the catalog that leverage AI models for very specific use cases, like repairing corrupted text in comments, but these only run if you explicitly configure them. If a recipe does require an external AI service, you’ll be asked to provide an API key first. You’ll never unknowingly run a recipe that calls out to an LLM.
Moddy, Moderne’s multi-repo AI agent, for example, can use AI to help developers discover and interact with recipes, but the underlying recipes themselves still apply deterministic, reviewable code transformations.
Myth 15: OpenRewrite competes with AI technologies
Reality: OpenRewrite and AI complement each other—AI can help suggest or draft recipes, while OpenRewrite provides the deterministic framework for safely applying the changes.
Large language models (LLMs) are great for generating recipe code or suggesting refactorings, but they can’t safely rewrite entire codebases by themselves. OpenRewrite provides the deterministic foundation for applying changes at scale, with the ability to review and test every transformation.
Rather than competing, AI and OpenRewrite work best together. AI can help suggest or draft recipes, while OpenRewrite applies them safely and consistently.
Myth 16: “AI will do it all”
Reality: AI is helpful, but human judgment and deterministic tooling like OpenRewrite are still essential to reduce risk when modifying code at scale, particularly when it’s critical to your business.
AI coding assistants can help guide you on which recipes might be helpful to run or get you started writing recipes, but they can’t fully parse and rewrite complex, multi-language codebases on their own.
OpenRewrite is the tool that actually identifies and modifies code in a structured, testable way. It provides the framework to safely apply those changes at scale and with human oversight.
Think of it this way: AI can help you decide which recipes to run or how to write them. OpenRewrite finds and applies the changes, lets you review the results, and ensures you can trust the outcome.
The bottom line
OpenRewrite isn’t just a code formatter. It isn’t risky, and it isn’t only for upgrades. It’s a proven way to safely automate code changes at scale across multiple languages, frameworks, and repositories.
If you want cleaner, more consistent, and more maintainable code without endless manual refactoring, OpenRewrite is the most effective tool for the job.
