OpenRewrite recipes: deterministic, type-aware code change at scale

Recipes are like keys fit to a business problem “lock”.

A change you need to make across a codebase has a precise shape. You have to find that exact pattern in the source and rewrite it.

A recipe is the key cut to fit it. It’s a deterministic program that walks the code, recognizes that shape, and rewrites it the same way every run.

Recipes are like keys fit to a business problem “lock”.

Think about a simple problem. An agent can cut this key on the fly with a grep and an edit. We see this happen all the time.

Recipes are like keys fit to a business problem “lock”.

But it’s never just that one lock. The same change is waiting in every repository you own, hundreds of identical locks.

Recipes are like keys fit to a business problem “lock”.

Instead of having an LLM rediscover the shape over and over again, it cuts a “key” once. A recipe is that one key, that can then unlock every matching lock.

Recipes are like keys fit to a business problem “lock”.

But many business problems are more complex. The JUnit 4 to 5 migration is hundreds of coordinated steps. Annotations, imports, assertion signatures, lifecycle hooks, and much more all need updating.

We know our agents are capable of one-shotting these kinds of changes. Much less certain is whether they will chase down every occurrence. When the change needs to touch a lot of files, they typically don’t.

Recipes are like keys fit to a business problem “lock”.

The same migration waits in every repository. So even if we could consistently one-shot the migration in every repository, it would involve a wasteful rediscovery and application of the same “key” over and over again.

Recipes are like keys fit to a business problem “lock”.

An agent making the change on many independent repositories will get some of them right. And some of them won’t be, but compilation and tests alone won’t catch the gaps.

Working on one repository doesn’t carry over to the next. There is no herd safety.

Recipes are like keys fit to a business problem “lock”.

Alternatively, an agent writes a recipe once. It thinks of all the edge cases and encodes those as unit tests. The feedback loop is initially between the agent and the unit tests for the recipe.

As the recipe gets tested on repositories, edge cases are discovered and the recipe gets tighter. The act of applying the recipe to many repositories bestows herd safety to changes on any one.

Recipes are like keys fit to a business problem “lock”.

The validated recipe drops into every matching lock and turns it identically, every run.

In many enterprise organizations, these kinds of changes need to happen on not just dozens but thousands or even hundreds of thousands of repositories. Because the recipe is a deterministic program, the outcome is predictable, and you’re not burning tokens making the same kinds of changes over and over again against each repository.

scroll↓

What a recipe is↓

A recipe is a program shaped to the problem.

A recipe is a deterministic, composable program. It walks a Lossless Semantic Tree of the code, recognizes an exact target by its resolved type (not just its text) and rewrites it precisely. The business problem is a lock and the recipe is the key cut to fit it.

Recipes compose. The Spring Boot 4 upgrade is over 4,000 recipes all composed together, with hundreds of preconditions deciding where each step applies.

The Moderne recipe builder with the Spring Boot 4 recipe open: a graph of several thousand connected recipe nodes on the left, and on the right a recipe list of 4,340 steps with 427 preconditions, headed by Migrate to Spring Boot 4.0, ready to dry run on 45,877 repositories.

A key already exists for many of the thorniest business problems in code.

The same lock repeats across an industry. So the catalog is broad on purpose. Thousands of small, sharp keys compose into composites, each fanning out into tens of thousands of sub-recipes in a single run.

Code quality 808

Spring 510

Modernize 448

Style 408

Migrate 342

Testing 320

Search 300

Security 207

10,000+ deterministic, type-aware recipes, spanning Java, Kotlin, C#, Go, Python and JavaScript, across 340+ frameworks and tools.

As it turns out, agents like writing recipes
rather than doing manual edits too.

Ask an engineer to do something 3 times and they’ll automate it! As it turns out, agents write scripts for just about everything too. They love writing new recipes. Filling out the OpenRewrite recipe marketplace used to be a manual lift of a whole community.

When an agent writes a recipe and its unit tests and then tests it, it’s like setting a ratchet strap. With every additional edge case that gets discovered, added, and tested, the ratchet strap tightens. So the next time the agent is reaching for that change, it’s already got a tightened down highly calibrated tool to get the job done.

Agents also know that applying a recipe to a codebase means that it won’t miss any occurrences.

UseAppendLine.kt

val UseAppendLine: Recipe = recipe(
    displayName = "Use `appendLine()` instead of `appendln()`",
    description = "`Appendable.appendln()` was deprecated in Kotlin 1.4 in favor of `appendLine()` (consistent naming with `Reader.readLine()`).",
) {
    edit {
        rewrite { sb: StringBuilder -> sb.appendln() } to { sb -> sb.appendLine() }
    }
}

val UseAppendLineWithValue: Recipe = recipe(
    displayName = "Use `appendLine(value)` instead of `appendln(value)`",
    description = "`Appendable.appendln(value)` was deprecated in Kotlin 1.4 in favor of `appendLine(value)`.",
) {
    edit {
        rewrite { sb: StringBuilder, v: String -> sb.appendln(v) } to { sb, v -> sb.appendLine(v) }
    }
}

val UseAppendLineChar: Recipe = recipe(
    displayName = "Use `appendLine(char)` instead of `appendln(char)`",
    description = "`Appendable.appendln(value: Char)` was deprecated in Kotlin 1.4 in favor of `appendLine(value: Char)`.",
) {
    edit {
        rewrite { sb: StringBuilder, c: Char -> sb.appendln(c) } to { sb, c -> sb.appendLine(c) }
    }
}

A diff your engineers can actually trust.

Just like engineers like writing automations for repetitive tasks, we also tend to trust the outcome of an automation more than something done by hand.

Just ask any engineer that was around before immutable infrastructure patterns!

OrderServiceTest.java

-import org.junit.Test;-import static org.junit.Assert.assertEquals;+import org.junit.jupiter.api.Test;+import static org.junit.jupiter.api.Assertions.assertEquals; class OrderServiceTest { // totals must include tax @Test- public void calculatesTotal() {+ void calculatesTotal() { assertEquals(expected, order.total()); } }

Everything the recipe didn’t touch (imports, comments, whitespace) is byte-for-byte unchanged.

Related resources

Frequently asked questions

What is an OpenRewrite recipe?

A recipe is a deterministic program that traverses your code’s Lossless Semantic Tree (LST) using the visitor pattern: visiting each node, recognizing an exact target by its resolved type, and editing it precisely. The same input always produces the same result, with no AI hallucination in execution.

How is a recipe different from an AI agent editing code directly?

An agent editing source is a fresh guess on every run. It’s text-level, non-deterministic, and blind to type information across files. A recipe is authored once, validated, and then applies an identical, type-aware change every run, across any number of repositories. The agent’s job is to reach for (or write) the recipe, not to be the editor.

What languages and frameworks do recipes cover?

The open catalog holds 10,000+ recipes spanning Java, Kotlin, C#, Go, Python and JavaScript, across more than 340 frameworks and tools: Spring, Quarkus, Hibernate, JUnit, AssertJ, the major clouds, CVE patches and more.

Can I write my own recipes?

Yes. Recipes are authored three ways: declarative YAML that composes existing recipes into a named pipeline (no code), Refaster-style before/after templates the compiler verifies, or imperative Java visitors for full control over the LST.

Are recipe changes safe to merge?

Recipes produce format-preserving, minimal diffs. Imports, comments and whitespace they didn’t touch are unchanged, and the result is deterministic and identical every run. Engineers review a clean, trustworthy diff instead of a noisy, approximate one.

OpenRewrite recipes: deterministic, type-aware code change at scale

A recipe is a program shaped to the problem.

A key already exists for many of the thorniest business problems in code.

As it turns out, agents like writing recipes rather than doing manual edits too.

A diff your engineers can actually trust.

Related resources

Frequently asked questions

As it turns out, agents like writing recipes
rather than doing manual edits too.